If Dorothy didn’t have a yellow brick road, would she have found her way to the Emerald City? Probably not, since she was in an unfamiliar land with no shortage of advice from munchkins, talking trees, and the unlikely travel companions she met along the way.

In Dorothy’s case, she needed a road to get her from Point A to Point B: a way to help her stay the course. The product roadmap for a company does much the same thing. Your product roadmap shows where the product is today, the final destination, and how the product will get there. It is the direct route to the end goal, guiding the team through each phase of the journey (your new features or other initiatives).

Whoever built that original yellow brick road had a tough job, and as the product manager, you'll be picking up where they left off. You are determining the best course for the product. Without the product roadmap, the team gets lost. Whether you’re working on a new product from the ground up or laying the foundation for future success, a lot is riding on your shoulders. No pressure. 😉

If you’re wondering how to create a product roadmap, don’t worry—you can do it! In this article, we’ve outlined some of the key elements to help you create (and re-create) your very own yellow brick roads.

1. Define the overall product vision

You can’t have a map if you don’t know the destination. So before you begin outlining your product roadmap, you need to make sure that you, the stakeholders, and the entire product team are on the same page with the product vision.

Your product vision should describe your product’s place in the world. You can start by answering these questions:

• Who is going to use the product?
• What problem does your product solve?
• Why is your product needed—what sets your product apart from competitors’?

Here’s how the automation platform Zapier describes their product vision: “We want to empower businesses to create processes and systems that let computers do what they are best at doing and let humans do what they are best at doing.”

This vision statement clarifies who Zapier is for (businesses) and why their product is needed (to give humans more time to complete tasks).

If your product vision is vague, try to sum it up in a clear sentence or 2. Pretend you’re explaining your product to a 5-year-old and need to use the simplest words possible. Or take a cue from Zapier and outline the intended user, the pain point, and the solution.

And to keep your product vision at the forefront of everything, tape it to the actual or virtual office wall, so that you are reminded of your product vision every time you talk about your product roadmap and goals.

2. Review ideas for the product

Remember that your product roadmap includes all of the twists and turns to your final destination, and your feature requests are the different routes you can take along the way.

If you already have a working product, you probably have a mountain of feature requests. Even if your product is new, it’s likely you’ve got competitor research or a huge list of features that you want to include to take your product to the next level. But how do you know which ones to include?

“Prioritize the [features] that are most important, most impactful, either to your users or to your revenue stream or whatever that may be,” says Scott Davis, founder and CEO of MobX, in a Stretch Goals podcast episode. “Get those done first. Then, you can iterate over time.”

You’ll first want to gather up alllllll of your feature requests. From there, look at the requests through the lens of your product vision. Does the request make sense, and is it aligned with your overall vision? If not, do yourself a favor and get rid of the request. Don’t save it for the “maybe someday” pile.

With your remaining requests, group them into categories. Maybe some requests are about your mobile app, while others apply to security or a specific feature. This organization will help you manage their priority (knowing you need to tackle security first, as an example) and put related feature requests on the roadmap together.

3. Define the scope for each feature request

Once you’ve reviewed the feature requests, it’s time to start thinking about how they’ll fit into the product roadmap. To do that, you need to know the amount of effort involved in each feature. Is the feature request a 2-week project or a 2-month project? How many team members will need to be involved?

You should map out each feature request’s scope by determining:

• The minimum functionality for the feature to be viable
• Which team members you’ll need to create and deliver this functionality
• Time estimates from these team members for each of the tasks needed to create and deliver this functionality

While you don’t want to get mired in the details (that will come later), you want to make it clear what the feature does and doesn’t include. Scope creep is real, so you need enough to get clear estimates of the resources needed to make the requests happen.

4. Put the features on a timeline

Now your product roadmap is starting to take shape. Plot on a calendar when tasks for a feature request should be completed and who is responsible for these activities.

Your product roadmap should tell you where you’re going for the next 12 to 18 months, at most. The next quarter or 2 will have firmer project plans, and farther out, things will be a bit looser. Your product roadmap is likely to change based on new customer feedback, new competitors, or any number of unforeseen issues.

We cannot stress this enough: don’t plan your product roadmap too far into the future. It may be tempting to create a 5-year plan, but it’s not a good idea, since the product landscape can change rapidly and development can always take longer than expected.

5. Share your product roadmap with stakeholders

Once you’ve created your product roadmap, you need buy-in on the product’s direction from stakeholders at the company—the CEO, a development team lead, sales, etc. Your product roadmap is not created in a vacuum. Be prepared to explain why you’ve prioritized different features on the roadmap along with resource constraints and dependencies (“we can’t do X unless we do Y first”).

Keep in mind that the product roadmap should be an open discussion. You may end up rearranging features based on feedback from your stakeholders. Maybe you’ll need to take a feature to market sooner rather than later or add in another strategic initiative. Or maybe you’ll decide that it will take so long to add a feature that it’s not even worth keeping it on the product roadmap.

6. Set cut-off release dates for features

Once you’ve finalized your product roadmap, it’s time to identify the “cut-off” for releases.

Be sure to set deadlines that give you enough room to give new features and products the appropriate attention (and planning) they deserve. Sure, you may push out smaller features into mini-releases along the way, but big new features or products need to have a plan for the creation and distribution of marketing campaigns and resources about the product.

As you consider your product releases, don’t forget your customers. While some customers will gladly take on new features, others will be hesitant. Major changes can cause product adoption friction, so your releases should include resources like feature announcements, tutorials, and release notes to guide customers. These resources can reduce stress by explaining any new functionality and giving users something to read/watch, so that they understand how it works.

For product releases, you’ll need to include other teams, such as marketing (to get the word out) or customer service (to support customers as they adopt the new product). Depending on the size of your team, you may only be able to handle a few major releases per year.

Adjust your product roadmap when needed

Unlike the yellow brick road, your product roadmap is not set in stone. External forces may shift the product roadmap in unexpected ways (did someone say 2020?).

As a product manager, you should know how and when adjustments are needed—and when to raise a red flag. By communicating early and often, you can keep everyone updated on why and how changes may need to be made.