Create your own
Lesson illustration

Crafting an Idea Record: Problem, Sufferer, Falsifier, and Alternatives

Good to see you again. You have already set the lane cap and assigned roles that keep an Owner from approving their own enthusiasm. Phase 1 now turns a raw idea into a bounded investigation: a one-day Idea Record that says what problem is worth investigating, who is known to experience it, what result would make you stop, and what other approaches deserve consideration.

This is deliberately not a miniature product requirements document. At this point, a detailed solution is usually a way of hiding an untested assumption. Your task is to make the problem claim clear enough that it can later be disproved.


An Idea Record is a commitment to learn, not a pitch

A raw idea often arrives in solution language:

“We should build an AI tool that turns client-call notes into follow-up plans.”

That may be a promising candidate solution, but it is not yet a problem statement. It embeds several untested beliefs: that people lose important follow-ups, that this happens often enough to matter, that existing habits are inadequate, and that AI is the appropriate remedy.

A Phase 1 Idea Record separates four things that are easily blurred together:

ElementIts purposeWhat it must not become
Problem statementStates the user’s difficulty and consequenceA feature request or product pitch
Named suffererGrounds the run in at least one real person or accountA generic persona such as “busy professionals”
FalsifierPrecommits the observation that ends the runA vague concern such as “if demand is low”
AlternativesPrevents attachment to the original ideaA list designed to make the original look best

The central distinction is simple: a solution is one proposed way to change a situation; a problem is the costly situation that exists whether or not your proposed product is built.

For example:

  • Solution-first: “Consultants need automated follow-up notes.”
  • Problem-first: “Independent consultants struggle to convert meeting decisions into reliable follow-up commitments, causing missed actions and rework.”

The second statement does not prove that the problem exists. It states the claim that discovery must test.

Identify user needs - GOV.UK content and publishing guidance

Read GOV.UK’s Identify user needs guidance for a disciplined way to distinguish a user’s task from a presumed tool or channel. Its examples are especially useful when an idea has arrived as a feature request.

In the section “Find out your users’ needs,” read the setup, noting the prompts about likely users, their current methods, and their frustrations. Then, in “What the user wants to do and why,” read the examples and warning. Pay particular attention to why “use a benefits calculator” is a poor need statement: it preselects a tool before establishing the underlying task.


Write one solution-free problem statement

A useful working form is:

[Specific user group] struggles to [complete a task] when [trigger or context], causing [concrete consequence].

This form makes four elements visible:

  1. Who has the difficulty.
  2. What task they are trying to complete.
  3. When the difficulty becomes acute.
  4. What happens when it remains unresolved.

It does not require you to know the cause already. At Phase 1, a proposed cause should be recorded separately as an assumption, not embedded as fact.

Consider the difference:

DraftDiagnosis
“Independent consultants need an AI assistant to manage client follow-ups.”Names a solution and gives no observable difficulty.
“Consultants need better ways to stay organised after calls.”Avoids a product, but is too broad and does not define task, context, or consequence.
“Independent consultants managing several client engagements struggle to convert meeting decisions into reliable follow-up commitments after calls, causing missed actions and unbilled rework.”Identifies a group, task, context, and impact without prescribing a product.

The final example is still a hypothesis, not evidence. At this stage, label it accordingly:

Problem statement
[assumption] Independent consultants managing several client engagements
struggle to convert meeting decisions into reliable follow-up commitments
after calls, causing missed actions and unbilled rework.

The word assumption is not a weakness to conceal. It is an honest description of the current state of knowledge. In Phase 3, interview evidence may support, refine, or destroy this statement.

A problem statement passes a quick solution-free test if you can imagine several radically different responses to it: a changed workflow, a human service, a template, a spreadsheet, training, an integration, or no action. If only one product seems possible from the wording, the statement is probably solution-first.

