Stuff I'M Thinking About

The way we typically do roadmaps limits both innovation and agility. Work never seems to be delivered when planned, and everything takes much longer to complete than the original estimate.

When we optimise for predictability and efficient use of people’s time, which is what roadmaps are supposed to do, we inevitably end up with less predictable outcomes, overloaded teams, and slower delivery of value to customers.

The answer is to change from a roadmap that is focussed on features, to a portfolio of customer problems that need to be solved.

In this short post I’ll outline a model I’ve used as a starting point in previous roles, and one that you can adapt to you own circumstances. 

The typical roadmap is a list of high-level features in priority order. These will sometimes be sized as t-shirt sizes, or possible even time required. These roadmaps are often under the purview and control of senior leaders in the company who sometimes also get to add their own items to the list.

This type of roadmap promotes and encourages discussion about the features themselves, how they might be built, and how long that will take. This quickly leads to a focus on the efficiency of the team in delivering features, and debates about the estimates and why can’t they be more accurate.

This system is based on the premise that work is controlled by managers, and passed down to the teams to carry out. A number of unhelpful behaviours arise from this model.

The first is that sales-driven feature requests.

A sales person is on call with a customer. The customer says they are having some problems using the product because it does not support a certain workflow. They talk about this, and the sales person suggests a solution. The customer likes the sound of the idea, so the sales person adds the feature to the backlog. Sometimes a promise is made on when that feature will be available.

The problem here is that when the feature gets built, the team are often not told much about the problem that lead to the request, or any context. They also do not know if other customers have this problem, or if it is still really needed.

The second is the CEO-driven features.

The CEO is out playing golf with a friend. The friend talks about a product they use, and a particular feature. The CEO thinks it sounds cool, so it gets added to the backlog for their own company’s product.

The problem here is that the feature might not solve any problems for a customer.

Another is the competitor-driven features

In this case the senior team look at the competition, decided what the best features are, and adds them to the backlog. After all, we cannot be in the market with missing features, can we?

The issue here is that the features might not solve any of our customer’s problems or add any value.

Finally, there is the product owner driven features.

Here, it is the product owner who writes all the tickets, works out the solutions, or worse, is just a relay for tickets provided for others.

Overall, the requests in the above scenarios often provide little context about why the feature is needed. The longer this list of features, the less agile the company and the team can be in delivering value to customers.

The other point about this is that all of these features will need maintenance, even the ones that deliver nothing of value; the cost of implementing a feature is not limited to the cost of building it.

Of course, in most roadmap scenarios there will be a mix of the above, but all have a negative impact on the agility of the company, and the ability of the team to deliver value effectively.

I have no argument that features do provide value to customers. But they only do so when they solve specific problems. When we switch to being focussed on the problems to solve, we can have more useful discussions about the true value any solution might provide to the customer and the business.

The Problem Portfolio

My solution to the above is the Problem Portfolio, or the Portfolio of Customer Problems to solve. This approach limits work in progress for the team, and stages potential work in a way that allows greater agility and more relevant and timely discussions.

This differs from a standard roadmap because each portfolio item documents a problem the customer has, not a feature. The problem statement describes the struggle a customer is having, the progress they are trying to make, and any relevant context.

I will explain the method first, and then talk about the improvements it provides. There are three classes of item in the portfolio.

1. Next

These are the items, in order, that the team will work on next. If there is one team, then there will only be one item in Next. Two teams, two items, and so on. Time will be allocated by the team, alongside other work, to start shaping the work to be done to solve the problem. This happens as part of the team process and does not need oversight of control by senior staff.

Once an item is in Next it should never be bumped in favour of other work. An item in Next can be discussed with customers—they can be told we are working on solving this problem next.

This will include looking to see if the problem can be broken into smaller pieces. Are there sub-problems? The focus is on the problems to solve, not the way in which they will be solved.

This approach ensures that the team can have their best shot at finding the best solution when they get to this item. They are closest to the code, closest to the customer, and have the most context to understand what will work.

Leaving the team to find the solution at the last possible moment ensures that any solutions are based on the reality of the world right now. The problem with feature-based roadmaps is that they are based mostly on assumptions about the future, creating a scenario when the team delivers what was on the card, only to find it is no longer needed, or doesn’t actually solve the problem as expected.

In the event that an item is bumped from Next, customers may need to be told that the item has been bumped, and they should also be told why. Having to disclose this imposes a high bar for bumping items at this late stage, ensuring there is a sensible, logical and genuinely urgent business reason for the late change.

2. Soon

These items are in rough order, but can change at any time. The primary questions to be answered at the portfolio meeting are these:

Is this still a problem for the customer?

Based on what we know, is this order still valid?

If the problem no longer exists then the card can be removed. Perhaps a feature shipped as part of the solution to another problem that solved this problem. Maybe the customer has changed something at their end. Either way, if the problem doesn’t exist anymore, then the card can be deleted.

The number of items allowed in this list is two times the number of teams, to a maximum of eight items. If there is one team, then only two items can be considered.

Limiting this to eight items (in the case of four teams) avoids the problems of trying to order too many items. For most humans it is impossible to prioritise long lists of things, with eight being close to the upper limit.

3. Later

This is an un-ordered list of problems that we don’t feel strongly about. We don’t order them because ordering anything that is more than three months away from being solved is meaningless. Doing any work on these items to size, estimate, or design, will be a waste of time.

4. New

Items that have been added since the last meeting.

Items will each have a problem card with the the following information.

Problem Statement:

What is the problem the customer is having. Avoid trying to document a solution.

Context:

