post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

mission statement

Deep dive: Crafting your product vision and mission

Podcast

Connecting fans to creators at Spotify (Dariusz Dziuk, Product Lead, Spotify)

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Join us at #mtpcon London in 2025 – mark your calendars

How Google makes AI work at Enterprise scale – Miku Jha (Director, AI/ML and Generative AI, Google Cloud)

5 ways to invent and simplify as an AI/ML product manager

Why teams often struggle with OKRs: A conversation with Jeff Gothelf

Building your own user experience and software stack: This week’s product news

As chief product officer of Shipa Freight, Paul has overseen development of shipafreight.com, a digital logistics platform for small and medium-sized enterprises. Formerly vice president of digital marketing for global logistics leader agility, Paul was responsible for establishing agility’s digital brand, building an online audience, and generating qualified leads. In his 25 year career, Paul has held various product and technology leadership positions with early-stage startups and Fortune 500 companies including Unisys, Destiny, and US Airways. Paul has a Master of Software Engineering degree from Carnegie Mellon University and a Bachelor of Computer Science from Brown University. Paul is based in Philadelphia.

Paul Rehmet

<p>Product roadmaps&#8230;love &#8217;em or hate &#8217;em, you probably spend a lot of time on them. For most of us product managers, the roadmap is a key output of our product process. But very often, that colorful set of bars on the timeline that we artfully sell to our leadership inadvertently leads to challenges down the road. Here are some roadmap tips to get your project off and running, avoid the potholes, and set you up for success.</p>
<h2>The roadmap from on high</h2>
<p>Is your roadmap <span style="font-style: italic;">your</span> roadmap? Yes, you and your team created user <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/tag/personas/" target="_blank" rel="noopener">personas</a></span>, conducted interviews, analyzed user behavior, built prioritization frameworks, and organized the to-be-built features into a documented roadmap. But who made the final decision on what features to include/exclude in your roadmap?</p>
<p>If it was your boss, that&#8217;s a problem. As the product manager, you should have the insights from your product process and the product experience to make good tradeoffs. You should be accountable for decisions made and feel the pressure to prove yourself right. Your boss should believe in the discipline of product management and have trust in your ability to perform that function. It&#8217;s your roadmap!</p>
<p>If your boss is dictating what gets built:</p>
<ul>
<li>Have an open discussion about your product process, your role and responsibilities, and what you need (and don&#8217;t need) from your boss. What you need is clarity around objectives and key results, and support in managing other stakeholders. What you don&#8217;t need is to be told how to achieve the results. Understand the concerns they have with delegating roadmap decision making to you.</li>
<li>If that doesn&#8217;t help, you may be at an organization with a weak product function and a leader who trusts their gut instincts above all else. Changing this situation, if possible, takes time. Consider ways to showcase how the best companies work, including seeking outside expertise if your leadership tends to put more stock in input from beyond its walls.</li>
</ul>
<h2>The stakeholder compromise</h2>
<p>Is your roadmap a hodgepodge of features meant to appease each of your stakeholders? Maybe something that helps optimize the marketing and sales funnel. And something to reduce technical debt. Something else to assist your operations team. You get the idea. Sounds great, but beware. Such a roadmap is unlikely to bring game-changing value to your product and often the customer ends up being the stakeholder who isn&#8217;t adequately served. Of course, you want to keep your stakeholders happy and such roadmaps aren&#8217;t all bad, but I suggest to:</p>
<ul>
<li>Start with a clear vision of what your roadmap needs to achieve. Customer needs should be at the core of this, then your roadmap features come next. If the roadmap is successfully executed, will the customer be engaged, delighted, and loyal? Imagine presenting your <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/category/product-roadmap/" target="_blank" rel="noopener">roadmap</a></span> to your customers. Would they find it relevant, interesting, and important?</li>
<li>Build releases around a theme, communicate the theme to your stakeholders and align your stakeholder&#8217;s requests around the theme. By doing so, you are more likely to get cross-functional synergies that result in meaningful business impact.</li>
<li>Involve stakeholders in your project process so they understand that there is a method to your madness. When you end up saying &#8220;no&#8221; to a requested feature, you don&#8217;t want the decision to be perceived as arbitrary.</li>
<li>Even if stakeholders understand your rationale for saying no, they may not be happy about it. Develop a thick skin. Being a good product manager means taking some punches for the interest of the project!</li>
</ul>
<h2>The immutable roadmap</h2>
<p>To what degree is your roadmap a firm commitment around deliverables and milestones? This will vary based on the maturity of your product, state of your process, <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/tag/product-culture/" target="_blank" rel="noopener">organizational culture</a></span> and other factors. Regardless, any features and timelines shown on a PowerPoint by default will be interpreted as fixed, frozen, and immutable. If that&#8217;s not your intention, be very explicit about what your roadmap means.</p>
<p>My recent roadmaps typically communicate a firm plan for the next three months and our strategic direction beyond that. I already have the buy-in of my agile team for the three-month plan so I am confident that we will find a way to deliver on time. I am much less confident about the deliverables beyond that. So I make a clear distinction between the two parts in my roadmap presentations. To do this right, make sure to:</p>
<ul>
<li>Visually distinguish feature commitments from things that are the only direction in nature in your roadmap presentations. For example, use fuzzy boxes, call-out boxes, etc.</li>
<li>Be clear about where your ongoing product discovery and <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/tag/user-feedback/" target="_blank" rel="noopener">user feedback</a></span> fits in. What happens if you learn something as you are executing your roadmap that invalidates something on the roadmap? Do you have the ability to revise plans, change deliverables, reset dates, and reset stakeholder expectations?</li>
<li>Be clear about A/B tests and other experiments, and what happens based on positive or negative results. Often my team will build an MVP to test a hypothesis (e.g. &#8220;if we remove these three boxes on the booking form, our conversion rate will increase&#8221;) then implement the change in a more robust way if the hypothesis is true. If it turns out that the hypothesis is false, we will scratch the feature from our roadmap. If you work this way, make sure stakeholders understand your process and implications to the roadmap.</li>
<li>If you use cloud-based roadmap tools, consider sharing links to your active roadmap, explain how you manage it and figure out the rough frequency of updates.</li>
</ul>
<h2>The feature-only roadmap</h2>
<p>Now that you&#8217;ve communicated what&#8217;s going to get done, ask yourself what <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/early-and-often-the-secrets-to-product-success/" target="_blank" rel="noopener">success</a></span> will look like. Are you being measured on your ability to complete the listed features by the specified dates? Or is success measured in terms of achieving particular customer or business goals? If the former, in some ways your job is easy. You just need to execute your plan, hit the dates, and move on. But think about it — as a product manager, is it not your job to make sure you are delivering value to your customers? Shouldn&#8217;t you be appraised based on how well you accomplish this? The good news is that moving to an objective-driven approach can be done gradually. Start by listing some of the outcomes you are hoping the features will bring. Find ways to measure if those outcomes are realized. And use your findings as input into your next roadmap phase.</p>
<p>Assuming you are already being measured in terms of business goals, make sure those goals remain top of mind. Consider the following:</p>
<ul>
<li>Your agile team should be incented to achieve those same business goals, not just build the features. All team members should be aware of the business targets and hopefully, most will share your belief that the roadmap features will achieve the goals.</li>
<li>Your team should have already considered options for achieving the business goals without building new features. For example, building a feature may be an expensive way to fix a problem that can be solved with a simple business process change.</li>
<li>Even if it&#8217;s not your primary responsibility, ensure there is a plan that maximizes the use of the new features, including things like training, communication, and evangelism. You don&#8217;t stand a chance of hitting your business goal if users don&#8217;t know about the features, how to use them, and understand what&#8217;s in it for them.</li>
</ul>
<p>If you keep these tips in mind, your roadmap can steer your agile team in the right direction, set proper expectations with leadership, and help achieve your business goals. Ultimately, that will be a win for your customers.</p>
<p>Discover more content on <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/tag/product-roadmap/" target="_blank" rel="noopener">product roadmaps</a></span>. For even more content on a range of product management topics, see our <span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/content-a-z/" target="_blank" rel="noopener">Content A-Z</a></span>.</p>

Building a product roadmap to avoid potholes down the road

Paul Rehmet

Read more

Comments