This is my 2nd post on the topic of “How to build solid roadmaps.” In part 1, I wrote about using two vectors to map out the full set of product opportunities for your product/team/company. The 1 sentence summary is that if you consider all trends (from your internal data to external market data) and all beliefs (from the core beliefs you hold to what you hear/see/recognize your customers need), you can map out the set of product opportunities. It looks like this: The Quibb community provided great feedback, many of whom rightly noted something akin to: “Great, but how do you transform this into an actionable roadmap?” Good question. Beliefs and trends are really the fundamental building blocks. A lot of tactics are required before a roadmap emerges. In whole, the process might look like this:
- Beliefs and trends -> This helps illuminate the full scope of opportunities
- Define priorities -> This forces focus (eg what is most critical next week, month, quarter, etc)
- Estimate impact of items -> This forces clarity (eg what 20% of stuff drives 80% of results)
- Get costing for items -> This forces reality (eg what can we get done)
- Putting it all together -> This forces everyone to exclaim “How could you cut X!?!”
Priorities: It’s critical to define and limit your product priorities, which are distinct from your beliefs. You are entitled to multiple beliefs but not multiple number one priorities. For example, it is quite possible that Phil Libin (Evernote founder) believed since 2004 that his technology would be great for documenting and remembering meals. That is (if it were true) a perfectly valid belief. However, it was not a priority for his team, given that they launched Evernote Food 8 years later. At the highest level, you can bucket priorities into 1) market share and 2) revenue. Market share is about getting customers and keeping them happy and can be broken down into specifics like optimizing user acquisition channels. Revenue comes from having customers so happy they pay you. Again, this can be narrowed to specific priorities. For example, a pre product/market fit start-up might be laser focused on further engaging users in order to get their product well oiled before focusing on acquisition or monetization. Conversely, a later stage start-up considering an IPO or looking to spin up its revenues might completely focus on converting new customers into payers (eg Evernote, which recently re-designed its mobile apps to more prominently feature “Premium” account upsells).
Many factors will determine your priorities (stage of product, funding situation) and this post won’t discuss those. But I will stress the importance of setting clear, stack ranked priorities. My personal preference is 3 priorities for the product (but this could scale depending on your team). No two priorities are created equal. Rank them. As Hunter Walk points out, “hard decisions make great products.” This will help you make trade-offs when putting together a final roadmap and it will help you navigate unforeseen bumps in the future (eg “delays on project X mean we won’t get to all items, what can we cut?”) At this point, you can take all of your concepts (from the beliefs and trends matrix) and see which priorities they fall into. It’s likely that many will be outside your priorities. That’s fine (they’re probably good ideas it’s just not their time in the sun yet). You might end up with something akin to this: Impact: Each item must have a tangible expected impact. This does not mean that you must have specifics like feature A will drive $342K incremental revenue in 2012 (although you could and some companies do operate this way). Rather, the critical component is that each item has a stated, measurable purpose. For example, a re-working of an app homepage screen might be to reduce clutter and drive up a core user action (eg think Evernote’s redesign to highlight grabbing a screenshot of a notebook). Any item will have some measurable impact whether it’s reducing customer support tickets, increasing revenue from a specific channel, reducing sign-up flow drop-off, etc. This will help when finalizing a roadmap and deciding what to keep vs. what to postpone but it has further value in protecting against feature creep down the line (because the feature owners can use the initial stated impacts as a guiding lighthouse). Now your roadmap is filling out. You’ve got the initial items, which fall into your top priorities and estimated impacts for each: In the next post, I’ll go through the final steps of costing and putting it all together. To bring things to life, I’ll use an example (likely Evernote to stay consistent) to walk through the final steps.
(NOTE: I have no official association with Evernote, excepting that of a mostly satisfied user).