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 a real front end.
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.
A score is worth more than its design value: it 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 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.
In place of the clickable mock-up, a real front end wired to a test database. The final product, responsive and adaptive: you can walk through all of it, only the data is fake.
The effect on testing: the client uses it instead of imagining it. And on the plan: the front end put in front of testers is the one that goes to production.
Twenty-eight deliverables, in the four phases of the double diamond. The sequence is the same from one assignment to the next; only the depth varies.
Three engagements, three readings of the same method: a bank, industrial mail, industrial IoT.