There are lies, damned lies and roadmaps
(title adapted from @StartupLJackson, but then I discovered that this phrase is actually much older: https://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics)
Does this sound familiar?
The management team sits together and puts everything they can think of on the roadmap for the next quarter. The employees look at it, think ‘This is impossible!’ and after the quarter 15–20% of the roadmap items are actually done. This leaves a bitter feeling in the product teams (“We know it is not realistic, but we haven’t achieved our goals”) and destroys trust in the company’s plans and execution. The management team actually put a lot of effort into it (maybe even a two day ‘roadmap workshop’), which feels like waste.
Why does this happen?
The 5 sins of building a roadmap
- Nobody looks at actual capacity and everybody assumes that the teams don’t have to spend time on maintenance work, bug fixes and other emergencies.
- Putting things on a roadmap might be the only way to get items from teams outside of product done. A common example here is marketing, which often doesn’t have a dedicated team and so sometimes puts things like ‘fix the email system’ on the roadmap.
- The roadmap is done purely top down with very little or no input from the teams. This way roadmaps are not aligned with actual team structure (which is not always bad) and the roadmap is more used to impress board or other stakeholders.
- Put dates to everything — predicting actual dates a few quarters in advance is close to impossible and missing dates is never fun. So defines release dates as late as possible.
- Some people confuse a roadmap with a comprehensive list of everything which will be released (‘fix the font on the careers page to 12px’). Please see below for a definition what needs to be on a roadmap and what not.
But first let’s talk about what in my view a roadmap actually is — in this blog post we are focusing on product roadmaps. This term is used very differently in companies:
A product roadmap is a tool that provides a strategic guidance to team members, business partners and customers. Please pay attention to the word “strategic” here — a roadmap should provide clarity about the strategic direction of a company in the next time (a few quarters) — not about tactical things.
A roadmap is not:
- A list of detailed release dates of all planned features
- A replacement for product backlogs (or whatever your teams use for the concrete tasks of the teams)
- A place where the product leads try to impress other parts of the company with all the crazy stuff they hope they will deliver (but won’t)
But what is a product backlog now?
From Wikipedia: “The product backlog comprises an ordered list of requirements that a scrum team maintains for a product. It consists of features, bug fixes, non-functional requirements, etc.”
So a roadmap heavily influences a backlog, but is only part of it. A bug fix is only part of a backlog, never of a roadmap. Constant iteration on features (making a feature better and better based on user feedback and metrics) is also only part of the backlog.
Before talking about how a roadmap should look like, let’s get into more detail why a roadmap makes sense. We mentioned strategic guidance above, let’s talk about that in more detail:
- It makes the strategic direction visible to other departments (including board).
- To quote Eisenhower: ‘Plans are useless but planning is indispensable’. The actual process of building a roadmap can create a lot of understanding of what the company actually has to do.
- If done right it gives the single teams the understanding how they contribute to the overall success of the company. If a top KPI of a company is Engagement and a team works on a engagement roadmap feature, it should be clear to the team how they contribute to the company’s success.
How should a roadmap look like?
Typically a roadmap contains release names and approximate delivery dates if the confidence in those dates is high enough. Releases should be ordered by priority:
EXAMPLE ROADMAP (assuming it is created end of the year)
Q1:
January: Release completely revamped Android app
February: Release new website design in time for big web conference on the 17th
Q2, Q3, Q4: (ordered by priority — dates get fixed as soon as confidence is high enough)
Internationalization (preparation for entering new markets)
Revamped Statistics (big new feature to excite customers)
Move to new Data Centers (has big internal impact)
Enter Brazil (first market entered outside the US)
Summary:
If you want to create a roadmap which is ambitious, but realistic and gives the company strategic guidance you should follow this basic guidelines:
To make it ambitious but realistic — do retrospectives every quarter and adjust if necessary ,if you don’t have an understanding of your capacity. Include the actual teams in the roadmap process wherever possible and remember: ‘It is better to underpromise and overachieve than to overpromise and underachieve’
For strategic guidance only put items on the roadmap which have strategic value, if there is a need to put other items on it — try to fix it in a different way than polluting the roadmap. To repeat the marketing example from above you could build dedicated engineering capacity for marketing.
Links:
