icp-v0.3: updated after paid pilots

Goal

Update the product’s Ideal Customer Profile from ICP v0.2 to ICP v0.3 using evidence from paid pilots.

Treat ICP v0.2 as the interview-derived hypothesis and the paid pilots as tests of actual purchasing behavior, activation, product value, implementation burden and commercial repeatability.

Determine which ICP assumptions were confirmed, weakened, falsified or remain unresolved.

Do not treat payment alone as validation. Distinguish:

- agreeing to a pilot
- signing an agreement
- making a real payment
- activating
- completing the intended workflow
- obtaining measurable value
- continuing usage
- requesting renewal or expansion

Complete the analysis autonomously. Do not modify application code, overwrite previous ICP versions or manufacture missing pilot evidence.

Inputs

Locate and read:

- all applicable AGENTS.md instructions
- ICP v0.1 and ICP v0.2 Markdown and YAML files
- the ICP changelog
- interview evidence used for v0.2
- paid-pilot plans and validation thresholds defined in v0.2
- pilot agreements, scopes of work and pricing
- invoices, payment records, refunds and credits
- product analytics and usage exports
- onboarding and activation records
- implementation and integration logs
- support conversations and issue records
- customer feedback and outcome reports
- delivery-time and founder-time records
- product changes made for pilots
- renewal, expansion, referral or cancellation evidence
- declined, stalled and lost pilot opportunities
- relevant CRM or sales-pipeline data available locally
- relevant product implementation when checking whether pilot delivery depended on the core product or custom work

Search common locations such as:

- `docs/gtm/`
- `docs/research/`
- `research/`
- `pilots/`
- `customers/`
- `analytics/`
- `sales/`
- `crm/`
- `invoices/`
- `support/`
- `outcomes/`

If ICP v0.2 or paid-pilot evidence cannot be found, do not fabricate v0.3. Report what is missing and where you searched.

Evidence standard

Label every material finding as:

- VERIFIED: Supported by payment, product telemetry, delivery records or documented customer outcomes.
- SUPPORTED: Corroborated by multiple credible sources but not completely verified.
- INFERRED: Reasonably implied by incomplete evidence.
- UNKNOWN: Cannot be established from available evidence.
- CONTRADICTED: Evidence conflicts with the previous assumption.

Use this evidence hierarchy:

1. STRONGEST — Commercial commitment plus realized value

- non-refundable payment
- activation
- completed core workflow
- measurable customer outcome
- continued voluntary usage
- renewal or expansion commitment
- referral to another qualified buyer
- willingness to continue at sustainable pricing

2. STRONG — Real product and operational behavior

- customer provided required data or access
- onboarding completed
- product used in a real workflow
- agreed success threshold reached
- customer incorporated the product into an ongoing process
- buyer requested continued use

3. MODERATE — Commercial commitment without demonstrated value

- paid but did not activate
- signed but delayed implementation
- pilot completed without a measurable outcome
- heavily discounted or conditional payment
- positive feedback without continued usage

4. WEAK — Stated satisfaction

- compliments
- survey enthusiasm
- hypothetical renewal
- feature requests
- willingness to refer without an actual introduction

5. NEGATIVE EVIDENCE

- refusal to pay
- stalled procurement
- failed onboarding
- missing technical prerequisites
- low usage
- customer abandonment
- refund
- inability to demonstrate value
- excessive support or customization
- refusal to renew
- buyer disagreement with the user
- successful outcome that depended primarily on founder labor

Do not discard failed, declined or incomplete pilots. Negative evidence is required for determining the ICP.

Step 1: Reconstruct the pilot cohort

Create an inventory containing:

- pilot identifier
- organization
- v0.2 segment
- Green, Yellow or Red classification under v0.2
- organization operating state
- user
- champion
- economic buyer
- pilot scope
- proposed price
- actual price
- discount or special concessions
- payment status
- refund or credit status
- start and completion dates
- intended use case
- success criteria established before the pilot
- activation status
- outcome status
- renewal or expansion status
- source files
- evidence completeness

Include prospects who:

