Four moves, every time

In practice

• I read pre-work worksheets from three people on the client side, and the workshop transcripts, before writing any strategy. The two founders were not yet telling the same story. Their own words showed it.
• A client’s company deck became a table of 14 verbatim rows, each tagged as a definition, a claim, a positioning line or a commitment.
• I audited the live website string by string against that deck: 38 strings, 25 fine, 9 drifted, 4 stale. The fixes came as four ready-to-run prompts, one per group of files.
• A brand that existed only inside a design file was decoded into tokens: 776 nodes and 236 text layers read, every value taken from the designer’s own labels, not guessed.
• On a trilingual site, I locked a glossary before the build. Every term has a definition and a list of words to avoid.

Deliverables

• Discovery report
• Personas
• Multi-actor journey map
• Verbatim extracts and content audits, tagged at source

AI in this move

AI does the first pass of reading: it pulls a deck into rows, drafts a first synthesis of the research, transcribes a recorded brief. Each row is checked against the source before it moves on, and names are fixed by hand against what the client confirmed. The extract stays verbatim, with the source next to it, so a misreading is easy to spot.

In practice

• A 90-minute strategy workshop in four blocks, with a pre-read sent 48 hours ahead, built around nine open decisions, each with an owner and a horizon: before the partner meeting, before investors, before the build.
• Personas built from the research, not from assumption. The executive who buys and the programme lead who uses the product are different people, and the strategy has to serve both.
• A strategy taken through five versions until it held. One round tested it against two real programmes. The final version added no strategic claim and removed none. It made the ones already there hold.
• A product requirements document that does not re-argue the strategy. One term per concept, stable IDs, a priority on every requirement.
• When a plan was stuck, the plan named the four answers that would unblock everything and got those first.

Deliverables

• Vision board
• Objectives and success metrics
• Strategic synthesis
• Workshop plan and decision log, with owners

AI in this move

AI prepares the ground before the room meets. A chain of research agents drafted a first strategy set, and a separate review agent found three critical issues in it before a client saw it, one of them a statistic with no source. A scoring script with no model in it grades each version, so progress is not a model marking its own work. In the workshop itself, people decide.

In practice

• A seven-screen interactive demo, presented live in about eight minutes, instead of a deck. The requirements document was written from it.
• Every fix to a live storefront was checked on the rendered page at three breakpoints, not read back from settings. That is how four live defects nobody had briefed came to light.
• A test harness compares two ways of understanding voice messages on labelled clips, so the model is chosen on evidence, not on taste.
• Before an automated pipeline moves to its rebuilt version, the plan runs both side by side for three to five cycles and compares the output. A feature flag keeps the old one as the fallback, and the rebuild has its own tests.
• On Zilliqa’s first staking portal, design changes were made directly in the build with AI coding tools, instead of going back and forth in a feedback thread. Production time fell by nearly 40 percent.

Deliverables

• Discovery backlog: what is done, what is proposed, what waits on the client
• PRD, with falsifiable success metrics
• Functional scope map: what ships first, what is cut, what comes later
• Interactive demo or prototype, with rendered evidence

AI in this move

AI helps me build the proof faster: the demo, the prototype, the design change made directly in the code. It does not grade its own proof. The checks read rendered pixels, run a test suite, or use a script with no model in it, because a check that reads back its own settings misses what is on the screen.

In practice

• The model never owns state. In a booking bot, the model proposes field values and reply text, and plain code owns every status change.
• In a content pipeline, an AI supervisor picks the topics, but plain code dispatches the work, and a rule-based check with no model runs before any model judges the content.
• When a model judges, the judge is checked too. I measure how often it catches a real failure and how often it correctly passes a good answer, each against a stated bar.
• Changes are held for review. Storefront fixes ran on a separate branch while the live site stayed untouched, and reference screenshots are only re-captured as a reviewed act.
• The booking bot answers bookings only. Anything else goes to a person.

Deliverables

• Written rules for what the model may and may not do
• Review gates in the workflow
• A measurement plan for time saved: baseline, AI-assisted time, review time, net

AI in this move

This move is where AI gets its limits. I use it for analysis and synthesis inside the frame the client sets, and I count the time it takes to check its output as part of the cost. Published studies show what is possible. They are not my results, so I keep them apart.