Back to prompts

Prompt 002

icp-v0.2: updated after interviews

An evidence-weighted prompt for updating a codebase-derived ICP with completed customer-discovery interviews while preserving contradictions and uncertainty.

Ready-to-use prompt

Copy the assignment.

Goal

Update the product’s Ideal Customer Profile from ICP v0.1 to ICP v0.2 using completed customer-discovery interviews.

Treat ICP v0.1 as the original codebase-derived hypothesis and the interviews as new market evidence. Determine which assumptions were confirmed, weakened, falsified or left unresolved.

Do not merely summarize the interviews or accept respondents’ opinions literally. Analyze actual past behavior, experienced problems, existing workarounds, expenditures, authority, urgency and commitments.

Complete the analysis autonomously. Do not modify application code, overwrite ICP v0.1 or invent missing interview evidence.

Inputs

Locate and read:

- all applicable AGENTS.md instructions
- the existing ICP v0.1 Markdown and YAML files
- interview transcripts, recordings converted to text, notes or research summaries available in the repository
- interview metadata, including participant role, company, segment and date
- relevant product documentation and implementation when an interview claim must be checked against the product
- any related CRM, customer, usage or pilot data stored locally

Search common locations such as:

- `docs/gtm/`
- `docs/research/`
- `research/`
- `interviews/`
- `customer-interviews/`
- `discovery/`
- `notes/`

If ICP v0.1 or interview evidence cannot be found, do not fabricate v0.2. Report exactly what is missing and where you searched.

Evidence hierarchy

Evaluate interview statements using this hierarchy:

1. STRONGEST — Demonstrated past behavior
   - actions already taken
   - money already spent
   - tools already adopted
   - repeated workarounds
   - recent incidents
   - measurable consequences
   - concrete purchasing processes
   - access, introductions, pilots or payments committed

2. STRONG — Current operating reality
   - recurring workflow
   - known budget
   - active project
   - immediate deadline
   - named decision-maker
   - existing mandate or trigger

3. MODERATE — Specific dissatisfaction or stated preference
   - credible objection
   - detailed unmet need
   - comparison with an existing alternative
   - desired improvement grounded in current work

4. WEAK — Hypothetical intent
   - “I would use this”
   - “I would probably pay”
   - feature requests without demonstrated need
   - predictions about what other people might want
   - general enthusiasm or compliments

5. NON-EVIDENCE
   - politeness
   - abstract opinions
   - speculative market commentary
   - compliments about the idea
   - statements unrelated to the respondent’s actual behavior

Do not count all statements or respondents equally. Weight evidence based on:

- proximity to the problem
- whether the respondent is a user, champion, buyer or approver
- whether the organization fits the hypothesized ICP
- specificity and recency
- demonstrated behavior
- economic consequence
- authority and budget knowledge

Step 1: Reconstruct the interview sample

Create an interview inventory containing:

- interview identifier
- source file
- date
- organization type
- organization maturity or operating state
- participant role
- user, champion, buyer or approver classification
- hypothesized ICP segment
- whether the participant appears GREEN, YELLOW or RED under v0.1
- relevant selection-bias concerns
- completeness of the interview

Identify sample limitations, including:

- too many interviews from one segment
- interviewing users but not buyers
- interviewing friends or unusually warm contacts
- overrepresentation of small or easily accessible companies
- missing negative cases
- participants without recent experience of the problem
- participants who cannot describe purchasing authority
- interviews conducted after pitching the solution too early

Step 2: Extract structured evidence

For every interview, extract:

- most recent occurrence of the problem
- problem frequency
- problem severity
- measurable consequence
- emotional or organizational pressure
- triggering event
- current workaround
- existing tools or vendors
- current expenditure in money or labor
- satisfaction with the status quo
- desired outcome
- urgency and deadline
- user role
- champion
- economic buyer
- approver or blocker
- purchasing process
- technical prerequisites
- security, compliance or integration concerns
- objections
- switching costs
- requested product changes
- willingness to provide data or workflow access
- introductions offered
- pilot commitment
- payment commitment
- evidence contradicting ICP v0.1

Cite interview source files and participant identifiers for every material finding. Use short representative quotations only when the exact language matters.

Do not expose unnecessary sensitive personal information in the final ICP.

Step 3: Test every v0.1 assumption

For every important assumption in ICP v0.1, classify it as:

