Lean Roadmaps for internal teams

Roadmaps for your internal teams are one of the key artefacts to produce as a Product Manager.

We’ve already discussed why public roadmaps are a bad idea. Many of those reasons hold true for traditional internal roadmaps as well.

On the surface, they look harmless. Worse than that, they actually look like great planning. They often revolve around the pillars of project management; scope, time and resources of all the upcoming work, often months in advance and in great detail.

Upon seeing things are under control, senior management often ticks the ‘roadmap’ box and moves on to other matters. All is well.

Except it isn’t.

Roadmaps are a false sense of control. This is because they are built on project management principles of scope, resources and time. This approach works when you are building a known solution with little variance; such as an apartment building.

Product management is different. Whilst you often know where you want to go, you don’t necessarily know the best way to get there. The what and how are uncharted territory. Product Management instead revolves around finding solutions that are desirable, viable and feasible. That is to say:

  • Desirable: Do Users want us to build this?
  • Viable: Should we build this?
  • Feasible: Can we build this?

By trying to forecast the exact what and how so far in advance on a traditional roadmap, you leave your team very little room to pivot.

It is at this stage that any number of unconscious biases can come into play to ‘stick with the plan’. Let us view them through these through the eyes of Sam, our hypothetical Product Manager.

Selection perception – This is a mental shortcut people take to only see info that supports their previous interpretation. Despite growing evidence to the contrary, Sam thinks “Overall, this project still looks worthwhile.”

Availability heuristic – The tendency to base judgements based on available data, at the expense of accuracy. “This feature has a lot of votes from users, so we need to do it.” says Sam.

Escalation of commitment – with each investment of time, money and brain-power into a project, the harder it becomes to kill it off. Everyone can relate to an experience where a project or feature had been dragging on far too long, despite all signs pointing to the fact it was a failure, only for management to dig their heels in and keep going. Sam exclaims “We’ve come this far – we can’t stop now! At first everyone knew this as Sam’s “pet project” and didn’t want to upset him. Over time, it became the project they always worked on. They were on a mission and it was part of their culture. This is also known as the sunk-cost fallacy; that because so much has been invested, people feel they will be losing all previous investment if they do not continue.

Yet that is not how it works in economics. The money and time are already spent. They cannot be recovered. The only thing to evaluate is whether to spend more, or whether there is a better opportunity to divert those resources to.

Ultimately the project limped across the finish line with disappointing performance. It was a large waste of resources with a large opportunity cost.

Sam needed a better way. How could she update the unwieldy roadmap to minimise waste?

Behold the Agile roadmap.

Source: Gothelf, 2019

I’ll discuss each of the various pieces that make up the Agile roadmap.

Objective & Key Results (OKR) framework allows for multiple layers of goal setting throughout an organisation.

They could begin at the company level, then down to product, and finally to teams. The key is to have both vertical and horizontal alignment. Vertical meaning that the teams will be working on initiatives that flow up to company-wide objectives, Horizontal alignment so that they are working towards common goals with other teams around them.

This might sound obvious, but teams can work against each other, whilst having the best intentions and trying to move the metric they were given. Here are some examples:

  • Sales team over-promising to get the sale (and hit their KPI), whilst Customer Success is measured on NPS. Due to unmanaged expectations, Sales is driving up against CS.
  • Development team being measured on velocity, whilst Operations is measured on service level agreements (SLA’s). Development introducing bugs now hurts Operations.
  • Support being measured on first-call-response and response time, whilst Development is measured on NPS. Support never raise ‘common + easy fix’ bugs with Development, as they can turn those around fast (thus make their numbers look good). Meanwhile the customers that call the centre often to have these bugs fixed are unhappy and give a poor NPS rating. Development never had much chance to impact that number.  

Some OKR’s should be time boxed to timescales of a quarter. This is for multiple reasons. It will be more motivational (or less demotivational) for the team to have a medium term goal to work towards. Any timescale too short, and people think it unrealistic. Too far away and people will slow down to ‘fill up’ the perceived space.

Timeboxing OKR’s to a quarter also gives a natural break point for any long-running projects suffering from escalation of commitment to be halted and reconsidered.

Finally we have the ‘features we may build’. These are the one-pagers and features-as-bets that align with the quarterly OKR that align with the quarterly OKR.

Here the team would innovate, getting ideas from internal and external sources, quarterly OKR. The best ideas would be outlined as features-as-bets using the one-pager template.

