Prove the Next Step Before You Fund the Whole Future State

A roadmap can describe the whole future state without requiring the company to fund all of it at once.

That distinction is easy to lose.

Once leadership has agreed on the target architecture, operating model, organization, or technology environment, the gap between today and the future can quickly become a large funding request.

Sometimes the full build is necessary.

Often, the organization can answer an important question first.

I think the useful management question is: What do we need to prove before the next investment makes sense?

Every roadmap contains assumptions

A roadmap may look like a sequence of work, but underneath it is a set of beliefs about how the business will behave.

Customers will adopt the new experience.

Employees will use the new workflow.

Better data will improve a decision.

An integration will remove a meaningful bottleneck.

A new channel will create attractive growth.

A different operating model will scale.

A platform will be worth the cost because the organization will use the capability it enables.

Those may all be reasonable assumptions.

They are still assumptions until the business has evidence.

Funding the entire future state before testing the assumption that could invalidate it turns uncertainty into capital commitment.

Use what exists to test the logic

At the Army, the broader recruiting modernization opportunity crossed marketing, CRM, analytics, recruiter workflows, and several underlying systems.

It would have been easy to frame the answer as a large technology program.

The more important question was whether a more connected recruiting model could improve progression through the journey from initial interest to enlistment.

That could be tested before every system was replaced.

Early integrations and practical improvements used capabilities already available to connect prospect behavior, communications, and downstream action more effectively.

Those changes produced evidence that the broader model could improve performance.

That evidence mattered when larger technology investments came into view.

Leadership was no longer evaluating the future state only as an architectural idea. There was operating evidence behind the logic.

The first stage should attack the largest uncertainty

A pilot has little value if it only proves something the organization already knows.

The useful test is the one that reduces uncertainty around a decision that matters.

If the future state depends on customers adopting a new behavior, test that behavior.

If it depends on frontline employees using a new workflow, test whether the workflow improves the job enough to be used consistently.

If it depends on connecting two data sources, connect them for one consequential use case before funding the enterprise data program around the idea.

If it depends on a partner ecosystem, test whether the essential participants have a reason to participate.

The Bob Vila venture is a good example.

Consumers responded positively to the home-improvement concept. The model also depended on contractor participation.

Research showed that contractors did not see enough value in participating in a venture associated with the Bob Vila brand.

That finding changed the investment decision before the full vision was built.

The work produced useful evidence because it tested a condition the business needed in order to function.

The first proof often does not require the future-state technology

Leaders sometimes assume that testing the idea requires building the intended final solution.

It often does not.

A manual process can test whether a customer responds.

A limited integration can test whether better information changes a decision.

A pilot can test whether an operating model works under real conditions.

A small market can test the economics of a growth idea.

A temporary workflow can test whether a new handoff improves progression.

These are not scalable end states.

They are ways to separate two questions:

Does the business logic work?

What should we build to scale it?

Answering the first question often changes the answer to the second.

Staging improves capital allocation

Staged implementation is usually described as a way to reduce risk.

I also see it as a way to create better investment decisions.

If the first stage works, leaders can fund the next stage with more confidence.

If it works differently than expected, the roadmap can change before the company has committed to the original design.

If it fails, the organization has bought information at a lower cost than a full implementation would have required.

That is useful even when the evidence is disappointing.

A roadmap should create decision points where evidence can change the level or direction of investment.

Otherwise the roadmap becomes one large approval made at the beginning, with every later phase treated as inevitable.

A pilot needs a decision attached to it

There is a weak version of staged implementation.

Teams run pilots because no one wants to make a commitment. Tests are too small to matter. Success criteria are vague. Nothing gets stopped, and nothing earns scale.

That approach creates motion without much learning.

A useful stage has a clear decision attached to it.

What are we trying to learn?

What evidence would increase confidence in the next step?

What result would cause us to change the plan?

What investment decision follows from the evidence?

Those questions make the test consequential.

Staging should lead to commitment. The difference is that the larger commitment comes after the organization has learned something that matters.

Fund the future in steps that can teach you something

The target state still matters. The roadmap still matters.

They tell leadership what business it is trying to create and what has to happen along the way.

They do not require every component to be funded on day one.

When an important assumption can be tested with the capabilities already available, I would rather prove that assumption first and let the evidence shape the next commitment.

Sometimes the evidence will justify moving faster.

Sometimes it will change the design.

Sometimes it will tell leadership not to build the thing it thought it needed.

All three are better than discovering the answer after the entire future state has already been funded.