What Happens in a Product Clarity Sprint? (Week by Week)

A Product Clarity Sprint is a two-week, fixed-price engagement. It produces one primary output: a decision document that locks product scope, validates assumptions, and defines the build plan before a single line of production code is written.

This is what happens, week by week.

Before Week 1: The Intake Call

Before the sprint begins, we run a 60-minute intake call. The purpose is not to define scope — that happens in the sprint. The purpose is to establish the starting conditions.

We need to understand: what problem are you trying to solve, what have you already built or decided, what are the constraints (technical, organisational, timeline, budget), and who needs to be involved in the sprint to have authority over decisions.

The intake call determines whether the sprint is the right engagement. If the product is already built and the problem is operational, the sprint is not the right start. We tell you that on the intake call.

Week 1: Diagnosis

Week 1 is about discovering what the problem actually is — not what it appears to be from the outside.

Most product problems present as one thing and are caused by another. A product that "isn't growing" may have a distribution problem, a retention problem, a pricing problem, or a product-market fit problem — and each has a completely different solution. A product that "needs to be rebuilt" may need restructuring, not rebuilding, or may need a product decision before a technical one.

The diagnostic work in Week 1 includes:

User and stakeholder interviews. We talk to the people who will use the product and the people who have authority over its direction. The goal is to surface the gap between what stakeholders believe users want and what users actually need.

Decision archaeology. We map the decisions that have already been made — explicitly or implicitly — and identify which ones are reversible and which ones are not. Irreversible decisions that were made informally are the most common source of expensive rebuilds.

Assumption mapping. Every product sits on a set of assumptions about the market, the user, and the required functionality. We make these assumptions explicit and rank them by risk. The highest-risk assumptions are the ones that need to be resolved before the scope is locked.

By the end of Week 1, we have a clear picture of the actual problem, the decisions that have already been made, and the assumptions that need to be validated or accepted before scoping.

Week 2: Decision and Scope Lock

Week 2 is about translating the diagnostic findings into locked decisions.

Day 1–2: Assumption validation. For the highest-risk assumptions identified in Week 1, we run rapid validation exercises. These are not full user research studies — they are targeted experiments designed to reduce uncertainty enough to make a decision. A landing page test. A prototype interview. An analysis of competitor behaviour. The goal is not certainty; it is sufficient evidence to commit.

Day 3: Scope definition workshop. A working session with all decision stakeholders. We define the product's core user, the outcome it must produce, and the features required to produce that outcome. Critically, we also define what is explicitly out of scope. Every "nice to have" feature gets evaluated against one question: does this feature directly serve the core outcome? If not, it goes in a backlog for a future version.

Day 4: Decision document drafting. We produce the written decision document. This is the artefact that makes the sprint valuable beyond the two weeks. It records every decision made, the assumptions underlying each decision, and the explicit scope. It is the document that gets referenced when scope change requests arise during the build.

Day 5: Review and sign-off. All stakeholders review and formally sign off on the decision document. This sign-off is not ceremonial — it is the moment that converts an informal discussion into a binding commitment. Without the sign-off, the document is just a draft.

What You Walk Away With

At the end of the Clarity Sprint, you have:

1. A decision document. Written, signed off, and ready to serve as the build brief. It defines what the product is, who it is for, what outcome it produces, and what the first version includes and excludes.
2. A validated assumption set. The assumptions that were too risky to carry into the build have been tested. You know which ones held and which ones needed to be revised.
3. A fixed-scope build plan. A timeline and cost estimate for the build phase, derived from the locked scope. Because the scope is fixed, the timeline and cost are fixed. There are no surprises mid-build.
4. A prioritised backlog for future versions. Everything that was scoped out of Version 1 is documented in a prioritised backlog, not discarded. Future versions have a starting point.

What the Clarity Sprint Is Not

The Clarity Sprint is not a strategy consulting engagement. We are not producing a 40-page market analysis or a competitive landscape report. The output is a decision document and a build plan.

It is also not a discovery phase in the traditional agency sense. Discovery phases often produce requirements documents that are then handed to a separate build team. The Clarity Sprint produces decisions that are immediately actionable by the team that will execute the build — which is the same team that ran the sprint.

After the Sprint

Most clients proceed from the Clarity Sprint directly to the defined-scope build phase. The transition is seamless because the sprint produces the build plan. The same team that ran the sprint executes the build.

Some clients use the decision document to brief an internal team or another agency. This is fine — the document is designed to be a complete build brief, not dependent on our specific involvement.

A small number of clients discover during the sprint that the product they thought they wanted to build is not the product they should build. This is a valuable output — discovering a strategic redirect for $3,000 and two weeks is significantly cheaper than discovering it after six months and $200,000 in build costs.

If you are unsure whether a Clarity Sprint is the right starting point for your product, start a conversation. We can tell you in 30 minutes whether it is.