How our Applied Product Discovery works

Somewhere in the second week of every Shipped engagement, a client asks the same question: when does the building start? The honest answer is week five, and the two-week pause before any interface gets designed is the part of the cycle clients are most sceptical about going in and most convinced by coming out.

Here's why the cycle is shaped the way it is, phase by phase.

The problem the shape solves

Drift is the gap that opens between what a team decided to build and what it eventually ships. It doesn't come from incompetence. It comes from handoffs, where each transfer compresses decisions into artefacts and sheds the reasoning, and from time, where the people who made a call in March have moved on by June. Most delivery processes fight drift with documentation and meetings. Applied Product Discovery fights it with architecture.

The twelve-week cycle

• Discover (weeks 1–2): problem framing, user and stakeholder interviews, and the hard prioritisation of what this cycle will not attempt. Every decision gets recorded as structured context: the call, the reasoning, the constraints, the explicit non-goals. That context loads into a central agent layer, connected over MCP to every tool the team uses.
• Design (weeks 3–4): designers work with discovery context live in their tools rather than reconstructed from a deck. A design choice that contradicts a discovery constraint surfaces immediately, not in a sprint review six weeks later. Design decisions join the context layer with their own reasoning attached.
• Deliver (weeks 5–12): a cross-functional triad of product, design, and engineering builds against the context layer. When an edge case comes up that the designs don't cover, the agent in the IDE answers from recorded reasoning, or flags that a genuinely new decision is needed and routes it to its owner. The team stops re-litigating settled questions, which is most of what velocity turns out to be.
• Deploy (ongoing): the product ships and the cycle's context gets archived in queryable form. Whoever maintains the product next, your team or our embedded specialists, inherits the reasoning rather than just the repository.

Where drift normally enters, and what blocks it

• Handoffs compress decisions into decks and tickets; the context layer carries the reasoning instead
• Personnel changes erase memory; the archive answers "why does it work this way" with a record, not a shrug
• Backlogs get reinterpreted by inheritors; scope additions show up as the explicit decisions they are

The honest constraint

Twelve weeks works because discovery cuts ambition down to what twelve weeks can carry, and the context layer enforces the cut. APD does not rescue a vague brief or an organisation unwilling to choose. It rewards teams that can say what matters most, and makes that statement durable for exactly twelve weeks: long enough to ship something real, short enough that nothing rots.

A question for your current delivery partner

Where, physically, does the reasoning behind your decisions live, and who reads it in week nine? If the answer is a deck nobody opens, you've found your drift.

The Applied Product Discovery whitepaper documents the full mechanics. A Shipped engagement is the twelve-week version with our triad running it, and our case studies show what comes out the other end. If a full cycle is more than you need, the same method scoped to three weeks is a Framed blueprint.