How to Write an ICP Hypothesis That Can Be Proven Wrong

Who this framework is for

This framework is for teams creating a new ICP, transferring one into a new region, or questioning a profile built from anecdotes. It is designed for decisions that can be tested through account research and a bounded validation sample before irreversible investment.

Contents

1 Replace the profile with a claim 2 Define the unit and boundary 3 Specify evidence and unknowns 4 Write disconfirming conditions 5 Design a bounded test 6 Predefine the review outcomes 7 Complete the hypothesis record 8 Illustrative example 9 Common mistakes 10 What this does not mean 11 Common questions 12 Sources and methodology

1. Replace the profile with a claim

A descriptive profile lists attributes. A hypothesis connects those attributes to a reason the account should fit and makes that connection testable. Use this SellersGPT template: We believe that [defined account unit] in [geography] with [observable structural conditions] is more likely to have [specific application] and a viable [commercial relationship] because [mechanism]. We will evaluate this claim using [evidence and sample] by [review point]. We will revise or reject it if [disconfirming conditions] occur. Avoid “best customers are innovative mid-sized manufacturers.” “Innovative” lacks an observable definition, “mid-sized” may use several incompatible measures, and “best” has no outcome or comparison set. A testable version might say: “Independent packaging-machine OEM divisions in two named states that publicly document washdown applications and support a specified sensor interface are more likely to pass our design-fit and service gates than the broader machinery account universe.” This can be checked against named records. The claim is about account fit. It is not a claim that accounts will reply, become qualified leads, create opportunities, or buy.

2. Define the unit and boundary

Every hypothesis needs five boundaries: 1 Unit: parent, enterprise, legal entity, establishment, facility, project, or account-application record. 2 Product: exact offer, configuration, and exclusions. 3 Application: operating function, conditions, and alternative. 4 Relationship: OEM, distributor, end user, contractor/integrator, or another defined path. 5 Geography and period: where the evidence applies and when it will be reviewed. Official data can establish a sampling frame only when its unit and coverage fit the claim. County Business Patterns reports annual statistics for employer businesses at establishment level by geography and detailed industry. U.S. Census Bureau - County Business Patterns API The QCEW concept page distinguishes establishments from firms and describes establishment-level industry and location concepts. BLS - QCEW Concepts If the hypothesis concerns independent firms, do not sample raw establishments and call them firms. If it concerns applicable plants, a parent-company list is not the correct denominator. Define deduplication and hierarchy before selection.

3. Specify evidence and unknowns

List each critical claim, evidence requirement, source scope, and state. Claim Minimum evidence State options Account unit Current entity/site relationship Confirmed, probable, unknown, contradicted Application First-party process, equipment, project, or direct verification Confirmed, probable, unknown, contradicted Relationship Evidence of integration, resale, operation, or project role Confirmed, probable, unknown, contradicted Qualification Requirement and ability to meet it Pass, unknown dependency, fail Serviceability Delivery and support requirement within approved boundary Pass, unknown dependency, fail Accessibility Appropriate account and responsibility path Confirmed, probable, unknown, contradicted EDGAR provides public access to filings that can support first-party facts about a public company’s reported operations, segments, facilities, or risks. U.S. Securities and Exchange Commission - Search Filings Procurement notices on SAM.gov can support project-specific requirements and roles. SAM.gov - Contract Opportunities Keep dates, entities, and document scope visible. Write unknowns explicitly. “Facility process unknown” is more useful than a guessed application score. Identify which unknown is critical enough to block the decision and which can be resolved during a limited test.

4. Write disconfirming conditions

The hypothesis is falsifiable only if the team states what would count against it. Conditions should target the mechanism, not campaign performance alone. Examples:

• fewer than a predefined share of sampled units can confirm the application;

• the supposed OEM accounts primarily buy for their own facilities;

• mandatory qualification requirements exceed the product’s documented scope;

• the service model cannot meet verified site requirements within the approved cost boundary;

• the reachable universe is materially smaller after parent and site deduplication;

• the segment splits into incompatible applications or buying paths;

• evidence comes mainly from one atypical project or corporate group. “Low reply rate” may trigger investigation, but it does not by itself disprove account fit. The cause could be contact selection, message, deliverability, timing, or the ICP. Similarly, a high reply rate does not prove that the application and commercial path pass. Use both a failure threshold and an uncertainty threshold. For example:

• Reject or redesign: fewer than 6 of 24 sampled records pass all critical account gates.

• Unresolved: more than 10 of 24 retain a critical unknown after the research protocol. The numbers are management choices for a bounded test, not universal benchmarks.

5. Design a bounded test

Pre-register the practical test record:

• source universe and extraction date;

• inclusion and exclusion rules;

• sampling method;

• target sample and stop point;

• account unit and deduplication method;

• evidence fields and acceptable source types;

• researcher instructions;

• treatment of unknowns;

• calculations and denominators;

• decision owner and review date. Sampling should expose the hypothesis to failure. Do not choose only the best-known logos or accounts already cited by sales. If the initial sample is purposive, state the purpose and limitation. A sample of likely positives can test whether evidence is obtainable, but it cannot estimate prevalence across the universe. Separate sequential filters. If 40 records are sampled, 30 have correct units, 18 confirm the application, and 12 pass the relationship and service gates, report 30/40, 18/30, and 12/18, plus 12/40 end to end. Do not present 12 as a percentage of an unspecified population.

