Every product is a series of bets someone else has to accept.

Act I — The wager worth making

Before any pixel: is this bet worth anyone’s doubt?

Three questions, each with a veto. Does the market actually want it — desirable? Can we actually build it with the technology and people we have — feasible? Does it make sense as a business — viable? The overlap of the three is the product vision. Everything outside that overlap is a feature that will die in review, six sprints and one budget later than it should have.

This act is where I’ve earned the “strategy” half of the job — and where most of the value is created, because the cheapest design decision is the one that stops a doomed bet before anyone codes it.

Act II — The spiral

Not a line. A spiral — and every loop ends in front of a user.

Four moves, repeated: Listen — user research and requirement gathering in the problem space’s own words, not mine. Structure — journey maps, service blueprints, and information architecture, deciding what the product even is before what it looks like. Prove — prototypes from paper-rough to production-real, built to be argued with. And “real” means real: I prototype in the medium — AI-assisted working HTML, not clickable pictures — put it in front of users for usability testing, and when it survives, the code ships as part of the codebase. Land — visual design, brand, and tone, the layer people mistake for the whole job.

AI runs through every loop as a sounding board — a tireless colleague to argue a layout with before spending an engineer’s afternoon. The order of the moves matters less than the rule: research is a rhythm, not a phase. The Act / Review / Ignore pattern that anchors my whole library wasn’t invented at a whiteboard — it came out of a Listen loop, watching traders override an algorithm that was outperforming them. The spiral exists so moments like that get caught before launch, not explained after it.

Act III — The loop that never closes

Shipping is the first honest data.

The MVP is the first bet a real user accepts or declines with their own time. Then version one, version two, version n — each release smaller than the last one’s ambitions and better aimed, because what users do (not what they say in a survey) returns as the next brief. The feedback line in the diagram isn’t decoration; it’s the part of the process that most teams cut first and regret longest.

This is also why my case studies lead with adoption numbers instead of deliverables: the process’s output isn’t a design file. It’s a bet that got accepted — 64% of new bookings, 250 people running on a system built for 200, a planner trusted enough to replace two weeks of phone calls.

And the version of that I keep quoting on myself: I argued hard for a three-option recommendation card. The live A/B test made the single-option version permanent — the ship taught me what the mock could not.