From a brief to a buildable roadmap

1. Start with the work happening today

Instead of asking what the software should contain, follow the most recent real case. Who initiated it? Where did the information come from? Which step had to wait? When something failed, who received the call? An imperfect current workflow contains more truth than a wish list.

For example, “we need an order dashboard” does not explain who makes which decision. Following one late order may reveal that an operator needs the overdue item, its reason and current owner — not another revenue chart.

• Record the actor, input, decision and output at each step.
• Mark where data is re-entered, waits for confirmation or moves through messages.
• Choose three to five real cases: a normal path, an error and an exception.

2. Answer six questions before estimating

Easy Alo uses six questions to test whether a brief is ready for planning. Answers need not be perfect, but every unknown needs explicit discovery or validation in the roadmap.

Do not force every outcome into a vague number. “Reduce handling time” becomes useful only when the measurement has a start, an end and rules for waiting time.

• Who uses the product directly, and who is affected by its outcome?
• What is difficult, slow, error-prone or invisible today?
• Why change now: cost, scale, regulation or customer experience?
• Which outcome matters, and where in the workflow can it be measured?
• Which constraints are real: data, integration, time, security or operating capacity?
• What is the smallest useful test that reduces the biggest risk?

When executives, operators and end users answer differently, the workshop has not failed. It has exposed the alignment work required before scope is fixed.

3. Cut scope into value slices, not technical layers

A roadmap that says “frontend first, backend next” describes how a technical team divides labour. It does not produce anything a user can validate. A better slice runs end to end: create, approve, notify and review history for one request type.

Each slice should finish with observable behaviour. Once the first slice works with controlled real data, the team learns about permissions, exceptions and integrations much earlier.

• Slice 1: one primary role, one critical journey and controlled real data.
• Slice 2: the common exception and permissions of the related role.
• Slice 3: reporting, automation or integration after source data proves reliable.

4. Write acceptance criteria in operating language

“Includes approval” describes a feature. “A manager can approve only requests from their unit; the requester receives the outcome; every change records its time and actor” is testable.

Useful criteria cover the main path, access rights, required data, error response and the audit trail. This becomes shared language for design, engineering and the operating owner.

Criteria that cannot be tested usually contain undefined words such as fast, friendly, flexible or automatic.

5. Order the roadmap by the risk it reduces

The largest feature is not always the right first step. If the product depends on legacy data, test data quality and integration in the first slice. If users have little time to learn, validate a prototype with them before polishing the interface.

A credible roadmap states what the team will learn after each stage, who confirms it and which decision becomes possible. When needs change, impact can be judged against outcomes and risks instead of promised feature names.

• Discovery ends with a workflow map, assumptions and open questions.
• Prototype ends with evidence from the correct user group.
• Pilot ends with operating data and a list of real exceptions.
• Rollout ends with ownership, guidance and post-handover monitoring.