6. Predefine the review outcomes

Use five outcomes: Outcome Evidence pattern Action Support Gates and thresholds pass with manageable unknowns Advance to a bounded execution plan Revise Core mechanism holds but criteria or scope are wrong Version the definition and retest changed fields Split Two distinct applications or buying paths appear Create separate ICP hypotheses Pause Critical dependency cannot yet be resolved Name the evidence trigger and stop active expansion Reject Mechanism or hard gates are contradicted Archive the hypothesis and rationale Do not rewrite the original threshold after results arrive. If new learning shows the initial rule was poorly designed, preserve version 1, explain the change, and create version 2. That is learning; erasing the original rule is not. The review should distinguish data quality failure from hypothesis failure. If researchers cannot identify the correct sites because records are incomplete, the result may be “pause and repair the universe,” not “application absent.”

7. Complete the hypothesis record

Field Required entry Hypothesis ID and version Stable ID, version, owner, date Bounded claim Unit, product, application, relationship, geography, mechanism Population frame Source, unit, coverage, exclusions, date Required evidence Source types and scope for every critical field Hard gates Pass, fail, and unknown rules Sample Method, size, deduplication, stop point Support conditions Predefined evidence pattern Disconfirming conditions Predefined failure pattern Uncertainty condition Maximum unresolved critical fields Decision outcomes Support, revise, split, pause, reject Review point Date or completed-sample milestone Attach the evidence ledger rather than summarizing it away.

8. Illustrative example

Illustrative example - explicitly fictional. LumenPack, a fictional component maker, tests this hypothesis: “Packaging-machine OEM divisions in three Great Lakes states that document high-pressure washdown lines are likely to pass our application, interface, and service gates.” Before research, LumenPack sets:

• sample: 24 deduplicated OEM division records;

• support threshold: at least 6 of 24 pass all critical gates;

• reject threshold: fewer than 4 of 24 pass;

• revision band: 4 or 5 of 24 pass, provided the uncertainty rule is not breached;

• unresolved threshold: more than 10 of 24 retain a critical unknown;

• review point: all 24 records completed. Results: Result state Records Pass all critical gates 7 Fail at least one critical gate 8 Critical unknown remains 9 Total 24 Gate-pass share is 7 / 24 = 29.2%. Failure share is 8 / 24 = 33.3%. Critical-unknown share is 9 / 24 = 37.5%. The counts reconcile: 7 + 8 + 9 = 24. The support threshold of 6 is met, and the unknown count of 9 does not exceed 10. The hypothesis is supported for a bounded next test, not proven universally. The seven passing records are not forecast leads or customers. A review of the eight failures shows three divisions are end users rather than OEMs, so relationship classification becomes a required pre-screen in version 2.

9. Common mistakes

• Writing adjectives that cannot be observed or contradicted.

• Leaving the account unit or geography unspecified.

• Setting thresholds after the results are known.

• Sampling only recognizable or favorable accounts.

• Scoring unknown as false, zero, or average.

• Treating replies, clicks, or meetings as the only validation evidence.

• Changing the message while assuming the ICP cannot be wrong.

• Deleting failed versions instead of preserving the decision record.

10. What this does not mean

A falsifiable ICP is not a scientific experiment with perfect control, and a small sample does not prove prevalence across a market. It is a disciplined commercial decision record that makes evidence and revision possible. The method does not promise pipeline results and does not convert account research into intent. It does not replace applicable product, privacy, legal, procurement, or channel review. A supported ICP still requires buying-group mapping and execution testing; a rejected ICP does not imply the product has no market anywhere.

11. Common questions

How large should the validation sample be? Choose a size that can expose the key failure modes and is feasible to complete consistently. State whether the sample is purposive or representative. Do not claim statistical precision the design cannot support. Can existing customers be used? Yes, for mechanism discovery, but they are a selected group. Use them to draft criteria, then test those criteria on a separate bounded account sample. What if most fields remain unknown? Treat that as an evidence-system finding. Improve the source universe, narrow the claim, seek direct verification, or pause. Do not manufacture certainty. Can outreach be part of the test? It can be one bounded evidence method under applicable rules, but separate account-fit confirmation from response and downstream outcomes. When is the hypothesis proven? Commercial ICP hypotheses are not permanently proven. They accumulate support within a stated scope and remain subject to new evidence, market change, and version review.

12. Sources and methodology

The claim template, evidence states, thresholds, test record, review outcomes, and worksheet are SellersGPT editorial tools. Official sources are used only for population units, public filings, and procurement-notice scope. Illustrative thresholds are fictional management rules, not benchmarks. 1 ICP06-CENSUS-CBP - U.S. Census Bureau, “County Business Patterns APIs.” https://www.census.gov/data/developers/data-sets/cbp-zbp/cbp-api.html Accessed August 24, 2026. 2 ICP06-BLS-QCEW - U.S. Bureau of Labor Statistics, “Quarterly Census of Employment and Wages: Concepts.” https://www.bls.gov/opub/hom/cew/concepts.htm Accessed August 24, 2026. 3 ICP06-SEC-EDGAR - U.S. Securities and Exchange Commission, “Search Filings.” https://www.sec.gov/search-filings Accessed August 24, 2026. 4 ICP06-SAM-OPPORTUNITIES - SAM.gov, “Contract Opportunities.” https://sam.gov/opportunities Accessed August 24, 2026.