Note the team doesn’t commit to any one ‘bet’ at this stage. Over the course of the quarter, they will be validating assumptions and trying experiments to learn which of the proposed features are desirable, viable and feasible that meet this objective.

We’ll build out an example of a Agile Product roadmap using a hypothetical company that makes software for Veterinarian.

Company-wide OKR:
Become the most loved Vet Software on the market. Have the highest NPS in regions we support.

Quarterly team OKR:
Increase business outcomes for Vets. Lift their revenue by 20%.

Features we are considering:
-New SMS recall system to bring back existing customers
-Email campaign support
-Google Ads integration
-Revamped Online Booking engine
-Revenue Dashboard

So we have our roadmap, our bets have been placed, and it’s time to get down to work. Where do you start? With a RAT.


Any proposed feature will have various assumptions attached to it. A RAT is a ‘riskiest assumption test’ (Higham, 2019). If your riskiest assumption turns out to be false, it will be a point at which the team needs to decide whether to pivot or persevere. If you persevere you will move onto the second RAT. If you pivot, you will move onto the first RAT of the new direction. You may decide to put the feature on ice totally and move onto the next.

So how is this different from an MVP?

Somewhere along the way, the definition of MVP lost it’s meaning. It was originally more of a RAT, however increasingly MVP is used in reference to a first iteration or beta product. It was far more work than was needed than to test the riskiest assumption, and yet it was not enough for customers to actually like it either.

New variations on MVP came out to differentiate that gap between launch and customer delight. MMP (Minimal Marketable Product), MLP (Minimal Lovable Product), MDF (Minimal Delightful Feature) and more. When you are planning features-as-bets to hit a quarterly OKR, you don’t have time to waste by creating the wrong M-acronym.

A riskiest assumption test need not even involve code. It could be any number of:

  • Data-mining or data analysis of existing product usage
  • Survey and NPS results
  • Phone interviews and focus groups
  • Design mockups
  • Competitor analysis

To combat confirmation and availability heuristics, we need to search for disconfirming evidence. We can’t simply stop at the first data point that indicates we’ve made the right choice. This is easier said than done. How often have you hit Google’s home page, convinced an opinion you held was fact, and searched for evidence that aligned with that? Rarely do people go looking for evidence that would debunk their beliefs.

The reason for this is to avoid cognitive dissonance; the state of mind where two opposite things are true. Your brain does not like to hold conflicting information, so it will one in favour of the other; typically preferring to keep it’s original stance.

Let’s update our Agile Roadmap with our RAT progress.

Assume we had previously arranged the features in WSJF order. Looking at the new SMS recall system, our riskiest assumption was the design. It included a number of components, including templating and scheduling. So the team create paper mockups and had our beta group work through them. There were some adjustments to make, however overall we mitigated the rat. It could now progress into development.

Google Ad integration was another highly requested feature. The risk here was the integration piece between our legacy backend and the Google API’s. Some tech debt was uncovered and the overhaul involved simply wasn’t worth the value this feature would bring. The RAT failed, and the feature was iced for now.

The team had anecdotal evidence that their Users wanted ‘better’ email campaigns. They weren’t clear on exactly what that meant. So the risk was building the wrong thing. They analysed the email data in their production system. Upon studying the habits of our 10,000 users – when they sent emails, what kinds of emails, who did they send them to – we were able to group use cases into buckets that we could then look to help automate for customers. It would progress into the design phase.

Through prioritizing, analysing and testing, the Agile roadmap helps ensure the team is delivering value with the ability to persevere, pivot or punt as required.


Gilad, I. (2019). Why you should stop using product roadmaps and try GIST Planning. [online] Hacker Noon. Available at: https://hackernoon.com/why-i-stopped-using-product-roadmaps-and-switched-to-gist-planning-3b7f54e271d1 [Accessed 29 Jan. 2019].

Gothelf, J. (2019). What does an agile product roadmap look like? – Jeff Gothelf – Medium. [online] Medium. Available at: https://medium.com/@jboogie/what-does-an-agile-product-roadmap-look-like-cf0dbe5be4ef [Accessed 28 Jan. 2019].

Higham, R. (2019). The MVP is dead. Long live the RAT. – Hacker Noon. [online] Hacker Noon. Available at: https://hackernoon.com/the-mvp-is-dead-long-live-the-rat-233d5d16ab02 [Accessed 29 Jan. 2019].

Leave a Comment