- CONFIRMED
- PARTIALLY CONFIRMED
- CONTRADICTED
- UNTESTED
- REFRAMED
- NEWLY DISCOVERED

For each classification provide:

- original v0.1 assumption
- interview evidence
- evidence strength
- number and type of participants supporting it
- contradictory evidence
- sample limitations
- resulting v0.2 change
- confidence level

Do not use simple majority voting. Three buyers describing recent expenditures may outweigh ten users expressing general interest.

Step 4: Compare problem language with product language

Identify:

- how customers describe the problem in their own words
- how the product currently describes the problem
- terminology customers understand immediately
- terminology that creates confusion
- benefits customers value
- features customers discuss without economic importance
- important outcomes absent from current positioning
- promises the current product cannot yet support

Recommend messaging changes separately from ICP changes. Do not change the ICP merely because customers prefer different wording.

Step 5: Reevaluate the economic job

Using interview evidence, update:

- recurring painful job
- frequency
- severity
- economic consequence
- triggering event
- current workaround
- existing expenditure
- buyer
- user
- champion
- blockers
- budget source
- purchasing process
- measurable desired outcome
- expected time to value

Determine whether the interviews reveal:

- a vitamin rather than a painkiller
- a user problem without a budget owner
- a serious problem with an adequate workaround
- an urgent problem poorly served by the current product
- a product capability without a meaningful commercial problem
- a different economic job than v0.1 assumed

Step 6: Rescore all ICP candidates

Rescore the original GREEN, YELLOW and RED segments from 1–5 on:

- demonstrated problem severity
- demonstrated frequency
- urgency
- existing expenditure or workaround
- dissatisfaction with the status quo
- product fit
- technical readiness
- buyer authority
- budget clarity
- buyer reachability
- time to value
- activation likelihood
- retention potential
- expansion potential
- implementation burden
- support burden
- roadmap distortion
- strength of interview evidence

Add newly discovered segments only when supported by concrete interview evidence.

For every score, show:

- v0.1 score
- v0.2 score
- reason for the change
- supporting evidence
- remaining uncertainty

Step 7: Attempt to falsify the emerging ICP

Challenge the highest-scoring segment:

- Did participants experience the problem recently?
- Have they attempted to solve it?
- Is the consequence large enough to justify action?
- Is there an identifiable budget?
- Does the interviewed user influence the purchase?
- Is the trigger externally observable?
- Can the current product produce value quickly?
- Are requested changes repeatable or customer-specific?
- Are participants committing anything beyond attention?
- Could enthusiasm be caused by interview politeness?
- Would customers still care without the product’s AI or technical novelty?
- Is this segment attractive because it is genuinely ideal or merely accessible?

State the strongest argument against selecting this ICP.

Step 8: Update Red / Yellow / Green classifications

Classify each segment:

GREEN — Core ICP

Requires strong evidence of:

- recurring consequential pain
- relevant current workaround or expenditure
- clear user and buyer
- strong product fit
- plausible adoption path
- measurable value
- acceptable implementation burden

Interview enthusiasm alone cannot promote a segment to GREEN.

YELLOW — Experimental periphery

Use when:

- the problem appears real but budget or urgency is uncertain
- the buyer was not interviewed
- product fit requires a limited experiment
- evidence is promising but the sample is weak
- a paid pilot is needed to resolve the uncertainty

Every YELLOW segment must have a specific experiment, success criterion and kill criterion.

RED — Do not pursue

Use when:

- the problem is weak or infrequent
- the respondent has no meaningful workaround or expenditure
- there is no identifiable buyer
- the status quo is adequate
- adoption requires excessive change
- the segment demands non-repeatable customization
- evidence indicates likely churn or roadmap distortion

For every promotion, demotion or unchanged classification, explain why.

Step 9: Select ICP v0.2

Produce:

- one primary GREEN ICP
- one narrow beachhead
- justified YELLOW experiments
- explicit RED segments
- disqualifying conditions

Express the revised ICP as:

“[Economic buyer] at [specific organization in a particular operating state] who is experiencing [demonstrated recurring pressure], usually after [observable trigger], and currently relies on [verified workaround]. They need [desired measurable outcome] because [economic consequence]. The product initially helps them through [smallest use case], with value demonstrated by [metric].”

Also provide:

