The Method

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

A user betting their workflow on a recommendation. A stakeholder betting a quarter on a roadmap. An engineer betting a sprint on a spec. My process isn't a ritual for making screens — it's a machine for making each of those bets smaller, better-evidenced, and easier to say yes to.

The method: every turn narrows the bet A wedge opens at the left, where three questions — desirable, feasible, viable — converge into one bet worth making. The gap between the wedge's upper and lower edges is how big a bet someone else still has to accept. A flat spine runs through the middle of the wedge, passing four repeating moves: listen, structure, prove, land. Each move drops a dotted line to its label, and the gap around the spine narrows steadily from one move to the next. Past a dashed marker reading "ship", the wedge keeps narrowing but never closes, because shipping is the first honest data and the turns do not stop. Every turn narrows the bet. THE GAP = HOW BIG A BET SOMEONE ELSE STILL HAS TO ACCEPT ACT I · THE WAGER Desirable? Feasible? Viable? ALL THREE, OR IT DIES IN REVIEW ACT II · THE SPIRAL = ONE TURN: LISTEN, STRUCTURE, PROVE, LAND Listen Structure Prove Land RESEARCH IS A RHYTHM, NOT A PHASE ACT III · THE OPEN LOOP SHIP SHIPPING IS THE FIRST HONEST DATA THE TURNS DO NOT STOP Confidence is earned in loops, not declared in launches. EVERY TURN ENDS IN FRONT OF A REAL USER — THAT IS WHAT NARROWS THE NEXT ONE
The gap is the only thing measured — how big a bet someone else still 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.

"Design is an upward spiral: every turn reduces risk and raises the odds of adoption. Confidence is earned in loops, not declared in launches."

If that last line sounds like the human-in-the-loop thesis, that's not a coincidence — it's the same principle at two scales. Users learn to trust an AI through small, evidenced, reversible bets. Teams learn to trust a design direction the same way. The method and the specialty are one idea.