Greyquill

Product engineering

The discovery week

What a week of proper discovery produces before anyone writes production code, and how to tell whether it is good enough to build from.

One page, the agenda and the checks.

What actually happens

An idea goes in. Five days of structured questioning turn it into three things a team can build from and a sponsor can fund.

What a discovery week converts On the left, an idea, carrying six unanswered questions that live in people's heads and that different stakeholders answer differently. In the middle, five days of work: the outcome, the workflow today, constraints, options, then scope and estimate. On the right, three artifacts: a scoped specification with an explicit out-of-scope list, a prioritised backlog where every item is checkable, and an estimate drawn as a range from earliest to the point where the known risks land. Underneath, the questions still open are written down as open. YOU START WITH FIVE DAYS YOU LEAVE WITH An idea Who is it actually for? What is in, and what is out? Which systems does it touch? How long will it take? What happens if we do nothing? Has anyone tried this before? The answers live in people's heads, and they disagree with each other. DAY 1 The outcome DAY 2 The workflow today DAY 3 Constraints DAY 4 Options and trade-offs DAY 5 Scope and estimate Scoped specification with a written out-of-scope list Prioritised backlog every item checkable by someone else Estimate earliest if the known risks land Anything still unanswered on Friday is written down as an open question, so it is planned around and priced.

The most valuable output is usually the list of questions nobody had asked, and the discovery that two stakeholders meant different things by the same word.

What each day leaves behind

DayWhat happens in the roomWhat exists that evening
1 The outcome, and who it is for. What has to be different in the business once this exists, and how anyone would know. Features come later. A stated outcome, the users named by role, and the measure of success.
2 The workflow walked end to end with the people who perform it, including the parts done in spreadsheets and email. A current-state map, and the list of places it breaks.
3 Constraints. Systems it must integrate with, data it must not move, regulation it operates under, the deadline that is real and the one that is aspirational. A constraints list, each with a named source.
4 At least two ways to reach the outcome, with what each costs and gives up. Prototype only where a picture settles an argument faster than a paragraph. A recommendation, with the rejected options recorded and why.
5 Scope, order, estimate. What is in, what is explicitly out, in what order, and how long with what uncertainty. The three artifacts, and the questions that remain open.

One week for a contained scope. Two where there are several stakeholder groups or an existing system to understand.

Six questions that earn their place

A few of these are mildly uncomfortable to ask, and those are usually the ones that change the plan.

What happens if we do nothing?If the honest answer is "not much", better to know in week one.
Who has to change how they work?Software needing a behaviour change from people nobody consulted fails regardless of quality.
What was tried before?There is usually a previous attempt somewhere. Understanding why it stalled costs you one conversation.
What would you drop to ship two months earlier?Asked directly, it tends to produce a genuine priority order quickly.
Who signs it off, and what will they check?Knowing the acceptance test on day one changes what gets built.
Where does the data come from?Data that turns out to be unavailable or owned by someone else is a common reason a plan has to be redone.
A scoring pass on the brief

Before a specification goes to a build team we run it through ClarityAI, our own tool for scoring the clarity and risk of an initiative. It points at the ambiguities, the untestable statements and the missing decisions, line by line. It reliably catches the vague sentence everyone had read past. See ClarityAI.

Four tests on the output

Four tests on a discovery output The estimate test: two engineers who were not in the room estimate within the same range. The acceptance test: every item is checkable by someone other than its author. The out-of-scope test: a written list of what is not being built exists. The disagreement test: at least one real disagreement was found and resolved. Estimate Two engineers who were not in the room estimate within the same range. wildly different means ambiguous Acceptance Every item is checkable by someone other than its author. without asking what was meant Out of scope A written list of what is not being built. empty means the boundary was never drawn Disagreement At least one real one was found and resolved. none found usually means it did not go deep enough

Fail any of these and another day of discovery costs less than the rework it prevents.

What it does not do

Remove uncertaintyIt states it, so it can be priced and planned around.
Fix a price on a vague problemIf the scope is genuinely unclear, the honest output is a smaller first phase.
Replace the first sprintSome things are only learned by building.
The failure mode

Discovery that runs past two weeks stops producing decisions and starts producing documents. If the questions cannot be closed in the time, narrow the first phase and say so.

Greyquill
greyquill.io/dc/services/discovery-week.html
Greyquill Software

The discovery week

Agenda, questions, and the checks on the output.

Three outputs

Scoped specificationIn enough detail to estimate, with what is explicitly out of scope written beside it.
Prioritised backlogOrdered by value and by what unblocks what. Each item with a checkable acceptance criterion.
EstimateA range, with the assumptions it rests on.

Five days

Day 1

The outcome

What changes in the business, and how you would know.

Day 2

The workflow today

Walked with the people who perform it.

Day 3

Constraints

Systems, data, regulation, the real deadline.

Day 4

Options

Two routes, what each costs and gives up.

Day 5

Scope and estimate

In, out, order, duration, uncertainty.

Ask these every time

  • What happens if we do nothing?
  • Who has to change how they work?
  • What was tried before, and what happened?
  • What would you drop to ship two months earlier?
  • Who signs it off, and what will they check?
  • Where does the data come from, and who owns it?

Four tests on the output

  • Estimate. Two engineers who were not in the room land in the same range.
  • Acceptance. Every item checkable by someone other than its author.
  • Out of scope. A written list exists. Empty means no boundary was drawn.
  • Disagreement. At least one real one was found and resolved.
Failure mode

Past two weeks, discovery stops producing decisions and starts producing documents. If the questions cannot be closed in the time, narrow the first phase and say so.

Greyquill Software runs discovery like this before every build, including our own products. greyquill.io