7 Blog Posts That Will Change The Way You Think About Product Roadmaps

September 18, 2017

5:00 pm

Product roadmaps are common fixtures in most industries and every bit as common as business plans. Every business has its unique take on the process and many try to establish their roadmap as a virtual competitive advantage. Unfortunately, most fall into the same category as your average business plan — a pile of hopes with subheadings.

Here, we look at seven of our favorite blog posts on product roadmaps. Each post will challenge the way you think about planning and will offer a different view when it comes to executing your product vision. Here are the key takeaways:

Hope Is a Four-Letter Word

“Remember, if you don’t have data, you only have hope. And none of us are doing what we’re doing because we hope it will work,” said Cody Simms, Executive Director at Techstars.

In his piece Why Most Product Roadmaps are a Train-wreck (and how to fix this), Cody Simms talks about how so many companies tend to fill in product roadmaps with arbitrary estimates and rough guesses.

When it comes to board meetings he said, “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.”

The alternative? Focus on learning goals. Timebox experiments and feed the next sprint with better learning opportunities. We all like to design solutions, it feels good to have new ideas, but the hard thing to do is to focus on customer problems and structure ways to learn more about them.

It requires some intellectual honesty to accept that we are all victims of inertia and we tend to do things because they have always been done that way. The challenge is to purposely take the time to do the right thing.

Roadmaps Kill Creativity

“Your ability to pursue new great ideas as they arise will be seriously dampened when you’ve already committed to a tall stack of requests eagerly awaiting implementation,” said  David Heinemeier Hansson, creator of Ruby on Rails.

In his blog You Don’t Need a Product Road Map, David makes a solid case about how laying out a product roadmap can stifle your creativity as you try to balance the promises you’ve made to your customers and stakeholders while you are learning and evolving your product.

“When you sell the software that you actually have, there’s a limited amount of wiggle room to cajole prospects. Customers have to make real decisions about whether the current state of your software is a good fit for them. Sometimes it’s not. That’s okay. It’s better to turn customers away than to placate their instincts and lure them in with vague promises,” David said.

It takes a lot of self-discipline keep promises. The pressure from stakeholders and high paying customers is always high, but self-discipline will separate the good from great product teams.

Business Is War

“Roadmaps derive from the old centralized command-and-control model. A bunch of stakeholders meet, usually quarterly, in a room to come up with the priorities and the projects for the teams for the next quarter,” said  Marty Cagan.

In The Alternative to Roadmaps, author Marty Cagan talks about why product roadmaps are so popular. He blames it on the need of companies to preserve business value and put deadlines in place. He advises using a product team model where the company as an army and the teams are individual platoons.

Marty explains, “I often encourage teams to look back over the past year and grade themselves on the success rate of their roadmap in terms of how many of the items actually met the business objectives. If you do this, and if you’re not proud of what you find, then I’m hoping you’ll consider this alternative. Ensure your product organization has a compelling product vision. Ensure that each product team has a clearly defined, prioritized set of business objectives. Make sure any commitments that must be made are high-integrity commitments”

Similar to Cody Simms points, the focus should be on building better team structures where autonomous learning happens, where the focus is about outcome rather than output.

Perspective Changes Everything

“Roadmaps solve for the company not the customer,”  said  David Cancel, CEO of Drift.

In David’s post, When it Comes to Building Products, Agile and Waterfall Just Don’t Cut It Anymore, he discusses the value of shifting perspectives.

“I’ve never believed in setting a public product roadmap,” Cancel explains. “The problem with product roadmaps is that they often satiate company curiosity more than they solve customer problems… What solves for the customer is non-stop testing and a continuous improvement. Instead of having 2–3 releases a month, we’re shipping daily. This way, the customer could help us correct and iterate on our direction — not approval from an executive.”

We often hear that to succeed in today’s business environment we need to embrace uncertainty. However, it seems that nobody gets excited about it. Instead we spend more time moving boxes around in our Gantt tables.

Product roadmaps and all the logistics around them make us feel busy and safe. Learning how to learn surrounded by uncertainty is a better approach but far more uncomfortable that most people are prepared to handle.

“Every company in the world will tell you they are customer-driven. They’ll believe in the principle. They’ll have framed posters on the wall about it. ‘Solve for The Customer.’ But none of that means anything unless you actually make the structural decisions to ensure it,” Cancel said.

Expired Before it Started

“In my experience as a product manager, roadmaps are bullshit. They are created to make the company at large feel comfortable with where the product is going.”  said Daniel Schmidt, product manager for Maze.

In his post, Let’s Rethink Product Roadmaps, Daniel argues that roadmaps are already expired before they begin.

“Roadmaps make the product evolution legible. But inevitably, the experience of each project completely changes the trajectory. Things you thought were important aren’t…So if we don’t do roadmaps, what do we do instead?” Daniel said. “I’m not entirely sure yet. In my current company, I just say what we’re doing next and keep a list of all the things we could be doing but aren’t. The collective imagination of a company should be captured, just not with flawed forecasts for dreams becoming real.”

It seems that many of the authors mentioned in this post have found better ways to work by letting go the need to plan and control the future. Instead, they have found speed, impact and flexibility by focusing on the learning process.

A Common Language

“A common language goes a long way,”  said Noah Weiss, Head of Search, Learning, & Intelligence at Slack. Previously at Foursquare.

Noah Weiss took a different approach in his post #now, #next, #later: Roadmaps without the Drudgery. At Foursquare, he had his teams divide everything into three timeframes, #now (2–4 weeks), #next (1–3 months), and #later (over 3 months). The simplicity makes it easy to adopt and the common language makes it easy for teams to communicate.

Noah explains, “Between 20 people and 1,000 people is the sweet spot for a lightweight approach to product roadmaps. We had tried many at Foursquare, but none had stuck — including a few attempts at OKRs. The alignment from OKRs is great, but the measurement overhead is overkill for companies changing quickly and the quarterly cycle is too inflexible.”

How many organizations with over 500 employees do you know that are comfortable with not having at least a six month roadmap already planned?

Solve Problems Instead of Building Features

“When a team has a clear definition of a problem, solutions are often easy. Usually, the biggest source of trouble with defining solutions comes from unclear problem definitions.” said Jared M. Spool, Founder of UIE.

In Themes: A Small Change to Product Roadmaps with Large Effects, Jared Spool discusses the use of themes to frame a project. Themes based on customer problems.

He explains, “You can’t fill a roadmap with customer problems if you don’t know anything about your customers. By moving away from the invention of features (which can be done independent of whether customers need what you’re building), the roadmap technique requires deep and thorough customer insights.”

Switching from features lists to customer problems is a challenge for most organizations that crave certainty. Teams who want to move away from the feature factory will struggle, but those who succeed will enjoyed the benefits of having a shared understanding and the speed that comes with it.

Whether you think roadmaps are useful or not, we can no longer pretend that a long list of features with timeframes attached to them is the right way to build product. The job is to understand how we can transition to a problem-focused organization where teams can immerse themselves in continuous learning and fully embrace uncertainty.

Read more tips from experts about executing product plans at TechCo

Did you like this article?

Get more delivered to your inbox just like it!

Sorry about that. Try these articles instead!

Sofia is the Founder and CEO at NomNom.it (London ’15). Before NomNom, Sofia was the Head of Growth at Geckoboard. She loves startups, UX, CX, growth, philosophy, psychology, life hacking, data driven culture, art, fajitas and awesomeness.

Leave a Reply

  • (will not be published)