Chapter 10. Keeping It Fresh
What you’ll learn in this chapter
How the roadmap evolves
How far out your roadmap should go
Ways to manage planned change
Ways to manage unplanned change
How to communicate change
When conditions in the environment change, your roadmap—like any living thing—must change as well in order to survive.
How would your stakeholders feel if you built what you thought was important nine months ago instead of what is clearly important now?
But wait—your closest competitor just came out with something that’s eating into your close rate. And one of your largest customers just announced they won’t renew without a feature you ended up cutting. Not only that, but your team tells you that what you had planned for February is going to take until May to deliver.
If only the world would hold still long enough, we could get to the end of our roadmaps, achieve our visions of success, and retire rich and happy. But it never works that way. As we mentioned in Chapter 6, things change, and the closer your product is to the cutting edge, the faster they change. So what do you do?
When conditions in the environment change, your roadmap—like any living thing—must change as well in order to survive. In this chapter, we’ll discuss the frequency of change, how to manage it, and how to communicate it.
Roadmap Evolution
Imagine a species of small birds living on the mainland of South America. That species feeds on small, soft seeds common on the continent, and has evolved a small beak that is well adapted for quickly crushing these seeds and swallowing them in quantity. Life is good, and the species multiplies.
Over time, though, the population grows to the point that the supply of these seeds is no longer adequate. Individual birds sometimes have to range far to find enough seeds to survive. Some even fly away from the mainland and happen upon islands where there are no other seed-eating birds to compete with and plenty of seeds for them to feed on and multiply.
The only trouble is that the seeds native to these islands are larger and harder to crush than the seeds on the mainland the birds evolved to eat. It can be a lot of work to get enough nutrition out of these seeds, especially as the population grows and once again is competing for food. In this situation, birds with larger and more powerful beaks have an advantage. They can quickly crush and swallow the native seeds and get more of the available food for themselves than their competitors.
This, so the theory goes, leads to more viable offspring who tend to inherit their parents’ larger beaks. And pretty soon, the islands are filled with birds who resemble their mainland cousins in every way except for the size of their beaks.
The sudden change in the food supply forced this species to adapt quickly to their new environment. Having adapted to the island food supply, however, the birds settle into a period of relatively little change. The original birds evolved because of a stimulus, a change in their situation. While the situation remained stable, there was no stimulus to change, and bird beaks remained small.
Evolutionary theory suggests that this is what happened to the Galapagos finches Darwin described in On the Origin of Species (see Figure 10-1).
Figure 10-1. The evolution of Galapagos finches
Given a stable environment, a roadmap should not change either. But most market environments are not completely stable. Technology advances, competitors try to outflank us, fashions wax and wane, customers’ wants and needs evolve—even the company mission and strategy may change. Like Darwin’s finches, roadmaps are living things and must evolve to fit changes in their environment or face extinction.
Let’s look at an example. After executing on a robust roadmap for some months, Gillian Daniel, former VP of Products at smartShift Technologies, saw solid traction on business goals she had set, including increasing revenue per customer. However, she also discovered that margins took a hit as the cost to serve customers rose. This caused the company to reevaluate its objectives, adding “increase profit” (mostly by seeking ways to lower costs) to their prioritization scorecard. As you can imagine, the resulting scoring shifted priorities, and the roadmap was adjusted to fit the new direction, keeping the company in the black while it grew.
This change didn’t come on a whim one day, but after analysis of business results, discussion among the executive team, and examination of the implications on commitments already made to customers.
Successful companies revise their roadmaps on a regular cycle to reflect market changes and shifts in strategy or priority, while also allowing execution to proceed steadily between updates. This is similar to the concept of sprints in Agile Scrum development, but on a larger scale. In Scrum, the development team is left alone to execute for a few weeks with no changes in priority. Priorities for the next increment are determined when the output of the first increment is available for analysis.
According to Webster’s Collegiate Dictionary, punctuated equilibrium is “a theory that evolution proceeds with long periods of relative stability interspersed with rapid change.” We believe this is a good metaphor for managing roadmap change in the least disruptive way possible.
That begs the question, however: how stable is your environment? This will determine how far out your roadmap should go, and how frequently you should update it.
How Far Out Should Your Roadmap Go?
The faster the pace of change in your market, the faster your development cycle should be—and the more compressed your roadmap should be in terms of both total timespan and the intervals you choose. While an established product in a mature market that releases new and improved versions once per year will have a correspondingly long roadmap, a startup that is releasing new capabilities every week will have a roadmap that may stretch only a few months into the future.
This is why Intel’s public roadmap typically stretches out two to three years (and you can be sure the internal one projects further), as shown in Figure 10-2.
In contrast, many startups favor a simple roadmap format, which uses broader timeframe bucketing like Now, Next, and Later.
Generally, the pace of change and development is directly related to your product’s stage of life and the maturity of its market. If companies in your space are still figuring out what the future might hold, it doesn’t make sense to spend a lot of time making detailed long-term plans that will surely change.
Use Table 10-1 to help you determine what timeframes are most appropriate for your roadmap based on your product’s stage of life.
| Product Stage of Life | Timeframe |
|---|---|
Discovery | Short (e.g., months) |
Growth | Longer (e.g., quarters) |
Maturity/decline | Longest (e.g., years) |
Figure 10-2. This public roadmap from Intel spanned three years
Planned Change
You might be asking: But how can I justify changing my roadmap partway through? Won’t my customers, my partners, my salespeople—my board!—expect me to deliver on my roadmap commitments?
We’re going to go out on a limb and say no. The board and all of these other stakeholders understand and expect you to respond to changes in the market. How would your salespeople feel, as an example, if you stuck to your roadmap but failed to respond to a new competitive threat that was causing them to lose deals? How would your investors feel if you spent their money building what you thought was important nine months ago instead of what is clearly important now?
Even customers understand that your roadmap will evolve over time. (And if they don’t, make sure you remind them whenever you discuss the roadmap. See the Disclaimer section of Chapter 2 for guidance on forward-looking statements.)
Remember, a roadmap is not a contract. As long as customers see that your essential vision is one they share, considered changes in the path you take to get there are generally OK. When they see clearly that their interests are being served, stakeholders in general are supportive of roadmap changes.
Change Frequency
As we discussed in “How Far Out Should Your Roadmap Go?” organizations in fast-moving industries with rapidly evolving solutions need to update their roadmap at the speed of their business. A rule of thumb is that the refresh rate of your roadmap should match the time scale of your roadmap.
If your roadmap is laid out in quarters, you should probably revisit and update it every quarter. Repeating the same steps outlined in this book for creating a new roadmap allows you to regularly reexamine your visions, strategy, goals, and themes to ensure you are still headed along the right path.
Unplanned Change
When Features Are Late
The most common reason for roadmap change is when work is delivered (or it becomes clear it will be delivered) later than planned. In Chapter 6, we talk about how these delays sometimes result in carryover items that get pushed from one roadmap version to the next. In tech companies, product development seems always to be late. Similarly, supply-chain delays always seem to slow manufacturing output.
If you are focused on a certain outcome you want to achieve for your customer and your company, you can absorb changes to the output of your operation and shift your resources to maximize results against those outcomes.
Sometimes, however, delays occur that necessitate reevaluation of your roadmap at a high level. Enter what’s called the iron triangle (see Figure 10-3).
Ideally, you’d like to ship everything on schedule, on budget, and with the full scope and quality you envisioned at the start. However, when change happens, you have to adjust accordingly. The four levers of the iron triangle are available for you to push or pull when things don’t go as planned. Let’s look at each in more detail.
Schedule
The most obvious response to something taking longer than planned is to accept the new date and adjust the roadmap accordingly. This is not always the best option, however, especially if a delay will cause you to default on commitments, miss a market window, or fail to comply with regulations.
Therefore, when the schedule shrinks, you may need to consider decreasing scope or increasing resources to assure an expected level of quality.
An unanticipated delay may also be a symptom of trouble with one of the other variables, so it makes sense to have a detailed discussion with your team and evaluate the situation from all angles before committing to adjustments.
Figure 10-3. The iron triangle
Scope
If it is most important to meet the original schedule, you can look at cutting back on some of what you planned to deliver by that date. You can either deliver in stages (some features on the original date, some later) or deliver what you can on time and move on to other priorities after, depending on your product strategy.
Cutting scope might mean removing some features that are not required to solve for a particular theme, reducing capacity or quantity, or constraining options. It turns out, for example, that the reason Henry Ford famously painted all Model Ts black was that the fast-drying paint his team came up with to accelerate manufacturing (and maintain affordable prices) came only in black.
Sometimes, though, scope cannot be cut or has already been reduced to the point where further cutting makes something unusable for its intended audience. Regulatory compliance, for example, is often a binary thing. Either you comply or you do not, and you can’t shave a few things to make up time.
Resources
If you can’t change schedule and you can’t reduce scope, the next option is to add resources, thus probably blowing the original budget for the project and/or starving other priorities. If it’s a simple matter of manufacturing capacity, bringing on a second shift or an additional plant may make sense.
In software and other endeavors leveraging small teams of knowledge workers, however, this approach seldom works. As far back as 1975, Frederick Brooks published his now-famous book, The Mythical Man-Month (Addison-Wesley), wherein he demonstrates with data and numerous real-world examples that “adding manpower to a late software project makes it later.” And studies have since shown that small teams of three to seven people are most effective at delivering on software projects. This effect is thought to result from the increase in communication overhead necessary to coordinate larger groups. This effect is magnified if new people are added late in the project, thus burdening the existing team with getting the new team members up to speed when time is at a premium. (Amazon.com’s famous two-pizza rule is an attempt to apply this team-size principle across an entire large organization.)
Quality
The less-often-discussed aspect of the iron triangle is quality. When teams attempt to hold all other variables—schedule, scope, and budget—constant despite slippage, quality is what ends up suffering. People work late in an effort to meet unreasonable deadlines and end up making mistakes due to fatigue. Then, as the deadline approaches, they cut corners out of desperation.
As Edward Yourdon explains in his book Death March (Prentice Hall), “While the corporate goal of such projects is to overcome impossible odds and achieve miracles, the personal goal of the project manager and team members often shrinks down to mere survival: keeping one’s job, maintaining some semblance of a relationship with one’s spouse and children, and avoiding a heart attack or ulcer.”
This situation can lead to manufacturing defects, software and hardware bugs, and service quality issues that result in poor reviews, product returns, lack of reorder or renewal, and (ironically) delays in future roadmap deliverables because the team is occupied with fixing the quality problems resulting from the compromises made to achieve the prior date.
Software teams sometimes refer to the buildup of quality issues that slow development as technical debt, and too much of it can seriously hamper your ability to move your roadmap forward.
When to Compromise on Quality
Is it ever OK to compromise on quality? Surprisingly, yes.
If you know your product will be used by many millions with minimal changes and refinements over time, it makes sense to invest up front in the kind of foundation that will support that scale. In manufacturing, we develop our tooling for a certain throughput and lifespan based on assumptions about the quantity we will need to produce over a period of time. In software, we plan the database and application layers to handle the expected load of a projected level of simultaneous users. If your quantity of product or number of users is expected to be in the millions, it is necessary to make up-front investments to support that scale. In fact, to skip that investment would be irresponsible. As numbers mounted, you’d be unable to keep up with demand and you might never recover.
But what if your product or service is such a new and untried idea that you cannot make a realistic projection of demand? What if you are so far out on the cutting edge that there is a large chance the initial version of the product will be a flop and you’ll have to quickly replace it with something better? What if you might have to iterate several times to arrive at the optimal fit between what your product does and what the market needs?
This is exactly the situation most high-tech startups find themselves in, and exactly the reason why the Lean Startup movement advocates creating minimum viable products (MVPs), defined in Eric Ries’s book The Lean Startup (Crown Business) as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Ries encourages humility in the service of learning, saying, “Startups that succeed are those that manage to iterate enough times before running out of resources.” Working hard to make that first version of your product the best, most scalable, most reusable, most elegantly built thing is likely wasted effort. Worse, it actually slows your progress toward putting something in front of customers that you can learn from and then change based on their feedback. Once you have hit on a success, then it makes sense to go back and rebuild experiment #6 to the quality and scale required.
What combination of the four variables in the iron triangle you decide to play with depends on what is most important to your business. If you have a hard deadline you really can’t move without serious consequences to your business, then you’re going to have to look at scope, budget, and/or quality. If, on the other hand, scope is paramount, you may want to give on schedule and/or another variable. You can never have everything, but you can pick which goals to focus on and decide where compromise is the least painful.
Special Requests
Another frequent challenge to an established roadmap is the request to “slip in” a feature, fix, or one-off version for a “special” customer or a partner. This often will come from sales. “If we can just add this one little thing,” they’ll plead, “we can close this big deal and make the quarter.”
Whenever a request comes in that, if granted, would adjust the roadmap, we recommend asking three questions:
What problem is this request trying to solve?
This question can help you get past the specific request to the real customer need. Very often, sales (or even the procurement department at the company you are selling to) will not actually know why the request is being made. It’s important that you, the product person, learn why this request is important (other than that it purportedly will clinch the deal).
We recommend that you try to speak directly to the requestor, and then trace it back to the person with the underlying problem that needs solving. Sit with that person or interview them over the phone and learn about their circumstances. Ask them what they are trying to accomplish and how they imagine fulfilling this request.
You may have to ask why multiple times before you get to the root of the problem. Most often, specific feature requests are one person’s guess as to the best solution to an unstated problem. Learning who that person is allows you to evaluate whether they are in your target market. And learning what that problem really is enables you and your team to generate alternate ways of solving it that may be less disruptive to your roadmap, better for the original requestor, and possibly more applicable to all of your customers.
Does solving that need align with our objectives?
This question allows you to distinguish between simply providing value and making progress toward the goals you’ve spent so much effort defining and rallying stakeholders around. If the whole organization is focused on entering a new market, why would you slow progress on that effort by building features for a market that’s tapped out?
Is it more important than what’s on the roadmap now?
This question focuses the discussion on trade-offs. Though stakeholders often conveniently forget this, the iron triangle dictates that adding something in means cutting something out (or delaying it or adding resources). Many times it will not make sense to displace existing roadmap items with a special request, but sometimes it will. See Chapter 7 for some objective ways to evaluate the priority of one feature against others.
As we mentioned in earlier chapters, pet projects from your stakeholders are also a frequent challenge to the plan. Somehow, the individual(s) in question always seems to think that adding more work to an already challenging schedule will inspire the team to greater heights.
However, adding scope will unquestionably have an effect on one or more of the other variables in the iron triangle. If you agree to add that scope, then it’s best to decide right away which variables will be compromised to accommodate it. Not choosing is to let chance decide for you.
The easiest thing to do is swap out something already planned, thus managing scope back to its original size and leaving the other variables unaffected. This works well if your roadmap consists of themes only (see Chapter 5). A theme that describes the benefits but leaves out specifics about features gives you flexibility to cut specific features to make room for late-breaking requests.
External Pressures
The reason games like chess are a contest at all is that it’s not possible to predict precisely what your opponent will do in the future. Business competitors are the same. You can make a reasonable guess about how they will respond to your moves in the marketplace, but you can never be certain.
Similarly, you cannot predict with accuracy when the economy will rise or fall, when prices will inflate or stagnate, when new regulations will emerge, or when fashions will change (or in what direction). Analysts around the world expend a lot of energy attempting to forecast these things, but even they don’t agree. You must make some educated guesses about the future state of the world (or at least your market) in order to set direction, but you must also plan for being wrong.
These unforeseen changes in the market will at some point affect your strategy and therefore your roadmap—and sometimes they won’t occur on a nice, neat, quarterly schedule. What’s a product person to do? Respond and adjust the roadmap.
You might argue that you have a vision and that you plan to stick to it, come what may. As long as you are still solving a real problem for people who are willing and able to pay, you should stay the course, but you will get there faster and with less risk if you adjust your precise route based on the weather or traffic conditions.
Changes in Strategy
That said, at some point in the life cycle of many businesses, there comes a time when you realize your strategy and your goals are all wrong. At that point, the business may decide to pivot—that is, to implement what Eric Ries describes in The Lean Startup as “a change in strategy without a change in vision.”
For example, in the 1980s Intel was facing increasing price pressure from Japanese manufacturers in their mainstay memory chip business. Andy Grove and his then-CEO Gordon Moore looked at their future in this business, realized how poor their prospects were, and decided to make a strategic move into microprocessors. They completely exited the memory business, refocused their strategy on a better market, and ended up creating one of the most profitable companies in the world.
Intel was even then a large company, but pivoting is much more common in startups. Fred Wilson of Union Square Ventures says that 17 of 26 companies in his portfolio “made complete transformations or partial transformations of their businesses” between investment and exit. That’s 65%!
The upshot here is that it doesn’t make sense to wait for a regularly scheduled roadmap review to change strategy. When it’s time for a pivot, revisit everything from the product vision down, and be explicit about what is changing, what is not changing, and why these changes are necessary.
Communicating Change
Whether it’s part of a regularly scheduled roadmap update or in reaction to unanticipated shifts in external forces, when the roadmap changes, it is critical to the success of your efforts that you clearly and broadly communicate the why, what, and when of roadmap updates. Everyone needs the latest version of the treasure map if you are all going to dig in the same spot, right?
Why
The reasons change is occurring may be the most important part of a roadmap update, and yet this information is often left out. People are often embarrassed about the necessity for change, and they want to avoid scrutiny or argument about it. But leaving your team without a clear reason why is worse—it can undermine their confidence in the strategy and the leadership and invite them to make up their own (less-than-charitable) reasons.
Don’t shy away from discussing change. Embrace it and get everyone on board. We recommend socializing changes just the way you would socialize a new roadmap created from scratch (see Chapter 8 if you need a refresher).
Regardless of the impetus to change, the focus of your discussion must be on how, given the new reality, the changes in the roadmap will result in a better future for the company, the customer, and all of the stakeholders.
This is easy if you refer back to the vision, strategy, and goals you developed for the original (or most recent) roadmap. In most cases, your vision won’t have changed. Your strategy will often be unchanged as well. However, one of your goals may have been achieved, may have proven to be too ambitious, or may simply no longer be as relevant.
Suppose your goal of entering a new market has been achieved. You’ve signed on 100 customers, your close rate is pretty good, and you are collecting feedback from those new customers that there are some missing capabilities they really expect and need. It would probably make sense at this stage to replace your goal of entering that market with one of growing your business there, or possibly of increasing your renewal or reorder rate. This change would in turn likely refocus your roadmap on delivering those missing capabilities. Is this a bad change? No, it’s an indication of progress. Celebrate it!
Suppose, conversely, that your goal of penetrating this new market has manifestly not been achieved. Perhaps you’ve been able to sell only a few units, and those customers do not seem happy. Maybe your analysis shows there are cheaper alternatives with greater capabilities. You tested the waters and found them turbulent. What’s your next move?
That depends on your vision and your strategy. If this market is a key part of your vision and your first forays have identified some new themes that are the keys to success, then you should probably add those themes to your roadmap. If, like Intel’s Andy Grove, however, you realize that your strategy is likely to fail in this market, it’s time to pivot to a new strategy for achieving your vision. Perhaps there is a more attractive adjacent market, or a narrow slice of this new market that is willing to pay more for your unique solution.
You have limited resources; if you determine this is not the best use of your team’s time and effort, redirect them where they will be most successful. Giving your team the context for a change will inspire them to move forward with it instead of clinging to the old strategy.
What and When
If you’ve done a good job of setting the stage for change, your stakeholders will be hungry for the specifics. They will want to know how any shift in strategy or priorities affects the expectations you’ve set for deliverables.
Changes might be small—for example, adding or dropping a single subtheme for the next release or version, or changing a date by a week. This type of change may not necessarily affect your roadmap. They may affect the release or project plan, however.
Changes might be broad-reaching—for example, moving a theme planned for next year forward many months to be the next big focus, or dropping a theme that no longer seems crucial to success.
Changes can also be fundamental—as when the company or product pivots to a completely new strategy. In such cases, the themes, subthemes, and features of a roadmap may be changed or replaced entirely.
For the broad-reaching and fundamental changes, you’ll need to update your roadmap, inform all your stakeholders, and obtain buy-in—and if you’ve read this far, you know what all of that entails.
Roadmap Changes
If a roadmap is in some ways a story about how you envision success for your stakeholders such as the broad-reaching or fundamental levels, a roadmap update must tell the story of how you learned something that caused you to change direction.
Suppose it’s been nearly six months since this roadmap was created, and circumstances have changed a bit. Development and manufacturing of the indestructible Wombat hose is on schedule, but apparently, there have been difficulties with leaks in the 40-foot version.
Let’s revisit the current roadmap of our fictitious garden hose company. It consisted of these primary components:
Product Vision: To perfect American lawns and landscapes by perfecting water delivery
Business Objectives: 1M unit sales, <5% returns, <2% defects, Double average selling price (ASP)
Timeframes: H1 2017, H2 2017, 2018, and 2019
Themes: Roadmap to Perfecting Water Delivery, consisting of seven themes delivered over three years, and three features supporting the first theme to be delivered in the next six months
Disclaimer
After much analysis of the market, your take is that the “no-leak connections” claim is more important than having a second, longer model. You have decided, therefore, to ship only the 20-foot model for now and delay the longer model until the “extended reach” theme planned for the following year (when you plan also to develop an 80-foot model).
This change at the feature level, though, is nothing compared to the strategic opportunity you’ve identified in fertilizer. A few of your early test customers have discovered that your hoses are much better than most at delivering fertilizer. Apparently the Wombat hoses’ more rugged construction keeps them from clogging like cheaper hoses often do when spraying dissolved solids. Your research uncovers widespread dissatisfaction with the performance of competitors in this area and pent-up demand for an effective solution.
Suddenly, something you had planned as a theme a couple of years out looks more like something that will provide clear differentiation in your target market. You do your market research and your business projections. You discuss timelines with your development team and manufacturing partners. You shuttle between stakeholders and socialize the opportunity as well as its significance in terms of roadmap changes. You even go to the board and preview a possible change to your stated strategy.
In the end, you decide to move “Fertilizer Delivery” up from 2019 to the second half of 2017. You also reach agreement with the board that if you meet certain thresholds in sales, you will adjust your product vision to read, “To perfect the landscapes of affluent Americans by perfecting nutrient delivery,” and develop new themes along these lines.
Figure 10-4 through Figure 10-9 show what your slides might look like at a quarterly roadmap review with the executive team or the board (see Chapter 9 for a reminder on detailed recommendations for presenting the roadmap).
Figure 10-4. Remind your audience that your company vision hasn’t changed by showing the same slide you showed a quarter before
Figure 10-5. Describe the opportunity to enter the fertilizer delivery business and provide the rationale for the change, explaining why it benefits both the customer and the company
Figure 10-6. Visually indicate which themes and which specific features are changing or moving on the roadmap with colors, arrows, pop-ups, or whatever is necessary to annotate your roadmap clearly
Figure 10-7. Show the updated version of the roadmap without the markup; this is the new version you will share outside the review meeting (note the date in the lower-left corner)
Figure 10-8. Make the newly accelerated item on the roadmap real with a diagram, photo, or mockup
Figure 10-9. Preview the new strategy that will go into effect if your fertilizer theme is successful—you will likely not share this outside of the roadmap review with executives unless it takes hold
Forks in the Road
The situation of our fictitious garden hose company is not that unique, actually. Many companies (especially startups) face strategic forks in the road, where they must answer questions like these:
Do we grow revenue by going down market to a larger number of smaller customers, or do we differentiate further to support higher prices among our high-end customers?
Do we pursue a promising but untried technology, or do we focus on unit cost reduction?
Do we focus on channel partners, or sell direct?
Rather than pursue all avenues at once, successful organizations often focus on one opportunity at a time, but leave the door open to pivot or expand in the future if the situation warrants.
Having played multiple scenarios out on paper, the garden hose company has concluded one option is the best, and its roadmap reflects this decision. There are always risks, however, and one or a few other options may have been almost as attractive.
One way to disentangle this situation is to test the underlying assumptions in your projections. If path #1 is the correct one, you should see signs of success at some point along that path. And if you can incorporate thresholds (reference Chapter 4’s discussion about key results)—specific performance numbers your product needs to achieve—into your roadmap, you can build optionality and decision criteria right into your plan.
Our garden hose company might, for example, build a roadmap with one pathway that assumes delivery of fertilizer is a huge winner for the company, and another pathway that assumes it is but one among many themes built around specialized needs (Figure 10-10). Which path is ultimately followed depends on the performance of the initial product for fertilizer delivery.
This decision will have such profound effects on the company direction that, in addition to the roadmap visualization itself, it requires additional information on the decision criteria (Figure 10-11). If you were to travel from point A to point B and decided that a ferry was how you’ll get there, you couldn’t suddenly, in the middle of the ferry trip, decide that you want to take a car instead. You’ll have to finish the ferry trip and then get into a car, so this type of information gives a team foresight into how to plan out their future product, which can have impact on how the near-term development is done.
This additional information may be presented at a stakeholder buy-in meeting (see Chapter 8 for buy-in meetings and Chapter 9 for presenting and sharing).
Figure 10-10. Which path our garden hose company ultimately follows depends on the performance of our initial product for fertilizer delivery
Figure 10-11. The decision criteria behind the proposed new business objectives
Lather, Rinse, Repeat
Whatever process you follow to create your first roadmap, you will have to revisit it at intervals that match the pace of change in your market.
How deep you will need to go on subsequent revisions, however, depends on how much things have changed since the last version.
Whenever you revisit your roadmap, we suggest you review Chapter 8 to help ensure the buy-in is smooth and transparent. This may be sufficient if changes are minor.
If your product vision has not changed, but you have new priorities based on changes in your market, we suggest you review Chapter 7 to ensure these changes have a clear rationale.
If you have made such progress on solving customer and organizational needs that you are moving into whole new areas of functionality, you may want to review Chapter 6 to ensure you are focused on providing real value.
If customer or organizational needs have changed, or you are serving new types of customers, you may want to review Chapter 5 to ensure you’ve identified the most important themes to focus on.
If your company’s vision, strategy, or key business objectives have changed, you may want to go all the way back to Chapter 3 to rethink your roadmap from the ground up.
As you can see, the deeper the changes, the further back in this book you may need to go!
Summary
Everyone has a plan ’til they get punched in the mouth.
Mike Tyson
No matter how well you plan, change is unavoidable. Following the steps in this book won’t help you develop a plan that’s immune to change, but it will help you create one that can evolve with it.
Have a regular process for reassessing your roadmap and communicating the why, what, and when of any changes you make.
When change is necessary (and leading up to your regular roadmap updates), assess the depth of that change and decide how far back you need to go in the process described in this book to revisit assumptions.
In the final chapter, we’ll recap what you’ve learned throughout the book and offer some tips on where to go from here.