1. Define the selection decision you need to make
Start with a specific business decision: which customer type should we pursue next, where does our offer fit only with exceptions, and which cases should we decline for now? An ICP should make those choices easier. Revenue bracket, industry and headcount can provide clues, but do not explain by themselves why a problem becomes urgent now.
The fictional Freigabefluss offers a structured approval process for technical documents. Its team suspects a good fit where several departments repeatedly need to approve material together. That situation initially matters more than a broad label such as mid-market. Conversations can test it through concrete workflows and consequences rather than simply asserting fit from a company list.
2. Separate the organisation, situation and people involved
Describe three layers separately. The organisation must meet basic conditions. The situation explains when pressure to act emerges. The people involved determine who experiences the problem, evaluates solutions, carries risk or authorises resources. Someone with a suitable job title does not automatically occupy all these roles.
In the fictional case, Freigabefluss separates quality management as the operational user, IT as a technical reviewer and a department lead as a potential sponsor. Actual roles are checked in each conversation. Instead of creating a rigid persona with invented leisure interests, the team records responsibilities, objections and required evidence. That helps interview recruitment and clearer messaging later.
| Layer | Fictional starting assumption | What needs verification |
|---|---|---|
| Organisation | Several departments work on technical documents | Is joint approval genuinely recurring? |
| Situation | A document is repeatedly returned before publication | Which recent specific event created pressure to act? |
| User | Quality management coordinates approvals | Who collects comments and follows unresolved issues? |
| Reviewer | IT evaluates technical integration | Which integrations or requirements are decisive? |
| Sponsor | Department leadership prioritises improvement | Who can defend the initiative against competing tasks? |
3. Select conversations that can disprove your assumption
Do not interview only satisfied existing customers. Include lost opportunities, initiatives that stalled, weak-use cases and people solving the problem without you. One counterexample can matter more than another confirmation. Record how participants were selected and which groups are missing.
In the example, Freigabefluss plans conversations covering three situations: a suitable customer, a lost comparison and a team deliberately keeping its existing solution. This is not a representative market sample. It is intended to reveal different mechanisms. The team therefore avoids market-wide percentages based on a handful of selected conversations.
4. Interview script: from the latest event to the decision path
Ask the participant to reconstruct something that actually happened. Explore sequence, people, available documents and consequences. “Would you buy a better solution?” easily produces politeness or speculation. “What did you actually do after the last problem?” gets closer to observable behaviour. You do not need to explain or defend every answer immediately.
For an adaptable conversation structure, the fictional team allows five minutes for context, fifteen to reconstruct the event, ten for alternatives and ten for the decision path. These are facilitation assumptions rather than a mandatory duration. Use the following questions directly. When answers are vague, ask for a specific example and keep missing evidence visibly marked.
| Interview segment | Ready-to-use question | Non-leading follow-up |
|---|---|---|
| Event | Tell me about the last document that was difficult to approve. | What happened immediately before and afterwards? |
| Work | Who actually handled each step? | Can you show the workflow through a specific document? |
| Consequence | What changed because of the delay? | Which impact was observed and which was only assumed? |
| Alternative | What did you subsequently try or keep using? | Why did that make sense in that situation? |
| Decision | Who participated in evaluating a change? | What information was missing before the next step? |
| Counterquestion | When does your current approach work well enough? | What is different in those cases? |
5. Keep an evidence log without hiding interpretation
First record the observed or reported statement, its source and context. Put your interpretation in a separate field. “One participant named three departments involved” differs from “complex organisations need our product”. The second statement is a conclusion requiring further investigation.
In the fictional Freigabefluss case, one role reports reliance on email attachments while another team already has a working document process. The team does not treat these observations as a contradiction to argue away. It investigates which conditions distinguish the cases. Protect confidential documents; anonymised notes with traceable context often suffice for internal analysis.
| Fictional observation | Tentative interpretation | Open disconfirming check |
|---|---|---|
| Approvals use email attachments | A shared status might help | Is the problem the tool or unclear responsibility? |
| Existing system is deliberately retained | Value of switching may be insufficient | Which task does the current system already solve adequately? |
| IT wants integration clarified before business approval | Technical evidence forms part of the buying decision | Does this apply generally or only to particular information? |
| One team rarely needs approvals | Recurrence might be a fit criterion | Could an infrequent critical case still justify change? |
6. Build the ICP around conditions and exclusions
Phrase fit signals so sales can check them through a conversation or traceable research. “Innovative” is not a useful observation. “Several departments repeatedly approve the same document types” is more concrete. Add prerequisites your service genuinely requires and exclusions that reveal commercially or operationally unsuitable projects early.
In the example, Freigabefluss initially excludes cases without a shared decision owner. That does not mean the organisation is permanently unsuitable. It may need process clarification before software. A useful ICP makes this distinction and records exceptions. Every exclusion includes a reason and the new information that could change the decision.
7. Treat actual alternatives as competition
Ask about more than similar suppliers. Existing spreadsheets, email, additional staff, an internal script or deliberately doing nothing may be the real alternatives. Explain what each alternative does well in context. Listing only weaknesses often misses why customers choose not to change.
For the fictional Freigabefluss, email is immediately available and familiar to everyone involved. A more modern interface does not erase those advantages. The team must explain when traceable status and structured handoffs could justify implementation effort. Where that condition is absent, respect the existing alternative rather than exaggerating the problem to discredit it.
8. Derive positioning through an evidence chain
Connect five elements: a suitable situation, the alternative actually used, a verifiable difference, the task that difference plausibly improves and the required proof. Do not jump directly from a product feature to a broad outcome promise. A feature can support a workflow without already demonstrating reduced costs or shorter cycle times.
The fictional draft reads: “For teams repeatedly approving technical documents across departments, Freigabefluss makes owners and outstanding approvals visible in one place. Unlike scattered email threads, its workflow connects each decision to a shared document version.” This remains a draft to investigate. It needs product evidence and a comprehension test rather than internal workshop approval alone.
| Step | Fictional completed positioning logic | Acceptance question |
|---|---|---|
| Situation | Recurring cross-department document approval | Is this situation supported by interview notes? |
| Alternative | Scattered email threads and attachments | Is this alternative actually used? |
| Difference | Shared document version with visible approval status | Can the product demonstrate this statement? |
| Plausible value | Participants see outstanding status without collecting separate threads | Does a suitable user understand the specific task improvement? |
| Proof | Guided walkthrough using a labelled example document | Can the difference be shown without an invented outcome figure? |
9. Test counterexamples explicitly
Actively seek situations where the new explanation fails. Perhaps an existing system is adequate, approvals are rare or a shared information base is missing. Record whether the counterexample affects the whole ICP, a specific condition or only the wording. Not every deviation requires an entirely new strategy.
Freigabefluss tests a fictional countercase: many people are involved, but an existing document system already solves the status problem reliably. The original condition of multiple participants is therefore insufficient. The team adds a specific gap in the current workflow as a prerequisite. This makes the ICP narrower and more useful instead of retroactively explaining every observed case as suitable.
10. Carry the decision into sales and the website
An ICP becomes useful when it changes specific routines. Add discovery questions about the situation, current alternative and ownership. Adapt the website introduction and service description so a suitable visitor recognises their context. Avoid repeating one comprehensive explanation everywhere: the short statement introduces, the conversation investigates and the demo substantiates.
In the example, Freigabefluss discusses document approval on its website rather than making a generic efficiency claim. Sales asks about the latest affected event and the current approach. The demo shows the relevant status transition. All three steps share a logic but require different depths of evidence. Unsuitable cases receive an honest assessment rather than a forced standard presentation.
11. Workshop: derive decisions from interview notes
Prepare anonymised interview notes and let participants identify observations independently first. An adaptable agenda allows fifteen minutes to read evidence, twenty to collect patterns and counterexamples, twenty to define fit and exclusions, twenty to derive positioning and fifteen to plan validation. These timings are facilitation assumptions.
Distinguish “recorded in the notes”, “we assume” and “we deliberately choose” throughout the discussion. A strong opinion does not acquire better evidence merely because it comes from the most experienced participant. End with a working draft and open tests. Missing support becomes a research assignment rather than being replaced by attractive wording.
12. Accept and update with explicit reasons for change
The draft is usable when a salesperson can assess fit, someone uninvolved can explain the positioning and a specialist can demonstrate the claimed difference. Every important inference needs evidence or an assumption label. At least one counterexample has been investigated rather than merely mentioned.
Agree on concrete review triggers: recurring unsuitable enquiries, newly lost opportunities, changed product capabilities or a different typical buying path. Compare observations with the original logic. Change only what the new information justifies. An ICP can evolve; repeatedly rewriting it without new learning often reflects isolated strong opinions rather than a better market understanding.
YOUR WORKSHEET
Editable ICP and positioning record
All completed prompts are explicitly fictional. Replace them with verifiable information from your conversations. Add a source and a counterexample before treating a statement as established. Unsupported statements remain assumptions.
| Work item | Fictional completed draft | Your evidence / counterexample | Decision / owner |
|---|---|---|---|
| Buying situation | Recurring approval of technical documents across departments | Add your entry | Add your entry |
| Specific trigger | A document was repeatedly returned before publication | Add your entry | Add your entry |
| User task | Quality management collects comments and outstanding status | Add your entry | Add your entry |
| Review role | IT evaluates necessary integrations | Add your entry | Add your entry |
| Current alternative | Email threads with attachments | Add your entry | Add your entry |
| Fit prerequisite | Current approach does not adequately provide shared status | Add your entry | Add your entry |
| Exclusion and exception | No shared responsibility; assess process clarification first | Add your entry | Add your entry |
| Counterexample | Existing document system already solves the task reliably | Add your entry | Add your entry |
| Verifiable difference | Shared document version with visible decisions | Add your entry | Add your entry |
| Positioning evidence | Walkthrough demonstrates status change on an example document | Add your entry | Add your entry |
| Comprehension test | Uninvolved person explains audience and specific help | Add your entry | Add your entry |
| Review trigger | Repeated unsuitable cases despite meeting the criteria | Add your entry | Add your entry |
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
1. Define the selection decision you need to make
Start with a specific business decision: which customer type should we pursue next, where does our offer fit only with exceptions, and which cases should we decline for now?
CHECKPOINT 02
2. Separate the organisation, situation and people involved
Describe three layers separately.
CHECKPOINT 03
3. Select conversations that can disprove your assumption
Do not interview only satisfied existing customers.
Frequently asked questions
How many interviews do I need for a defensible ICP?
No universal number guarantees evidence quality here. Distinct relevant cases, traceable situations and investigated counterexamples matter. Record gaps and selection bias. A few conversations can support a working draft but not a representative statement about the entire market.
What if customers describe very different reasons?
Separate situation, role and decision moment first. Different reasons may belong to one buying journey or reveal genuinely different segments. Investigate concrete workflows and alternatives before creating a new persona for every individual phrase.
Must positioning claim an entirely unique feature?
No. It needs to explain a defensible difference from alternatives actually used in a relevant situation. The difference may arise from a combination, workflow or specialisation. Do not claim uniqueness you cannot investigate and demonstrate against real alternatives.
When should I reconsider an exclusion?
When new information changes its original rationale, such as clearer ownership, suitable integrations or a different need. Record the exception and supporting evidence. One insistent request does not justify abandoning every previously useful boundary in the ICP.
How do I adapt a guide or framework to our business?
Start with a specific decision and add your own customer data, assumptions and owners. Use the described steps as a working structure and check whether examples fit your market and product. A general download does not replace an individual strategy or technical review.
Sources & editorial context
The working models and examples are editorial decision aids. Cases labelled fictional are not client references. Technical foundations are linked below; platform capabilities may change.
