Building product road maps

You have an amazing idea. You’ve taken the core concepts of your idea and turned them into a prototype, a Minimum Viable Product (MVP). The prototype is the first pass. It’s not pretty, nor complete, and often not tested. Frank Robinson said when he coined the MVP term:

… think big for the long term but small for the short term. Think big enough that the first product is a sound launching pad for it and its next generation and the road map that follows, but not so small that you leave room for a competitor to get the jump on you.

Once you have your prototype and you know that it’s viable, how do you turn it into a fully-fledged product and how do you get there? Enter the product road map.

This post is an introduction to product road maps and presents a high-level structure for road maps and a process for how to build them. We assume you’re using an Agile (or Agile-ish) methodology, but we’re not strongly opinionated about what sort of Agile you embrace. This isn’t a definitive guide to product road maps but a starting point from which to get started, experiment, and learn what works for you.

What is a product road map

A product road map is a plan for your product. It’s a strategic document that helps you plan for your product, its growth, and keeps your team on track in executing on that growth. It is what allows your Product organization, and your Product Managers, to know and report where you are, where you’re going, and what the steps are along the path.

A good road map is the “north star” for your product. It connects the long-term vision your organization has for the product with the operational and customer reality on the ground. From your road map, your Product and Engineering teams derive the list of work that they’ll undertake and populate backlogs.

A living document

A road map is a living document. Its development is iterative and organic. It changes as priorities and focuses change, as the product grows, you learn what product market fit looks like, and you learn from your customers. A real product road map is never finished.

How often you update your road map usually depends on how mature your organization is, early-stage startups probably have road maps that range out 3 to 6 months and are updated monthly. A larger or more mature organization might plan quarterly with some, less stable, future plans laid out for coming quarters.

A collaborative, iterative, and data-driven document

A great product road map is a collaboration between many partners across your organization. Owned and collated by your Product team, it draws on inputs from internal groups like Engineering, Support, Marketing, and Sales. It is also driven by external data collected from your product, your customers, your competitors, your investors, and the market.

A good Product Manager is constantly gathering this data, validating, and feeding into the road map, and seeing how, or if, it impacts plans. The Product Manager is also feeding in the outcomes of the ongoing work you’re doing, whether the features you have build had an impact on metrics like user adoption, customer satisfaction, or whatever else drives your business.

The outcomes from our road map then become part of the inputs, together with the continuous data gathered from the other sources, and combines to form an iterative, cyclical, document.

A road map isn’t easy

A product road map is hard to make. It’s a balancing act of finding the right features to build, evaluating customer asks versus product goals (like avoiding being captured in the orbit of a single large customer!) and then applying the engineering and design resources you have available to you.

Let’s look at the high-level components that make up a road map.

Why, always start with why

The product road map is the strategic guide to building your product. Every road map should open with the mission:

• Why are you making this product?
• What problem are you solving?
• Who are you building it for?

If you can’t answer these questions or haven’t yet done so, then you need to rethink building a road map or developing the product in the first place!

The art of defining a mission is beyond the scope of this post but remember that everyone in your Product, Design, and Engineering teams should be able to give the product’s “elevator pitch” and understand and absorb the answers to these three questions. They provide those teams with a reference point to validate the work they are doing is the right work and that it is adding value to the product. Both key drivers for engineer happiness. If you can’t connect work to the mission (or engineering tooling that accelerates your development) in some way, then it’s probably a good indication that it is work you should not be doing.

Know your audience

In addition to knowing who you are building your product for, you should know who you are making your road map for. Every audience of a road map will have different expectations: what investors, your executive team, or your customers want to see is different from the needs of your product and engineering teams. Since your road map can’t be all things to all people, you’ll need to consider different formats or documents for these different audiences.

You will want to produce a high-level presentation with quarterly milestones for investors and executives. They are interested in your high-level goals and the total time and cost of development work. Customers (and Sales and Marketing) want to see what features you’re adding that will give customers more capabilities or make the product easier to use. Your product engineering teams are looking for lower-level tactical information, sprint and story-level, that will tell them what to work on right now.

This revelation often prompts a debate about the single source of truth for your road map. If suddenly you have data in multiple places, then you need to update them all when something changes. This is where an off-the-shelf road map tool starts to come in handy. There is a wide selection of potential tools ranging from add-ons or extensions to common ticketing frameworks like Jira, GTD planning tools like Trello and Asana, or specifically product-centric road map tools like Clubhouse. These tools allow you to have a single source of truth and output the data in a variety of forms, suitable for varying audiences. If you don’t already have a tool, then we recommend you try a few to find one that suits your team. And, don’t forget to consider some growth: will it still work for your team in 6-12-18 months?

Prioritization

As we mentioned earlier, one of the critical differences between a backlog and a product road map is prioritization. You’re never going to have the resources to work on every aspect of your product at once, so you need to prioritize the work. There are numerous approaches to prioritization, too many to cover in this post.

If your ideas are starting to pile up, this is an excellent opportunity to leverage a prioritization framework, such as the Lean Startup’s 2×2 grids or weighted scoring models to eliminate low impact ideas further.

What we’ve discovered in working with teams though, is that nothing deflates morale more than a seemingly arbitrary process of prioritization, this doesn’t foster good team relations and productivity. So pick an approach, establish and agree to it with your team, and be transparent about the process, especially any exceptions you make to the process like “the CEO says we should build…”!

Build from the top down

Now that you’ve added our mission to your road map let’s continue to work top down; from the least granular component to the most granular.

• Mission: your reason for building the product, we’ve discussed this above.
• Themes: high-level components of the product, for example, “Acquire new customers.”
• Milestones: groups of epics, time-boxed, for example, three months worth of work.
• Epics: collections of user stories that often represent a feature, for example, Authentication.
• User Stories: user-centric stories that describe a requirement. Usually collected in an epic.

