Roadmapping is the single most important Product Management process and ensures we are building the right thing. In this process, stakeholders are aligned on what new product features to build based on identified user needs and supporting data. I highly recommend reading the extensive introduction to roadmapping in to road-mapping in Appendix A: Introduction to Roadmapping.
Roadmapping is an ongoing process and part of the Discovery Process.
- 2-3 weeks before the Product Council meeting analyze data from Learning and experimentation from last month (i.e. outcomes of User Interviewing, Surveying, User Testing, Analysis of Analytics and Support tickets, NPS surveys, fake page tests)
- Put relevant data in the column "Supporting Data" for the relevant existing or new Roadmap theme's (see Roadmap template for columns). Sidenote: For learnings that just need small product improvements (max 3 days development time) I recommend adding 'small improvement' type user stories into the Jira Backlog or add the findings to existing stories. Update the scoring for these theme's when relevant.
- Based on new data and scoring update the priority order of the theme's (including putting new theme's somewhere in the list).
- In case theme's entered the top 5 for the first time:
- Create a short presentation (max 5 slides) about the new theme (slides: High-level user need and supporting data, Scoring and business case, high-level solution direction, similar competitor features, high-level estimate)
- Prepare a slide about why you scored this relatively high, and how you see this will contribute to a higher LTV?
- Will it increase revenues per order? (basket size)?
Will it increase our profit margin? (reduce cost per order / reduce CAC)?
Will it increase orders per year (purchase cycle)?
Will it increase the customer growth?
Will it reduce churn/increase customer lifespan?
- Take a look at how competitors are addressing this user need, or how non-competitors solved a similar problem (you can also ask the UX designer to help with this). (screenshots don't count as extra slides)
- After you created the presentation so far, plan a meeting with the team, plus Head of Product and CTO, to present the new theme('s) and get their input and feedback. Also, let the team estimate the theme in terms of 'project points' by comparing the theme to the themes from the past. Ideally, you want to identify at least 2 theme's that were a little bit smaller than the current theme, and 2 theme's that were a bit bigger, and then more or less average the lower and higher theme to come to a rough project points estimate.
- Based on how long it took the team to complete theme's of a certain number of project points in the past, you can now calculate a rough end date for the Design and Delivery phase of the project and put this on the last slide.
- Present the new themes to the product council using the presentation you made. (I recommend presenting the highest ranked 3 or so new ones, not to overload the Product Council with information). Ask the Product Council for feedback.
- In case you don't have any next theme approved by the Product Council already:
- Ask the product council to vote blindly on the priority order (i.e. give 3 points to their number 1 theme, 2 points to 2, 1 point to 3, on a piece of paper). Summarize the votes and discuss with the Product council until you at least achieve agreement on the next theme.
- In case you still have approved theme's on the roadmap or don't need a new one for the next month:
- Per theme ask the product council members, per member, if they feel they have enough data to prioritize this theme, or if they want further data collection during the next month. Majority vote goes.
- In case the product council has enough data to make their decision for one or more new theme's s launch a voting round (same as above. You can also do this for i.e. 5 theme's). Since there are already there is already other approved theme's on your roadmap, they also need to score points to those too.
- Now you have a newly approved roadmap theme that you can start off in the Design process as soon as the designers in the team are done with the previous theme.
Plan an emergency Product Council meeting, and do your best effort do the normal preparation steps. Usually, this will end in the Product Council talking sense into the stakeholder to finish the current theme and follow the normal process for the new theme (i.e. first investigate if there is really a user need). You can help shoot down bad ideas by doing a quick poll (i.e. using hotjar popupusing the hotjar popup, or emailing a few users), ask support about it or a quick experiment (i.e. place a fake button for this functionality and see if anyone clicks it).
Why 1.5-3 month long theme's? Isn't that too waterfall? Why not smaller steps to reduce risk and develop more incrementiallymore incrementally?
A certain amount of capacity is allocated to small improvements (i.e. 25%), however, to really move a product forward effectively and efficiently you need to make bigger steps too. Several successful companies (i.e. intercom) stick to 6 weeks because to keep the planning effort low. This is why themes are important next too small improvements:
Generally speaking, the Roadmap is an experiment backlog. By implementing a (MVP) solution you learn if it works. On the other hand, you constantly do collect data (i.e. experiments, surveys, interviews) to collect data and see which Theme should go first. I often see some companies read a growth hacking book and then try to be more 'experiment & data-driven' but overshoot by doing too many experiments and concentrate on too small improvements and trying to be too sure of things before moving forward. On one hand, you shouldn't start a roadmap theme for which there is insufficient supporting data, on the other hand, you shouldn't endlessly keep experimenting and collecting data until you are 'sure' a theme will work out. For the 'Fruit Basket subscription' example customer interviews followed by a larger online survey gives you the impression that circa 20% of your customers will order it. You could further proof this by offering it via mail to some of your existing customers and see how many subscribe. However, at some point you some point, you are spending too much time on collecting data on one theme without gaining much more certainty. To quote a famous Amazon principle: If you're 70% sure of something, go for it!
A final point is 'smoke test'/'concierge model' experiments, whereby you only design and develop the first step in a process , and from there on the handle it manually. I.e. in the fruit subscription example one could create an order form in wufoo.com (and accept only payment by invoice). The question often is if this test is really needed. I.e. you could also call 10 customers to check if they would order, and the design of the page will later be tested with a user test. In many situations such a test could also require quite some 'backofficeback-office'/concierge staff that you actually don't have.
You should own it, meaning the process and preparation for the product council, although the whole council is, in the end, the decision maker on the next theme. Read: https://medium.com/@kathmatsumoto/having-trouble-with-owning-your-product-6fdd9b885c3c
Isn't a more gradual check/approve roadmap process better? (i.e. Stage-gate process)
This is more of 'company preference' nature. The Product Council could give more gradual, step by step approval of a Roadmap theme. As a first agenda point the agenda point, the council might select a few theme's themes they want more data to be collected on. As a second point they might approve the start of design of one or two Roadmap theme's (based on the collected data). And a third agenda point they might approve the start of development of a Roadmap theme (based on the Design and User testing that has been done on the design). This more gradual approach prevents theme's from proceeding when the user test results clearly say users don't like the solution. It also helps to prioritize the data gathering (learning/validation/experimentation) efforts by PM, as the Product Council will ask for the the most most important data they need for their decision making. It could however be agrued that could, however, be argued that a good Head of Product / CPO / PM could does not really need the direction from the council for this. An example from "How to create Products that customers will love":
For each product effort (except minor updates or fixes) there are five major milestones ("gates") for product council review and decision making:
- Milestone 1: Review of proposed product strategies and product roadmaps, and initiate opportunity assessments for specific product releases. That is, select the product opportunities to be investigated.
- Milestone 2: Review opportunity assessments and recommendations, and issue go/no-go decisions to begin discovering a solution (=design prototype, do estimate).
- Milestone 3: Review product prototypes, user testing results and detailed cost estimates, and issue go/no-go decision to begin engineering.
- Milestone 4: Review final product, QA status, launch plans, and community impact assessments, and issue go/no-go decision to launch.
- Post-launch assessment: It can be useful for the product council to review the business performance of the products that have launched. The product council may request a presentation on the business results of the product launch, typically 3-6 months post-launch. This sort of accountability will help the council better understand which investments and decisions they made were good ones, and why.
- Intercom - Why 6-week theme's
- Also, note that this page have has several sub-pages that dig deeper into subtopics (see left side menu).
Taking charge of the Roadmap process is one of the core duties of a PM, and it's totally learnable and doable and does not require stellar negotiation or presentation skills and certainly does not require a company off-site (those are great for team building and brainstorming, not for roadmappingfor road-mapping).
Foundations of Roadmapping Success
|Waterfall thinking Roadmap||Agile Roadmap|
|Roadmap work items are feature-based (i.e. payment provider x integration).||Roadmap work items are user need-based (One-time payment by Creditcard or Paypal).|
|Estimated by 1 or 2 people, not always developers.||Estimated by the team including designers and testers, comparing it to past projects.|
|If development is delayed the deadline gets postponed.||If development is delayed the scope is reduced, but the deadline is fixed.|
|Often big projects / large scope||Small as possible theme's (MVP's)|
|Planning doesn't get updated until the first deadline is missed||Constant re-prioritization of the roadmap|
|One big release planned, i.e. 1.0 release on 1st of April.||Intermediate Release every (2 weekweeks) sprint.|
|Planning 6 months or more ahead, with details even far ahead||Don't plan too far ahead. Theme's who are at the top of the backlog get more detail.|
|A team working on several projects in parallel.||Just one theme per team at a time (until the design is done and tested, then the designers can already start on the next theme)|
Companies that need to transition from a more waterfall approach could start with just some of these practices and instead of a 12-month roadmap do a 6-month roadmap.
Feeling you don't really own the Roadmap? You should, meaning the process and preparation for the product council, although the whole council is, in the end, the decision maker on the next theme. Read: https://medium.com/@kathmatsumoto/having-trouble-with-owning-your-product-6fdd9b885c3c
to roadmapping in to road-mapping in Appendix A: Introduction to Roadmapping.Roadmapping is the single most important Product Management process and ensures we are building the right thing. In this process, stakeholders are aligned on what new product features to build based on identified user needs and supporting data. I highly recommend reading the extensive introduction