- daily user
- champion
- buyer
- blockers
- current workaround
- trigger
- initial offer
- pilot structure
- value metric
- expected proof of value
- qualification signals
- disqualification signals
- likely retention mechanism
- likely expansion path
- remaining commercial unknowns

Do not claim the ICP is validated unless the evidence supports actual purchasing and successful usage behavior.

Step 10: Determine the next validation stage

Identify what interviews still cannot establish, especially:

- actual willingness to pay
- product activation
- realized value
- implementation burden
- repeated usage
- retention
- expansion
- cost to serve

Create the smallest paid-pilot tournament needed to advance toward ICP v0.3.

Specify:

- target segment
- number and type of pilot candidates
- offer
- price or commitment test
- scope
- duration
- required customer contribution
- success metric
- activation threshold
- outcome threshold
- confirmation condition
- falsification condition
- conditions for changing the ICP again

Deliverables

Preserve all v0.1 files.

Create:

1. `docs/gtm/icp-v0.2.md`

Include:

- executive conclusion
- interview-sample inventory
- sample limitations
- structured evidence synthesis
- v0.1 assumption audit
- contradictions and surprises
- updated economic job
- customer language
- segment rescoring
- Red/Yellow/Green changes
- primary ICP v0.2
- beachhead ICP
- disqualifiers
- strongest falsification argument
- unresolved unknowns
- paid-pilot plan for v0.3

2. `docs/gtm/icp-v0.2.yaml`

Include:

- version: 0.2
- status
- based_on
- evidence_cutoff_date
- interview_count
- interview_segments
- confidence
- primary_icp
- beachhead_icp
- operating_state
- users
- champion
- economic_buyer
- approvers
- painful_jobs
- economic_consequences
- triggering_events
- current_alternatives
- existing_expenditure
- prerequisites
- qualification_signals
- disqualifiers
- initial_offer
- pilot
- value_metrics
- retention_hypotheses
- expansion_hypotheses
- green_segments
- yellow_segments
- red_segments
- confirmed_assumptions
- contradicted_assumptions
- untested_assumptions
- new_findings
- interview_evidence
- sample_limitations
- unknowns
- next_experiments
- confirmation_conditions
- falsification_conditions

3. `docs/gtm/icp-changelog.md`

Record:

- what changed from v0.1 to v0.2
- why it changed
- supporting evidence
- confidence change
- segments promoted or demoted
- questions still unresolved

Boundaries

- Do not overwrite or retroactively edit ICP v0.1.
- Do not modify application code.
- Do not treat interview compliments as demand.
- Do not treat hypothetical willingness to pay as payment evidence.
- Do not count every respondent equally.
- Do not use majority voting without considering role and evidence strength.
- Do not allow one large potential deal to redefine the ICP.
- Do not convert every feature request into an ICP requirement.
- Do not infer retention or LTV from interviews.
- Do not hide contradictory evidence.
- Do not expose unnecessary personal or confidential information.
- Preserve uncertainty rather than manufacturing confidence.

Done when

- Every interview has been inventoried and classified.
- Every material v0.1 assumption has been audited.
- Past behavior is separated from hypothetical interest.
- Contradictory and negative evidence is visible.
- All segments have been rescored.
- Red/Yellow/Green changes are explicit.
- One primary ICP v0.2 and one beachhead have been selected.
- The differences between v0.1 and v0.2 are traceable to interview evidence.
- Remaining unknowns are explicit.
- A paid-pilot plan exists for advancing to ICP v0.3.
- All three deliverable files are complete and internally consistent.

Expected result

A testable ICP hypothesis, not manufactured certainty.

The finished analysis separates what the repository proves from what customer and market evidence must still validate.

Use this when

Use this after customer-discovery interviews have tested an existing codebase-derived ICP and the evidence needs to be weighted, reconciled, and converted into a traceable v0.2 hypothesis.

What it produces

  • An interview-evidence-backed ICP update at docs/gtm/icp-v0.2.md
  • A machine-readable v0.2 hypothesis at docs/gtm/icp-v0.2.yaml
  • A traceable version history at docs/gtm/icp-changelog.md
  • A paid-pilot tournament for advancing toward ICP v0.3

Guardrails

  • Preserves every ICP v0.1 file and does not modify application code
  • Weights past behavior, expenditure, authority, and commitments above enthusiasm
  • Keeps contradictory evidence and sample limitations visible
  • Avoids exposing unnecessary personal or confidential information