Approach
Start with the work as it is, then change it deliberately.
The useful path is not discovery theatre followed by a disappearing build phase. It is a direct sequence from understanding the current workflow to supporting the software in use.
One connected path
Four decisions that keep the project attached to the problem.
- 01
Understand
Trace the work that exists now.
Start with the people, handoffs, source material, exceptions, and constraints already shaping the day. The workaround is evidence, not an embarrassment to hide before the project begins.
Useful outcomeA shared view of the workflow, its friction, and the boundary of the problem worth solving.
- 02
Frame
Choose the smallest coherent change.
Turn the problem into a first release with a clear job. Important states, privacy boundaries, integrations, and operational ownership are decided before a feature list grows around them.
Useful outcomeA practical release shape with explicit priorities, constraints, and measures of usefulness.
- 03
Build
Make the real workflow visible early.
Build in working slices so the interface can be judged against real use, not a polished mock-up alone. Edge cases and system behaviour stay visible while there is still time to change them.
Useful outcomeA usable product that can be tested with representative work and revised from evidence.
- 04
Launch
Support the move into operation.
Deployment, data movement, monitoring, documentation, and support are part of the product. A release is complete when people can depend on it, not merely when the code reaches a server.
Useful outcomeA supported transition with known ownership and a sensible path for the next improvement.
Working principles
Clear enough to use, honest enough to trust.
- 01
Keep the product legible.
People should be able to tell what the software did, what it stored, and what still needs their judgement.
- 02
Prefer evidence over theatre.
Working software, representative data, and observed use settle more questions than elaborate process language or high-fidelity promises.
- 03
Treat operations as product work.
Integrations, deployment, recovery, and support shape whether an application is genuinely useful after launch.
A useful starting point
A finished brief is not required.
Bring a clear account of the work and where it keeps fighting back. Timing, budget, and the first release can be framed together once the problem is visible.
Describe the workflow- 01
Current workflow
What happens now, including the spreadsheets, messages, repeated entry, and informal checks.
- 02
Recurring friction
Where time, confidence, or continuity is repeatedly lost rather than where one unusual day went badly.
- 03
Real constraints
The systems, privacy boundaries, deadlines, access, and people the first version must respect.