The Alternative to Roadmaps

I have always loved the General George Patton quote: “Don’t tell people what to do; tell them what you need accomplished, and you’ll be amazed at the results.”

Unfortunately, typical roadmaps do just what the General warned against – they tell the team what to do.  Usually that’s in the form of a prioritized list of features or projects that someone believes will actually solve some problem (even if that problem is often not explicitly stated or understood).

For example, if your roadmap has “integrate PayPal as an additional payment method” on it, is that because you believe that there is a market of people that can’t pay with your other payment methods, or because there’s international payment issues, or is it about lowering payment fees, or maybe it’s there because someone believes it’s a competitive disadvantage not to have it.

In several articles I have highlighted the reasons I see typical product roadmaps as the source of so much waste in product teams.  The Product Fail article covers this at a high level, and the concept is elaborated on in The Inconvenient Truth About Product .

While there is increased recognition of the problems with roadmaps, many people have asked me to say more about the alternative.

In this article, I’d like to try to tackle this.  It is a big topic, and touches on issues beyond roadmaps such as product culture, empowerment and autonomy, and it usually takes me more than an hour to explain in person, but hopefully I can get those that are interested pointed in the right direction.

Before we jump into the alternative, we need to acknowledge that roadmaps have existed for so long because they serve two purposes, and these needs don’t go away.

The first purpose is because the management of the company wants to make sure that the teams are working on the highest business value items first.

The second purpose is because since they’re trying to run a business, there are cases where they actually need to make date-based commitments, and the roadmap is where they see and track those commitments.

So in order to be accepted in most companies, any alternative approach to roadmaps must address these needs at least as well as they are addressed today.

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.

In contrast, in the product team model, the teams are supposed to be equipped and empowered to figure out the best ways to solve the particular business problems assigned to them.

But for this to happen, it’s not enough to have strong people.  The teams need to have the necessary context.  They need to have a deep understanding of where the company is heading, and they need to know how their particular team is supposed to contribute to the larger purpose.

To bring this back to General Patton, some of you might already know that this concept of an autonomous team is at the core of the way military forces operate.  A team is typically referred to as a “squad,” which is intentionally small and largely autonomous, working under the common intent, but free to solve problems as they best see fit.

The common intent is the context we have been talking about.  “Intent is a concise formulation of the overall goals and purpose…A clear intent initiates a force’s purposeful activity. It represents what the commander wants to achieve and why; and binds the force together;  It is normally expressed using effects, objectives and desired outcomes….The best intents are clear to subordinates with minimal amplifying detail.”

For technology companies, there are several ways to provide this context or intent, but what I advocate is two distinct components:

The Product Vision: this describes the holistic view of what the organization as a whole is trying to accomplish.

The Business Objectives: this describes the specific, prioritized business objectives for each product team.

There are several systems and methodologies for managing these business objectives, but my current favorite is the OKR system (Objectives and Key Results).  The idea is simple enough: tell the team what you need them to accomplish, and how the results will be measured, and let the team figure out the best way to solve the problems.

Note that you might recognize these same parameters from the opportunity assessments/canvas.

As an example, suppose your product currently requires 30 days for a new customer to on-board.  But in order to scale effectively, this needs to be reduced down to 3 hours or less.  That’s a good example of an objective for one or more product teams: “dramatically reduce the time it takes for a new customer to go live.”  And one of the key results would be “average on-boarding time less than 3 hours.”

While the concept of team objectives might sound straightforward, there are many ways to institutionalize this across product teams and organizations, and it can take a few quarters before the organization reaps the benefits.

There are actually quite a few lessons learned about both good product vision, and especially regarding good application of the OKR system, and I’ll make that a focus for the next several articles.  In the meantime, start with Christina Wodtke’s materials.

So this context is critical – the product vision and the team objectives.

Earlier I said we needed to acknowledge the two drivers for old-style roadmaps.  The first was the desire to work on the highest business value items first.  Hopefully it is clear that this need is addressed by management providing the specific objectives for the organization and their prioritization.  The difference is that they are now prioritizing the importance of business results, rather than perceived value of features.

The second driver was the need for commitments.  We address this with the concept of high-integrity commitments. We do this for those situations where we need to actually commit to a date or a specific deliverable.

There are several benefits to this way of working:

First, the teams are more motivated when they are free to solve the problem the best way they see fit.  It’s the missionary vs. mercenary thing again.

Second, the team is not off the hook just by delivering a requested feature or project; the feature must actually work (as measured by the key results) otherwise the team needs to try a different approach to the solution.

Third, no matter where the idea for the solution comes from, very often the initial approach doesn’t actually work out, and rather than pretending this is not the case, this model embraces that likelihood.

It is all about outcome rather than output.

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.

Now empower the product teams to solve the business problems the best way they see fit, and see how many of your teams surprise you with their results.