Why Most Companies Design Future States That Are Already Obsolete

A big fear that many companies have is that they're going to design a future state that is not going to be useful by the time that it is implemented, because of changes in markets, technology, or customers. A future state that takes 6-18 months to design and is meant to last 5 years is almost certainly built on assumptions that will shift over time. A lot of future state work in the market produces a document or a deck that gets approved and then rolled out, a static document with a static implementation plan. When the design phase treats the future state as an end goal rather than a direction, customers feel that revisiting the plan feels like admitting that it was built wrong. With that, why are future states useful? And how can they be built to mitigate this issue?

Let's quickly broach some of the reasons for why a plan can become obsolete: it didn't take into account emerging technology, customer behavior was assumed to be stable, the competitive landscape wasn't stress-tested, leadership changes upset priorities during implementation, or the design process took so long that the market overall has changed.

I prefer to build what I call an "adaptive" future state model to help mitigate the above issues. First, document your assumptions, and make it explicit what assumptions affect which portions of the design. Second, add trigger points to have reviews when certain assumptions change (i.e. if your CRM changes and you have different capabilities in the new system, review the customer relationship processes). Third, break the overall design and implementation into shorter planning horizons with structured review to make the process more iterative and flexible. Fourth, if this is a company-wide future state plan, break it into smaller sections, where you prioritize which functions and departments to work on first. Breaking it into smaller pieces of a larger strategy helps you stay nimble and adapt over time. Overall, differentiate between the core design principles of the future state plan which should be durable, versus the specific solutions which should be more flexible.

Briefly diving deeper into the review cycles, the key here is to formalize them. Set an official cadence, either quarterly or biannually depending on how fast your industry moves. Review the progress of the future state plan and build a set of questions ahead of time that address not just your assumptions but also keep the team curious and looking for disruptors or external factors. Give someone ownership of running the reviews and keeping the future state document current. Additionally, prior to a review cycle, look for active feedback from all levels of employees, to see if the implementation so far has helped or if new challenges have come up.

Finally, I want to talk about mindset. While the future state is technically a destination you're moving toward, I find it better to think of it as a direction. You're trying to answer the question "how should we operate" based on current assumptions, but that answer may change over time as the market, technology, and customers change. So while you should do your best to create a detailed, well-thought out solution to the problems that face you today with the solutions available today, you should always be open to newer, better versions of that solution. That is how you create an adaptive future state model.