01Demand leak playbook

Prove the product deserves intervention.

A demand-evidence protocol for founders who have software but cannot yet prove that a market wants it.

USE THIS WHEN

Use this when interest is mostly compliments, waitlist names, old traffic, or founder conviction. A repair sprint is premature until one current behavior proves the problem is real.

01 / BASELINE

Measure before touching the product.

  1. 01One observable behavior that represents real problem-solving value.
  2. 02One current source of users who can perform that behavior.
  3. 03The count of unique people who performed it in the last 30 days.
  4. 04The count who returned, paid, referred, or repeated it.

02 / THE 90-MINUTE AUDIT

00:00

Write the smallest falsifiable demand claim.

Proof: A sentence with a user, problem, behavior, and time window.

00:20

Separate access from value.

Proof: Visits, signups, and waitlist names are not counted as successful use.

00:40

Find the last ten real users.

Proof: A dated list of value events, not names or private records.

01:00

Test willingness to repeat or pay.

Proof: A return, renewal, purchase, referral, or explicit refusal.

01:20

Set the next evidence threshold.

Proof: A number and deadline that can fail.

03 / REPAIR OPTIONS

Choose one. Instrument it. Ship it.

01

Value-event instrument

Use when
Usage exists but nobody can define success.
Change
Track the first behavior that delivers the product's promise.
Measure
Unique users reaching the event and the time required.
02

Current-user evidence pass

Use when
The only proof is old or anecdotal.
Change
Review the last 30 days and classify actual value, repeat use, and payment.
Measure
Verified current value events divided by activated accounts.
03

Paid signal test

Use when
People use the product but willingness to pay is unknown.
Change
Offer one honest, narrow paid outcome to the most relevant existing users.
Measure
Explicit accept, decline, and reason counts.

04 / MEASUREMENT CONTRACT

A result needs a denominator and a guardrail.

Primary
Current verified value events
Leading signal
Qualified users who begin the core workflow
Guardrail
Support requests caused by an unclear promise
Review window
Until the evidence threshold is reached or the claim fails

05 / STOP CONDITIONS

  • No current user can describe a recurring problem the product solves.
  • The value event requires a different product than the one already built.
  • Interest disappears when a price, commitment, or repeated-use request appears.

DO NOT DO THIS

  • Do not count a waitlist as product demand.
  • Do not redesign the site to avoid a weak signal.
  • Do not buy a Revenue Rescue Sprint before the gate clears.

NEXT MOVE

Still proving demand?

Run the evidence protocol first. Reclaimware will not recommend paid repair work until a current demand signal exists.

Run the free triageBrowse all playbooks →