- were offered a pilot but declined
- verbally agreed but never signed
- signed but never paid
- paid but never activated
- activated but abandoned
- completed without obtaining value
- completed successfully
- requested continued usage
- renewed, expanded or referred another buyer

Identify cohort limitations such as:

- very small sample
- unusually warm relationships
- founder-selected friendly customers
- excessive discounts
- inconsistent pilot scopes
- different success criteria between customers
- pilots concentrated in one segment
- lack of genuine economic buyers
- unusually high founder involvement
- missing baseline measurements
- incomplete instrumentation

Step 2: Audit pilot integrity

For each pilot determine:

- Was money actually collected?
- Was payment non-refundable and economically meaningful?
- Was the customer paying for the product outcome, consulting labor or custom development?
- Was the price close to the proposed sustainable price?
- Did the customer have a real problem and deadline?
- Did the customer provide meaningful access, data or internal effort?
- Was the core product used?
- What product modifications were required?
- How much manual founder intervention was required?
- Would an ordinary employee or repeatable system have been able to deliver the same pilot?
- Was the success metric defined before observing the result?
- Was there a credible baseline?
- Can the outcome reasonably be attributed to the product?
- Did the customer continue using the product after the supervised pilot period?
- Did the buyer—not merely the user—recognize the result?

Flag:

- disguised consulting engagements
- bespoke development
- vanity pilots
- innovation-budget experiments without operational ownership
- payments too small to demonstrate meaningful demand
- moving success criteria
- unpaid “paid” pilots
- customer success dependent on founder heroics

Step 3: Calculate pilot outcomes

Where the necessary data exists, calculate:

- offer-to-pilot conversion
- agreement-to-payment conversion
- payment-to-activation conversion
- activation-to-completion conversion
- completion-to-success conversion
- median time to agreement
- median time to payment
- time to activation
- time to first value
- time to measurable outcome
- pilot completion rate
- success-threshold attainment
- post-pilot continued-usage rate
- renewal-request rate
- expansion-request rate
- referral rate
- refund rate
- abandonment rate
- implementation hours
- customization hours
- support hours
- founder hours
- infrastructure and model costs
- approximate delivery cost
- approximate pilot gross-margin contribution
- product changes required per pilot

Do not invent missing numbers.

For small samples, report raw counts alongside percentages. For example:

“2 of 3 activated” rather than presenting only “67% activation.”

Do not extrapolate long-term retention or LTV from short pilots.

Step 4: Compare results with predeclared thresholds

Locate the confirmation, falsification and success conditions defined in ICP v0.2.

For every condition record:

- original condition
- target threshold
- observed result
- whether it was met
- evidence source
- caveats
- interpretation

Do not silently replace a missed threshold with a more convenient one.

If success criteria changed during a pilot:

- show the original criterion
- show the revised criterion
- explain why it changed
- evaluate the result under both criteria

Classify each v0.2 assumption as:

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

Step 5: Evaluate product value

For each completed pilot determine:

- customer’s baseline state
- intervention delivered
- workflow completed
- measurable outcome
- customer-recognized value
- economic value, if measurable
- time to value
- durability of the outcome
- dependence on manual assistance
- difference between promised and realized value

Separate:

- product usage
- product output
- operational outcome
- economic outcome

A customer using the product is not equivalent to the customer obtaining value.

Identify which product capability created the outcome and which capabilities were unnecessary.

Step 6: Evaluate commercial quality

For each pilot determine:

- whether the buyer had a recognized budget
- budget source
- procurement difficulty
- sales-cycle length
- pricing resistance
- discount dependence
- implementation burden
- support burden
- security or compliance friction
- number of stakeholders required
- decision-maker involvement
- likelihood of sustainable pricing
- evidence of renewal
- evidence of expansion
- evidence of internal advocacy
- evidence that another similar customer could be sold and served repeatedly

Distinguish a good product user from a good commercial customer.

Step 7: Evaluate repeatability

Determine whether successful pilots were successful because of:

- repeatable product capabilities
- repeatable onboarding
- repeatable customer prerequisites
- repeatable data access
- repeatable integrations
- repeatable sales motion
- repeatable value measurement