In what context does the customer have this problem. Write down the story of the customer’s struggle. When does the problem occur? What is the customer trying to do when they hit a roadblock? The more context, the better.

Environment:

What is the environment? Are they any external factors relevant to this problem. A good example from a sales perspective is, the customer’s experience with competing products.

Value:

There may be a value associated with solving this problem. For example, if we solve this problem, we will gain another $40 per customer, per month, in revenue.

Cost of Delay:

This is an analysis of the cost of delaying the feature. For example, for each month we delay solving this problem, we lose five customers to a competitor.

There might also be a drop-dead date on the problem: if we cannot solve this problem by 15 March 2024, the day of our customer conference, then it is not needed.

A detailed overview of ways to calculating the cost of delay is outside the scope of this post.

Consequences

Framing potential work in terms of the problem fundamentally changes the nature of discussions with customers, and among stakeholders. There is no longer talk by senior staff at the meetings about the how the work is done. The portfolio allows them to focus on the strategic rather than the operational.

For example, the question “does this customer problem still exist” is much more valuable starting point than “is this feature still relevant”.

The problem with features is that we become invested in them. We asked for a feature, so we want to see it in the product. We promised the customer, so we have to do it.

If we talk about problems instead, we can have more meaningful discussions with the customer too.

Under this scenario, sales staff will obviously sell what the company already has to offer, but they are not there to make speculative sales bases on features that do not yet exist.

A better approach to sales—and those who are experienced already know this—is to get alongside the customer, understand their business, and to see how the product can support them. If there are customer problems we cannot solve, in part or in full, that becomes a strategy discussion. Does solving those problems support delivery of our strategy? When an item is placed in New, that triggers a strategy discussion.

It is very easy to chase every piece of business, and say yes to everything, but the place of strategy is to help use stay focussed and say no to things that would push us off course.

Once a problem is passed over to the team, and this is the big difference between a problem portfolio and a traditional roadmap, the team are responsible for deciding how to solve it.

This will be a difficult change for some leadership teams because it means getting out of the weeds and elevating the discussion back to strategy. Moving to an effective delegation model like this may require outside help.

This approach changes everything about how the team works. They are now responsible for working out a solution by collaborating with the customer and responding to feedback. They will decide how to break any work down into deliverable pieces of value, and deliver that value.

The Meeting

The portfolio meeting is run by a senior product person. They ‘own’ the portfolio.

Prior to the meeting, any items in new are checked to make sure that they have all the needed information. Items that do not have enough information will not be discussed at the meeting.

For each new completed item there will be a discussion—do we want to solve this problem at all, does it support our strategy? If it does, only then there can be a discussion about how valuable it is, and whether it should be moved into Later.

Once all the new items have been dealt with, the items in Later and Soon are considered. Do we have any new information—which should have already been added to the cards—that might change our views on which items should be in Soon. Because no commitments have been made on any of these items, they can be moved around freely.

The meeting cannot move more items into Soon than is allowed. If something is moved into Soon, something else must be moved out. The team cannot do all things at once, so limiting work that is allowed to progress towards the team at this early stage is key in ensuring they do not get overloaded. Overloading slows down the progress of all work.

Team changes

Alongside this approach there needs to be changes in the team. Their primary focus will be on solving problems, not on building specified features.

A big question here is, how they can work without requirements?

The requirements will be based on whatever is needed to solve the problem. The team itself will gather this information in advance of it being needed, but only just-in-time. In many cases they will start shaping the work to be done for the sole item in Next.

You might argue that this is wasting the team’s time, that if they have to spend time working out the solution, that it will slow delivery down. This is never the case.

In a traditional roadmap scenario delivery is already slow because those same people are also being asked to size and specify future work, sometimes to an extraordinary level of detail, so that we can have “a delivery date”.

We only have a limited number of people, and they only have a limited amount of time. If they are working on sizing, or design, or architecture, for future work, then they are not available for current work.

Team members do not have ‘spare time’ in which to do this work.

Running a problem portfolio, and allowing the teams to work on the solutions ‘in the now’ and with today’s context is going to result in far more value and far less waste than a traditional feature roadmap.

If the team are forced to start work on items that are months or years away, assumptions will often have to be made to fill in any gaps. Most of these—and we all know this from experience—will be found to be wrong, or require re-work when the team finally gets to that item.

This will almost always be the case for purely software projects, or any project that is solely knowledge work.

There is one additional matter to cover, and that is what happens to any work that does not directly solve problems. This includes upgrades to databases and external software packages, and anything technical. Perhaps the design system needs some refactoring as a result of recent changes. Maybe there are some security updates to packages.

Under a system that splits the portfolio of problems and the team’s own work plan (however they do that work), the team makes the decisions on what needs to be done.

It is the responsibility of the senior product person to make the senior leaders aware that there are on-going tasks to keep the platform in good order, and that reliable and consistent delivery of value can only be achieved and maintained when this work is done.

In some cases this will require feedback to the portfolio meeting if there is going to be anything out of the ordinary. An example might be a major version update of the database that requires a large block of the team’s time. Information can be provided to the portfolio meeting, although it is not their role to approve this work.

This system of working does rely on excellent communication between the product leader, the team, and senior leadership.

Excellent three-way communication ensures that the team can schedule all the work they do in a way that supports the most effective delivery of value to customers.

The free flow of information also ensures that senior staff can see value being delivered, and customer problems are being solved.

A no surprises policy, in both directions, is a good basic principle to have in place.

In keeping this post short, I have left out a lot of detail. That is deliberate; there is no framework that works in every context, and it is up to the reader to determine if this approach, or aspects of it, can be applied their own work.

If you want to talk about anything in this post, I am open to having a chat.