So You Want to Manage a Product?
What no one tells you about the role.
By Rohini Venkatraman (Product Manager, Livefyre)
Is it just me or are there a lot of aspiring product managers out there? Maybe it’s just because I am one myself, but I feel like all I hear these days is that people — consultants, MBA candidates, engineers — want to be product managers.
If this is indeed true, that “everyone” wants to be a product manager, I’m not surprised.
The role sounds sweet on paper. It’s a role that doesn’t require expertise in any concrete skill. You don’t need to know how to create data models; you don’t need to know how to code; you don’t need to be able to design websites. It could help but it’s not necessary. Unlike becoming an engineer or a designer, you can conceivably wake up one morning as a product manager.
If you aren’t one or haven’t profoundly interacted with a product manager at work, product management is not what you think it is.
How I Know
A psychology major, I applied to be a product manager impulsively. Discussing only my passions in my interviews, I was surprised to receive a PM Associate role at Intuit. After all, I didn’t even know what a product manager does.
My first responsibility was to lead a QuickBooks Beta launch. The experience encapsulates everything that surprised me about product management. Things that weren’t in any job description.
Here are the main three:
1. You’re not managing a product. You’re managing the problem it solves.
When I learned of my assignment, I could have vomited. “QuickBooks?!” I scoffed. “That thing is old!” I wanted to do what a “real” product manager does and “innovate” something young and sexy.
Oh, how wrong was I.
When you manage a product that has at least one customer, you 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. 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 20 years ago.
2. Your product is only as good as a user’s perception of it.
In running our Beta, I emailed testers weekly and frequently spoke to them on the phone to provide tech support. At first, this came as a huge disappointment. I’d wonder, “Why am I responding to problems? 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 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 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.
For a sales page, I was told I needed to provide a design. I took my assignment literally, submerging myself in Photoshop layers. When I finally I sent my design to my manager, his response was not praise-filled 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 mature companies, 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.
Eight months ago, I joined Livefyre, a startup 80 times smaller than Intuit. I am still a product manager but a lot has changed including resources, internal tools, and physical proximity to my team. What hasn’t changed, however, is my responsibility to profoundly understand, effectively communicate, and successfully solve what my users need.
After three years of PMing, I’ve realized that those passions I stated during my first interview — deeply understanding humans, removing pain from their lives, writing, field-research, and finding data trends — were exactly what my interviewers were looking for, because that’s what it takes to be a successful product manager.
I had and have my set of ongoing worries as a product manager — feeling stupid when I talk to engineers, wishing I could design websites, accidentally stepping on my researcher’s toes — but at the end of the day, when I’m sitting there watching a user smile as she engages with my product, I know that it’s all worth it.
Being a product manager is not about obsessing over the “manager” in your title. Sure, you get to call the shots. But you also get to be accountable for every up and down of your product. If a user doesn’t understand your product, that’s on you, not Marketing. If your product comes at the wrong time, that’s on you, not Strategy. If a user can’t find the button, that’s on you, not Design.
And if a target user has no use for your product, that’s on you, not him.
A version of this post previously appeared on Medium.