GTM strategy · v0.1
icp-v0.1: inferred from codebase
An autonomous, evidence-backed prompt for reconstructing an implemented product’s strongest initial Ideal Customer Profile from its codebase.
Created by Charlie Greenman · Standalone prompt
Produces
- An evidence-backed ICP report at docs/gtm/icp.md
- A machine-readable ICP hypothesis at docs/gtm/icp.yaml
- Competing segment scores, falsification tests, and explicit Red / Yellow / Green boundaries
Open prompt guide
Goal
Analyze this complete codebase and create the strongest evidence-backed Ideal Customer Profile for the implemented product.
Treat the repository as a fossil record of the customer the product was designed to serve. Reconstruct that customer from the actual implementation, compare several plausible ICPs, select the strongest initial ICP, and clearly identify what still requires market validation.
Complete the analysis autonomously. Do not stop to ask clarifying questions. When evidence is missing, make the narrowest reasonable inference, label it appropriately, and record the unknown.
Do not modify application code.
Repository inspection
Begin by reading all applicable AGENTS.md files and repository guidance.
Inspect the repository broadly, including:
- README and product documentation
- routes, pages, navigation and UI copy
- onboarding and first-run experience
- primary user journeys
- API endpoints and schemas
- database models and relationships
- authentication, permissions and organizational structures
- integrations and external services
- billing, pricing and feature-gating logic
- analytics events and telemetry
- tests, fixtures and example data
- deployment and infrastructure configuration
- Git history and frequently changed areas
- TODOs, issues, roadmap files and decision records available locally
- support, interview, CRM, usage or customer-research data included in the repository
Do not rely primarily on the README. Treat implemented behavior, user flows, data models, tests and integrations as stronger evidence than aspirational descriptions.
If web access is available, it may be used only to identify existing alternatives, market terminology and observable qualification signals. Keep external market evidence separate from repository evidence.
Evidence standard
Label every material claim as:
- PROVEN: Directly demonstrated by implementation, documentation or actual repository data.
- INFERRED: Reasonably implied by multiple pieces of repository evidence.
- UNKNOWN: Cannot be determined without customer, usage, financial or market evidence.
Cite relevant file paths, routes, symbols, schemas, tests or commits for every important PROVEN or INFERRED claim.
Never present an inference as a verified customer fact.
Step 1: Reconstruct the product
Determine:
- What the product actually enables.
- Its primary value-producing workflow.
- The user’s starting state before using it.
- The inputs, access and integrations it requires.
- The concrete output it produces.
- The business or operational result that output could create.
- What must already be true about a customer for the product to work.
- What level of technical, organizational or process maturity it assumes.
- The smallest existing workflow that could demonstrate meaningful value.
- Which capabilities appear central versus incidental.
- Which parts of the product have received the most implementation effort.
Distinguish between:
- features
- user capabilities
- operational outcomes
- economic outcomes
Do not describe features as benefits without explaining the causal connection.
Step 2: Identify the economic job
Determine:
- What expensive, slow, risky, frustrating or revenue-producing work the product affects.
- How frequently the problem likely occurs.
- Who experiences the problem directly.
- Who would use the product.
- Who would champion its adoption.
- Who would control the budget.
- Who could block adoption.
- What the customer probably does today instead.
- What triggering event would make the status quo intolerable.
- What measurable result could justify purchasing the product.
- Why the problem might be urgent now rather than someday.
Explicitly distinguish the user, champion, buyer and approver. Do not assume the builder or daily user controls the budget.
Step 3: Conduct a Product–Market Alignment Audit
Reconstruct three potentially different customer definitions:
1. Intended customer
- Who the founders, documentation, terminology and original architecture appear to envision.
- What problem the product was originally designed to solve.
- What assumptions the product makes about this customer.
2. Implemented customer
- Who the current workflows, UX, permissions, integrations and data structures best support today.
- Which customer can obtain value with the least customization.
- Which customer would encounter excessive adoption or implementation friction.
3. Economically validated customer
- Who buys, activates, obtains the intended outcome, retains, expands and remains profitable to serve.
- Use actual billing, product-usage, retention, customer or support data only if it exists in the repository.
- If this data is unavailable, classify economic validation as UNKNOWN and specify exactly what evidence is needed.
Do not automatically privilege founder intent, current implementation or current buyers.
Identify where the intended, implemented and economically validated customers align and where they conflict.
A customer purchasing the product is not sufficient evidence of ICP fit. Where data is available, distinguish:
- ease of closing
- successful activation
- time to value
- usage intensity
- realized outcome
- retention
- expansion
- implementation burden
- support burden
- gross-margin potential
- roadmap distortion
- strategic reference value
Step 4: Generate competing ICP hypotheses
Generate between three and five meaningfully different ICP candidates.
Do not create superficial variations based only on company size. Each candidate should represent a different operating condition, painful job, buyer or triggering event.
For each candidate specify:
- organization type
- operating state
- likely company or team maturity
- daily user
- champion
- economic buyer
- recurring painful job
- triggering event
- current workaround or alternative
- reason the problem is consequential
- reason the customer might act now
- observable qualification signals
- technical and organizational prerequisites
- likely budget source
- smallest initial use case
- expected time to value
- measurable success outcome
- retention mechanism
- expansion path
- adoption friction
- support or implementation burden
- potential roadmap distortion
- disqualifiers
- repository evidence
- assumptions requiring external validation
Avoid generic profiles such as:
- developers
- startups
- small businesses
- enterprise companies
- SaaS companies
- companies interested in AI
The ICP must be narrow enough to identify a concrete list of testable organizations.
Step 5: Score the candidates
Score every candidate from 1–5 on:
- severity of the problem
- frequency of the problem
- urgency created by a trigger
- evidence of an existing workaround or expenditure
- fit with the implemented product
- technical readiness
- time to demonstrated value
- reachability of the buyer
- clarity of the budget owner
- activation likelihood
- retention potential
- expansion potential
- implementation and support burden
- gross-margin potential
- risk of roadmap distortion
- strength of repository evidence
Explain every score. Do not allow theoretical TAM, company prestige, company size or ease of closing to dominate the decision.
A segment that is easy to close but unlikely to activate, retain or succeed should score poorly.
Step 6: Attempt to falsify each candidate
For every candidate, ask:
- Why might this customer not care?
- Is the problem painful or merely interesting?
- Does the user have authority or budget?
- Could an existing workaround be sufficient?
- Does the product require too much behavioral or technical change?
- Would the segment require substantial custom development?
- Is this a repeatable customer or a consulting engagement?
- Could the product be solving a technical novelty rather than an economic problem?
- What evidence would disprove this ICP?
- What would have to be true for this segment to become attractive?
Prefer the candidate that survives falsification, not the candidate with the most imaginative upside.
Step 7: Apply Red / Yellow / Green classification
Classify every segment:
GREEN — Core ICP
- Strong product and problem fit.
- Serious, recurring and economically meaningful problem.
- Can obtain value from the current product without substantial customization.
- Identifiable buyer, budget and trigger.
- Strong expected activation, retention and expansion.
- Appropriate for proactive product, marketing and sales investment.
YELLOW — Experimental periphery
- Plausible fit but important assumptions remain unvalidated.
- May be accepted through inbound or tested through a controlled experiment.
- Must have a stated hypothesis, success criteria, resource limit and expiration condition.
- Must not influence the core roadmap until validated.
RED — Do not pursue
- Weak problem fit or missing prerequisites.
- Excessive implementation, support or customization burden.
- High likelihood of churn, poor outcomes or roadmap distortion.
- May produce short-term revenue but is unlikely to become a repeatable and profitable customer.
- Should not receive proactive sales or marketing effort.
For every classification explain:
- why it received that color
- supporting repository evidence
- missing market evidence
- what would cause the classification to change
Treat company size, geography, industry and role as useful filters, not as the foundation of the ICP. Prefer operating conditions, recurring pressures and observable triggers.
Step 8: Select the primary ICP
Select:
- one primary GREEN ICP
- one narrower beachhead within that ICP
- any justified YELLOW experiments
- explicit RED disqualifications
Express the primary ICP in this format:
“[Economic buyer] at [specific organization in a particular operating state] who is experiencing [recurring consequential pressure], usually after [observable trigger], and currently relies on [workaround]. The product helps them achieve [measurable outcome] through [smallest initial use case], without requiring [important avoided cost or change].”
Then provide:
- a one-sentence positioning statement
- the initial offer
- the smallest paid or concierge pilot
- the value metric
- the expected proof of value
- the best observable prospecting signals
- why this segment should retain
- why this segment might expand
- why adjacent segments should not yet be pursued
Step 9: Produce a validation plan
Identify the most important facts the codebase cannot establish.
For each unknown provide:
- why it matters
- the evidence needed
- the fastest reasonable validation method
- confirmation criteria
- falsification criteria
Create a validation plan containing:
- customer interview targets
- questions about actual past behavior
- questions about current expenditure and workarounds
- observable external signals
- a concierge or paid-pilot offer
- success metrics
- evidence that would promote a YELLOW segment to GREEN
- evidence that would demote a GREEN hypothesis to YELLOW or RED
Do not use compliments, survey enthusiasm, clicks or hypothetical willingness to buy as primary validation. Prefer commitments such as providing workflow access, supplying real data, introducing a decision-maker, agreeing to a pilot or paying.
Deliverables
Create the following files:
1. `docs/gtm/icp.md`
Include:
- implemented-product reconstruction
- evidence table
- Product–Market Alignment Audit
- competing ICP comparison
- scoring matrix
- falsification analysis
- Red/Yellow/Green classifications
- primary ICP
- beachhead ICP
- positioning and initial offer
- disqualifiers
- major unknowns
- validation plan
2. `docs/gtm/icp.yaml`
Use a structured, machine-readable format containing:
- version
- status
- confidence
- primary_icp
- beachhead_icp
- organization
- operating_state
- users
- champion
- economic_buyer
- approvers
- painful_jobs
- triggering_events
- current_alternatives
- prerequisites
- qualification_signals
- value_proposition
- initial_use_case
- value_metrics
- retention_mechanisms
- expansion_paths
- disqualifiers
- yellow_segments
- red_segments
- repository_evidence
- assumptions
- unknowns
- validation_experiments
- confirmation_conditions
- falsification_conditions
Use `status: hypothesis` unless actual customer outcome and economic evidence in the repository justifies a stronger status.
Boundaries
- Do not modify application code.
- Do not invent customers, revenue, retention, demand or willingness to pay.
- Do not confuse easy-to-close customers with ideal customers.
- Do not confuse the founder’s intended customer with a validated customer.
- Do not define the ICP primarily through demographics.
- Do not optimize for CAC or initial revenue without considering activation, outcomes, retention, expansion and cost to serve.
- Do not recommend a broad ICP merely because multiple segments could theoretically use the product.
- Flag segments that could generate attractive short-term revenue while damaging long-term product alignment.
- Treat YELLOW segments as controlled experiments, not permission to pursue everyone.
- Preserve uncertainty instead of manufacturing confidence.
Done when
- The repository has been inspected broadly.
- Every important claim is labeled PROVEN, INFERRED or UNKNOWN.
- Every PROVEN or INFERRED product claim cites repository evidence.
- At least three competing ICPs have been evaluated and falsified.
- One primary ICP and one narrow beachhead have been selected.
- Red, Yellow and Green boundaries are explicit.
- The final ICP is specific enough to produce a list of 25 testable organizations.
- The result clearly distinguishes what the codebase demonstrates from what the market must still validate.
- Both deliverable files are internally consistent and complete.