Identify any success dependent on:

- founder reputation or personal relationship
- exceptional customer patience
- custom engineering
- manual data preparation
- unusual discounts
- one-off integrations
- undefined consulting
- continuous founder supervision
- customer characteristics unlikely to recur

For every successful pilot answer:

“If ten comparable customers began next month, could the current organization deliver the same result without proportionally increasing founder labor?”

Classify delivery as:

- PRODUCT-REPEATABLE
- SERVICE-ASSISTED BUT STANDARDIZABLE
- FOUNDER-DEPENDENT
- BESPOKE
- UNKNOWN

Step 8: Rescore ICP candidates

Rescore all v0.2 Green, Yellow and Red segments from 1–5 on:

- demonstrated willingness to pay
- pricing quality
- activation rate
- time to value
- measurable outcome attainment
- product fit
- technical readiness
- buyer authority
- budget clarity
- procurement friction
- implementation burden
- support burden
- founder dependence
- delivery repeatability
- gross-margin potential
- continued usage
- renewal evidence
- expansion evidence
- referral evidence
- roadmap distortion
- strength of evidence

For every score provide:

- v0.2 score
- v0.3 score
- reason for the change
- pilot evidence
- negative evidence
- remaining uncertainty

Do not let a single large payment outweigh poor activation, excessive customization or an inability to repeat delivery.

Step 9: Attempt to falsify the winning segment

Challenge the leading ICP:

- Would these customers have paid without a founder relationship?
- Would they pay the intended recurring price?
- Did the product create the outcome or did manual service create it?
- Can onboarding be repeated?
- Can the success metric be measured consistently?
- Did the economic buyer recognize the value?
- Did customers continue voluntarily after the pilot?
- Would the product remain valuable after the triggering project ends?
- Were successful pilots materially different from failed pilots?
- Are the observed qualification signals available before selling?
- Is the segment attractive because it is ideal or because it happened to be accessible?
- Would serving ten more customers improve or destroy operational economics?

State the strongest argument against adopting this segment as the ICP.

Step 10: Update Red / Yellow / Green classifications

GREEN — Pilot-supported core ICP

Requires evidence of:

- actual payment
- successful activation
- completed core workflow
- measurable customer outcome
- identifiable buyer and budget
- acceptable time to value
- manageable implementation burden
- repeatable delivery potential
- credible continued-use or renewal interest

A single successful bespoke pilot is insufficient for GREEN.

YELLOW — Promising but unresolved

Use when:

- customers paid but value was inconsistent
- activation occurred but repeatability is unclear
- successful outcomes required standardizable services
- the buyer or budget remains uncertain
- pricing was heavily discounted
- additional comparable pilots are required
- renewal or continued usage has not yet been observed

Every Yellow segment must have a next experiment, success condition and kill condition.

RED — Do not pursue

Use when:

- customers would not pay
- paid customers failed to activate
- value was not measurable
- the status quo remained adequate
- delivery required excessive customization
- founder labor made the economics non-repeatable
- procurement costs exceeded likely value
- customers declined continued usage
- the segment distorted the product roadmap

For each classification explain:

- v0.2 classification
- v0.3 classification
- reason for the change
- supporting evidence
- contradictory evidence
- remaining uncertainty
- condition that would change the classification again

Step 11: Select ICP v0.3

Produce:

- one primary ICP
- one narrow beachhead
- justified Yellow experiments
- explicit Red exclusions

Express the revised ICP as:

“[Economic buyer] at [specific organization in a demonstrated operating state] who is experiencing [verified recurring pressure], usually after [observable trigger], and currently spends [money, labor or delay] on [existing workaround]. They purchase the product to achieve [measurable outcome] through [repeatable initial use case]. Pilot evidence indicates value can be demonstrated within [observed time] when [required prerequisites] are present.”

Also specify:

- daily user
- champion
- economic buyer
- approvers and blockers
- verified problem
- trigger
- current workaround
- existing expenditure
- initial offer
- sustainable pricing hypothesis
- onboarding requirements
- activation event
- value event
- time-to-value range
- measurable outcome
- support requirements
- retention hypothesis
- expansion hypothesis
- qualification signals
- disqualification signals

