A Roadmap Is Not a Project Plan

A roadmap should explain why one thing has to happen before another.

If it cannot do that, it may still be a useful project plan. It is not doing the job I expect from a roadmap.

I have seen plenty of documents called roadmaps that were really schedules stretched across several quarters. They had workstreams, milestone diamonds, owners, and delivery dates. They looked precise.

What they often did not show was the logic underneath the sequence.

Dates are easy to add

Once a leadership team has a list of initiatives, putting dates against them creates momentum.

Replace CRM in Q1. Launch the new customer journey in Q2. Add analytics in Q3. Roll out automation in Q4.

The sequence may still be wrong.

What customer behavior has to change before the new journey creates value?

Will the CRM have the data the process needs?

Does the organization know how frontline employees are supposed to use the new information?

Does the economic case depend on adoption that has not been proved?

Will the analytics measure the business result or only the activity produced by the new system?

A calendar cannot answer those questions.

Adding dates too early can make weak assumptions harder to see because the conversation shifts from whether the path makes sense to whether the milestones are on track.

A roadmap should show the logic of change

When I build a roadmap, I want to know what has to become true between today and the target state.

That may include a capability the organization does not have. It may include a system connection, a change in customer behavior, a new operating process, a different role for frontline employees, or evidence that the economics work.

Those conditions create real dependencies.

At the Army, improving recruiting performance could not be reduced to a marketing calendar or a CRM implementation schedule.

A prospect moved from initial interest to an appointment, then through recruiter engagement, qualification, application, and ultimately enlistment.

Different systems and groups touched different parts of that journey.

Marketing could improve response. CRM could improve communications. Recruiters could improve follow-up. Analytics could improve reporting.

The roadmap had to account for how those parts worked together to help a qualified prospect progress.

That is a different problem from sequencing projects by department.

Dependencies matter more than workstreams

A good roadmap exposes the relationships between changes.

Suppose a company wants personalized customer communications.

The visible initiative is personalization.

But useful personalization may depend on reliable customer identity, behavioral signals, content that can vary by customer need, and a process for deciding what should happen next.

If those dependencies are hidden, the organization can buy a personalization platform and still be unable to personalize anything that changes the customer outcome.

The same pattern appears in operating-model work.

A new process may require different decision rights. A new sales motion may require different economics. A new product may require service capabilities that do not exist. A market-expansion plan may depend on recruiting partners faster than the organization has ever demonstrated it can.

Those conditions belong in the roadmap because they determine what can sensibly happen next.

Economics belong in the sequence

Many roadmaps describe capability without showing the economics that make the capability worth building.

A future state can be operationally possible and still be unattractive.

If a growth plan depends on an acquisition channel that becomes uneconomic at scale, that matters before expansion begins.

If a new operating model only works after a certain level of volume, that threshold affects sequence.

If a technology investment depends on reducing labor or producing enough revenue to justify the cost, the roadmap should make that assumption visible.

This does not require a false level of numerical precision.

It requires enough economic logic to know what evidence would justify the next commitment.

A roadmap should preserve decisions that have not been earned yet

One reason I resist overly detailed roadmaps too early is that they can turn assumptions into commitments.

A line on a roadmap starts as a possibility. After enough planning meetings, it becomes something everyone assumes will happen.

That is especially dangerous when the later stages depend on evidence that does not yet exist.

The Army modernization work was intentionally phased. Early integrations and practical changes created evidence that a more connected recruiting model could improve performance. That evidence helped support larger technology investments later.

The roadmap therefore included places where learning could change the next decision.

That is useful.

A roadmap should tell leadership where it expects to learn something important and what that learning will affect.

Project planning comes after the major choices

Once the organization knows what it is building, understands the important dependencies, and has chosen the next set of changes, detailed project planning becomes essential.

Then dates matter. Owners matter. Resources, risks, milestones, and delivery discipline matter.

Those tools organize execution.

They do not determine whether the organization chose the right path.

A well-managed project can still create a capability the business does not need yet. A program can hit every milestone while moving the company no closer to the target state.

That is why I want the roadmap to answer the path question before the project plan answers the delivery question.

What has to become true?

What depends on what?

Which assumptions need evidence?

Where will leadership have to make another choice?

Once those relationships are visible, dates and workstreams become much more useful because they are attached to a sequence the business can explain.