We always recommend this approach because the top-level components are closer to the mission and should be a logical progression of detail, easily rolled up and tied to that mission. The alternative, starting from the base and writing up a series of user stories, leaves a lot of space between your mission and its practical application. We find if you start with that base you end up twisting the top-level components into the shape of the user stories and not vice-versa.

So we start with breaking our product into themes.

Themes

Themes are the present articulation of some aspect of the overall mission. You break down the journey to mission success into the current themes you need to focus on to continue that journey. A theme might be: “Acquire more customers!”, “Reduce customer churn” or “Increase stability of notifications.” They could also reflect internal priorities: “Streamline deployment!” or “Reduce test suite run time.”

Themes provide the glue between the mission and the tactical work to be done to execute on the mission.

A good theme can be clearly traced back to the mission but also has direct and immediate outcomes and measures. Themes should be tied to measures and metrics that demonstrate the impact of the theme, for example, if the theme is to acquire new customers, then the measure might be a customer acquisition target.

Themes are also an excellent way to communicate progress to stakeholders:

This quarter we’re going to focus on reducing customer churn by 20% by working on the look and feel of the UI, adding a recommendation engine, and the reporting capabilities of the product.

A theme, or a variant of a theme, will likely be repeated throughout a product’s lifespan, so it’s important to be as explicit as possible about the theme and what it achieves in this particular incarnation. This also ensures you keep your theme focused and you make it achievable.

Next, let’s think about milestones for our road map.

Milestones

A milestone is a collection of themes, epics, and stories. It might be a version of your product, for example, version 1.0 or it might be a month, three months, or another period. We strongly recommend time-boxing milestones, either explicitly by adding a target date or using a time-based interval like months or weeks.

Each milestone usually has a few themes associated with it. A milestone also allows you to report what you’re going to achieve to address that milestone and will enable you to measure progress towards that goal. This is likely the component that your leadership team or customer will be most interested in your reports on. So you need to be realistic about what you can achieve in a milestone.

This quarter we plan to focus on two themes: “Acquire more customers!” and “Reduce customer churn.”

Startups tend to be fast-moving, priorities and resourcing and requirements change quickly, so most people don’t plan milestones beyond short and medium periods, for example, 1-6 months. Anything beyond that starts to become more like guesswork than planning. We suggest planning 2 milestones, say month 1 and month 2, so you know what you’re doing now and broadly what you plan to do next.

Epics

Contained inside of your themes are epics. Epics are collections of stories, generally aligned with a feature of some kind. Earlier in the post, we talked about a theme of “reducing customer churn” and how it included working on look and feel, a recommendation engine, and the reporting interface. Each of these can be broadly considered features. So our recommendation engine feature would be described as an epic. To build that engine you might have an epic called “Recommendation Engine,” perhaps containing user stories for:

• The back end engine.
• A data pipeline.
• The recommendation algorithm.
• The recommendations interface.

Each epic should have a description and measures of success. For our recommendation engine, this might be:

An engine that returns product recommendations based on customer’s prior purchases. The recommendation engine must return the customer a minimum of 3 recommendations within 1ms.

Like themes and milestones, epics are about achievable and measurable goals. You might be thinking “we’re measuring a lot of elements in our road map,” but this is key to having a realistic road map. At every level of the road map, you can determine progress towards objectives, what success looks like, have a clear measure of it, and adjust the objectives and measures if circumstances change. This allows you to understand where the product is in terms of completion and success and is critical to managing your product’s delivery.

Inside our epics are user stories, the basic unit of work for most product engineering, let’s look at them now.

User stories

User stories are the base artifacts for Agile planning. A user story is a high-level definition of a requirement. It should contain enough information that the requirement is understood and a reasonable estimate of the effort required to build it can be made.

User stories are written throughout the development life cycle, but the core of them are usually written when you create an epic. Typically, the whole team involved, and often stakeholders from the business or even customers, and the stories are written in a workshop-like forum. Further stories will evolve as the epic proceeds, to address new requirements or to split existing stories that have become too complex. Some stories will even evolve into epics in their own right if they turn out to be very complex or emerge as functionality worth extending.

A good user story contains a summary of the requirement, no more than one or two sentences, a series of stories about the requirement, a test of the story’s success, and a rough estimate. Those stories typically follow a format something like:

As a < type of user >, I want < some goal > so that < some reason >.

They tell the story of what the user wants, expects, and needs from the requirement. Let’s look at an example story for our recommendation engine.

1
2
3
4
5
6
7

    Build a content-based recommendation algorithm.

        * As a customer, I want to see recommendations based on my prior purchases, so I can find the best items to buy.
        * etc...

        Test: The algorithm returns three content-based recommendations for a customer’s user ID.
        Estimate: 3 days.

This is a very formal user story, a lot of organizations often use more lightweight and informal representations. If a story feels like it has too much detail, then the traditional approach is to split the story into smaller stories.

Go build

These are the building blocks (or at least one approach anyway!) of a successful and useful product road map. We want to leave you with some parting points that have served us well in working on road maps and with Product teams.

• Find a good tool that works for you to manage your road map. The less labor you spend on administering your road map, the more time you can spend on managing your product.
• Be transparent and honest with your team and leadership about the road map process, prioritization, and progress. Nothing breaks team morale and the faith of leadership in a startup faster than a breach of trust here.
• Be inclusive of everyone in your road map process, both by seeking folks out as inputs and by sharing the status and outputs widely with the company. Your all hands or all company communications should always include product updates.

Good luck and we hope this will prove useful to you. Go build some awesome products!