Assign one status:

- `hypothesis`
- `interview-supported`
- `pilot-supported`
- `provisionally-repeatable`

Do not use `validated` unless there is sufficient evidence of repeat purchasing, retention and sustainable economics beyond the pilot period.

Step 12: Establish readiness for ICP v1.0

Determine what remains unproven, especially:

- recurring willingness to pay
- renewal at sustainable pricing
- continued usage without pilot supervision
- retention across a meaningful period
- repeatable acquisition
- repeatable onboarding
- stable delivery cost
- sustainable gross margins
- expansion
- churn reasons
- performance across a larger cohort

Create the smallest next-stage plan required to reach ICP v1.0.

Specify:

- target customer count
- target segment
- standard offer
- standard price
- maximum discount
- standardized onboarding
- activation threshold
- time-to-value threshold
- customer-outcome threshold
- maximum founder involvement
- maximum implementation and support hours
- renewal threshold
- retention measurement period
- gross-margin requirement
- expansion signal
- confirmation condition
- falsification condition

Deliverables

Preserve all v0.1 and v0.2 files.

Create:

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

Include:

- executive conclusion
- pilot-cohort inventory
- cohort limitations
- pilot-integrity audit
- funnel and outcome metrics
- comparison with v0.2 thresholds
- customer-value analysis
- commercial-quality analysis
- delivery-cost analysis
- repeatability analysis
- successful, failed and declined pilot evidence
- v0.2 assumption audit
- segment rescoring
- Red/Yellow/Green changes
- primary ICP v0.3
- beachhead ICP
- disqualifiers
- strongest falsification argument
- unresolved unknowns
- readiness plan for ICP v1.0

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

Include:

- version: 0.3
- status
- based_on
- evidence_cutoff_date
- confidence
- pilot_count
- paid_pilot_count
- completed_pilot_count
- successful_pilot_count
- 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
- pricing_hypothesis
- activation_event
- value_event
- time_to_value
- value_metrics
- implementation_requirements
- support_requirements
- delivery_costs
- repeatability_status
- retention_hypotheses
- expansion_hypotheses
- green_segments
- yellow_segments
- red_segments
- confirmed_assumptions
- contradicted_assumptions
- untested_assumptions
- new_findings
- pilot_evidence
- negative_evidence
- cohort_limitations
- unknowns
- v1_readiness_plan
- confirmation_conditions
- falsification_conditions

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

Append:

- what changed from v0.2 to v0.3
- why it changed
- supporting pilot evidence
- confidence change
- segments promoted or demoted
- pricing and delivery discoveries
- questions still unresolved

Do not alter previous changelog entries.

Boundaries

- Do not overwrite ICP v0.1 or v0.2.
- Do not modify application code.
- Do not treat signing as payment.
- Do not treat payment as activation.
- Do not treat activation as value.
- Do not treat pilot success as retention.
- Do not infer LTV from short-term pilot evidence.
- Do not hide failed, declined or abandoned pilots.
- Do not allow one bespoke success to define the ICP.
- Do not ignore discounts, refunds, credits or concessions.
- Do not exclude founder time from delivery cost.
- Do not move success criteria after observing results.
- Do not treat feature requests as expansion evidence.
- Do not expose unnecessary confidential customer information.
- Preserve uncertainty rather than manufacturing confidence.

Done when

- Every paid, declined, failed and incomplete pilot has been inventoried.
- Payment, activation, value and continuation are reported separately.
- Pilot results are compared with the v0.2 thresholds.
- Founder labor, customization and delivery costs are visible.
- Every v0.2 assumption has been audited.
- All segments have been rescored.
- Red/Yellow/Green changes are explicit.
- One primary ICP v0.3 and one beachhead have been selected.
- The final ICP is traceable to verified pilot evidence.
- Remaining retention and economic unknowns are explicit.
- A measurable plan exists for reaching ICP v1.0.
- All deliverables are complete and internally consistent.