post

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! 🎉

Can product operations and innovation be friends?

Why can’t we get accessibility right? Claire Bauden (SVP Global Product Design, Global Payments Inc.)

Ditch the PRD template and embrace the PRD checklist

How to price your subscription product: insights and examples

International strategy with a 360 view by Chris Butler

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Sunday Rewind: The good, bad, and ugly of OKRs by Jenny Herald

Product Management

Janna Bastow

I wonder what it is about feature roadmaps that is comforting to the C-suite. Is it the false sense of security that you’re setting yourself up to deliver a list of features based on untested assumptions and educated guesses? Is it the delusion that locking your organisation into a plan a year in advance equals a competitive edge?
As product managers, we instinctively know that planning things out in advance is impossible, because our work depends on a constant stream of testing, data and feedback.
Our bosses don’t. Or maybe they do, but they’re not ready to accept it yet. Cody Simms of Techstars <a href="https://medium.com/techstars/why-most-product-roadmaps-are-a-train-wreck-and-how-to-fix-this-12617e3adabc">is convinced that everyone already knows</a> that feature roadmaps are nothing more than a comfort blanket: “Whether you are a CEO, board member, investor, or employee…EVERYONE knows that the roadmaps that are published in these documents are a joke. And yet, there they are. Every time. A random list of features with monthly or quarterly delivery dates assigned to them,” he says.
For bosses, I think there’s a perceived risk in moving from a safe and predictable feature roadmap to an experiment-based lean product roadmap.
They want answers. They want predictability. They want you to know exactly what to take to market, they want customers to know exactly what they’re getting and they don’t want any surprises along the way. Minimising risk feels good.
But it doesn’t square up at all with your reality: that if you get your predictions wrong, it’s nearly impossible to course correct. Imagine having to build out phase 2 of something your customers rejected last month.
Feature roadmaps communicate those features you plan to build, even if they’re the wrong ones.
<a href="//wp-content/uploads/2017/05/bad-roadmap.jpg"><img loading="lazy" decoding="async" class="alignnone wp-image-11523" src="//wp-content/uploads/2017/05/bad-roadmap-300x221.jpg" alt="" width="694" height="511" srcset="/wp-content/uploads/2017/05/bad-roadmap-300x221.jpg 300w, /wp-content/uploads/2017/05/bad-roadmap-768x567.jpg 768w, /wp-content/uploads/2017/05/bad-roadmap-1024x755.jpg 1024w" sizes="(max-width: 694px) 100vw, 694px" /></a> 
Imagine trying to casually change this roadmap at a 500-person organisation.
So how do you break in the idea of lean roadmapping with a boss who finds anything less than a feature roadmap to be an unnecessary risk?
By convincing them that it opens up your business to an even greater risk: that by sticking to the plan they risk losing customers and market share.
How would you convince your seniors to try out this new approach? Here’s how you do it:
<h2>Show Them Problems You’re Solving</h2>
Features and timelines make bosses feel comfortable &#8211; and you can give them some of that comfort without making huge commitments on your roadmap.
First of all, bosses are usually only interested in upcoming initiatives. That’s an opportunity for you to explain dates wherever it’s important to do so, but also use it to explain the bigger picture in a way that still lets you be flexible.
For example, here’s a lean product roadmap split into three time horizons: Current, Near Term and Future.
<a href="//wp-content/uploads/2017/05/lean-roadmap.png"><img loading="lazy" decoding="async" class="alignnone wp-image-11524" src="//wp-content/uploads/2017/05/lean-roadmap-300x169.png" alt="" width="644" height="363" srcset="/wp-content/uploads/2017/05/lean-roadmap-300x169.png 300w, /wp-content/uploads/2017/05/lean-roadmap-768x432.png 768w, /wp-content/uploads/2017/05/lean-roadmap-1024x576.png 1024w, /wp-content/uploads/2017/05/lean-roadmap-285x160.png 285w, /wp-content/uploads/2017/05/lean-roadmap-570x320.png 570w" sizes="(max-width: 644px) 100vw, 644px" /></a>
Current might mean &#8220;next two weeks&#8221;, Near Term might mean &#8220;next two months&#8221; and Future might mean &#8220;six months or so, if we&#8217;re still in business!&#8221;.
Typically, you can get agreed dates (at least roughly) with your team for Current term projects, because you’re working on them already. You can note these dates on the card themselves. If there are specific milestones that are business critical, note those on the cards too.
As the company and the product vision grows, these horizons naturally expand &#8211; as if you&#8217;re able to see further and think bigger. A complex mature product might have a roadmap that stretches five years in the future, where current is &#8220;next six months&#8221; or more.
It makes sense that you can provide more certainty on the stuff you&#8217;re currently working on over the stuff that&#8217;s way out in the future. It&#8217;s intuitive to understand and easy to explain, and your bosses will be on board with this.
<h2>Show Them What You Lose When You Give Up Validation and Testing</h2>
The best example I can think of when a product veered dangerously off track from what customers want is Juicero. Juicero used their $120 million investment to the solve <a href="https://medium.com/@Juicero/a-note-from-juiceros-new-ceo-cb23a1462b03">the following problem</a>:
“Juicero’s mission is to make it dramatically easier and more enjoyable to consume more fresh, raw fruits and vegetables.”
This seemed like a pretty ambitious goal with a pretty big market value. Fair enough. But the public fallout/outcry after the company introduced a $400 juicer that was, <a href="https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensive-6add74594e50">according to one product designer</a> “easily in the top 5% on the complexity scale” was no doubt incredibly painful and expensive for everyone involved.
The team engineered a beautiful and intricate product, but ostensibly did not test their assumptions along the way.
<ul>
<li>Who was in the market for a $400 juicer?</li>
<li>Did the product they were building match up to their vision and mission?</li>
<li>What value or problems were they solving for customers?</li>
<li>Would people maybe realise that they could squeeze the juice bags faster by hand and more cheaply than a $400 juicer?</li>
</ul>
<a href="//wp-content/uploads/2017/05/hp-easy-tab-no-background-min-1.png"><img loading="lazy" decoding="async" class="alignnone wp-image-11526" src="//wp-content/uploads/2017/05/hp-easy-tab-no-background-min-1-300x231.png" alt="" width="460" height="354" srcset="/wp-content/uploads/2017/05/hp-easy-tab-no-background-min-1-300x231.png 300w, /wp-content/uploads/2017/05/hp-easy-tab-no-background-min-1-768x591.png 768w, /wp-content/uploads/2017/05/hp-easy-tab-no-background-min-1-1024x788.png 1024w, /wp-content/uploads/2017/05/hp-easy-tab-no-background-min-1.png 1950w" sizes="(max-width: 460px) 100vw, 460px" /></a>
Obviously this is a somewhat extreme example in terms of money and stakes, but this happens all the time at companies that rely on a feature roadmap.
There’s little leeway to test and validate assumptions, and though that may keep you on track, what if it’s the wrong track? If you’re slow to adapt to market reality, reality isn’t going to wait for you to start over and get it right.
<h2>Keep Them In The Loop On How Your Product Strategy Is Changing Through Testing</h2>
Problems that are valid now might not be valid down the line. Instinctively, we all know that, including your boss.
Just as the prototype of your product evolves and changes as you learn from your users, your roadmap should be open to evolution too.
When you learn something new, you remove irrelevant items and add in new things as you learn.
The roadmap you created six months ago isn&#8217;t meant to be valid today. If it were, it would mean that either you were 100% correct in all of your assumptions (unlikely!) or that you haven&#8217;t been learning along the way.
Revisit your roadmap every month or so, or whenever you learn something that changes your view on what should be built. Whenever you update your bosses about your product roadmap, emphasize what you’ve learned and how that’s guiding your product decisions.
The great thing about this format is that it allows you to add to the roadmap, stick to the format, but evolve your thinking around the product planning as you grow.
You&#8217;re not just adding a longer and longer timeline with more features, you&#8217;re actually evolving the contents of the roadmap to better tell the story of how you&#8217;re going to reach your vision.
When you present your roadmap, make sure to explain the rough timelines you&#8217;re talking about, but also point out that these are subject to change and shift as you all as a team learn and develop the product.
<h2>Remind Them It’s What Leading Businesses Are Doing </h2>
When Slack first introduced its platform roadmap last year, it was clear its vision was bigger than communicating features and its launch dates: “We are building for a future where Slack is dwarfed by the aggregate value of the companies built on top of it. This is our success as a platform — when the value of the businesses built on top of us is, in sum, larger than we can ever be.&#8221;
Leading product companies like <a href="https://medium.com/slack-developer-blog/the-slack-platform-roadmap-34067b054177">Slack</a>, <a href="https://medium.com/@noah_weiss/now-next-later-roadmaps-without-the-drudgery-1cfe65656645">Foursquare</a>, <a href="https://blog.intercom.com/666-product-roadmap/">Intercom</a> and <a href="https://www.prodpad.com/our-roadmap/">ProdPad</a> are doing their product planning without timelines because there’s a bigger endgame in sight.
<a href="//wp-content/uploads/2017/05/slack-roadmap.png"><img loading="lazy" decoding="async" class="alignnone wp-image-11528" src="//wp-content/uploads/2017/05/slack-roadmap-300x123.png" alt="" width="615" height="252" srcset="/wp-content/uploads/2017/05/slack-roadmap-300x123.png 300w, /wp-content/uploads/2017/05/slack-roadmap-768x315.png 768w, /wp-content/uploads/2017/05/slack-roadmap-1024x420.png 1024w, /wp-content/uploads/2017/05/slack-roadmap.png 1344w" sizes="(max-width: 615px) 100vw, 615px" /></a> 
Slack invites developers into its product management process with its product roadmap.
The benefits of a product roadmap extend far beyond communicating a set of features on a timeline.
A roadmap can be used to share upcoming plans with your customers, communicate the exciting future of your product and build an ongoing dialogue with the stakeholders that matter to your business.
Roadmapping without a timeline is not a leap into the unknown. Quite the opposite, actually. It’s control over the future of your product like you’ve never had before.
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

How to Sell Your Boss on Roadmaps Without Timelines

Janna Bastow

Comments

Read next