You're reading for free via Lucas Didier's Friend Link. Become a member to access the best of Medium.
Member-only story
How to build a product roadmap
An attempt to solve this product manager’s puzzle.
Over the past 7 years, through several product management roles & freelance projects, I’ve learnt a lot in terms of building product roadmaps. This is one of the most challenging exercises you can be faced as a product manager. Because you have to make sacrifices. And because you’re faced with a lot of pressure, whether it be internally, from other teams, or externally, from your users.
In this post, I’ll try to give a few tips I’ve gathered from my own experience and from product teams working for inspiring companies like Intercom, Basecamp, Front and Slack.
What is a product roadmap?
A product roadmap is the exercise of turning a messy list of projects into a prioritized, visual summary of the product team’s priorities for the next weeks/months/years. It enables the product team to plan and communicate their view of the future that they have for the product.
There are 2 key elements in building a product roadmap:
- Prioritizing projects
- Visually communicating the roadmap.
Prioritizing projects
Cost / benefit = ROI
There’s only so much a product & engineering team can achieve within a fixed period of time. Not everything can be done. That’s why projects need to be prioritized. How? The basic method is to assess the cost and benefit of each project.
By doing so, you can deduct the ROI (Return on investment) of each project turn an unordered list into an ordered list.
But this remains very conceptual. “Time to build” can easily be measured if you have basic wireframes of your solution and show it to your engineering team. But how can you scientifically measure the customer value?
Value for the company, value for the customers
In reality, “Customer value” is often a mix between “Value for the company” and “Value for its customers”.
And some companies even implement features that are only generating value for them, but not for their customers. Look at the example of Ryanair’s travel insurance UX: if you didn’t want to get insured, you had to choose “Don’t Insure Me” in their country list dropdown.
This generated a massive backlash from lots of consumers who lost trust in the airline company.
This difference of balance between “value for the company” and “value for the user” is what differentiates user-centered product teams from growth-centered product teams (following Ariel Verber’s great post The 6 Types of Product Teams You’ll be Working In).
A user-centered product team puts its users above all other company KPIs. Example of such teams can be found at companies like Basecamp or Duolingo.
A growth-centered product team is a team who’s mostly looking at KPIs. Example of such teams can be found at companies like LinkedIn or Booking.com.
Prioritization frameworks: The RICE example
Anyway, let’s get back to our prioritization topic! We saw ROI as the most basic way to prioritize projects. But some companies have come up with their own prioritization frameworks. For instance, Intercom has created the “RICE” framework.
“RICE” stands for Reach, Impact, Confident and Effort:
- Reach: How many people will this impact? For instance, if I’m working on the revamp of the Events feature (used by 15% of the users) on the Android Facebook app (which has 500M users), the reach is 75M users.
- Impact: How much will this impact each person? The idea here is to choose an arbitrarily defined impact score. Intercom advises to take a range from 0.25 (for minimal impact) to 3 (for maximal impact), which will act as a coefficient.
- Confidence: How confident are you in your estimates? This is a percentage of probability.
- Effort: How many “person-month” will this take? This is purely an engineering estimate.
This framework is great if you have no starting point. Here are a few other personal ideas of criteria to take into account in a projects prioritization:
- Real user problem: You can create a score, from 0.25 to 3 like for the Impact score, to define whether your project solves a real user problem or whether it’s purely a “value for the company” project.
- Alignment with company strategy: Sometimes you need to push opportunistic projects that aren’t necessarily aligned with the long-term company strategy / product vision.
- Competition: How much does this project enable your company to differentiate itself from the competition? In highly competitive verticals, this is a really important criterion to take into account.
Last word on prioritization: There’s no ideal recipe. You should iterate until you find your own prioritization framework that corresponds to your product, industry, metrics and values.
Visually communicating the roadmap
Once you’ve prioritized your projects, you can start communicating your roadmap to your stakeholders (your team, your company, your partners and your customers).
At this point, you might be facing something like this:
No one will want to read this cumbersome spreadsheet. So, the next step is to turn this messy list of projects into a visually compelling document.
Which format to choose?
My tip #1 is to avoid building a GANTT diagram.
It’s a massive source of headaches, never up-to-date and never respected.
I found it easier for other teams & clients to read roadmaps in a kanban way, with one column per status. Slack Platform’s Roadmap for Developers is a good example.
If you want to build a simple roadmap that’s easily readable, I would strongly recommend to use Trello or Notion.
The deadlines’ headache
My tip #2 is to avoid giving deadlines as much as it is possible.
In software, requirements often change and there’s a high part of technical uncertainty that makes it tricky to announce a launch date too much in advance.
For instance, on their public Trello board Front Product Roadmap, Front publicly shows the projects currently being coded but doesn’t give any deadline. All currently developed projects are displayed under the column “Coming soon”.
Of course, not giving deadlines might create problems for some teams who depend on them in their daily job.
That’s why Intercom found a compromise for the product & engineering teams to work in harmony with sales & marketing. I attended the Intercom Tour 2017 conference in Paris. During his talk, Paul Adams, VP Product at Intercom, detailed how they’re internally dealing with deadlines.
Every quarter, Product & Engineering teams announce a list of projects they intend to work on during the quarter — without any deadline. They only announce deadlines 2 weeks in advance, when they have a 99% confidence that their project will be safely delivered. This gives a minimum level of information to sales & marketing team, who largely rely on deadlines to establish sustainable relationships with their prospects and clients.
Problems vs. features
Another useful insight from Paul Adams during this talk was the importance of creating problem-oriented roadmaps rather than feature-centered ones.
Why is it so important? From the moment a product team starts tackling a problem until a solution is actually shipped in production, dozens of possible features might be considered. Through user research, technical limitations and company strategy, the team will iterate until everyone agrees on the right solution. That’s why announcing a specific feature in your roadmap early on might be deceptive down the road.
To sum it up, here are my tips to build a product roadmap:
- Prioritize your projects by assessing engineering cost and benefits (for your users and for your company). Get inspired from prioritization frameworks like RICE. Come up with your own prioritization criteria!
- Visually communicate the roadmap. Avoid GANTT diagrams. As much as possible, avoid deadlines. Use a simple tool, like Trello or Notion.
Feel free to react if you have any other tips. Enjoy building roadmaps!
Want to get more product tips? Sign up for my monthly newsletter to stay in touch! 👉 http://eepurl.com/gYTX2b
Need product/UX consulting on your own product? Check out my services! 👉 http://www.lucasdidier.com
