Separate an observation from a thesis

Start with a dated observation: who needed what outcome, what information was available, which person decided, and where the ordinary path broke. Then state a testable thesis separately: “this bounded decision may be transferable with these inputs and this recovery path.” The thesis is an interpretation, not a fact hidden inside a feature list.

The accompanying product-thesis evidence ledger keeps six items visible: outcome, occurrence, inputs and rule, exception, transfer test, and counterexample. It is intentionally not a score. A high number of requests cannot compensate for an unbounded exception or missing accountable owner.

Look for a bounded rule, not a repeated interface

A shared spreadsheet, inbox label, or client portal request may describe a surface. Ask instead whether a qualified second person can apply the same rule to the same inputs and explain the same failure path. If not, the repetition may be evidence that the human service needs clearer operating practice—not that a product exists.

Record at least one counterexample. Perhaps one customer needs a standard outcome and another needs a consequential exception that depends on trust, negotiation, or unavailable context. The counterexample narrows the possible software boundary; it does not invalidate the service.

Decide the next smallest experiment

When the ledger shows a stable, transferable rule, test the smallest possible support around that rule with an accountable operator. Keep the service and exception handling visible. When the ledger instead shows changing inputs, unowned decisions, or high-consequence exceptions, invest in the human workflow before proposing a product roadmap.

This method does not predict revenue, willingness to pay, or defensibility. It helps a founder make the uncertainty inspectable before turning it into a build commitment.

Questions for a product-strategy review

  • Which observations are first-hand, and which are memory or interpretation?
  • What comparable case weakens the proposed product boundary?
  • Can a second qualified person reproduce the rule without the original founder?
  • Who owns a bad or ambiguous outcome once the process is partly automated?

Does repeated demand prove a product opportunity?

No. It proves only that something recurred. A product thesis also needs a bounded outcome, transferable rule, exception policy, and a way to test the claim.

Should every exception be automated later?

No. Some exceptions are the part that requires accountable human judgment. Preserve them as an explicit service boundary until evidence supports something narrower.