How to Sell Your Boss on Roadmaps Without Timelines "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 22 May 2017 True Juicero, Lean, Lean Product Management, Product Roadmap, Slack, Testing, Validation, Mind the Product Mind the Product Ltd 1338 Product Management 5.352
· 6 minute read

How to Sell Your Boss on Roadmaps Without Timelines

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 is convinced that everyone already knows 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.

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:

Show Them Problems You’re Solving

Features and timelines make bosses feel comfortable – 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.

Current might mean “next two weeks”, Near Term might mean “next two months” and Future might mean “six months or so, if we’re still in business!”.

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 – as if you’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 “next six months” or more.

It makes sense that you can provide more certainty on the stuff you’re currently working on over the stuff that’s way out in the future. It’s intuitive to understand and easy to explain, and your bosses will be on board with this.

Show Them What You Lose When You Give Up Validation and Testing

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 the following problem:

“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, according to one product designer “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.

  • Who was in the market for a $400 juicer?
  • Did the product they were building match up to their vision and mission?
  • What value or problems were they solving for customers?
  • Would people maybe realise that they could squeeze the juice bags faster by hand and more cheaply than a $400 juicer?

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.

Keep Them In The Loop On How Your Product Strategy Is Changing Through Testing

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’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’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’re not just adding a longer and longer timeline with more features, you’re actually evolving the contents of the roadmap to better tell the story of how you’re going to reach your vision.

When you present your roadmap, make sure to explain the rough timelines you’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.

Remind Them It’s What Leading Businesses Are Doing

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.”

Leading product companies like Slack, Foursquare, Intercom and ProdPad are doing their product planning without timelines because there’s a bigger endgame in sight.

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.

Comments 2

Thanks, Janna! I’ve noticed that the Lean roadmap without quarterly deadlines is great for almost all purposes, including prospects, current customers, boards of directors, etc. I’ve sometimes had a small number of people sitting outside my realm of immediate influence (key customers, integration partners, etc.) still demanding firmer dates. My solution has been to modify the roadmap for those instances as they come up. Is that how you would handle it?

Yep, that’s exactly right!

If a date is known, agreed upon, and achievable, then it does deserve a spot on the roadmap. Simple as that, just add it to the item in the roadmap in plain text, clear for everyone to read and understand.

But just because you set a due date for one upcoming release doesn’t mean you have to set dates for all things in your roadmap. This is one of the key differences between a lean roadmap and a timeline roadmap: A timeline, by it’s very essence of being an x-axis line representing time, forces you to show a date for everything below it (whether explicitly or not).

By removing the timeline, you still have the freedom to say what dates and milestones are known and needed along the way, but gives you the freedom to leave dates off for later initiatives – best of both worlds!

Join the community

Sign up for free to share your thoughts

About the author