The focused roadmap framework
Building software is expensive – time, money, and focus are always in short supply. Startups are burning runway. Product teams at larger companies are under pressure to deliver. Every research & development team at every company needs to attempt to maximize the ROI on the time they spend.
The good news is there are only 10 reasons to build anything. If your team’s work doesn’t map to one of these, you’re probably wasting time.
Roadmap criteria
- Innovation / strategic fit – Provide users with a new way of solving a problem or job
- Customer need – A large group of users need the functionality (you define what "need" and "large" means)
- Lost deals – You’re actively losing sales because it’s missing
- New revenue – This opens up a new stream or upsell opportunity
- Retention – Keeps existing customers happy and renewing
- Product parity – Competitors have it and it's starting to hurt
- Cost savings – Cuts internal costs or automates manual work
- Compliance – You need it to stay legal or meet requirements
- Risk reduction – Improves security, stability, or avoids disaster
- Strategic prerequisite – Unlocks or enables future work
Priority order
Sometimes shit happens and you just have to adapt. Many of us had to adjust our plans to adapt to COVID. At times there's a clear winner whether it's progressing your strategic direction or reducing intolerable risk.
Otherwise, this list is generally in priority order for early stage companies. Obviously each team and organization is unique and circumstances differ. If you're at a later stage the list shifts downward in terms of prioirties or you may find this list is just out of order for your team.
Product decisions should be data informed but they're ultimately subjective bets about potential value. Sometimes these decisions are more objective because you have extremely clear signal about the value, costs, and risks. Most often they fit in a gray area and you need to place a bet without having much context.
Focus
People can only focus on one thing at a time.1,2 This applies at the individual level and the team level. Which is why it's often easiest for early stage businesses to focus on a more kanban style of project management. A job is an opportunity to deeply focus on a task, give your team the opportunity to actually focus and solve the f*cking problem.
Epilogue
This list is short on purpose, it only includes work that creates value for others. You won’t find “learning” here. Learning is great for the individual, but it doesn’t add market value. Keen observers also may have noticed there's no line for feature delights. Delights are important but they don't materially increase revenue, the decision to build a delightful feature is often really a retention decision. Otherwise, it doesn't add market value. Reframing decisions against this model can give you a more apples to apples comparison.
The Product Manager's role changes a bit from company to company. But across each organization the goal for the role is the same: to maximize the value of the asset you're producing. That's a complex problem impacting many people and as a result, product decisions are not fact based decisions. Product decisions absolutely should be informed by data but they're ultimately opinion based decisions. Your organization exists within a complex system, the future can't be predicted; everything is a bet.
Founders and product managers have to balance limited people, time, and capital against outcomes that will impact all your stakeholders. The job isn't easy, but the roadmap criteria are.
References
Disclaimer
- I have no idea how much of this article is novel and how much I've learned from others. At some point in the last decade someone has given me or I've found a short list criteria for a roadmap. I didn't think it was quite right and adjusted the roadmap criteria and added a some context.
- This article includes Amazon affiliate links: if you click on one of these links and purchase a product, I may make a small commission.
Comments