This problem-statement framework separates the person, their goal, the obstacle, a possible cause, and the consequence. Use it to expand a raw observation into a draft, but treat proposed causes and consequences as assumptions until a retrievable source supports them.

The framework in the image is useful for thinking, especially its attention to what someone is trying to do and what failure costs them. In the Idea Record, however, do not force every clause into the one-sentence problem statement. A suspected cause, such as “because the wrong colour scheme was used,” is often precisely what you do not yet know. Keep it in an assumptions field where it can be tested.

A complementary user-need formulation can make the statement more human and task-focused:

As an independent consultant managing multiple engagements, I need to reliably capture and follow through on client decisions, so that commitments do not disappear between meetings.

Use this as an aid to framing. The Factory gate still requires one solution-free problem sentence naming no solution.

Webinar: How to Nail the Customer Problem Statement by Amazon Sr PM, Rashi Gupta

Watch Webinar: How to Nail the Customer Problem Statement from Product School. Rashi Gupta explains the common tendency to work backward from a solution, a technology, or a competitor rather than from a customer difficulty.

Watch the solution-first traps. Focus on the three forms of backward reasoning: starting with a chosen solution, a new technology, or a competitor’s feature. For this course, the practical response is to return to the user’s task, friction, and consequence before discussing what to build.


Name a sufferer, not a persona

The Phase 1 gate requires at least one named person or account. “Freelancers,” “operations teams,” and “busy parents” are not named sufferers; they are broad candidate segments. A persona with a fictional name is not one either.

A named sufferer is a real, traceable person or organisation connected to the observation. Depending on your context, the record may identify them by a privacy-safe internal ID rather than publishing personal details.

Weak entryWhy it failsStronger entry
“Busy consultants”A segment, not a real contact or account“S-01, independent consultant; contact held by Owner; introduced through client-success lead”
“Marketing manager Maya”May be a fictional persona“Account A-14, agency with five account managers; recurring missed-handoff issue reported in support ticket CS-228”
“Anyone who has meetings”Too broad to recruit or test“Three-person consultancies delivering weekly client projects and currently using manual meeting notes”

The name alone is not evidence that the person has the problem. Record how you know of them and tag the claim appropriately:

Named sufferer
S-01: [real name or privacy-safe internal identifier]
Context: Independent consultant managing four active client accounts.
Why included: Reported missed follow-up work in a client-success conversation.
Source: [int-001]

If the named person comes only from an introduction and you have not spoken with them, write that honestly:

S-01 appears to fit the proposed group. Whether they experience the
stated problem is [assumption].

This distinction prevents a frequent discovery error: treating access to potential users as validation that those users have the problem.


Turn doubt into a falsifier

A falsifier is the precommitted condition under which you abandon the run. It is not a general risk list and it is not an invitation to keep researching until the answer feels favourable.

Weak falsifiers protect the idea:

  • “We will stop if users do not like it.”
  • “We will stop if the market is too small.”
  • “We will stop if the technology does not work.”

Each leaves room to reinterpret poor results.

A usable falsifier has five parts:

  1. The specific claim at stake
  2. The relevant participant group
  3. A measurable observation
  4. A deadline within the lane
  5. The explicit action: stop the run

For a Lane M example:

We abandon this run if, by the Phase 3 decision date, fewer than eight of twelve independent consultants matching the stated cohort describe difficulty managing post-meeting follow-through before we introduce our problem language.

This is strong because it tests the core claim, specifies an observation, uses a number chosen in advance, and defines the consequence. It also protects against a common interviewing failure: participants agreeing with a problem only after you have explained it to them.

Another example focuses on observable cost:

We abandon this run if fewer than three of twelve relevant participants show that they currently spend at least two hours each week, or pay money, to manage the workaround.

The precise Phase 3 metrics will be gathered later. Today, you are writing the commitment that gives those metrics their meaning.

