Think back to the last time you took a road trip with a group of friends. If you’ve never taken one, just work with me here…
When you started tossing around the idea of driving cross country, you most likely had a final destination in mind. And that’s about it. “Let’s drive to Austin”, for example.
As you chatted with your pals, though, your plan became more and more fleshed out. You pinpointed major landmarks you wanted to hit, discussed potential routes to take, and began thinking in terms of the logistics for the trip (e.g., where and when you’d stop to eat, sleep, and relax).
What you didn’t do, though, is plan out the exact route you’d take on your journey, or the exact times you’d stop to rest. Because so many things could happen along the way – road closures, flat tires, exhaustion, and more – it just wouldn’t make much sense to plan out every little step of your trip. In fact, should an unanticipated problem arise along the way, such rigid planning could actually end up derailing your trip altogether.
Creating a product roadmap, then, is a lot like planning for a road trip.
It defines your intended goal, as well as your general plan for reaching the goal – but it also allows for maximum flexibility throughout each step of the product-creation process.
In this post, I’ll describe multiple ways in which to design a product roadmap, as well as how to determine what should be included in a specific roadmap.
But first, let’s make clear what product roadmaps actually are, and explain the main reasons for creating them.
What Are Product Roadmaps And Why Should You Use Them?
As we said earlier, a product roadmap is a strategic document that summarizes and plans out your overall vision for a product to be created.
A product roadmap defines the product to be created, the reason for creating it, and how the creation of said product melds with your company’s overall mission and vision.
Additionally, product roadmaps ensure that all involved parties stay on the same page at all times throughout the creation process, and that everyone is able to anticipate and navigate roadblocks and pitfalls along the way.
Lastly, product roadmaps give everyone involved a general idea of the logistics behind the creation process, such as the time, money, and other resources to be used throughout.
Absent a product roadmap, the process of creating a new product or service can easily go off the rails in a number of ways:
- Team members can become disjointed
- Minor issues can become major problems
- Resources can end up being wasted
Most importantly, though:
Without a properly defined mission and vision for the product in question, a team may end up creating a product that, quite simply, has little to no value to their target customers.
Just as a road trip is planned through a collaborative effort between everyone who will be along for the ride, a product roadmap is created through input from those involved in the creation, implementation, and use of the product in question. These individuals include:
- Members of all teams within the company (sales, marketing, design, support, and more)
- Current and prospective users and customers
- Other stakeholders, such as partner companies and investors
We’ll talk a bit later on in this article about how to solicit and use buy-in from your target customers when developing a product roadmap.
Before we do that, though, let’s look at three different ways you can structure your product roadmap – and when to use each of these structures.
Product Roadmap Structures
When it comes to creating a visual representation of your product roadmap, you have a few options:
- Theme-based structure
- Timeline-based structure
- Product-Line-based structure
Before we discuss the details of each, understand there is no single “best” product roadmap structure. Rather, the most effective and efficient structure to be used depends largely on your purposes for creating a product roadmap in the first place.
Let’s take a closer look at each structure to clarify this a bit.
Theme-Based Product Roadmaps
As we alluded to earlier, one of the main reasons for creating a product roadmap in the first place is to define why you’ve decided to develop the product in question.
A theme-based product roadmap puts this “why” front and center, and encompasses all the actionable parts of the plan within the overarching vision.
For a moment, imagine if the theme was missing from the above image.
A stakeholder or team member would probably be able to discern that increasing mobile support, streamlining credit card payment processes, and enhancing the overall user experience would improve the product in question in some way. But it’d be nearly impossible to conclude that these improvements are being made for the purpose of improving shopping cart completion.
In turn, team members and stakeholders might inadvertently end up taking the project in a different direction entirely – detracting from the original purpose of the project in the process. For example, the marketing team might suggest the company create more instructional content to help inform prospective customers of their product’s value. While this will probably improve CX on the whole, it wouldn’t necessarily affect cart abandonment rate in any meaningful or measurable way.
On the other hand, by clearly stating the overall theme of the project, the focus for all of the subtasks becomes clear, as well. In the example above, it’s easy to see that the improvements to mobile support initiatives, credit card payment processes, and overall UX are to be made with a specific focus on improving shopping cart completion.
Theme-based product roadmaps not only make it easier for teams to focus on improving specific areas of their service, but they also make it easier for teams to tell whether or not the improvements they made were effective with relation to their defined goal. In the above example, the company would revisit its shopping cart completion rate after implementing the designated improvements to determine whether the venture was successful or not.
Finally, theme-based product roadmaps are optimal when sharing information with stakeholders who need to quickly discern the “why” and “how” of a project – but don’t want to be bothered by ground-level details. This ensures CEOs and investors understand that the improvements being made by a company’s on-the-ground employees are being made for a reason – not just for the sake of improvement.
Timeline-Based Product Roadmaps
As the name implies, timeline-based product roadmaps illustrate your development plan in terms of when you expect to have completed specific tasks.
Timeline-based product roadmaps are useful when describing to C-suite executives exactly what tasks go into creating a product, and explaining how long specific processes will take. This structure can also help teams organize projects in which certain tasks are subordinate or dependent on others.
One thing to note from the example above is that, when creating a timeline-based product roadmap, you don’t need to be exact with your deadlines. By using soft deadlines, you allow supervisors to see about when a certain task should be completed, and also allow for flexibility from your employees if a task takes a little longer than expected.
Furthermore, the soft deadlines you set are contingent on your teams working at full capacity. This allows high-level stakeholders to understand the importance of letting your teams “do their thing” in order to hit their self-imposed deadlines – making them less likely to micromanage processes along the way.
Product-Line-Based Product Roadmaps
A product-line-based product roadmap is useful when you’re working on multiple products, or multiple versions of a single product, simultaneously.
Looking at the screenshot above, you might notice this structure shares characteristics between both theme-based roadmaps and timeline-based ones:
- The overarching “themes” for a given roadmap are the products being worked on
- Tasks are exhibited in a Gantt chart that acts as a timeline for task completion
For an example of a situation in which product-line-based roadmaps are most effective, think about a company that decides to create its first mobile app. If the company opts to create a native app for both iOS and Android platforms, it would need to create two separate product maps – but each would be almost identical (with a few platform-specific differences).
Utilizing a product-line-based structure allows you to create alignment between multiple versions of the same product (such as in the example mentioned above). This will help you ensure that each version gets the proper level of attention throughout the development process, and that both versions align with your central vision.
As we said earlier, each of these product roadmap structures has specific advantages and disadvantages, depending on the circumstances in which they’re used.
Before deciding on a structure, consider your purposes for creating a product roadmap in the first place:
Do you want to create alignment among your team members? Or are you providing your supervisors with an overview of the project’s processes?
Are you working on a single product, or multiple products at once? Are all of these products part of a larger initiative, or are they separate from one another?
Your answers to these questions – and more – will help determine which structure (or structures) are optimal for your purposes.
How Customer Input And Feedback Should Influence Your Product Roadmap
Note: If you don’t currently have a way to collect feature ideas and product suggestions from your customers, then you should make that your number one priority. Luckily, we can help with that.
There exist two popular – yet polarizing – schools of thought when it comes to giving customers what they want:
Despite the fact that these statements are diametrically opposed, there’s a certain truth to both of them.
It’s on this middle ground that you should create your product roadmaps in order to balance your customers’ needs and desires with the vision of your company. Mitchell Harper, co-founder of BigCommerce had this to say when we reached out:
“Customer feedback is critical to shaping your product roadmap. But you need consider how this feedback might impact revenue, retention, product development, competitive differentiation and alignment to vision. Building anything and everything your customers ask for is a recipe for a bloated, hard-to-use product.”
To illustrate why striking this balance is so important, let’s take a look at the pros and cons of developing a product roadmap from both a top-down and bottom-up approach.
Top-Down Product Roadmaps
A top-down approach to creating a product roadmap begins the process by looking at the company’s vision and goals for creating a product.
These goals might be something as obvious as “increase our profit margin,” but could be as nuanced as “increase lifetime value of our customers,” “increase cross-selling opportunities,” or “expand into a new geographic area.”
Notice, though, that each of these goals focuses on how developing the new product will ultimately benefit the company – hence a top-down approach to planning.
As Jim Semick, Founder and Chief Strategist of ProductPlan explains:
“Not starting with the vision and strategy is like building a home without first pouring the proper foundation; none of the subsequent steps in your construction process, or the quality of your other building materials, are going to matter much.”
That being said, there’s no way any company will reach such goals if it isn’t laser-focused on providing value to its customers. So, once you’ve set your goals for a specific product, you want to ask yourself the following questions:
- Who are you creating this product for?
- Why do these customers need this product?
- How will these customers use this product, and how will it help them?
By answering these questions, you’ll be better able to determine the specific features to be implemented within your product or service that you know your customers will find value in.
Yes, gathering input from your customers is important – but you want to ensure that your efforts align with your overall vision as a company. A top-down approach allows you to easily articulate your vision and mission when presenting to stakeholders – and to explain how you hope to attain these goals by providing value to your customers.
“We review every single piece of feedback and also get back to those users and say, “Hey, can you tell me a little bit more about what you actually meant?” So that’s how we iterate.
It’s not just about gathering the feedback and having someone say, “I want a Salesforce integration.” “Awesome. What does that mean?”. So we always ask why and not just externally, but also internally.”
Andrea Saez, Head of Customer Success at ProdPad
Bottom-Up Product Roadmap
While the general consensus is that creating a product roadmap from the top down is ultimately the best way to go, there are certain scenarios in which a bottom-up approach is actually most beneficial.
Now, the process of creating a product roadmap from the bottom up isn’t necessarily the opposite of the top-down process; you still need to have an overall vision for what you want your product or service to accomplish.
The difference lies in the way in which your company determines which features to include in your offering. In contrast to a top-down approach, creating a product roadmap from the bottom up requires that you solicit buy-in from other stakeholders, asking them to explain the features they, themselves, would like to see in your product.
The problem with this approach is you’ll almost certainly end up with a long list of suggested features, but will only be able to use a fraction of them. Some of them might be pie-in-the-sky; some might be superfluous; some might even contradict other suggestions.
This can be a no-win situation for you: you either ignore some ideas in favor of others (and risk alienating those who you shoot down), or you try to incorporate everyone’s ideas and end up spreading yourself way too thin.
However, while a bottom-up approach isn’t exactly beneficial in the long run, it can be used to great success when developing a minimum viable product. In this case, you may not truly know exactly what your customers are looking for in a product or service, so soliciting input from them can help you determine the essential features your product will need to include.
Once you’ve determined the essential things your new product must have in order to meet the needs of your target customers, you can begin planning for the creation of your full product using the much more efficient top-down approach.
A Note On Feature Prioritization
Regardless of whether you’ve brainstormed a list of potential features on your own or in conjunction with your stakeholders, you’ll eventually need to prioritize these features in terms of the value they’ll bring your customers.
Richard Banfield, CEO of product design firm Fresh Tilled Soil, suggests prioritizing features based on their feasibility, desirability, and viability.
Feasibility refers to whether or not your team can actually create the feature in question. Typically, this means assessing the technology and other resources your team is privy to, but could also refer to qualities such as manpower and ability. Essentially, feasibility asks the question: “Are we able to do this?”
Desirability assesses input from your target consumer base to determine whether your users actually need a specific feature. This information could be gleaned overtly (by surveying users and soliciting input actively) or covertly (by observing the manner in which users interact and engage with prototypes and beta versions of your product).
Viability focuses on the logistical aspects of including certain features within a product, both internally and externally. Internally, viability assesses the benefits of including a certain feature alongside the cost of developing it. Externally, viability refers to industry standards, such as resource scarcity, industry regulations, and copyright information.
As mentioned above, all three of these factors are equally important when prioritizing features to be implemented in a product or service. If one piece of the puzzle is missing – or even simply lacking – problems during development will almost certainly arise.
A Fun Way To Prioritize Features
Co-founder of ProdPad Janna Bastow understands that, with everything else going on throughout a company at any given time, the process of prioritizing features can often fall to the backburner and become an afterthought.
To bring it back to the forefront at ProdPad, Janna has begun implementing an activity she calls the Product Tree Game. Through this activity, team members collaborate to create a visual representation of a product’s features, from its core features (the trunk) to the less-essential – but still important – features (the leaves).
Check out Janna’s post for more on how to develop this activity with your team.
Though rather simplistic – or perhaps because of such simplicity, product roadmaps serve a number of valuable purposes.
First, they provide an overview of the major processes that will go into creating a new product, service, or feature, allowing all stakeholders to clearly see and understand these processes.
Second, product roadmaps allow all involved parties to know what’s expected of them, as well as what to expect from others, throughout the creation process.
But thirdly and most importantly, product roadmaps make it easy for project managers to maintain alignment between their organization and the product or feature being designed.
Whichever approach you take to building a roadmap, always remember that customer feedback should remain front and center. If you don’t currently have a way to collect feature ideas and product suggestions from your customers, we can help.