Overcoming the 10 dysfunctions of product management (Pt. 2)
This piece is a guest post from Rajesh Nerlikar, CEO of Prodify. See part 1 of the series here.
We’re back with tips on how to use Productboard to address the last 5 dysfunctions of product management, which Ben Foster and I defined in the opening chapter of Build What Matters. Click here if you want to catch up on part 1 of this series.
Dysfunction #6: The Business School— overuse of science and data
Business school is where you go to analyze business but not actually do business. Similarly, product teams can get so wrapped up in overanalyzing everything that they avoid making tough but essential judgment calls.
Some product managers will meticulously calculate return on investment (ROI) analyses to decide which features to pursue. With this approach, no product decisions are being made at all. Typically, it’s simply the lowest-effort improvements that end up above the cutline.
To make strategic decisions, you must consider the customers and the larger business strategy, not just mathematically calculated ROIs.
Addressing this dysfunction with Productboard
Product management is part art, part science. Knowing when to use data vs your gut instinct takes years to master (plus you need time for that gut instinct to mature). With Productboard’s new commenting feature (in beta) you can add some commentary on why something is prioritized so your roadmap audience can understand and ask follow-up questions, keeping the conversation contextualized to the roadmap item.
Dysfunction #7: The Roller Coaster — fast-paced twists and turns
A roller coaster is all about fast thrills and wild, whiplashing movements. In product management, investors and executives like to see immediate results, and when those results don’t materialize right away, they can be tempted to pivot suddenly, creating roller-coaster whiplash.
You need to be patient and provide sufficient opportunities for success. Otherwise, you’ll get false negatives, where a feature that is truly a good idea fails because there wasn’t time to properly execute it. Daisy-chained together, these false negatives result in a headache-inducing roller coaster ride for product development that ends up in exactly the same place it started.
Addressing this dysfunction with Productboard
Combatting this dysfunction will require some process discipline to create patience. To do this, you’ll need a buffer built into the roadmap so the team can find time to look back at previous releases to analyze user behavior metrics and collect qualitative feedback.
Within Productboard, you can create that buffer and manually place it into a roadmap so that stakeholders know there’s time reserved to work on something, although what may not be known yet. This way, you slow the feature factory and get stakeholders used to the idea of a post-release “cool down” instead of an immediate pivot because the first version wasn’t perfect (which it rarely is).
Dysfunction #8: The Bridge to Nowhere— over-engineering for future unknowns
Imagine if a team of engineers designed and constructed a bridge over a river to connect a city to a wilderness area where another city might someday exist. They invest a tremendous amount of time, money, and resources, and then the second city never gets built. What a waste!
That’s what happens with many product teams. They get excited about developing the infrastructure to get the product just right and then end up overengineering a product, trying to account for future needs that aren’t relevant—and may never be.
Focus on current needs. In the future, you can always adjust.
Addressing this dysfunction with Productboard
Once again, using color coding or swim lanes to show what roadmap items are related to the infrastructure, architecture, or technical debt can help stakeholders understand what the major investments are so you can get alignment on whether the size of the bet matches the expected customer and business value.
Dysfunction #9: The Negotiating Table — trying to keep everyone happy
Sometimes, product meetings can turn into a negotiating table, as the product manager tries to give everyone what they want.
Product managers often believe that success means keeping all of their stakeholders happy — or, at least, minimizing their unhappiness — but when teams and individuals throughout the organization collectively want more than engineering can potentially deliver, this becomes practically impossible.
It’s not your job to give everyone what they want. Your job is to give customers what they want. When you prioritize the right things for the customer, you help every team, whether those teams realize it or not.
Addressing this dysfunction with Productboard
One simple way to ensure everyone understands why you might need to say no to some ideas/requests vs others is to have a transparent prioritization framework. Productboard’s drivers and prioritization scores can help you show the value vs effort tradeoff that led to your decision on whether to include something in the roadmap or not. This way, viewers of the roadmap can drill into the scoring to understand where their items stand.
Dysfunction #10: The Throne Room — whipsaw decision-making from the person in charge
Sometimes, the founder or CEO just can’t let go, and they morph from CEO to king or queen in a throne room. They make and override decisions on anything and everything, sometimes without even offering a rationale.
In these situations, the CEO typically fails to drive alignment around the product direction, so no one really understands what they’re doing or why.
It’s an impossible situation for a product team that prevents the scaling of the company beyond a single decision-maker. For the most effective product management, the product team needs the ability to call their own shots.
Addressing this dysfunction with Productboard
I recently talked to the creator of the SU-RICE prioritization framework. Through Productboard, you can customize your scorecard to include a field for the source of the idea and user persona who’d benefit, placing a higher emphasis on customers, sales, or specific execs (or not!).
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 tackle first if there are several (which is common).