A falsifier need not prove that the idea is bad forever. It means that this bounded run does not justify further investment under its current claim, lane, and evidence plan. If something materially changes later, it may re-enter Phase 0 as a new run rather than becoming an unbounded continuation.


Generate credible alternatives, including doing nothing

Alternatives are not a brainstorming ritual. They make sure the team is investigating the problem rather than defending the original solution.

For each alternative, ask:

  • Does it address the same underlying task or consequence?
  • Could a real sufferer plausibly choose it now?
  • What trade-off would make it attractive or unattractive?
  • What evidence would distinguish it from the original approach?

For safety, create a candidate set of at least four entries: the original idea plus three alternatives. One alternative must be doing nothing.

Here is a hypothetical candidate set for the consultant follow-through problem. These are candidate approaches, not validated recommendations.

CandidateApproachWhy it is credible
Original ideaAn AI-assisted workflow that converts call material into follow-up tasksIt may reduce the effort of capturing decisions, but depends on accuracy and trust.
Simpler alternativeA structured meeting agenda, decision template, and end-of-call commitment ritualA consultant can adopt it immediately with little technical risk.
Narrow service alternativeA human assistant or virtual assistant prepares follow-ups for high-value engagementsIt may be viable where the cost of a missed action is high enough to justify paid help.
Do nothingContinue using notes, memory, email flags, or existing task toolsThis is the baseline that wins if the problem is infrequent, tolerable, or not worth changing behaviour for.

“Do nothing” is not sarcastic or incomplete. It is often the strongest competitor because it has no switching cost, no onboarding, and no new habit to learn. If people repeatedly choose it despite experiencing some friction, the proposed product must either solve a much more painful version of the problem or stop.

The original idea does not receive special treatment. At Phase 6, all candidate concepts will be scored using the same criteria. Starting with credible alternatives now makes that later comparison possible.


Assemble the Phase 1 Idea Record

Keep the record short enough to complete inside the lane’s Phase 1 time-box. The following is a practical minimum. Replace all illustrative content with real, traceable material before using it in a live gate.

IDEA RECORD — Phase 1

Run name and ID:
Owner:
Challenger:
Lane, time cap, and money cap:
Commitment status: Uncommitted / Committed

Raw idea
[One or two sentences. Solution language is allowed here.]

Solution-free problem statement
[assumption] [Specific cohort] struggles to [task] when [context],
causing [concrete consequence].

Named sufferer
Identifier or account:
Role and relevant context:
Why this is a real contact or account:
Source or status: [int-___] / [url] / [data: ___] / [assumption]

User need, in the user's language
As a [user], I need to [task], so that [outcome].

Key assumptions
1.
2.
3.

Falsifier
We abandon this run if [specific observation] is not met by [date],
using [defined evidence source or test].

Candidate approaches
1. Original idea:
2. Simpler or lower-cost alternative:
3. Narrow, different-segment, service, or different-model alternative:
4. Do nothing:

Challenger's initial concern
[The strongest reason this problem claim may be wrong.]

Before moving to the next stage, perform this short quality check:

  • The problem statement is one sentence and names no product, feature, technology, or brand.
  • A real person or account is identifiable in a privacy-appropriate way.
  • The record distinguishes facts from assumptions rather than using confident prose to blur them.
  • The falsifier has a number or other observable condition, a date, and an explicit STOP action.
  • The alternatives address the same job or consequence.
  • “Do nothing” appears as a serious baseline, not an afterthought.
  • The Challenger can explain the strongest honest reason to stop before the Owner writes the case to proceed.

A good Idea Record does not make an idea look inevitable. It makes the upcoming investigation fair: a defined problem claim, a real starting point for recruitment, a condition that can end the run, and competing approaches that may beat the original concept.

Next, you will rank the run’s unknowns by a stricter question: which uncertainty could kill this idea most cheaply? That ranking determines what to investigate first within the lane cap.

Can't find a good explanation? Sign up and we'll make it for you

Sign up