The Traditional Product Management Method is Broken

May 3, 2019

According to the State of Salaries report from Hired, Product Manager (PM) was the highest paid tech role in 2018. And yet, the overwhelming majority of companies aren’t leveraging their product managers to the greatest advantage. In fact, many of these companies have set up a structure in which PM incentives are completely out of alignment with the ultimate goals of the company.

This pattern has cropped up again and again in conversations I’ve had with colleagues and other people in my network. It’s a phenomenon I’m personally interested in because of my own experience as a PM. I joined Testlio as Head of Product when the company had fewer than ten employees, and by the time I left they had nearly fifty. When I joined Dropbox as a Growth PM, our team was about a dozen people, but grew to sixty+ in the two-and-a-half years I was there. Today, I’m a Growth PM at MailChimp.

I’ve found that—in an ideal world—there would be no need to differentiate between a “Growth PM” and a “Traditional PM” because all PMs would operate from a growth mindset. The traditional product management method is broken and needs to be permanently retired.

The Problem Is Focusing on the Solution

The underlying issue that creates a disconnect between PM and company objectives is a basic cart-before-the-horse problem. Most PMs are too focused on creating solutions, when they should be paying more attention to the actual problems they are trying to solve.

Far too often, the product roadmap is based off solutions and features. That’s not a product development roadmap, that’s an execution roadmap—first you do this, then you do that. An effective roadmap isn’t simply a list of features; it’s a strategic guide constructed around a framework of problems to solve and areas to investigate. Instead of being driven by bells and whistles, it’s driven by a coordinated and strategic effort to deliver specific business outcomes.

Solutions are easy to create. The hard thing is figuring out which is the right problem to work on to achieve an intended outcome.

By adopting a feature-focused approach to product management, a company sets itself on a track that weakens the PM role. To begin with, the misunderstanding of how to build a product roadmap leads many inexperienced companies to grade and incentivize their PMs based on output. When you think about it, output is a ridiculously stupid metric on which to measure a PM. But many, many companies continue to reward PMs based on whether or not they released features. It doesn’t matter if the features make any difference to the big picture as long as the PM got them done.

In this kind of environment, PMs naturally tend to only want to work on sexy projects with high visibility. They aren’t interested in doing any in-the-trenches experimentation because they need visibility in order to score promotions. They also know that they will be rewarded even if whatever they launch doesn’t do well because by the time anyone has analyzed the data and figured out that whatever they did failed to move the needle, they’ve already collected their reward and moved on to the next sexy project.

In the worst case scenario, a traditional PM may intentionally overlook or downplay a project’s lack of viability because they are more focused on pushing something out the door than on making smart decisions for the product. So, instead of putting a DOA project out of its misery, they forge ahead, wasting time, resources and money in the process.

It’s not hard to understand how companies end up operating this way. In addition to the widely held assumption that the traditional PM approach is the only way to go, there are other factors that contribute to companies getting caught up in pursuing the wrong “roadmap.” There’s the issue of company leadership making casual product suggestions without understanding the weight their words carry. (If a founder or CEO asks if the team has considered doing such-and-such, the members of the team are likely to assume that they need to get to work making such-and-such happen). There’s the scenario in which a founder has a hard time giving up control. (I’ve often seen this when someone in a position of power invites non-experts to the table and lets their opinions skew the conversation in non-productive ways). And then there is the common issue of a company culture that’s simply not set up to make good use of data. (If the higher-ups aren’t equipped or predisposed to make data-driven decisions, the rest of the company usually won’t be either).

There is a Better Way

At the opposite end of the spectrum, Growth PMs are all about data and experimentation. They start with the problem instead of jumping prematurely to solutions. Growth PMs are beholden to a KPI, so they have a reason to see their efforts all the way through. They care about the data and the outcome, not just checking off a series of releases. Instead of being responsible for delivering a list of features, Growth PMs are responsible for delivering results. For instance, rather than being tasked to release a new functionality, a Growth PM might be asked to take on responsibility for new user activation—figuring out what’s working and what’s not working, where there are opportunities, which elements warrant further investigation and how all of it can be used to achieve a specific business outcome.

This approach requires data literacy and experimentation skills. Frankly, it’s upsetting how many PMs I’ve come across who don’t know how to make solid, data-informed decisions. Understanding data, knowing how to navigate it, being able to detect biases—all of these should be basic requirements for any PM. And all PMs should be experimenting. Experimentation is how you deconstruct a problem so that you have the information you need to build the right solution. It’s a tool that every PM should be using to get to the desired outcome more efficiently.

And there are other tools and strategies that all PMs would do well to use. The squad model, for instance, is a powerful product management strategy that revolves around an autonomous cross-functional team dedicated to solving a very specific problem. Typically, such teams include a PM, a designer, and however many analysts and engineers are needed to get the job done. They can build whatever they want without worrying about anyone (even the CEO) derailing their efforts. Their only task is to solve the problem they’ve been given.

Discover the Value of Productive Push Back

All of this boils down to a pretty simple bottom line. If you want to switch gears from a Traditional PM model to a Growth PM model, you need to have the gumption to constantly push back and ask the big question: “Why?”

A company with a growth-mindset approach to product management is a company where the culture encourages PMs to ask the hard questions:

      • What problem are we solving?
      • How big is this problem?
      • Why do we think this solution will solve the problem?
      • Did the solution solve the problem?

And from there, the PM has to be empowered to demand the data that backs up the answers to those questions. While the PM can keep an open mind about every request, they have to have the right to create their roadmap and make their decisions based on the data. They have to be allowed to put every request through the full set of paces, including full analysis and experimentation, before green lighting any project.

It’s a smarter, more efficient approach to product management that will ultimately save a company time, money, and a lot of wasted effort building features that were doomed to fail from the start.

Growth PM

Willie is currently a Growth PM at Mailchimp where he is leading Activation (and soon Retention) efforts. Prior to Mailchimp, he was one of the early Growth PMs at Dropbox where he helped the Growth team scale from 12 to 60+. Before Dropbox, he was the Head of Product at Testlio where he helped the company scale from 7 to 40+. Willie’s Product focuses are on Growth, Experimentation Methodology, and creating scalable Product team processes for growing companies.