Design thinking frames the problem and tests the solution. Agile builds it and ships it. The hinge between the two is a QAP, which picks the features and stories of the MVP. Depending on your set-up, I take the whole chain or the one stretch you are missing: my background lets me join at the start, at the end, or stay from the first workshop to general availability.
Four phases, two methodologies, three roadmap horizons. Durations are given first for a single feature, then for a complex product.
The diagram slides sideways.
In copper, what I deliver myself. The other lanes show which stakeholder is involved at that point.
Identify, capture and prioritise
Understand and frame the problem
Test the value, viability and feasibility
Gather feedback from a selected cohort and fix
Roll out and fix issues at scale
Maximise the return on investment
Identify, capture and prioritise opportunities. Continuously, without waiting for a project to start.
Two diamonds. The problem first: research, then definition. The solution next: ideation, then validation. It ends with a framed problem and a solution tested on value, viability and feasibility.
The hinge between the two methodologies: a QAP, quarterly agile planning, picks the features and stories the MVP needs. Sprints start from there. I deliver the design system, the components and the pages, and follow the story mapping story by story.
Private beta, public beta, general availability. Then continuous improvement, the moment the return actually happens, and the phase most design engagements never cover.
Three practices that separate an engagement from ordinary design work: every story is scored on an explicit grid before it passes, everything lands in one document that opens up, and the prototype is no longer a mockup.
Every story leaves the story mapping as a prototype, tested with the client's real users and scored. Below target, the story goes back into iteration. It does not pass until the target is met.
The value sits outside design: a score can be shown to a board, compared from one iteration to the next, and defended in front of someone who was not in the room.
The scale is explained to participants before they start: 1 useless or incomprehensible, 2 unclear, 3 works but could be better, 4 meets expectations, 5 intuitive, useful, reassuring. Without that explanation, two participants are not scoring the same thing.
Everything above lands in a single document. It does not only show the result: it opens what sits behind each hypothesis, the research that produced it, the test that put it through its paces, the score it got.
That is what lets a board dig into any point weeks after the presentation, without having to ask again. And it is what aligns every stakeholder on the real value of what we are about to offer users: a value proposition written down nowhere reads differently in every department.
The clickable mockup has given way to a real front end, wired to a test database. It is no longer a simulation: it is the final product, responsive and adaptive, with the whole journey genuinely usable. Only the data is fake.
The effect on testing: the client no longer imagines, they use. And on the plan: the front end put in front of testers is the one that goes to production.
Twenty-six deliverables, grouped in four movements. The sequence does not change from one engagement to the next: only the depth of each does.
Four engagements, four different readings of the same method: a bank, industrial mail, industrial IoT, legal tech.