This is a continuation of my post on building a modern product management organization. Part 1 was posted here.
In this part, I try to cover the keys to modern product management and how products actually grow.
Everyone is in search of the growth line that goes up and to the right (the red line). That's why I labeled it the growth line that everyone draws. it's the growth line that everyone is in search of because they think that’s how real products get built and scale. But if you look at what really happens, actual growth looks a lot more like the blue line. You build a feature, it gives you a small spike, you optimize that feature to a point of marginal return. Hopefully at the same time you are also trying to figure out what to build next. And hopefully by the time you get to marginal return on the previous feature, you've found a new thing to build and optimize.
Growth happens in fits and starts. It doesn't happen as one continuous perfect line. Andy Johns did a really nice job explaining this in a recent article. If you're thinking about product as this continual up and to the right thing, you're thinking about it wrong. You need to think about it as, "What is the next incremental thing that I'm going to have that's going to get me more users and can get me more people engaging with my product?"
So what are the keys to modern product management? First of all, people need to understand their customer. I spent four years seeing different companies at Naspers, which is a large international holding company and venture investor. I work at Booking.com now. I spent ten years in Silicon Valley. And increasingly if you ask people, "Did you talk to your customers?," the answer is often no. That's disheartening because it means that people aren't actually spending the time to understand who their users are. Instead they're just treating their users as a data point.
Secondarily, it's really important to be able to formulate key hypotheses about a customer. If you're not actually talking to them, how can you possibly say what you think they're trying to achieve and how you're going to make their experience better? It’s also really important that you're able to do that even for things as small as running an A/B test. If we can't clearly articulate why an A/B test is a good idea, maybe we shouldn't run it. Maybe you should save those resources and do something else with them.
Data is incredibly important. I worry that some people misinterpret my message as saying don’t use data. That's not the point at all. The point of this talk is data matters a ton. Data is how you validate that you are taking the right approach. Data is also how you get insights about your users. Data is how you validate that your A/B tests or your ideas or your hypotheses are working. But data is not enough. You have to combine data plus insights about your user to really figure out how to build the best product for them.
Not surprisingly, the biggest takeaway is to talk to your customers. Figure out what problem you're solving. If you can't walk away from a product meeting and clearly say, "This is what we're trying to do for our users," both at a team level and also at a company level, that’s a problem. You then need to start asking, "Why are we not able to answer this and what could we do to be able to answer this question?"
Surprisingly, many teams cannot concisely state what customer problem they are solving. If you are one of those product teams, I'd recommend starting by solving that problem.
I will follow this up in the future with how this model can be applied to building a product organization and a larger company structure.