What product management is

Being the heart, mind, and voice of the user

Facilitating cross-functional teamwork

Making product trade-offs

Meeting an end-goal with fixed time and resources

Leading people along a product journey

Being positive and practical

Making tough calls with little information

What product management is not

Being the most important voice

Being the only idea-generator

Being a designer

Being a programmer

Managing QA

Optimizing websites

Writing marketing collateral

How I know

I applied to be a product manager on a whim. I was a college senior at the time and was majoring in psychology. I desperately wanted to move back home to the Bay Area and to my dismay, the only dime-a-dozen jobs were all in tech. I started poring over job descriptions to find options that would make my major feel less laughable.

To my surprise, I was offered a position as a product management rotational associate at Intuit, a technologically and culturally amazing company. To my surprise because I didn’t really know what a product manager does. “Wow,” I thought as I read and reread my offer letter. “All I did in those interviews is talk about my passions. I wonder how that was enough.” To my surprise because my thesis was in psycholinguistics. Last I checked, the psychology of language has little to do with financial software.

My first product management role was for QuickBooks. I was responsible for managing the Beta of our annual release, and the experience encapsulates everything that surprised me about product management. Things that weren’t in any job description.

Here are the main four:

You’re not managing a product. You’re managing the problem it solves.

When I found out I was going to manage QuickBooks, I could have vomited. “QuickBooks?!” I scoffed. “That thing is older than my grandpa!” (This is not actually true, but when you live in the Silicon Valley and there are products being born every second, QuickBooks looks like Father Time.) I was disappointed that I would not get to do what a “real” product manager does and “innovate.” I wanted to manage a product that was young and sexy.

Oh, how wrong was I.

When you begin managing a product that has at least one customer, you quickly learn that your job is much larger than even the fullest-featured product. Your job is to deeply understand the problem that your product aims to solve then chase the moving goal of solving every nuance of that problem.

You will always have too many feature requests and too little time. Too many bugs and too little time. There are always things to do. When you have a mature product around which users have built habits and your company has built processes, you actually need to be extra innovative in order to successfully deal with all your constraints.

Being a product manager is about making compromises between what your team can accomplish within a given period of time and what your customers absolutely need. You will continually be torn between your team, customers, and business in an impossible race against time. The minor victory is in balancing short- and long-term product strategy, no matter if your product was conceived today or twenty years ago.

2. Your product is only as good as a user’s perception of it.

In running our Beta, I not only reached out to testers weekly via email, but also spoke to them over the phone, sometimes spending entire days providing tech support of sorts. At first, this came as a huge disappointment. Why am I responding to problems? I wondered. I’m supposed to be managing a product!

As I spent more time talking to customers and watching them use my product, I learned that what they said “wasn’t working,” really just wasn’t working the way they expected. The customer perception is reality, and it wasn’t my job to tell them what they were doing wrong. Instead, my conversations with customers helped me see what I was doing wrong. I took these insights back to my engineers and designers to brainstorm how we could make our features “work” for users.

In the end, spending hours and even days on end talking to customers saved my product. And saving it was good because to manage a product, you need to have a product.

3. Product Managers are neither designers nor engineers.

As a part of a submission to the Mac App Store, I was told I needed to design our sales page. Still new to the game, I took my assignment literally, submerging myself in Photoshop layers and color palettes. Giddy with the endorphin rush that accompanies creation, I emailed the page design to my manager. His response was not dripping with praise as I expected. Instead, it read,

Great. Did this come from our designer? I’d like us to push her on color scheme.

“Designer!?” I asked my computer. “What is he talking about?”

This is how I learned that, especially at a large healthy company, a product manager does not create visual designs. She also does not write code. Your designer is the design expert. Your engineer is the programming expert. And you, the product manager, are the expert on whether the design and functionality meet the specific user need at hand.

4. It’s not about being a star — It’s about managing a universe.

The first day of my role on the QuickBooks team, my manager took me around the office to introduce me to everyone — and I mean everyone — support, marketing, engineers, design, finance. It was overwhelming for me, but I was more concerned by how much time my manager was “wasting.” I wondered why he didn’t just start by introducing me to the other product managers. “I’m sure I can meet the rest of these people later,” I thought. More intimidating than the sheer number of people to whom he introduced me was the way in which he did it. “She’s going to be responsible for the QuickBooks launch,” he would tell them. I didn’t know how I was going to carry off this product launch when I hadn’t even downloaded QuickBooks on my computer.

As the weeks went by, it became clear that I would not be single-handedly releasing QuickBooks into the world the way you do doves at a graduation ceremony. Instead, my job was to facilitate the right brainstorms and conversations between all those groups I had met on my first day in order to arrive at decisions influencing the launch. It was eye-opening and slightly comforting (only slightly). I didn’t need to come up with the best idea in the room. I just needed to make sure that I got the right people in the room to foster a deluge of ideas from which I could select the best one.