PRODUCT MANAGEMENT
Getting from product strategy to product roadmap
Building and communicating product roadmaps, and aligning stakeholders around them
Table of Contents
II. Developing consensus and pushing forward
Other reads related to Effective Product Roadmapping
Welcome!
If you found this article helpful, be sure to follow me on Medium to stay updated on and explore my publications..
The product roadmap is an agile and long-term product development plan that gives all product stakeholders the information they need to coordinate development plans. If built correctly, product roadmaps can be extremely critical to the success of a business, and there are a few reasons for this:
- A product roadmap provides predictability to the product development process, allowing all stakeholders of a product to plan, allocate resources, and coordinate future activities
- A product roadmap forces the leadership team of a business unit to clearly articulate its business goals and consequential strategies
- A product roadmap aligns product development efforts with corporate, business, and functional strategies
- A product roadmap helps align key stakeholders, creating cross-functional unity and ensuring everyone works together effectively
A wide variety of internal and external product stakeholders will be impacted positively by a product roadmap. Some of these stakeholders include:
- Customers, especially for B2B businesses, often want to see a product roadmap to help them make purchasing and execution decisions
- Customer-facing teams within the organization, such as sales, marketing, or customer support. They may use a product roadmap to develop their materials such as documentation and training
- Investors, the board, or sponsors, may use a product roadmap to estimate future revenues and costs, and decide what resources to allocate
- Product teams including architects, engineers, and designers, can use the visibility provided by a roadmap to create higher-quality offerings
- The human resources team needs to plan or change hiring activities
- The legal team, who needs to develop contracts
— The ultimate Roadmap template
- The format or beauty of the document is far less important than the main objective of a product roadmap; to build support and align stakeholders.
- Different organizations have a variety of development processes, sales cycles, and decision-making processes and therefore, there is no one-size-fits-all format or template that will work perfectly for every organization.
With these in mind, you can Google ‘Product Roadmap’ and find plenty of templates to download. Most of these templates use a graphical layout that can be easily drawn on software such as PowerPoint, show future periods along the x-axis at the bottom (in weeks, months, or even years), different products along the y-axis, and plot the upcoming milestones for each product across the grid. Each milestone is a meaningful grouping of new functional features that will have a significant impact on the business.
Overall, the product roadmap is a simple-looking document that is easy for everyone in the organization to understand. The difficult part is creating a roadmap with the right milestones with the right release dates in a way that implements the product strategy and has all stakeholders aligned around it.
— The product backlog vs. the roadmap
In an agile product development team (e.g. startups), there is a product backlog, a prioritized queue of the next most important bugs, product development tasks, or user stories. The backlog should not be mistaken for a product roadmap. The product roadmap is designed to give stakeholders the information they need to coordinate efforts.
Stakeholders, such as customers, marketing, or finance people are typically interested in milestones that will bring new customers or revenues and in knowing when the milestones will be marketed. However, the backlog does not provide any of this information. There is a close relationship between the backlog and roadmap, whereby each milestone shown on the roadmap will have to be turned into a large set of tasks on the backlog, not the reverse. The backlog will be directed by the product roadmap, which is one way you can ensure that the activities of the product development team are aligned with the needs and goals of the whole company.
In regards to the timing of the milestones, they are generally top-down estimations performed by the product development team. As long as they’re close estimates, they’ll serve the purposes of the product roadmap; to allow coordination among the different product stakeholders.
— Early-stage products
When developing an early-stage product, exploring a new market, a new customer, and a product, it would be unwise to plan out what you’re going to develop far into the future. In the very early stages of the product, the team has ideas about some unmet customer needs and a possible solution that may create business value.
In this case, the purpose of product development is to learn about the market and customers and validate the hypotheses that will later form the basis of the product strategy. Once your product has achieved product-market fit, and you’re able to articulate a product strategy that is based on solid market knowledge, that is when a product roadmap is needed.
You’ll see plenty of clues that product-market fit ISN’T happening:
- Customers aren’t quite understanding the product or seeing its full value
- Word of mouth isn’t spreading
- Reviews are sparse or mediocre
- Sales cycles are long, or customer acquisition costs are very high
On the other hand, if product-market fit IS happening:
- The growth curve is impressive
- Money is coming in faster than it is spent
- Deals are easy to close
- Customers are coming in outside of the marketing campaigns
- The press is constantly looking for information
I. Creating the roadmap
— Run an inclusive process
A product roadmap, no matter how great the strategic thinking, planning, and prioritization behind it, has no value if key product stakeholders aren’t aligned around it. If things start going wrong and the product roadmap does not have stakeholder buy-in, then everyone will start to blame each other for the shortcomings. The reason is that the roadmap champion, typically the product leader, didn’t take the time to get the entire team and stakeholders aligned around the roadmap. Unfortunately, product development doesn’t happen in a vacuum.
The purpose of product development is to serve the business and support the company’s overall strategy by winning customers’ loyalty and ultimately generating revenue. And, revenue requires that all the various teams in a company, sales, marketing, customer support, and so on, work together in an interdependent manner. If any stakeholder isn’t on board or doing their part, it’s going to present a major barrier to the success of the product roadmap.
To achieve alignment on the product roadmap, involve people in the process of making it:
- Include your stakeholders early in the process
- Ask for feedback and address it
- Send updates as the plan takes shape and evolves into the final form
When people are involved in making something, they feel ownership, and they’ll promote and defend it. With the product roadmap, stakeholder alignment is the ultimate goal, and the resulting product roadmap document is only there as a reminder of what you are aligned around.
— Success factors
A successful product roadmap needs to:
- Be based on a sound product strategy
- Be realistic
- Be fully supported by the key product stakeholders
Typically, powerful individuals, such as startup founders, CEOs, GMs, or CROs, use their experience and intuition to influence a product roadmap and push it out to the whole organization, resulting in a failed roadmap. As the product leader, it’s extremely important not to let this person’s intuition or power, no matter how good or well-informed it is, dictate the roadmap.
Note that:
- Intuition can be erroneous, leaving you with a roadmap that is based on flawed or unrealistic assumptions about the market
- With little stakeholder involvement during the decision-making process, you’ll end up with a lack of alignment, where people will not be supporting it or worse, actively trying to undermine it
- Ask stakeholders for the thinking that underlines the selection of their projects. Drill into their hypotheses, the whys of their proposals, and make sure that they are built on sound reasoning
- Educate individuals on the importance of including other product stakeholders in the process. Let them know that stakeholders are more likely to be aligned and to actively support the plan if their opinions are solicited and incorporated.
— Target stakeholders
Your main partners or stakeholders in building the roadmap will be:
- The direct business leader, CEO, or general manager of the unit. The business leader will allocate resources such as headcount. They must feel complete ownership at all stages of roadmap development.
- Sales leaders, such as the VP of sales or chief revenue officer, since have to hit their sales targets based on the product roadmap.
- The product development leader is responsible for organizing and motivating the product team to deliver the milestones. In many companies, this is likely to be the CTO or VP of Engineering.
It could also be useful to include other stakeholders in the process. For example, in a company such as Uber or Deliveroo, where the business is largely based on operations, a Chief Operating Officer or a VP of Customer Service will be valuable to the process. But whoever you choose to include, make sure they will be adding to and not distracting the process.
— Develop a sound product strategy
Customer knowledge is the primary currency of a product manager. The more a PM knows about the customer and market, the more he/she can speak with authority about the impact of specific product development options.
Only through a deep understanding of the customers will a product roadmap have the intended impact that achieves business goals. To better understand the user, the company needs to invest in gathering customer insights and research and build a comprehensive and detail-oriented product strategy. In researching customers, consider these options:
- Review your currently available user insights
- Initiate new research projects
- Design surveys and run them on a small sample of your target customers
- Participate in sales or customer service meetings
- Reach out to a handful of your customers directly with a personal phone call or email and conduct an exploratory or ‘open-ended’ interview
One can’t evaluate the quality of a product roadmap without knowing something about the company’s strategy. So, the first step in roadmap development is to clearly articulate the product strategy. A product strategy is a description of the way a company or business unit intends to achieve its business goals with its product. To create a sound product strategy ask these questions:
- What are your business goals? And how will you measure success?
- Who are your target customers? Which customers do you want to win? What are the key needs of your target customers that you think you can meet? And what is the key benefit that your product will provide to these target customers?
- Who are the key competitors for your product? What other options do your customers have?
- What are the key differentiators between your product and those of the competition?
With a product strategy articulated, discuss it with each of your product stakeholders starting with one-on-one meetings where people feel more comfortable giving unbiased feedback, and after incorporating their feedback, have group meetings where everyone discusses and agrees to support the strategy. If there isn’t consensus, you’ll need to go back and work on the product strategy again. With a product strategy in place and your key product stakeholders aligned around it, it’s time to start building the roadmap.
I’d love to hear your thoughts!
Share your insights and feedback in the comments below and let’s continue this discussion.
II. Developing consensus and pushing forward
— Identify and prioritize key milestones
Defining milestones will be the most creative part of building a product roadmap. After aligning around a specific product strategy with the team of stakeholders, it’s time to identify the sequence of milestones that best implement the strategy.
- Start by assessing the product strategy. What are the barriers to success? Which barriers could be removed or improved by making minor changes to the product?
- Understand the customer journey and the decisions customers make when choosing to use your product. What are the barriers preventing your target customers from adopting your product? Note the major product changes that you believe would have the desired impact on the strategic objective.
- Make sure you’re thinking about things at the right level of granularity, milestones should be major product changes that will take significant amounts of research, design, and development work and will correspond to perhaps dozens of tasks on the backlog.
- Correlate each milestone to the strategic objective that it supports as well as the rationale; the rationale should be high-level and easy to follow.
- Prioritize the milestones in a rough order
- Once you’ve done your best to brainstorm the milestones on your own, it’s probably a good idea to meet with each of your product stakeholders to see whether they can think of any that you might have missed. Meet with each stakeholder one-on-one before holding a group meeting.
- At the beginning of each of these meetings, start by reviewing the product strategy and then ask them for their ideas about which milestones would best support that strategy.
- Once you’ve exhausted their ideas, review all other milestones you have gathered and ask for feedback as well as a sense of priorities.
At the end of this process, you should end up with a sequence of product milestones, each of which has measurable impacts on one of your strategic objectives and which together will implement your product strategy.
— Estimate effort
Effort estimation will help you put dates on the roadmap that are as realistic as possible. You’ll need to work with your product development team on this:
- Gather a realistic estimate of the capacity of the development team and the amount that can be allocated to product development. A typical product development team’s time is spent on bug fixing, product maintenance, new feature development, and engineering projects.
- Once you know the available development hour capacity, usually measured in developer time units such as developer days, developer weeks, or developer months, estimate the amount of development time each of the milestones is likely to take.
Note: at this stage, you’re not asking the development team to commit to the estimates you are making, so no pressure yet.
Note: If, after scoping, some of the milestones are too small, you might want to group them into larger milestones that support some elements of the strategy. And if some are too large, decompose them into smaller milestones while making sure that each has a valid business impact.
Once you’re done with this phase, you should have a spreadsheet with enough information to build a product roadmap with milestones that are realistic for the team to complete.
— Share your first draft
The first version of your product roadmap, or a first draft, is likely to change before it gets approved by the team. It’s better to have a first draft before meeting with your team because you’re more likely to have a productive discussion. In your meeting:
- Sequence your milestones in terms of impact on supporting the product strategy. Go through them one at a time to remember the rationale for each and prioritize them.
- Schedule the milestones into the roadmap. Look at your first, highest-priority milestone. Use the effort estimate provided by your product development leader, as well as the development capacity of the team, to figure out when on the calendar you could expect it to be delivered. Then, pick up the second-highest priority milestone and assuming that the first one is completed on time, schedule that one in the same manner.
- Look at periods out into the future, such as the next four quarters. Identify a set of high-priority milestones that can be completed together in the first period along with a set of lower-priority milestones for the second period, and so on.
In larger product development projects, you’ll probably have multiple development teams working in parallel and on different products:
- If the teams are organized around distinct products or customers, you’d probably have separate milestones for each of them and should schedule them separately.
- If the teams are organized functionally, so that each team owns different components, like a front-end team and a back-end team, you need to figure out the capacity and effort required of each team separately. You’ll also need to schedule the milestones in a way that each team will have enough capacity to complete their milestones in the scheduled time while delivering the final product to the responsible business unit.
Once you’re done and have a completed schedule, run a sanity check from a few perspectives:
- Ask yourself if it implements your product strategy. Try to make adjustments so the impact on the product strategy is maximized.
- Ask yourself, is it feasible from a development resource perspective? Run it by your development leaders again, and make any adjustments they deem necessary.
- If you feel good about it, then share it with the rest of the team.
— The buy-in meeting
You’ll want to plan and run this meeting in close collaboration with the business leaders since they directly manage most of the product stakeholders and have the authority to ask for their participation.
- At the start of the meeting, explain the goal; to emerge with a shared product roadmap that all stakeholders fully support and can use in their planning.
- Quickly review the product strategy. Explain that it’s the foundation and that the roadmap must be designed to implement the strategy. The team must be aligned on the strategy by now.
- Review the development capacity of the team. Have the development leader present the team’s capacity and explain how their time will be spent on things other than new product development.
- Hold a walk-through of the first draft. Present each milestone one at a time as well as the strategic objective for each. Try to get through all the milestones before you start making changes just so people know everything under consideration.
- Ask your team what they wish was different. It’s important in this step that you listen to a variety of opinions about the roadmap. This is how you’ll surface the important issues facing the business.
- Modify the product roadmap directly in the meeting so everyone can see the consequences. Use a live and visually formulated spreadsheet. Show the team the trade-offs of the decisions they are making. Sometimes this will result in negotiations or trading between team members.
- Invite the group to think about the success of the business rather than their interests, aiming to build consensus on the greater good.
- Make sure that the whole team is aligned with the final decisions. It’s also the business leader’s responsibility to make the final decision and check for alignment with the rest of the team.
- Schedule a follow-up session to resume the process if you haven’t gotten to the point of consensus by the time the meeting is over.
- By the end of the meeting, everyone should have the revised product roadmap and have agreed to support it publicly.
III. Simple solutions to common challenges
— Pushing the roadmap to a larger number of stakeholders
Once you have a roadmap that’s been reviewed and approved by your key product stakeholders, it’s time to start building alignment among the people who weren’t in the meeting but who will need to support the roadmap and use it moving forward.
- Create a short presentation that simply presents the key elements and decisions of a product roadmap as well as the rationale behind them. Start with a slide or two about the product strategy, the top-level business objectives, target customers, and how you plan to win them.
- Include the product roadmap diagram followed by a couple of rationale slides, one for each of the key decisions where you had to favor one important project over another
- Schedule a series of one-on-one meetings where you present the new roadmap to any product stakeholders who will be impacted by it but who did not participate in the roadmap development process such as leaders of operations, customer service, technical support, finance, legal, etc.
- At the end of each of these one-on-one sessions, you need to check for alignment again. If there are any major issues that the decision-making team missed, you’ll have to raise them again with the whole group.
- Once all the one-on-one meetings are completed and the stakeholders are aligned, roll out the roadmap to the entire company or business unit that it’ll impact.
- Always present the product roadmap as the result of team efforts. ‘It’s OUR roadmap and WE decided.’
— Guard and update the roadmap
Product roadmaps are dynamic documents. They represent your organization’s development plan at a particular point in time based on the best information available to you. Based on new information about customers or the market, you’ll need to update them.
There are several types of information that you might encounter that could potentially change the roadmap:
- Changing customer needs and desires
- Information about competitors
- Time or cost of product development
- Internal requests, sometimes team members may ask for changes to the roadmap. In these cases, you must try to understand the new information that’s been learned as the reason for the change
- If the product is in the early stages of the life cycle, you’re probably learning new information all the time, so your roadmap will probably change very frequently.
IV. In summary…
- Make sure you deeply understand customers’ needs and how they think about your product
- Figure out who your key product stakeholders are and schedule a strategy meeting to get everyone aligned around the product strategy
- Build the first rough draft of the roadmap, identify milestones that will best implement the strategy, scope them with key stakeholders, derive a realistic schedule, share it, and get the necessary buy-ins and approvals
- Share it with the rest of the company
- Keep the roadmap relevant by constantly reviewing the market and the underlying driving assumptions of your business
