Product Roadmaps: Art or Science ?
Roadmaps are a vision. They are your future and your past rolled into a pretty visual presentation slide.
A good roadmap tells a story, while it is also logical and based in reality. When I look at a product roadmap, I like to think about its value. What do I want to commit to for the year? What is something that we can aspire to produce? What can we actually create given our resources, time constraints, budget and priorities?
The right product roadmap will make your customers happy, create value for the business and if you do it right, make you money too.
Another aspect of product roadmaps that I find important to understand is the value of input from your business partners and your ability to keep the roadmap coherent, yet flexible.
The following are a list of questions t I use to build my roadmaps:
- What do I want to deliver each quarter? What is the sum of its parts? For these questions to be answered, I need to have focus ( maybe its mobile, search, better browsing, omni-channel capabilities, online storage, new features or expanding on existing projects). No product manager lives in a bubble.
- What is the benefit for each of these features? You should be able to quantify the budget for every one of your product features. What is the level of effort required ( at least high level), what do you think is the return on investment? What are the KPIs that will be used to measure the success of failure of every feature you build?
- Prioritization is key. For each project you take on, inevitably you will be constrained by your time, the number of engineers, QA, environments for testing, competing projects, and other ideas. What can you and your team agree to as most important (must haves) vs nice to have?
- Create backup product features you would like to build. The more ideas you have the better. Not everything will get built. Projects will fail, business might take a turn, clients might want something different. When we look at “fail fast” cultures — you should know what your backup plan is ( without obsessing about it).
- Work your product roadmap, but be flexible in your approach. A great product roadmap does not need to be rigid. I like the analogy that a product roadmap has three states that mimic that of water. There is the solid state — that which you are working on and will do. There is the liquid state — that which is most probable and will be worked on soon. And there is the gaseous state of your product roadmap — this can be 6–18 months out and could change with your business.
Generally, I like to think that the first 3 months of an annual roadmap should be solid in nature. If you are in January, you should know what you are working towards the next few months, but coming into Q2 — April timeframe that is 90 days out. A/B tests might show you a new direction. New clients or competitors might request ideas that you never considered.
Bottomline there is no right or wrong product roadmap path. You should always be learning, paying attention to your competition, staying on top of your backlog, and thinking towards the future.
What works best for you and your organization?