Product management is about instinct, not data
Product management is about instinct, not data
If you understand the customer well enough, you don't need to justify what you're doing.
When you are a small, young company, product management is the easiest thing to do. You don’t have any customers or revenue and you want to get some money so you can live. So you build whatever you think someone will pay for, get them to pay for it, and repeat. You don’t even call it Product Management; it’s just building a product for your customers.
When you grow up and start to get lots of customers, product management becomes the hardest thing to do. Once it stops being obvious what to build next, the question becomes highly subjective and easily politicized. Even if you hire lots of engineers1, the number of ideas, requests, and bugs that come from customers and prospects will always outpace your ability to deliver them. The “obvious” solution is build a product management team that can help you work out what you should build.
Once you have the PM team, the temptation is to apply a data-driven approach. Let’s record everything users do using Amplitude. Let’s record feedback and suggestions from every user in Canny and Intercom. Let’s set up FullStory so we can watch every user use the product.
For a B2B product, this is a sure path to getting more confused and less certain. It also takes a long time to get (not very useful) answers, and it’s very expensive.2
The better way to decide what to build next is by instinct. Have one person (or a small number of people) in your company who is empowered to build whatever they want. This is effectively what founders are doing in the early days, and it turns out founders will keep being good doing it for a long time if you structure the way you work to enable them.
But how do you pick what to work on without data?
Good founders have incredible domain knowledge and an eerily strong understanding of what customers want. They will combine this with feedback from the sales process and from support/customer success interaction. As the company grows they won’t do this directly but will listen to what everyone in those teams complains about and distill it down to what is most useful. Finally, they’ll mix in their own ideas about the future (which is informed by all the same sources) to think a little bit further ahead than the rest of the market.
It’s not just founders that can, or should, do this. Lots of people can! For example, heads of sales have been known to be very good at it. Similar to being a founder, being great at sales requires a strong customer understanding and the ability to focus on what really matters to them.
Founder distraction leads to delegation
Founders picking what gets built works well in the early days. The reason it gets harder over time is because the responsibility for founders grows a lot as the company grows.
As the list of things you’re responsible for grows, you have to pick what you delegate and outsource. Either you pick things at the top of the pile - the really challenging, but really high value things, like figuring out what to build next. Or you can pick the bottom of the pile - the long tail of new tasks and day to day challenges that come with scale. Most choose to delegate the top of the pile, and start building a product management team.
The first day as a PM
Imagine it’s your first day as a product manager. Everyone assumes you’re somehow going to have some great insights as to what should get build next. But it’s unlikely you know anything about the industry, let alone have the deep insights the founder you replaced has. So a good safe thing to do is to start by collecting more data. Install Amplitude, and FullStory set up Canny, etc. This will bring some easy non-controversial ideas to the forefront and you can start shipping. Common ones are UX improvements to non-critical pages, or simple feature requests that are popular with everyone but they are inconsequential.
This isn’t inherently wrong. It’s not bad to get a feel for shipping some product improvements. What’s bad is getting dependent on these tools and never developing the instinct.
To be clear, anyone can develop this instinct - it’s not restricted to founders or heads of sales. But it is hard to develop if you don’t work on the frontlines, because getting a deep understanding of customers is a big grind. It’s much easier and more comfortable to collect data and try and use it to come up with answers. You can do it without ever picking up the phone.
Resist the temptation to make lots of decisions
The more time you put off developing a real instinct about customers, the more busy you will get and the less time you’ll have to do it. If a new product manager spends their first 3 months on the frontlines answering support calls and doing demos, that’s a brilliant idea. If they try and do it after 12 months on the job, there’s so many other processes dependent on them that it’ll feel like a big problem to take them “off the tools” for 3 months.3
It’s also just much more fun to make decisions about what to build and ship them, then it is it to do the work of learning more about customer needs than customers can articulate themselves. The temptation to skip to the fun part is pretty strong.
One way to avoid this temptation is to avoid using the term “product management”. Instead, think about - and talk about - setting the direction for your product. It’s fine to use instinct to guide the general direction. All the little details that need to get figured out once you have that direction, can be done by whoever is doing the building.
Whoever ends up setting the direction - and I’m a big advocate for it being founders for as long as possible, and then a little bit longer - should trust their instincts and not get blinded by data.
By the way, here’s some more reading on the topic:
Not surprisingly, product managers are very good at making and selling software to other product managers that claims to help with product managers. If you think that’s bad, check out the prices for SaaS products that salespeople sell to salespeople to help them do more sales.
It’s still the right thing to do. It just feels wrong.
I agree. Product managers can build a kind of product instinct or product sense. If you combine that with data, results are best. That's why "data-driven" is not the best approach. A "data-informed" approach uses data and combines it with a strong, opinionated product manager's product sense.