There are lots of great articles about developing a roadmap for a product or service. But sometimes these processes can seem too heavy, too slow, or too strategic (is there such a thing?) for the task at hand. A lightweight process, aimed at selecting and ordering improvements rather than expressing an ideal and working toward it, can work when certain conditions are met.
Conditions
- The product (or process or service) exists already.
- Stakeholders are certain the product does essentially what it is supposed to do, but are dissatisfied by the results.
- There are too many potential problems and potential fixes to clean them all up in a single project, though this is desired, or
- the political situation is such among stakeholders that choosing a good place to start will be difficult (some may not want their area touched, others may want to go first, still others may not want to work.
These conditions assume that the strategy is good, and that the stakeholders’ attempts to fulfill that strategy are based on sound choices, but are perhaps not well-executed.
Goals
To successfully produce a roadmap and manage the political situation among the stakeholders we must accomplish a few things:
- Uncover and arrange opportunities for improving the product.
- Group and sequence the opportunities.
- Plan the work for the first step on the roadmap.
Along the way we must be careful to:
- Make good use of any work the stakeholders have done to date.
- Demonstrate to stakeholders that we understand the current situation.
- involve the stakeholders in determining the value and feasibility of addressing each opportunity.
- Involve the stakeholders in negotiating the roadmap and selecting the first step.
Stakeholders appear in each of the four points above. We must bring them though this process and ensure that they are heard, and are at times active participants, but we must not become wrapped up in their shenanigans. There are defined points in the process where we involve them.
The process
1. Investigation
The first few steps of the investigation phase will occur together, and as you learn more you may find yourself returning to stakeholders for clarification, more information, or scope adjustment. The investigation phase typically takes the longest of the three.
- Stakeholder research to establish goals and wishes, and collect their ideas.
- Primary user and stakeholder research to understand existing needs and processes and learn of opportunities
- Review secondary research (research done by others).
- Express any found problems/opportunities (often pain points) in terms of their benefits (“gain points”) and likely features.
- Arrange these opportunities by theme to see if and where problems are concentrated.
Step four is critical: you’ll have detected many problems and pain points, but need to express them first in terms of a benefit you’d like to deliver rather that just a feature. Remember that a benefit is the result of having a problem solved expressed without regard to the exact method of solving it. If you learn that students struggle to fill out a financial aid form on time, it would be tempting to offer an advisor to help them. That’s a feature, and it might not be the right one; the benefit may be that students have the information they need to fill out the form quickly and submit it easily. Go ahead and offer features, but only after identifying the benefits. The stakeholders will help us choose features once the benefits are clear.
We arrange opportunities by theme now to see if it tempts the stakeholders to narrow the scope of the project. You have to start somewhere, and the earlier we can reduce scope the higher the likelihood that the project will produce a useful first increment.
At this point you’ll have be ready to show the stakeholders your understanding of the current situation and the opportunities you’ve uncovered. This will fulfill both “make good use of any work the stakeholders have done to date” and “demonstrate to stakeholders that we understand the current situation” reminders above.
2. Synthesis
You’ve produced the raw material necessary for the stakeholders to help arrange opportunities into a rough sequence. Depending on scope the entire synthesis phase could be done in one workshop, or it might require two with some thinking and preparation in between.
- Have a workshop with stakeholders to score opportunities by value and feasibility.
- Examine the high-value, high-feasibility opportunities for common themes, then sequence all opportunities within these themes according to value and feasibility. More doable and higher-value items come first, and valuable low-feasibility items come last.
- Have a workshop with stakeholders to arrange these themes in sequence according to feasibility and value.
Scoring opportunities for value and feasibility is a simple matter of placing these on everyone’s favorite business diagram, the 2×2 matrix. Items in the high-value, high-feasibility quadrant are potential good places to start. You’ll want a small but politically-effective number of stakeholders in this meeting; too many and it will be hard for the group to make decisions. too few and they won’t be informed enough to make good decisions.
This process requires you and the stakeholders to discuss how each of the opportunities might be met; what improvement (feature or change) would deliver the desired benefit. So we are sneakily involving the knowledgeable stakeholders in choosing improvements to deliver the benefits. They will feel useful pressure to help come up with high-feasibility ways to address high-value items.
Some items will be high-feasibility but low-value. These are nice-to haves that probably should not appear in the ultimate roadmap. Put them in a parking lot so that no one need be sad about them being cut outright. Still others are both low-feasibility and low-value. The stakeholders might have pet items among these. They should also go to the parking lot unless great ideas come up about how to rethink them, their value and feasibility jumps as a result, and the prior research supports their inclusion.
The themes that emerge from looking at the high-value, high-feasibility items are more informative than the rough themes we offered in the investigation phase, and will govern the arrangement of opportunities in the roadmap. And when you look at them you will likely see that some of these themes contain more high scoring items than others.
Offer these themes and the improvements they contain to the stakeholders in a workshop, and ask them to put these themes in order. If we could work on just one theme, which theme would we choose? That one will be first. By the end of the workshop you’ll have themes in a rough sequence, and within these their opportunities in a rough sequence.
You could stop here, but it is likely that the stakeholders aren’t done yet.
3. Negotiation
Now that you have a sequence of themes, and within those a sequence of improvements, you have a roadmap. But it puts some lower-feasibility items ahead of others just because of the themes they appear in. It also may offer a sequence that is awkward to accomplish, or doesn’t begin addressing top organizational goals early enough. Time for negotiation.
- In a workshop with stakeholders, negotiate tradeoffs in improvement sequencing to better meet organizational goals.
- Once that negotiation is complete, in that same workshop select one or a few items earliest in the sequence to make up the initial project.
- Then go away and plan and estimate the cost in time and treasure to effect that project.
If you have the right small group of stakeholders, they’ll notice that they can rearrange some items to have the roadmap better address systems, efficiency, or political factors, start delivering against key goals sooner, or have certain improvements essentially make decisions early that will be helpful when tackling later improvements. Let them make these tradeoffs. The integrity of the themes is not important; we used the themes as a tool to make the rough sequence easier to accomplish.
After the tradeoffs are done, look to the items at the early end of the roadmap for the scope of the first project. It is tempting to bite off too much; everyone is excited about all the things you’re planning to do together. It’s best to keep the scope of the first increment small, achievable, not too expensive. Short projects with narrow scopes are more likely to succeed, after all.
Why not define an ideal?
You’ll note that this process does not define an ideal end state nor attempt to arrange a roadmap to produce that end state. End-state-based design is interesting (and there’s a very nice process called Ideality that depends on an understanding of the ideal), but I’ve elected not to make use of it here. There are several reasons for this.
- Producing an expression of an ideal end state, when there are lots of potential improvements, is expensive.
- The sequence of roadmap items aimed at an end state is likely to be different than a value- and feasibility-weighted roadmap which leads to high value improvements more quickly.
- Understanding and acceptance of an ideal end state tends to decay rapidly as business conditions change and new information and technology becomes available.
- Commitment to an end state reduces optionality, the ability of the organization to make new decisions about the future as needed.
Instead, this roadmapping process relies on the improvements themselves and especially benefits they are intended to deliver to take the place of an ideal end-state. These benefits express the desirable future in a diffuse, less-specific manner. Indeed, the later and less-feasible an item on the roadmap the less likely it is to be developed. this is true fo end-state-based roadmapping as well; the likelihood that the organization will pursue the entire roadmap diminishes over time. Why not embrace this constraint?