How to Create a Product Roadmap for a Software Company

Most software development teams these days follow Agile principles. That means they work in quick iterations called sprints, ready to make changes, and move the deadlines.

As a result, long-term planning seems to be unnecessary. But long-time plans are somethings investors love to see.

That’s why you need a product roadmap: to show stakeholders (and your team) how the product will grow over time and why.

In this guide, we’re explaining what a product development roadmap is, why businesses need it, and how to build a roadmap that works for different audiences. Plus, listing some top-rated tools that’ll help you with creating a product roadmap.

A product roadmap is a visual step-by-step plan for the product's development. It may include upcoming features, tech considerations, and show how a product will evolve over time. Roadmaps often look like a Gantt chart or a mind map but for strategic planning. Yet Gantt charts aren't agile.

Product roadmaps help managers schedule tasks by time and milestone, create task dependencies, and check statuses as they work on the entire project.

Here’s an example of a simple roadmap:

But not all roadmaps look like that. They have different shapes and sizes, consist of a single page, or are multipage documents.

But why do you even need to create a product roadmap if you already have the project’s backlog—an ultimate to-do list?

Because backlogs do great only for short-term 'sprint' planning.

Here's how it works: following Agile methodology SDLC, teams write features in the form of user stories, for example, 'As a Rider, I want to be able to use the app to order a vehicle for a ride.' These stories are then put in the product backlog, a prioritized list of work for the development team.

But user stories won't work for a long-time strategy that covers months or the entire year. Otherwise, there would be hundreds of user stories making it impossible to prioritize anything.

As the company grows, developers also start working with teams like HR, legal, and accounting. These teams don’t follow Agile principles, but they need to see the long-time plan.

The roadmap shows the bigger picture to all team members, including teams that aren’t Agile. It doesn’t go into complicated details like a backlog or a project plan do.

A roadmap is NOT:

• Not a project plan. A roadmap isn't meant to go into details of how the team plans to implement features, commit to release dates, or set strict deadlines.

• Not a list of features and requirements. It's all about the strategy, not implementation. While designing a product roadmap, focus on the vision, direction of the products, and the problems you're solving. If specific features are meant to do that, of course, they should be included (just don’t overdo it).

• Not set in stone. The further your planning goes, the more abstract the roadmap becomes. It's impossible to predict the solution of problems for years ahead. There may be ideas, but a company can't stick to a certain course of development.

Roadmaps should remain easy-to-edit and update when the priorities change. It’s better to use specifically designed roadmapping tools like Aha! or ProductPlan. Or at least Google Spreadsheets so that other team members could see the updates right away. We’re going to talk about tools later on.

Companies make roadmaps for two types of audience: external (investors, customers) or internal (product team). You might even want to create two different maps (or different versions of one) for both:

• For investors and customers, the roadmap shows what you're going to do and how you're going to do it. It should be simple and visually appealing.
• For employees, the roadmap helps to make sure everyone is on the same page, and it’s usually more detailed.

Still, there are some things most product roadmaps include:

Let’s briefly review the popular roadmaps types:

1. Timeline-Based

A timeline-based roadmap answers the question, ‘How long are you going to focus on a specific task—and when you plan to complete it?’

The basic reason to add timelines is to give your stakeholders a high-picture view of when and in what order you'll be making progress. Sometimes, companies don't set the exact dates as they don’t want to tie up to specific deadlines. They keep the time-frames high-level—a few months, a quarter, a year.

2. Roadmaps With No Dates

When you're writing a product roadmap for customers or your sales & marketing teams, often the best decision is to focus on themes and strategies, not dates or deadlines.

That's how you earn people’s interest in the forthcoming product while not setting expectations about the day when it comes out.

Same for the marketing & sales teams: you probably don't want to risk reputation telling customers the release date. Or it may lead to the same risk of disappointment in case of a delay.

3. Kanban Roadmaps

Timeline-based and no-dates roadmaps usually present the plan for a great deal of time, like months or even years. On the contrary, a Kanban roadmap focuses on what needs to be done right now.

Kanban is more of a high-level project management view, mostly for internal audiences—developers, product teams, and others responsible for building your product.

You can use statuses for a Kanban roadmap:

• Approved
• Validated
• Ready for estimation
• In progress
• Ready

That’ll inform your stakeholders of the status and priorities of each development stage.

Product roadmaps are must-haves for a few reasons. First, they serve as a way to explain key product priorities to internal and external stakeholders. There's no need to get into detailed sprint schedules or user stories.

Second, roadmaps show how product priorities align with the company's vision and strategy.

Here are some other advantages of building a product roadmap:

• Cater to stakeholders. Investors rarely care about sprints and features, and a roadmap translates tech requirements and Jira tasks into a business language they know.

• Keep your users updated. Sharing the roadmap works when you want users to believe that the development team listens to their feedback. Or show your plans to deliver the features or fixes you've promised to add.

• Coordinate work across multiple teams. Including those that don't follow Agile principles like sales or HR. Or offshore teams that may not yet know your company's goals and vision.

Let’s look at how to build a product roadmap.

Product vision clarifies why you're bringing a product to market in the first place, what its success would mean to the world and organization.

