Product Idea Audit
A method for taking an idea from "sounds nice" to "here is what is true, here is what kills it, and here is where else it could go."
Two passes, run in this order. The product pass establishes what is real. The creative pass expands from that reality. Running creative first produces enthusiasm about a market that does not exist.
The core principle: deliver the negative
Most analysis lists what is there. The value is in what is missing.
Across markets, the same blind spot repeats: everyone ships the positive, nobody ships the negative. Handover tools produce a document of what was said, none produce the signed list of what was never covered. Verification tools mark true and false, none distinguish "unfound" from "contradicted". Contract platforms track obligations that are already active, none inventory the dormant clauses nobody ever exercised.
So on every idea, ask early: what is the negative artifact here, and does anyone deliver it? That question alone finds the gap in most markets.
Workflow
Phase 0 — State the idea in one sentence
Before any research, write the idea as: for [specific person], when [trigger moment], this [does what], so that [outcome]. If the sentence needs an "and also", the idea is two ideas. Split them and audit separately.
Phase 1 — Evidence sweep
Gather facts before forming opinions. Never audit from priors: named competitors, prices, and demand numbers change fast, and an audit built on remembered market knowledge is worthless.
When parallel research agents are available, fan out one per idea or
per dimension. See references/research-orchestration.md for the
briefing template, the anti-fabrication clause, and the cost warning
that comes with it.
Minimum to collect per idea: named competitors with URLs and prices where public, what incumbent platforms already ship natively, demand signals with sources, and available public data if the product depends on a corpus.
Phase 2 — Product pass
Seven lenses, in this order. Each is a question the idea must
survive. Full question sets in references/lenses.md.
1. The problem, in numbers. No sourced number, no problem. If the only evidence is "everyone knows this is painful", the idea is untested. Watch for the reverse trap too: a number that proves the problem was real in 2018 may prove it has since been solved.
2. Who pays. The most under-asked question and the most lethal. Name the budget line, not the beneficiary. A product whose benefit lands on one person, whose budget sits with another, and whose data comes from a third has no buyer, and it will price like office stationery no matter how good it is.
3. Who owns the field. Separate three tiers: direct competitors, adjacent products, and native features of the platforms your users already pay for. The third tier kills more products than the first two combined, and it is the one people skip. If the incumbent ships your feature by default at roughly no marginal cost, your product needs a different object, not a better version.
A named-but-undocumented incumbent signal (a feature name in a changelog, an agent called something suggestive, a roadmap hint) is not the same evidence as a documented capability, even when it is the closest thing found. State it as "name suggests X, capability not confirmed" and do not let it carry argument weight in the verdict or in lens 7 proportional to a confirmed feature. Writing "not found" in the prose does not neutralise the risk if the conclusion still leans on the claim as if it were confirmed: the disclaimer has to actually change how much the claim is allowed to move the verdict, not just sit next to it.
4. What is genuinely free. Not "nobody has this exact name", but what job nobody does. Apply the negative test from above. Also check whether the gap is empty because it is worthless: sometimes nobody occupies a space because there is no money in it.
5. Commodity versus moat. Name which parts of the build are now commodities purchasable per thousand requests, then say where the defensibility actually sits. It is almost never the pipeline. In practice it is one of: a closed and trusted corpus, an artifact someone can hand to a third party as proof, hand-built data that exists in no public source, or a distribution position. If the answer is "our prompt" or "our UX", there is no moat.
6. The v1 boundary. Given the actual time available, state what ships: the data model in five entities or fewer, the two or three screens, and explicitly what it does not do. An idea that cannot be bounded cannot be built.
7. What kills this. One structural reason, not a style complaint. Structural means: no budget owner, the person whose cooperation is required has negative incentive, the incumbent ships it free, the error rate is incompatible with the buyer's ability to check, the data goes stale faster than it can be maintained, or regulatory exposure caps the addressable ambition. Write it as the strongest version of the argument, not a weakened one you can easily rebut.
Optional eighth lens when the idea will be pitched: the 90-second proof. What single screen makes an audience understand? If the answer is a summary of the output, the demo is weak. The strong demo is almost always the negative artifact from the core principle.
Phase 3 — Creative pass
Now expand, using the reality established above. Six moves. Full
prompts in references/lenses.md.
Flip the object. What you sell is not the obvious deliverable. Not the summary but the register. Not the verdict but the attestation. Not the handover document but the map of the gaps. Flipping the object usually changes the buyer and the price at the same time.
Flip the user. Sell to the person with the power and the irritation, not the person with the symptom. The one who has to re-explain everything, rather than the one who is lost.
Flip the payer. If the top of a market is locked behind enterprise sales with no public pricing, the opening is underneath it, where the same pain exists without the budget to solve it. Consider also the payer who benefits indirectly: employer, insurer, school, platform.
Flip the trigger. Move from a rare event that is suffered to a frequent one that is scheduled. Scheduled triggers can be planned, recur, and align the incentives of the person whose cooperation you need, because they are still around afterwards.
The 10x version. Turn a one-off event into continuous measurement. Turn a private output into a public signal. Turn a disposable artifact into a queryable memory. Ask: what would make this a system of record rather than a tool?
Lateral pivots. Same engine, different corpus. List three, including one emotionally loaded domain and one where the business model itself flips, such as charging a share of what the product recovers rather than a subscription. Also name the moment of use: when in the calendar does someone open this? A product tied to a recurring moment beats a better product with no moment.
Phase 4 — Verdict
Three outcomes only, and say which one out loud.
Kill. The idea does not survive. Name the structural reason and do not soften it. Killing an idea early is the most valuable output this method produces, and it is the one people avoid delivering.
Reframe. The idea survives only under a different object, user, payer or trigger. State the reframe explicitly, and warn that presenting it under the old name will force the pitch to be spent explaining the difference from an incumbent.
Build. State the v1 boundary and the one assumption that must hold.
When several ideas are audited together, add the cross-idea thread: what is the same underlying product across them. This is often the most useful finding of the whole exercise, and it only appears when the ideas are analysed side by side.
Number hygiene
Non-negotiable, because one bad number destroys the credibility of everything else in the document.
Every figure carries its source URL. A figure without a source is not used, even when it is probably right.
"Not found" is a finding. Write it. Never fill a gap with a plausible number.
Label vendor numbers as vendor numbers. A supplier claiming their product saves two days of onboarding is marketing, not evidence.
Date every number and ask what has changed since. A 2018 statistic about knowledge trapped in people's heads predates modern enterprise search, which weakens it, and an honest audit says so.
When two market-size estimates differ by more than a factor of two, cite neither as fact. Report the divergence instead.
Check famous statistics for origin. Round, memorable, widely repeated figures are the ones most likely to be myths built on mis-citation. If a number is everywhere but its primary source is nowhere, do not use it: an informed reader will use it to discredit the rest.
Prefer the primary source over the article that cites it.
This discipline is not only for numbers. Any claim used to justify a verdict, most of all in lens 7 ("what kills this"), carries the same requirement: its confirmed evidentiary status, not its most dramatic possible reading, is what gets weighed. "Strongest form of the argument" means the strongest CONFIRMED reasoning, stated forcefully; it does not license inflating an unconfirmed signal's certainty to make the argument read stronger.
Anti-patterns
Falling in love with the mechanism instead of the buyer. The cleverness of the engine has never made anyone pay.
Confusing "nobody does exactly this" with "there is a gap". Check what incumbents already ship under a different name before claiming open space.
Treating the code as the risk when the corpus is the risk. If the product needs data that exists in no public source, that is the project, and the software is the easy part.
Scoring only on feasibility and impressiveness, and forgetting who pays.
Softening the kill argument to keep the conversation pleasant. A weak version of the objection means the person hears it for the first time from someone less friendly.
Presenting agent research verbatim. Research output is raw material. The analysis is written afterwards, in one voice, by whoever is accountable for it.
Running the creative-pass lenses only against this file's example bullets. The lenses are questions to re-run against the idea's own already-established facts (an architecture already sketched elsewhere in the same engagement, a mechanism already described), not a menu to fill from the examples given here. The examples illustrate the question, they do not exhaust it.