Core concepts of modern product management
A starting point for building successful products faster
I often come across companies that don’t really understand what strong product management is about, mostly because they just never have been exposed to it. So I decided to share a few fundamental product management concepts to help aspiring product people build a better product.
First, what’s the purpose of the product team? What are we really trying to achieve? My favorite definition is: “Come up with a solution that customers love, yet work for our business” (coined by Marty Cagan).
Why do so many teams fail to do that? Mainly for 2 reasons:
- It’s very hard to predict how well a given idea will work (typically 50% to 90% of the ideas don’t have the expected impact)
- Features are expensive (cost of building, bug fixes, complexity increase, customer support time, feature accretion, opportunity cost, …)
What does that mean for product teams? Because the cost of error is high, we need to be good at selecting what we work on. And because each idea has a high chance to suck, we need to be quick at figuring out what works.
Now, most often, products fail because either:
- The problem is not important enough. In the end, the customer won’t care enough about it and the company won’t be economically sustainable.
- or the solution is not good enough. This might be because we don’t understand the problem well enough, or because of execution problems.
Some real-world examples:
- You work for an eCommerce company and conversion in the checkout funnel is low. The PM proposes to add Paypal to the payment options. He often pays with Paypal for his own purchases, so surely this must be what’s missing! The team ships the feature and the KPI does not move.
What happened here: the team did not understand the problem well enough, so the solution they shipped did not solve the problem. - One of your first customers asks you for an Excel export feature. You oblige, because it’s important to make your customers happy! After a year, you’ve spent a considerable amount of time maintaining features like this one. At the same time, your product never reached product-market fit and the company has now ran out of money.
What happened here: the problems the company spent time on were not important enough to sustain a business. - You are building a new product and just released it to the public. You found in interviews that your target audience loves the concept, but your conversion rates are very low when you try to grow your user base. You investigate further and discover that visitors are really struggling with the complicated onboarding process and churn before finishing.
What happened here: the solution was not good enough to solve the problem.
So, now, we know that:
- our ideas often don’t work as expected
- building is expensive
- we often select unimportant problems
- we often design subpar solutions
How do we deal with this?
We pursue a deep Understanding of the problem and customer.
It’s worth detailing how important this Understanding really is.
What happens to a company that hasn’t this Understanding yet and isn’t actively learning? Every new pivot, initiative or feature is a stab in the dark, meaning the team starts from 0 each time. After some time, the team won’t have accumulated much more knowledge than they had at the start, and will only converge toward product-market fit (or a functional product) at a very slow speed (or not converge at all).
In contrast, when you have more Understanding of the customer, you:
- Select better problems to address
- Come up with better solutions
- Need fewer iterations to reach the desired outcome.
This represents a tremendous amount of time saved, and it compounds over time, so you actually get faster and faster.
In my opinion, there are 3 main levers to help product teams really learn faster.
1. Collect evidence
Steve Blank famously said: “In a startup no facts exist inside the building, only opinions”.
Backing key assumptions and decisions with evidence is the standard to aim for. Some ways to collect evidence: talk to customers (user research, shadowing them while they work, …), measure and analyse data, devise and carry tests (e.g. prototypes), talk to industry experts.
2. Separate learning and building activities
Since our first try at something has very high chances to suck, this first try shouldn’t be done through the heavy-duty building track.
Can we learn if our idea will work in 1 day with a scrappy prototype instead of one month of work? Can we schedule a call with 5 users and learn all about how they perform this specific task?
3. Focus on outcome rather than output
Get away from:
- The fire-and-forget mode where the focus is merely on shipping features
- Roadmaps filled with already-decided solutions to be built
Instead:
- Set goals in the form of problems to be solved, agnostic of any solution and focused on the customer value (the outcome)
- Follow up on what you ship by measuring the impact and checking the user experience
- Continue working on a topic until it is actually solved
That’s it. If you start using these concepts more, let me know how it went for you!