For example, Google Search’s product vision is “to provide access to the world’s information in one click.”

Start with realizing your high-level vision. From there, you can outline goals—specific, up-to-a-year short, and with clear metrics (like get 1,000 customers by the next quarter or earn $100,000 from direct sales).

You can use Geoffrey Moore’s Value Proposition template to compose your own product's vision:

• For: [target customer]
• Who: [target customer’s needs]
• The: [product name]
• Is a: [product category]
• That: [product benefits/reason to buy]
• Unlike: [competitors]
• Our product: [differentiation]

Remember, you're creating the product roadmap to share it in the first place. It makes no use if people—stakeholders, programmers, customers, marketing & sales reps—can't access it.

Make the roadmap available for people who work on the project and check it regularly not to miss updates.

It's a good idea to tailor the roadmap to each audience:

• Investors. Focus on metrics like revenue/growth divided by quarters or month
• Customers. Focus on benefits the product brings and pain points it solves; don't overload the map with details—it should be simple and visually appealing
• Developers. Want tech-related stuff: epics, user stories, challenges—organized by springs or releases
• Sales & mark reps. Focus on customer benefits and product features (be careful with the deadlines, though)

Themes like 'increase website performance' or 'make the app compliant with HIPAA' are too vague to be used by the development team.

It’s a good idea to break them into epics or ever smaller user stories that can be implemented within a sprint (2-4 weeks).

Then you can group the user stories into categories by business or tech similarities. Imagine how users will interact with your app or website and what they may need after the story is implemented.

Of course, you can create a product roadmap using the software already installed on your computer like Google Spreadsheets, PowerPoint, or Microsoft Excel.

But there are a bunch of roadmapping tools that can speed up the process:

• Aha!
• ProductPlan
• Roadmunk
• Jira

Start by figuring out what the main themes will be and placing them on the roadmap. If you're using specific roadmapping software, you can move the themes around later with a few clicks or a drag-and-drop to change the priority.

As soon as you've added major themes, you can move to layering epics and specific features. But don't overload the new product roadmap with every epic and user story. Better prioritize user stories on the backlog.

If you have trouble with estimating or prioritizing stories, use Weighted Shortest Job First formula:

• Priority = Cost of Delay ∕ Job Size

Job Size stands for tech difficulty and the amount of time you need to complete a theme or story.

Cost of delay is based on:

• How important the story is.
• How important it is to complete the story fast (for example, another company is going to roll out the same features in a month).
• How many risks it reduces or what possibilities opens up (you're making a healthcare app and HIPAA compliance should be handled first).

After you've placed themes and epics on the roadmap and prioritized them, it's time to plan the first release. Not all roadmaps include specific dates, but even if they do, these dates may change.

Put themes and epics on a loose timeline to visualize the planned development process, especially if you work in an Agile environment.

Don't commit to deadlines you can't possibly meet and keep implementation details away from your roadmap. As we've said, the roadmap isn't set in stone. Moves by competitors, change of priorities, or resources can force you to change the product's development or release schedule.

As promised, we're listing four popular roadmapping tools and showing how their product roadmap templates look.

Aha! claims to be the #1 tool for developing product roadmaps, with more than 5,000 companies using it (including LinkedIn, Dell, Siemens). Aha! offers six different roadmapping templates: product, IT, project, services, business, and marketing.

Example of Aha! product roadmap:

Pricing: Aha! prices start from $74 user/month for a premium suite up to $149 per month for an enterprise (paid annually).

If you're a small recently-launched startup, you can use Aha! Roadmaps Startup Pack—a heavily discounted plan for 5 users and 40-minute best-practices session.

ProductPlan is another roadmapping tool with a simple UI, drag and drop editor, unlimited roadmaps, and custom views that share different versions of the roadmap for different audiences.

It offers 25+ free roadmap templates, including the Agile roadmap template by sprints, IT strategy roadmap, and product roadmap template.

ProductPlan links with Jira, GitHub, Slack, Trello, Confluence, and other task management tools.

Pricing: Business suite costs $49/month for one user, an enterprise one—**$1,188/annually per editor.**

Roadmunk is an end-to-end tool for roadmap-making. It focuses on collecting user feedback, prioritization, and has a bunch of boardroom-ready roadmaps. Roadmunk is trusted by Amazon, Slack, Cisco, Ubisoft, Expedia, and lots of other tech companies.

Among the interesting Roadmunk’s features is Chrome extension that captures feedback from:

• Email
• Salesforce (and other CRMs)
• Support chats
• All browser-based tools

Pricing: Starter pack costs $19 per month, the most expensive—Professional — $99 per user/per month.

We've also made a roadmap template you can use for planning. Just copy the spreadsheet to your Google account, and you can edit it however you want.

That's basically it! Don't hesitate to edit your roadmap when you collect feedback from stakeholders. New ideas pop up daily, your competitors bring new features, and you shouldn’t lag behind.

An agile roadmap shows your product's overall direction and should be regularly updated as you reach your goals. How often you need to update the roadmap depends on the product and your approach to development. You may do it each week, spring, a month, or quarter.