How to build a solid roadmap: Part II

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:

  1. Beliefs and trends -> This helps illuminate the full scope of opportunities
  2. Define priorities -> This forces focus (eg what is most critical next week, month, quarter, etc)
  3. Estimate impact of items -> This forces clarity (eg what 20% of stuff drives 80% of results)
  4. Get costing for items -> This forces reality (eg what can we get done)
  5. Putting it all together -> This forces everyone to exclaim “How could you cut X!?!”
NOTE: When I first started, I thought I’d plow through all 5 points in a single post. I failed, and part 1 basically covers point 1. This post will focus on points 2 and 3. 4 and 5 will be for a future post.

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).

8 thoughts on “How to build a solid roadmap: Part II

  1. Pingback: How to build solid roadmaps: Part I | Kivestu's blog

  2. hunter walk

    thanks for pointing me to this via twitter. appreciate you taking the time to share your approach to the dark art of product planning :)

    1. admin Post author

      Thanks Hunter. If you’re on the hunt for more great blog posts and discussion, I’ve found Quibb to be really great at curating blog posts and fostering discussion around them.

  3. my blog

    I’m very happy to read this. This is the kind of manual that needs to be given and not the random misinformation that is at the other blogs. Appreciate your sharing this greatest doc.

  4. Alan

    This all (roadmaps and the roadmap process) really strikes me as silly, busywork for ‘product managers’ to do. It just seems like a way for upper management and investors to feel justified in trusting someone to lead a product or part of a product. I never take anyone seriously when they brandish a roadmap – to me it’s just a house of cards built of assumptions. Asking a PM for a roadmap is as silly as asking Lewis & Clark for their ‘roadmap’ before they set off on their exploration.

    How am I wrong?

    To me there is no roadmap (‘roadmap’ denotes a known starting point, ending point and how to get there) but instead a never ending process of exploring the product space; you’re searching for a missing solution in the market which your team is working to solve ( and monitize ).

    I’d like to read your thoughts about why we need a roadmap… and what actually IS a roadmap.

    1. admin Post author

      Thanks for the reply. At a very high level, I see a roadmap as a plan. So you can either have a) a plan OR b) no plan.

      The plan (read: roadmap) is 1) driven by your beliefs about what is important 2) reflects your goal(s) (prioritized for importance) and 3) contains the list of items that will carry your team/product/company from current state toward your goal(s) at the highest velocity possible. The starting point is when you write the roadmap and the end point might be a qtr away, a year away or five years away. While the iteration on the product might be theoretically endless, that doesn’t suggest you shouldn’t bring your full mental faculties to bear on the key efforts you can pursue to build the best product you can.

      So why have a plan? Plans focus scare resources on the most important problems to solve. Time, resources, funding and everything is finite and running out. The plan focuses those resources on the best course of action. There are definitely different types of roadmaps (and you’re right that larger companies are likely to have more robust, formal roadmaps) *but* at the end of the day, a good roadmap is just a plan to execute against the best ideas. A roadmap can always be tweaked, course-corrected or even completely scrapped in light of new discoveries (eg “user data shows X!”) or platform changes (eg “crap! FB just launched our feature…”).

      Plans (again, read:roadmap) are how things get done. JFK didn’t show up at NASA and say “Hey guys, it’d be cool if you took some of those space toys and did something awesome.” That is not what he said. He said, “Put a man on the moon.” And then they put a man on the moon. Someone defined a starting point (no man on the moon), an end point (a man on the moon) and then people figured out what features were needed to get from A to B. That’s a roadmap and it gets things done.

      1. Alan

        I caught your post again via the @svbtle feed. I missed this response earlier.

        I would like to hear more about what you consider a roadmap and the context of organizations which would use one. That would be a nice blog post and would help the product design community.

        I ask because this response sounds like ‘plan’ is being used interchangeably with ‘roadmap’. This can be a problem because not only does ‘plan’ have wide interpretation, but so does ‘roadmap’.

        The NASA example doesn’t translate well to the topic of product and roadmaps. NASA didn’t have customers to please and a market to compete in. They were solving a technical problem for themselves – not building a business. You can do a ‘roadmap’ in these circumstances because you know what you know and what you don’t know.

        The reason why roadmaps fail ( I’ll define roadmaps as detailed instructions on how and when to implement specific features for a product beyond the near future ) is because, unlike the NASA example, it’s not what you know you do / don’t know it’s what you don’t know what you don’t know . You’ll probably also remember Rumsfeld describing it as the ‘…unknown unknowns.’

        I would also like your opinion on David’s post You don’t need a product road map

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>