THE SHORT ANSWER
A defensible ICP needs a traceable research record. This guide explains how to connect claims about suitable customers with sources, samples, uncertainty and contradictory cases. The output is an evidence ledger that supports justified revisions to the customer profile. Use the linked ICP guide when you need practical account qualification rather than a research audit trail.
To connect this decision with positioning, market entry and growth, read the pillar guide Go-to-market for B2B SaaS: turn market insight into an executable growth strategy.
One testable claim per ledger row
Start with a statement that could be wrong: for example, that distributed IT service teams describe a particular handover problem as urgent. Separate that statement from the inference that these companies therefore fit your product. Give each row a stable identifier and record its scope. Which team structure, task and period does it describe? Link resulting decisions to this identifier. When evidence changes, you can trace the effect through targeting rules and messaging instead of simply replacing an outdated presentation. A broad label such as enterprise readiness is too ambiguous to audit without several more precise underlying claims.
Record provenance and sampling
Capture the source, collection date, responsible researcher and reference location. For interviews, include a protected reference to the original notes and the recruitment route. For CRM analysis, document the period, filters, missing records and definitions used. Also record how many separate organisations are represented. Several conversations within one account are not independent customer cases. The GOV.UK interview guide supports planned discussions grounded in concrete experiences. The ledger proposed here adds traceability between that material and an ICP decision. It does not replace participant consent, appropriate access restrictions or careful handling of personal information collected during the research process. Explore this further in the guide Win-loss interviews: understand buying decisions.
Separate observation from interpretation
Keep different fields for the observed material and your interpretation. Someone may describe repeated coordination difficulties while your team infers that buying software is a priority. The purchase priority has not yet been established. Add a reasoned confidence category such as provisional, partly supported or repeatedly corroborated. These are internal working definitions, not statistical probabilities. State the alternative explanation that remains possible and the evidence still missing. A percentage without a defensible sampling model creates false precision. Another colleague should be able to inspect the linked records, understand your judgement and reach a different assessment with explicit reasons rather than personal preference.
Retain contradictory cases deliberately
Look for cases that challenge the preferred claim. These include successful customers outside the assumed profile and apparently suitable organisations that solve the problem without your category. Investigate whether different triggers, maturity levels or operating conditions explain the difference. Do not remove conflicting notes simply to create a cleaner narrative. Include a contradictory-case field and distinguish genuine disconfirmation from an insufficiently investigated case. This can turn an overbroad claim into a narrower, better supported one. A lost opportunity, for instance, does not establish lack of need if an unrelated procurement freeze prevented the organisation from making any purchase decision. Explore this further in the guide Make GTM assumptions visible and test them deliberately.
Read an illustrative ledger
Suppose three existing customers identify the number of locations as the source of their difficulty. The ledger reveals that all three came through the same implementation partner and use similar legacy systems. Another interview, with a business operating many locations on a standardised system, provides a contradictory case. This example is hypothetical. The claim should not yet become a general location rule in the ICP. Comparing different system environments would be a useful next investigation. Preserve the original hypothesis, the possible recruitment bias, the counterexample and the resulting research question together, so later readers can reconstruct why the working explanation changed.
Agree validation and revision rules
Before another research round, decide what observation would change your assessment. Record the question, suitable cases, method and decision rule. After analysis, create a new ledger version with its date, approving owner and reasons. Keep the earlier state accessible. When a claim changes substantially, review the linked ICP rules, campaigns and sales materials together. Schedule reconsideration when meaningful product changes or new customer situations emerge. The result is not a permanently proven profile. It is an auditable state of knowledge with clear limitations, evidence references and a specific next learning step that someone is responsible for carrying out.
INTERACTIVE / FROM READING TO ACTION
Three checkpoints for your implementation
Choose a checkpoint and track your reading progress. Checks are neither saved nor sent and do not score your business.
CHECKPOINT 01
Separate observation from interpretation
Keep different fields for the observed material and your interpretation.
Explore in the article ↗CHECKPOINT 02
Retain contradictory cases deliberately
Look for cases that challenge the preferred claim.
Explore in the article ↗CHECKPOINT 03
Read an illustrative ledger
Suppose three existing customers identify the number of locations as the source of their difficulty.
Explore in the article ↗Frequently asked questions
What belongs in an ICP evidence ledger?
Include the claim, scope, source, date, sample, original reference, interpretation, uncertainty, contradictory cases and next test.
Is the confidence category a probability?
No. Without a suitable statistical method it remains a reasoned internal assessment with documented criteria.
How should we use a contradictory case?
Investigate alternative explanations and narrow the claim when justified. Keep the case and its original reference in the ledger.
How can I put “One testable claim per ledger row” into practice?
Start with a statement that could be wrong: for example, that distributed IT service teams describe a particular handover problem as urgent. Separate that statement from the inference that these companies therefore fit your product. Give each row a stable identifier and record its scope.
What matters when working on “Record provenance and sampling”?
Capture the source, collection date, responsible researcher and reference location. For interviews, include a protected reference to the original notes and the recruitment route. For CRM analysis, document the period, filters, missing records and definitions used.
