Five stages, one engagement. We gather the evidence that shows where the real opportunities are, sharpen them into problems worth solving, narrow to the one worth building, and put a clickable prototype in front of real people — before anyone commits to the build.
“Which idea is the right one? And how do we know it holds before we build it?”
Most teams are not short of ideas. They are short of a defensible reason to pick one, and of evidence that the chosen one works. Design Thinking is not a creativity exercise — it is a sequence that turns both of those gaps into something you can check.
The classic five stages of Design Thinking, kept honest: every one of them ends with something a real person has seen or said. What that looks like in practice is in the German Red Cross case — six research themes, three prioritised problem statements, one tested prototype.
Talk to the people who would use it and read what your own data already says. Interviews, analytics, support tickets and market signals together show where people struggle — including the opportunities nobody had written on the list.
An idea is not comparable; a problem statement is. Each candidate becomes one sentence naming the user, the need and the evidence behind it. Ideas that cannot survive that sentence tend to fall away on their own.
Generate options widely, then narrow against criteria agreed before anyone saw the scores — impact, confidence, effort and fit. Quantity first, judgment second, and the runners-up parked rather than forgotten.
Build the smallest thing that can be put in front of a real user. Detailed where it matters, deliberately rough everywhere else — a prototype is made to learn from and then thrown away.
Watch five people use it. Keep what held, change what broke, and write down which assumption just died — that is the result you were paying for.
Talk to the people who would use it and read what your own data already says. Interviews, analytics, support tickets and market signals together show where people struggle — including the opportunities nobody had written on the list.
An idea is not comparable; a problem statement is. Each candidate becomes one sentence naming the user, the need and the evidence behind it. Ideas that cannot survive that sentence tend to fall away on their own.
Generate options widely, then narrow against criteria agreed before anyone saw the scores — impact, confidence, effort and fit. Quantity first, judgment second, and the runners-up parked rather than forgotten.
Build the smallest thing that can be put in front of a real user. Detailed where it matters, deliberately rough everywhere else — a prototype is made to learn from and then thrown away.
Watch five people use it. Keep what held, change what broke, and write down which assumption just died — that is the result you were paying for.
Evidence first, then a decision, then proof. You end up with one tested direction, the reasoning written down, and a method your team can run again without me.
Sprint, three to six weeks
This is the stage before the expensive decision — when several directions look reasonable and nothing yet proves which one is.
With limited runway, building the wrong thing first is not a delay. It is the company.
You get the riskiest assumption tested before you spend on it.
Every idea has a sponsor, none has evidence, and the roadmap goes to whoever argues longest.
You get a ranked shortlist and a prototype of the winner.
What moves a decision is not a persuasive presentation. It is a real person using a real prototype.
You get recorded sessions and a decision you can present.
A sequence, not a mindset. Understand, define, ideate, prototype, test — each stage ending with something checkable rather than an opinion. Done badly it is a workshop with sticky notes. Done properly, every stage produces evidence the next one needs, and the last one tells you whether to build.
Not by scoring ideas against each other, because ideas are not comparable — they are described at different levels of detail by people with different stakes. First each candidate becomes a problem statement naming the user, the need and the evidence. Only then do you rank, against criteria agreed before anyone saw the scores.
No. A prototype is built to learn and then thrown away. An MVP is built to ship and has to be maintained from the day it exists. Building an MVP in order to test an idea is the most expensive form of research there is.
Usually three to six weeks, depending on how much evidence already exists in your organisation. You end with a ranked shortlist, a clickable prototype of the chosen direction, recordings of five people using it, and a clear recommendation: build it, change it, or drop it.
Then it has done its job. Finding that out in week four costs a fraction of finding it out after six months of development, and the sessions usually point at the version that would work. A clear no is a result, not a failure.
A free 30-minute call. No pitch, no pressure — just an honest look at your list and whether I can help.