In this chapter, I describe the alternative to product roadmaps. It's a big topic, and it touches on issues beyond product roadmaps, such as product culture, morale, empowerment, autonomy, and innovation. But my hope is to lay the foundation here and provide the details in the chapters that follow.
Before we jump into the alternative, however, we need to remind ourselves that roadmaps have existed for so long because they serve two purposes, and these needs don't go away:
So, to be accepted in most companies, any alternative approach to roadmaps must address these needs at least as well as they are addressed today.
In the empowered product team model this book is predicated on, the teams are themselves equipped 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 equipped with modern tools and techniques. The product teams need to have the necessary business context. They need to have a solid understanding of where the company is heading, and they need to know how their particular team is supposed to contribute to the larger purpose.
For technology companies, there are two main components that provide this business context:
The idea behind business objectives 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.
Consider this example of a business objective and a measurable, key result. Suppose your product currently requires 30 days for a new customer to onboard. But in order to scale effectively, management believes this needs to be reduced to three hours or less.
That's a good example of a business objective for one or more product teams: “Dramatically reduce the time it takes for a new customer to go live.” And one of the measurable key results would be “Average new customer onboarding time less than three hours.”
I'll describe much more about product vision and strategy—and business objectives—in the upcoming chapters. But for now I want to emphasize how important it is for each and every product team to know how their work contributes to the larger whole and what the company needs them to focus on right now.
It is management's responsibility to provide each product team with the specific business objectives they need to tackle.
Earlier, I said we needed to acknowledge the two drivers for old‐style roadmaps, and the first driver is the desire to work on the highest business value items first.
In the model I'm describing, it is management's responsibility to provide each product team with the specific business objectives they need to tackle. The difference is that they are now prioritizing business results, rather than product ideas. And, yes, it is more than a little ironic that we sometimes need to convince management to focus on business results.
The second driver is the occasional need for committing to a hard date. We address this with the concept of high‐integrity commitments, used for those situations where we need to commit to a date or a specific deliverable.
There are several benefits to this way of working:
It is all about outcome rather than output.
There are a few product teams out there that have modified their product roadmaps so that each item is stated as a business problem to solve rather than the feature or project that may or may not solve it. These are called outcome‐based roadmaps.
In general, when I see these, I'm pretty happy because I know the product teams are stepping up to solve business problems rather than build features. Outcome‐based roadmaps are essentially equivalent to using a business objective–based system such as the OKR system. It's the format that's different more than the content.
There is a tendency, however, with outcome‐based roadmaps to put a deadline date on every item, rather than only on the items with a true date constraint. This practice can have cultural and motivation implications to the team.
In most Agile teams, when you even mention the word “commitments” (like knowing what you're going to launch and when it will happen), you get reactions ranging from squirming to denial.
It's a constant struggle between those executives and stakeholders who are trying to run the business (with hiring plans, marketing program spend, partnerships, and contracts depending on specific dates and deliverables) and the product team that is understandably reluctant to commit to dates and deliverables. They're reluctant when they don't yet understand what they need to deliver, and if it will work in terms of delivering the necessary business results, in addition to not knowing how much it will really cost because they don't yet know the solution.
Underlying all of this is the hard‐learned lessons of product teams that many of the ideas won't work as we hope and those that could work will typically take several iterations to get to the point where they move the needle enough to be considered a business success.
In a custom software environment, you might just be able to iterate until the business is satisfied with the software (or they just give up on it). In a product company, this won't fly.
Now don't get me wrong—you've just heard how I feel about the perils of conventional roadmaps. Good product companies minimize these commitments. But there are always some real commitments that need to be made in order to effectively run a company.
It's a constant struggle between those executives and stakeholders who are trying to run the business and the product team that is understandably reluctant to commit to dates and deliverables.
So, what to do?
The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, whether what we deliver will solve the problem for the customer.
In the continuous discovery and delivery model, the discovery work is all about answering these questions before we spend the time and money to build production‐quality products.
So, the way we manage commitments is with a little bit of give and take.
We ask the executives and our other stakeholders to give us a little time in product discovery to investigate the necessary solution. We need the time to validate that solution with customers to ensure it has the necessary value and usability, with engineers to ensure its feasibility, and with our stakeholders to ensure it is viable for our business.
Once we have come up with a solution that works for our business, we now can make an informed and high‐integrity commitment about when we can deliver and what business results we can expect.
Note that our delivery managers are key to determining any commitment dates. Just because your engineers believe something might take only two weeks to build and deliver, what if that team is already occupied on other work, and they can't start on this work for another month? The delivery managers track these commitments and dependencies.
So, the compromise is straightforward. The product team asks for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well.
Again, in good companies these types of commitments are minimized, but there are always some. It's important for the organization to get comfortable with making these high‐integrity commitments and explain to the company that, while they are not something we do frequently, when we do them, they can depend on the product team delivering on these commitments.