A PM’s first priority is NOT the customer
Back when I was a sales engineer (presales), I loved solving customer problems. Loved hearing customers say how happy and thankful they were when we fixed something for them. Reading “Thank you” emails and ending calls on a great note would make my day.
We couldn’t always make every customer happy though. We were bound by the limitations of the product. When customers really needed something the product didn’t support- it sucked having to disappoint them. It felt frustrating when frequent asks from customers weren’t always on the product roadmap.
When I moved to product management, I felt so happy that I could finally do something about this. I was going to build delightful beautiful features that addressed customer problems. Cos at the end of the day, being a product manager is about solving customer problems and making sure they’re happy, right?
Wrong.
The impact a product manager creates
There are always a thousand features that you can build for the product. A thousand different ways you can cause “impact.”
The problem is that words like “impact” and “ROI” for a feature is subjective. Often, customer adoption numbers and anecdotes are confused for “good impact”.
The only thing that really matters is- impact on the company’s revenue.
Will what you build eventually help the company make money?
If you’re building a “delight feature”, are customers going to be happy enough that they become sticky, don’t churn, and bring more your product more credibility? Will that credibility and trust build your brand and eventually lead to more business?
Will your decisions help leadership show good numbers with investors? If there’s a recession tomorrow, have you helped the business thrive so it’s able to go steady?
Are you helping salespeople meet their target? Will your decisions make it easy for CSMs to stay within churn target limits?
Will your decisions continue to be relevant and keep the business thriving 3–5 years down the line? Will your future customers love it/not care/find it deficient? How expensive will it be if your decisions have to be reversed and redone?
Analogy time
Many skills can make a person a great singer. How well they emote, their voice, riffs and runs, vocal range, falsetto, ability to improvise, etc.
None of this matters if you cannot sing on pitch though — the most basic non-negotiable qualification.
Similarly, there are a LOT of skills needed to build a good feature/product. They are, of course, important.
But if the features you’re building aren’t going to have short/long term impact on the company’s revenue needle, you won’t have auto-tune to save a suffering business.
What caused this shift in thinking
Over a good 1.5 years into product management, I was listening on in a meeting with top leadership- including the founder. The topic of discussion was a new side product strategy. ( Not a good choice of words. I’m trying to talk about it without revealing sensitive info :) )
At one point, they spoke about how we could build value in a certain area, package, and monetize. “ Isn’t that what good product management is?”
I was literally dumbstruck.
They continued on with what seems like novel ideas on how we could solve common customer problems. They were nothing like how our product, or any product in the industry, worked. So much that it felt super uncomfortable for me to even consider them.
I’ve thought about that meeting for long long time since. It has slowly shaped my thinking and the way I work.
What’s changed for me. Day to day.
- I used to not care about pricing.
My decision on what plan a feature should be on was mostly based on gut feeling. Sometimes, an ill-informed gut feeling. I’d sometimes leave it to the growth team to decide. They are better experts at pricing and packaging anyway.
Even worse- one of the reasons I’d think a feature should go on a lower plan is “better adoption.” The more eligible customers, the higher the adoption numbers. Everyone loves and cares about adoption, right?
It’s just a random fluke and luck that these decisions haven’t caused a leaky revenue bucket for my features. shudders.
By not monetizing a feature correctly, you’re literally preventing the business from growing. You’re preventing salespeople from being able to hit their targets, preventing your stock prices from going up.
These days, I think about pricing in the very early stages of building something. For larger modules, it’s helped us take the right engineering calls to make sure we’ll be able to monetize at launch
2. I work for the product. Not for the modules I own.
Every PM owns different features/modules and has a strong POV on what they want to build. Naturally, not every PM gets to build what they want to.
When my feature asks didn’t make the cut, I would always defend the need for them to death.
These days, I’m able to handle roadmap prioritization conversations more maturely. It’s easy to see when feature wishlists from areas in the product I don’t own will have more impact than mine. Also, making a case for what I want to build is easier when it has the potential for higher impact.
This shift in thinking is perhaps what a lot of thought leadership content out there on product management talks about. “How to change from being feature owner to a product owner”, “feature strategy vs product strategy” , “ what made you a good Jr PM won’t make you a good Product leader” etc. They sort’ve made sense. Didn’t sink in though.
Only the shift in thinking about revenue impact has truly flipped the switch in my head.
3. The validation I seek is different. What is gratifying is different.
This is perhaps the most important.
Shreyas Doshi a few years back posted about how PMs are often lauded for launching something that customers and the business have desperately need. But PMs who make the right decisions to prevent such a desperate situation in the first place are rarely recognized.
I’ve experienced this first-hand.
The first feature I launched was highly requested, highly impactful. I barely had to make an effort to prioritize it. By the time I got ownership of the module, leadership knew it needed investment.
Such applause, much praise at the time of feature launch. Felt great.
What I didn’t do then, is prioritize future-proofing the solution to make sure it continues to work for the kind of customers we’ll have 3 years down the line.
It’s been 3 years, and we desperately need to revisit the feature.
What’s amazing is that only I know and recognize that it wasn’t a good decision to not future-proof the solution early on. Also, like Doshi says, had I worked on the v2 of the feature, I’m fairly certain I would not have gotten any applause or praise for it. It would’ve taken years for impact to show.
Problem is, the impact some good decisions has on business can be hard to quantity. Great decisions sometimes take time to get validation of their worth. When you lose a deal, customers tell you the gaps and the issues. When you win, it’s not always easy or straightforward to attribute the many amazing decisions that worked well and built trust with customers. Especially for a mature product like ours.
How I operate now is going to get less immediate praise and visibility compared to how I used to work. And boy I’m glad I couldn’t care less.
Knowing I’m building the right thing the right way, earning the respect of some brilliant minds is FAAAR more rewarding than optimizing for quick wins. I’m so much happier as a PM. :)
Long story short- Prioritize what to build to ensure the business thrives. For this reason, the first to keep in mind is whether what you build will benefit employees. Your colleagues.
The shift in thinking has been working well for me. I’m sure it’ll continue to shape how I work. Excited to see how things evolve. :)
P.S. You’ll excuse me for the click-bait title :D. I can’t imagine a feature/product that makes no customer/prospect happy. The point really is that being a guardian of customer happiness is not the job. The job is to help the business grow. As a consequence of this shift in thinking, you’ll make decisions that make way more customers happier in the long run. :)
