(from a 5/19/14 blog post by Melissa Perri, link to her blog here)
Melissa argues the the product roadmap needs to be replaced with the problem roadmap
Product roadmaps:
- Are built on arbitrary estimations
- Lack built-in time for validation and research
- Allow little room for change
- Focus solely on solutions and features, ignoring problems
- (read the post for a thorough explanation for each point above)
Problem roadmaps:
- Focus on problems to be solved, rather than on features to be developed
- Can be planned over any period of time (quarters in her example)
- Are broken into two phases:
- Discover & Experiment
- Build & Validate
(graphic from Melissa’s site)
Cross functional teams work on a problem to be solved during a set time frame
- The goal is to solve the problem
- KPIs are assigned to each team to signify if the problem has been successfully solved
During the Discover & Experiment phase:
- Teams focus on minimum solutions (feature sets) to solve core user problems
- Iterations are constantly released to customers and feedback is integrated into the next iteration
During Build & Validate:
- Over time, teams add more features and iterate
- If the product isn’t finished being built out by the end of the set time period, it’s evaluated against a prioritized backlog and work can continue if so decided
How to plan a Problem Roadmap
- List & prioritize top customer problems
- Assign top problems to teams
- For set time periods
- With established KPIs to measure progress
- Each team must validate that their problem is real and important; they move on to the next problem if research suggests it isn’t that pressing a problem
- Teams interact directly with customers to conduct research
- Teams develop MVPs after initial research and test them in the market
- Once an MVP is validated (i.e. met its goals and KPIs), teams start building the final product
- Teams focus on building Minimum Feature Sets, which they release and iterate on based upon feedback
- At the end of the time period, teams decide whether more investment is needed; the roadmap is adjust if so
- For the next cycle, the process repeats, revisiting the list of problems to reprioritize or add in new problems
With the Product Roadmap, we can communicate the problems we plan on tackling to our team and customers without committing to solutions for problems we may not understand
About Melissa (from her blog): Melissa Perri is a Product Manager, UX Designer, speaker, and coach. Working along side product development teams around the world, Melissa helps them create product strategies that satisfy users and drive business goals. She coaches Product Managers to answer two important questions – “Should we build this?” and “Why?” Harnessing knowledge from Agile, Continuous Improvement, and Lean Startup, Melissa has developed her own processes for great Product Management that she teaches through workshops and consulting. Her clients have included Spotify, Rovio, Valtech, Plated, Wayra UK, and Levo League.
