Overcoming the 10 dysfunctions of product management (Pt. 1)

This piece is a guest post from Rajesh Nerlikar, CEO of Prodify. See part 2 of the series here. 

In the opening chapter of Build What Matters, Ben Foster and I defined what problems the Vision-Led Product Management framework was intended to solve by naming them the 10 dysfunctions of product management. So when I met the folks at Productboard, we thought it might be really interesting to talk about how their product could help you address each dysfunction.

We’ve split this into two posts — the first for dysfunctions 1-5, and the second (which we’ll publish soon) for dysfunctions 6-10. Let’s get right to it!

Dysfunction #1: The Hamster Wheel — a focus on output over outcomes

On a hamster wheel, all that matters is continuing to run, even though you’re not getting anywhere. Similarly, sometimes product teams are almost entirely focused on output — hitting deadlines — with little regard for the outcome. 

Compare these two questions and you’ll see the difference in perspective:

• Did you ship that feature on time? (output-oriented)
• Did that feature deliver value to customers and grow revenue? (outcome-oriented)

What’s the use of shipping a feature on time if no customer wants or is willing to pay for it?

Addressing this dysfunction with Productboard

To escape the hamster wheel, use Productboard to create an outcome-driven roadmap and emphasize what metrics your proposed product changes are expected to move (rather than just when the releases are planned). After the release, be sure to go back and measure whether the changes delivered the expected outcomes. Then communicate the results to your team and stakeholders, along with any recommendations on the next steps.

Dysfunction #2: The Counting House —an obsession with internal metrics

In the counting house, the focus is entirely on internal metrics with no regard for customer success. Many product teams become obsessed with internal metrics like revenue growth, monthly active users, and customer retention. 

The truth is, most internal metrics are trailing indicators of a product’s success, and therefore shouldn’t be the primary focus of product management. 

It’s far better to answer the question, “How can we effectively deliver greater value to our customers?” If you can answer that question and create a good business model around the answer, your internal metrics will almost always follow suit.

Addressing this dysfunction with Productboard

To ensure you never lose sight of your customer’s needs, create a hierarchy that emulates how your customers would think about what you’re working on. For example, you could use a Jobs-to-be-Done hierarchy to show how your work is helping users get different jobs done, as seen in the example below. 

You could also implement our concept of customer outcome pyramids by orienting your hierarchy around metrics your customers would use to measure your product’s value, like saving them time in completing a task or hitting a personal goal like losing weight or exercising more. This may not feel natural, but going through the process of identifying the customer value proposition for each feature in your existing product/on your roadmap can force you to see if your product is helping customers achieve the outcomes they care about. If you can’t articulate why a feature is valuable, it begs the question of whether it’s needed.

Dysfunction #3: The Ivory Tower— a lack of customer research

In the ivory tower, product teams become so removed and so far above the customers that they start thinking they know their customers better than the customers know themselves. Consequently, they never really talk to their customers, which means they risk building a product no one wants or needs. This is one of the most common, and in my mind, egregious, dysfunctions.

This can also lead to mistrust between product management and other departments. Product management feels like they’re building the right product (though they may not be), so when the product doesn’t perform well, they assume the fault lies elsewhere. 

The ivory tower is a trap. Stay on the ground with your customers.

Addressing this dysfunction with Productboard

There are quite a few features in Productboard to help you better understand your users:

1. Use the Insights board to link customer insights and feedback directly to the features you’re working on. 
2. You can also collect feedback and ideas directly from users via the Portal. 
3. You can further clarify who you’re targeting with your roadmap by segmenting your users manually or based on the new Amplitude behavioral cohort integration (for example, find what power users are saying)

By using these features, anyone trying to understand your roadmap will be able to read what customers actually said or what your team heard that led to the feature. Now it will be more clear to stakeholders why you prioritized solving a specific customer problem and how the solution factors in all the feedback received.

Dysfunction #4: The Science Lab — optimization to the exclusion of all else

In the science lab, product teams tend to focus all of their efforts on highly measurable yet superficial improvements to their product. Collectively, these small-scale optimizations don’t do much to innovate or add customer value.

For more and more companies, optimization has become the be-all and end-all rather than a facet of a balanced product development roadmap. The assumption is that making improvements to existing solutions is the one thing that will drive results, but even effective optimizations can’t take the place of real innovation. 

Sometimes you need new solutions, not optimizations.

Addressing this dysfunction with Productboard

In the book, we go on to explain how to balance your roadmap between innovation, iteration, and operation. We also suggest you do a top-down allocation exercise to get stakeholders aligned on what percentage of product development capacity should go towards each category. The ratios likely depend on the product lifecycle stage. Early on, it’s mostly innovation, then mostly iteration as you seek product/market fit, and then mostly operation as you scale your product.

Through Productboard, you can help visualize how much of your roadmap is going to each of these three categories of work using swim lanes such as the example below.

This visualization can help your roadmap audience:

• Understand how much of a lift they can expect from different roadmap items (incremental for iteration, step-wise for innovation)
• Scan the roadmap artifact to quickly digest how much capacity is allocated to each category. That is, if they see a lot of green innovation cards, they’ll know we’re investing a lot in innovation.

Dysfunction #5: The Feature Factory — an assembly line of features

 

What does a feature factory build? Features. When is a feature factory done building features? Never. 

That’s the problem with being a feature factory: there’s always the next feature to build. Product teams fall into this trap because they are led to believe by customers or internal stakeholders that if they just had this one next feature, they will close incremental deals or keep customers who might otherwise leave.

Sometimes, it works out that way, but more often than not, the team discovers that yet another feature is also needed. At some point, you need to break the cycle.

Addressing this dysfunction with Productboard

You have to create a reason to pause the factory and break the cycle. To do so, consider using Productboard in a couple of different ways to take a breather and measure the impact of your team’s work:

1. Use Insights to build a sustainable feedback loop so you can hear what users are saying about the new features you’re building. Are they aware of the new feature? Do they understand the value? Do they like using it?
2. Integrate with an analytics product like Amplitude to see feedback from specific segments. Hopefully, the feedback from them is getting better (for example, “I’m so glad y’all finally built this feature — it was much needed! Now I can ________”)

Creating a process to pause and look back on your product development efforts can help combat a common sentiment from leadership to “just keep building” to showcase output/regular releases to their stakeholders. Instead, you can show whether you’re working on the right problems and solving them in a way that users appreciate. Also, think about how to create a cadence to share these learnings with your stakeholders so they better understand why the “factory is shut down” and that constant output isn’t the only path to product success.

Wrapping up

Ben and I called out these dysfunctions so there could be a common vocabulary for teams to acknowledge they were happening and address them. We know many PMs have probably experienced all of them at some point, and might even be seeing a few right now. If you’d like to see how your team is doing, you can use this scorecard we created, and email me at [email protected] if you’d like to discuss the results or how to prioritize which dysfunctions to pursue first. Keep an eye out for the next post, where we’ll wrap up the last five dysfunctions!