Product management turns chaos into order. We face down indecision, molding it into a concrete strategy. We sideline shiny objects. Pet projects do not distract us. Despite the influx of ideas and feedback, we don’t get tricked into wavering from our disciplined prioritization processes.
Others might stare into the abyss of an ungroomed backlog and throw their hands in the air and run away. So much to choose from… how could anyone sift through all this potential and figure out what to prioritize first?
That’s what they pay us for. Our job entails creating product roadmaps based on what’s doable and gives the product the most bang for its buck. To be successful, we must whittle things down to their essence, weigh the merits, consider the tradeoffs, and make the hard decisions.
But how can we be sure we’re making the right calls and roadmapping what matters most? And how do we pull it off without seeming tyrannical?
Productivity expert David Allen once said, “You can do anything, but not everything.” This quote has taken on a life of its own, but this truth certainly applies to product management.
Particularly in the software business, if you ask a team to build it, they likely can pull it off. The challenge isn’t figuring out what to build, it’s what you should build.
Product management sits at the nexus of many information streams. The fire hoses of data are coming from all angles, be it customer feedback, support requests, competitive intelligence, or new ideas from the executive team.
While it’s easy to be swayed by what you’re hearing, product managers must remain resolute and focused on what’s truly essential to the product’s mission, vision, and strategy. Good ideas will be left behind or put on ice, but that’s OK. In order to roadmap what matters, it means limiting what gets attention and energy.
Do less, but better
We’ve all seen those feature comparison matrices where a product compares itself to competitors by showing off how many more boxes it checks than the other guys. The implication here is that the more stuff something can do, the better or more valuable it is.
But that really only applies if two things are true. First, the “extra” stuff needs actually to be valuable to the user. A washing machine might have 22 different settings, but how often am I going to use most of them? Second, whatever features I do use better work, and work well.
“Checking boxes” is about sales and marketing, it’s not about customer delight, satisfaction, and usability. Product management must hold the line and prioritize quality over quantity.
Do the important stuff, and do it well. Don’t compromise excellence for edge cases.
Malcolm Gladwell talks about how the best athletes and musicians don’t truly reach their potential until they’ve put 10,000 hours into their discipline. Of course, 10,000 hours isn’t a magic number. You’re not a bumbling failure at 9,999 hours and then magically transform into a star quarterback or first chair violinist when the odometer rolls over.
The point is that to be truly great at something, it requires dedication and commitment. Quarterbacks focus on throwing the ball while wide receivers worry about catching it. No one really expects the same player to be great at doing both of those things.
The same truism applies to products and their roadmaps. The outstanding ones make sure they’re amazing at a limited set of tasks instead of just being mediocre at a bunch of them.
Over time, products can eventually add more diverse capabilities, but not until they master what’s core to their primary purpose. In the meantime, they need to stay in—and dominate—their lane.
Maintaining an MVP mindset
The Minimum Viable Product approach centers on boiling things down to the core value proposition of the product and what’s required to deliver on that. Strip excess away to make sure any essential functionality is well-executed.
But once it ships and product-market fit takes hold, product development can rapidly turn into a rat race of adding feature after feature to create a fully-formed product. This feature-factory mindset derails the laser-like focus that resulted in that successful MVP.
Product management must resist the urge to tack on new capabilities in favor of refining and augmenting what got them there in the first place. Instead of chasing potential and possibilities, the product roadmap must build on what matters most.
Don’t squander a solid foundation
Product roadmaps lay out the future for the product. They can take it in different directions.
A sprawling, empire-building roadmap branches out from the core capabilities that brought success to the product and tries to take it in new directions. But expanding into too many new areas typically results in poor execution, second-rate user experience, and disjointed messaging.
Instead, products should double-down on what they do well. The product roadmap should focus on iteration and improvement of the product’s true essence.
Just say no
Nobody likes being the bad guy, but as the gatekeeper to the product roadmap, that’s part of your job. You can’t—and shouldn’t—do everything, so that means shooting down plenty of worthy suggestions to free up bandwidth for the essentials.
Deciding what makes the cut is part of the challenge, but the other component is how you deliver the news. It requires a combination of soft skills, understanding stakeholder types, and tying every decision back to the product strategy and goals.
When people understand the rationale behind these decisions, they’re far more likely to respect you than resent you. Delivering these verdicts with compassion and data also softens the blow.
Pick prioritization criteria and stick to it
There are many prioritization frameworks to choose from. But regardless of which you choose, the output is just as dependent on what you value during those exercises as the methodology.
So before you whip out your MoSCoW matrix or set the stage for a Product Tree, you need everyone aligned around what you’re trying to accomplish. You are not building a magical multi-purpose tool that will satisfy every desire of every potential user in the world. You are trying to be the best at what you’re good at.
That means prioritizing functionality that builds on what’s already working—improving what exists, augmenting in areas that are lacking, gradually increasing the scope of the product’s capabilities that complement the core.
It might mean disappointing a few folks to delight the masses. You may not pursue a new vertical because it will take away focus from the users you already have. And that’s OK.
When evaluating potential enhancements, ask yourself (and challenge others to answer) these questions:
- Does this advance the established goals for this product?
- Does this improve the existing user experience?
- Will this delight or add additional value to existing users?
- Does this make the product’s core functionality accessible to a broader audience?
- Does this help monetize or increase revenue for existing functionality?
- Will this grow usage or the user base for what the product already does?
If you’re not saying “yes” to a few of those questions, then it’s probably time to say “no” to that idea.
Roadmap What Matters: The Essential Product Roadmap
An organized and focused product roadmap should impart the same essentialism you bring to everything else you do to keep your product on the straight and narrow. It starts with how you structure and format things.
A product roadmap cluttered with dates and dozens of specific features doesn’t convey a narrow focus on core functionality. Instead, it looks like a bunch of unrelated activities and priorities. You can free your product roadmap from the tyranny of details by instead basing it on themes.
No longer obligated to include every last detail, themes focus on big ideas that drive value. Themes should tie to goals or outcomes, so everyone knows why they’re on there and the expected results.
Themes have the additional advantage of maintaining focus so you can roadmap what matters. While a rogue feature to appease a customer or noisy stakeholder might slip into a traditional product roadmap, themes require broader buy-in and alignment. It minimizes any product development resources diverting away from the core mission.