Dan Lavin

Roadmaps are dead, long live roadmaps!

Written May 19, 2019

Roadmaps are a loaded topic. Ask someone to describe one and you're likely to get a description that includes things like fixed dates, long lists of features, and fancy Gantt charts. You know, those mythical roadmaps that tell you exactly what will be delivered a year in advance. I'm not buying it.

For starters, most people (myself included) aren't very good at predicting the future. It's nearly impossible to confidently know what features will make the biggest impact 6-12 months from now. It's a guessing game. In the real world, things change. Priorities change. Customer feedback changes. New ideas surface. You get the idea.

Another issue with this type of roadmap is that it often leads to disappointing outcomes, both internally and externally. Coming up with an idea is easy. It's even easier to place that idea on a product roadmap and call it a feature.

For example:

  • Q1: SEO improvements
  • Q2: Better Reporting and Analytics
  • Q3: Mobile App 2.0
  • Q4: Better On-boarding

The problem is that people will inevitably anchor their thinking to these "features." They will use their imagination to build up some idea of what this cool new feature will look/feel like. They will start selling their version of that feature to customers. Then, when it's finally delivered, and it doesn't meet their expectations, they will be disappointed.

So, assuming we are in agreement that: change is inevitable, predicting the future is hard, and poorly researched features lead to disappointing outcomes, then it stands to reason that listing a bunch of features or ideas next to fixed dates in a spreadsheet is probably not a very useful exercise. In fact, doing this emphasizes the delivery of features instead of successful business or customer outcomes. Each release cycle becomes a formalized box checking ceremony. The team is shipping things not because they provide strategic value but because a promise was made 6 months ago that something seemed important.

Did we do that thing we said we'd do 6 months ago?
Great.

Did it provide value to the business? Are customers using it?
I don't know, but we delivered it on time. Who cares if we cut corners, forgot documentation, created technical debt, or left bugs unfixed. We kept our promise!

Working this way can lead to some pretty nasty consequences such as frustrated engineering teams, unhappy customers, and bloated products with unused features. In this world, the engineering team becomes a feature factory. They’re just “cranking out features and sending them down the line” without much thought, context or measurement for success. This is less than ideal. As a company, we should avoid behaviors that encourage this type of culture and should instead focus on arming our teams with the feedback and context necessary to deliver solutions that address real customer pain points.

Feature Factory

Great Product Roadmaps

Does that mean roadmaps are dead? Are they a waste of time? Should we all take a ride down the chill rapids and hope things just kind of “work out?” Of course not. There is still value in planning. It's still important to think about the future of both the business and the product. And we absolutely must be thinking about features we can build to address customer pain points. Roadmaps aren’t dead, we just need to start treating them like strategic communication tools instead of feature backlogs or release plans.

Great product roadmaps provide clear direction on where the product is going based on company goals. Roadmaps organize company goals into themes to help identify the root problem and the desired outcome(s). Once you understand the problem and why it's important, you can start identifying features that deliver positive outcomes for both the business and the customer.

problem-vs-solution

Replace fixed dates and feature lists with goals and themes to:

  • create focus and alignment across the company
  • make smarter, more informed decisions
  • adapt to changing demands and constraints
  • focus on problems (what needs to be solved and why), not solutions
  • give teams freedom and autonomy

Great product roadmaps are kind of like Google maps. If you want to know what features are being worked on you should be able to zoom in and uncover those details. If you want to understand the strategic value of a particular feature or you want to understand why the team is focused on a certain problem, then you should be able to zoom out to understand how it ties into company goals.

Take Me Home

Alright, all this talk of themes and outcome driven roadmaps is starting to make sense in theory, but how does it work in practice? What does a product roadmap actually look like?

Generally speaking, the management team meets regularly to discuss both short and longer term goals and objectives. At beginning of each quarter these goals and objectives are shared with the entire company. These goals and/or strategic themes are intended to drive positive outcome(s) for the business and should be used internally to influence team or product specific goals.

Given proper context and a clear set of strategic goals/objective, it should be possible for product and engineering leaders to identify relevant themes or outcomes (e.g. performance, preparing for production launch, etc.) that need to be addressed in order to achieve the goals and objectives outlined for the company.

With clearly communicated goals and a quarterly strategic direction in place, the product and engineering is ready to begin more tactical planning around what features need to be built. At my current company, this tactical planning process typically starts with a "Pitch," which is a concept made popular by the wonderful folks at Basecamp.

A Pitch is a very clear and complete presentation of work that has been shaped into something the engineering team can deliver in 6 weeks or less. A great Pitch clearly articulates a problem and proposes a solution that's been vetted and scoped to fit within a 6 week cycle. It must include enough information and context for product and engineering leaders to confidently evaluate, budget, and execute work. Think of a Pitch as a more friendly, human readable product/feature spec or requirements document. It's our way of aligning features with the product, the customer pain point, and the business value or strategic initiatives of the company.

ideal product development flow

To The Place I Belong

We have finally reached the end of this manifesto on road ... maps (pun intended). To recap, there should be a company vision/mission that influences team goals and streams of work. These streams of work are organized into themes that help shape what we focus on each quarter. And Pitches are used to outline what needs to be built (product or feature wise) to achieve our goals for the quarter. However, there is still one final piece or question that still needs to be addressed. And that is is what does the product roadmap look like?

Where would I go to see:

  • what we're working on now
  • what we're thinking about doing next
  • what we've identified as potentially important work to do in the future

The answer to that will likely vary from team to team. At Hatch, my current company, that answer is Basecamp, but that's only because it's the tool we prefer to use for communication. It could just as easily be replaced with something like Asana, Trello, or one of the many Atlassian products, etc. What's important is that there's a place, where everyone in the company can go, that very quickly and easily helps them understand: what's being worked on, what coming up next, and what may be coming in the future.

Almost heaven, West Virginia
Blue Ridge Mountains, Shenandoah River
Life is old there, older than the trees
Younger than the mountains, blowing like a breeze
Country roads, take me home
To the place I belong
West Virginia, mountain mama
Take me home, country roads
-John Denver

External Resources