A Claude readiness assessment tells you where the gaps are. A roadmap tells you which gap to close first, what to test next and what evidence would justify wider use. Without that sequence, teams can accumulate pilots, connectors and Claude Code access while the operating model remains unclear.
1. Foundations: decide what deserves a first wave
Start with the six readiness workstreams: data and access, use case portfolio, platform route, controls, evidence and enablement. For each, name an owner, record the current proof and identify the blocker that would stop an actual workflow. A high aggregate score does not override a missing data approval or an absent reviewer.
Build a scored use case portfolio with a small number of candidates. Compare expected value with implementation effort, data sensitivity, frequency and the cost of a wrong answer. Write a one-page charter for each contender: the user, task boundary, baseline, desired result, approved data, human decision point and owner. If that cannot be written plainly, the use case is not ready to fund as a pilot.
Choose the route deliberately. A role-based Claude app workflow may help a knowledge team analyze and draft. Claude Code belongs in an owned repository with explicit permissions and runnable checks. An API workflow needs an application owner and a defined path for inputs, outputs, logging and review. These are different delivery paths, even when they serve one business goal. The target-state architecture should show where data enters, where tools can act and who can stop the work.
Ready if: each first-wave use case has an owner, approved data route, baseline task set and written exit rule.
Red flag: the roadmap is a calendar of tool rollouts with no evidence that a workflow is worth operating.
2. Prove: run bounded work and measure the result
Prove is where the roadmap becomes falsifiable. Select a handful of representative tasks, including awkward cases and failure cases. Capture the current human result before changing the process. For a Claude app pilot, measure accepted output, revision effort and time to a usable answer. For Claude Code, use one repository and a narrow task class; run tests, inspect the diff and require the same review expected of a human contributor.
Keep a shared evaluation set and a trace of important failures. Review quality, reviewer effort, security exceptions, latency and cost per successful task together. A low cost per request can be misleading if reviewers spend longer correcting the result. Re-run the task set after meaningful prompt, model, permission or tool changes. Anthropic's guidance on agent evaluations supports testing the whole workflow rather than judging isolated model responses.
Before introducing tool connections, decide which connectors or MCP servers a role may use, what data they expose and whether any action requires approval. In Claude Code, keep repository instructions concise and make deterministic checks runnable; do not ask a prompt to substitute for tests, permissions or review. Begin with limited autonomy and expand only when the evidence shows that the team can detect and recover from failures.
“Readiness shows where you stand. The roadmap decides what happens next.”— Mach Advisory™, Claude AI Roadmap brochure
- Foundations
Approve the data route, permissions and evaluation baseline.
Gate: Owners and controls are evidenced. - Prove
Run bounded Claude and Claude Code pilots.
Gate: Quality and review effort meet the exit rule. - Scale
Reuse approved tools, standards and training.
Gate: Regression checks and spend stay in bounds. - Compound
Expand autonomy only where results hold.
Gate: Portfolio review funds the next wave.
Timing follows evidence and capacity; the waves are decision stages, not fixed calendar promises.
The diagram is a decision sequence, not a promise that every organization moves through the waves on the same dates. A gate can result in go, hold while a specific blocker is fixed, or redesign when the use case, route or business case is wrong. Document the decision and its owner.
3. Scale: reuse the operating model, not just the licenses
Scale only after a pilot produces repeatable accepted results. Package the successful workflow as a role playbook: who can start it, what information may be supplied, how to review output, what to do on failure and which metric signals drift. For Claude Code, standardize repository onboarding, permission boundaries, tested commands and human code review. Shared skills and approved tools can help, but each new team still needs a task owner and an evaluation run on its own data.
Now turn the first-wave findings into an ordered backlog. Some work is reusable infrastructure: access patterns, a small evaluation harness, approved tool inventory and usage reporting. Other work stays local to a team. Keep the distinction visible so a central group does not become a queue for every prompt change, and teams do not invent incompatible data routes. Add training where the review process changes, not merely where a new login appears.
The scale gate should compare the new cohort with the pilot baseline. Are accepted outcomes stable? Can reviewers explain failures? Are permissions and spend inside agreed bounds? If quality falls when the workflow moves to another team, that is a signal to revise the playbook or the use case before further rollout.
4. Compound: keep the portfolio honest
A roadmap should survive its first launch. Review adoption, outcome quality, review time, exceptions and cost at a regular operating cadence. Re-score the six workstreams each quarter or after a material change in data access, model behavior, tool permissions or business priority. Retire workflows that no longer earn their review cost. Fund the next wave from demonstrated value, not from the number of people with access.
The useful output is concrete: a one-page roadmap, ranked use case portfolio, target-state Claude architecture, evaluation plan, stage-gate rules, Claude Code governance model and first-wave charters. Those artifacts let an executive see what is being funded and let a delivery team know what to build. They also make a hold decision constructive: the blocker, owner and evidence needed to reopen the gate are written down.
Teams that have not completed a readiness assessment can start with the six-check Claude readiness guide. Teams with a scorecard can use the Claude AI Roadmap service to turn it into an owned first wave.
Frequently asked questions
Do we need to finish every readiness gap before a Claude pilot?
No. Close any blocker that affects the chosen workflow, then run a bounded pilot with the right owners and controls. Record remaining gaps as explicit constraints.
Does Claude Code need a separate roadmap?
It should share the portfolio and stage gates, but its repository permissions, tests and code review need specific decisions that an app-only plan does not cover.
How long does each wave take?
The waves are decision stages, not fixed durations. Move after the agreed evidence is reviewed; hold or redesign when the exit rule is not met.
Sources
Roadmap service
Plan the first Claude wave.
Bring the scorecard, candidate workflows and owners together. Leave with a sequence, evidence gates and a build-ready first wave.



