» The Three States of a GTM Transition

How to plan for current state, launch state, and future state during M&A, divestitures, and carve-outs.

When a company is moving through a merger, acquisition, divestiture, carve-out, or major reorganization, there is usually one date everyone is working toward.

Launch day.

The new company goes live. The new website launches. The systems separate. The new brand appears. Employees officially move into the new structure.

That date matters. But one of the easiest mistakes to make during a major transition is treating launch state and future state as the same thing.

They are not.

In most transitions, you actually need to think about three states at the same time: current state, launch state, and future state.

Current state: How does the business actually work today?

Before deciding what needs to change, you need an accurate picture of what exists now.

And I mean what actually exists, not just what the org chart, process documentation, or system diagram says should exist.

How does work move between teams? Who owns what? Which systems are really being used? Where are people working around the documented process? Where is ownership unclear? What is duplicated? What works well enough that you do not want to break it just because everything else is changing?

This matters because a transition can create a strong temptation to start building immediately. There is a deadline, everyone is moving fast, and decisions need to get made.

But if you do not understand the current state, you risk carrying old problems forward or creating new ones because you did not see the dependencies.

Launch state: What has to work on day one?

Launch state is different.

This is the version of the organization that needs to be functional when the transition becomes real.

Some things genuinely cannot wait. Customers need somewhere to go. Critical systems need to work. Teams need enough clarity to keep operating. Required communications need to happen. Data needs to be accessible. Someone needs to know who is responsible when something breaks.

But launch state may include compromises.

Maybe you keep a system you ultimately want to replace because migrating it before launch creates more risk than value. Maybe two teams continue operating somewhat differently because redesigning the full process would delay something more important. Maybe the new organization structure is clear, but every role has not moved into its ideal place yet.

That is okay.

Launch state does not have to be perfect. It has to be intentional.

The danger is allowing temporary decisions made under deadline pressure to quietly become permanent ones.

Future state: Where are you actually trying to go?

Future state is what the organization should look like once you are no longer designing everything around the transaction deadline.

How should teams work together? What should be centralized? What should stay distributed? What technology belongs in the long-term stack? What does the customer lifecycle look like? Where should ownership sit? What processes need to change? What should be measured differently?

You may not be able to build all of that before launch.

You should still know where you are headed.

That future-state view changes the decisions you make now.

If you know a platform will eventually be retired, maybe you avoid investing heavily in a temporary customization. If you know a function should eventually be centralized, you can document the target model even if the reorganization happens through future hiring and attrition instead of immediately. If you know two teams eventually need shared lifecycle definitions, you can start introducing common language before attempting the full redesign.

The destination matters even when you are not ready to travel the whole distance yet.

The goal is not to do everything before launch

Major transitions already create more work than most teams have capacity to absorb.

Trying to reach the perfect future state before launch can create just as many problems as ignoring the future altogether.

Instead, look at every major decision through three questions:

• What do we need to understand about the current state before we act?
• What has to be true at launch for the business to function?
• What future state are we ultimately trying to create?

Then make the tradeoffs deliberately.

Some things have to happen now.

Some things are worth fixing now because the transition gives you an unusual opportunity to make change.

And some things can wait, as long as today’s decisions are not making tomorrow’s work harder.

Launch is a milestone, not the finish line

A successful transition is not one where everything is perfect on day one.

It is one where the organization knows what must work now, what it is deliberately carrying forward temporarily, and what it is building toward next.

Understand the current state. Build the launch state. Design toward the future state.

That is how you keep a deadline from becoming the operating model.