Founders often write an Ideal Customer Profile from memory: the customer they meant to serve, the last prospect who replied, or the largest company that could theoretically use the product. A working codebase offers a harder and often more useful starting point. It records the workflows, permissions, integrations, data models, and assumptions that the product actually supports.

I use three prompts to turn that evidence into a sequence of decisions. The first reconstructs an ICP hypothesis from the repository. The second asks whether a defensible market exists for it. The third prepares a 30-day sprint for collecting behavioral evidence from real buying units.

Your codebase can show who the current product appears built to serve. It cannot show who will buy, activate, or stay.

What the codebase can tell you.

Think of the repository as a fossil record of the customer the product was designed to serve. Routes reveal the jobs the product makes visible. Schemas reveal the objects and relationships it expects. Permissions reveal who can act and who must approve. Integrations reveal the surrounding stack. Tests reveal which behavior the team considers important enough to protect.

That is strong evidence of implemented-product fit. It can help distinguish the customer described in a pitch from the customer supported by the implementation. It can also expose prerequisites, likely adoption friction, and the smallest workflow capable of producing value. The later sprint still has to gate product and pilot readiness.

But repository evidence is not demand evidence. Unless the repository contains real usage, billing, retention, support, or customer-research data, it cannot prove pain severity, budget, willingness to pay, activation, or retention. The workflow below keeps that boundary explicit. 

implemented product
→ evidence-backed ICP hypothesis
→ bottom-up market audit
→ pre-registered validation sprint
→ real customer evidence

Before you run the prompts.

Open a repo-aware coding agent at the root of the complete product repository. Give it permission to read the codebase and create files under docs/gtm/. The prompts are designed not to modify application code.

Make sure the agent can inspect:

  • Product documentation, routes, onboarding, schemas, permissions, integrations, billing, tests, infrastructure, and Git history.
  • Any real usage, customer, sales, support, interview, or financial evidence that belongs in the repository and is appropriate to analyze.
  • The public web during the market-audit stage, where current external sources are required.

Begin with a clean, reviewable worktree. These prompts create a substantial evidence record. Keeping their changes separate makes it easier to inspect citations, assumptions, and generated market artifacts before accepting them.

Step one: infer the ICP from the codebase.

Start with icp-v0.1: inferred from codebase . This prompt reconstructs the implemented product, identifies its economic job, and separates three customer definitions that teams often collapse together:

  • The intended customer suggested by founder language, documentation, and original architecture.
  • The implemented customer best served by the current workflows, UX, data model, and integrations.
  • The economically validated customer supported by actual activation, outcome, retention, expansion, and cost-to-serve evidence—if that evidence exists.

The prompt generates three to five meaningfully different ICP candidates, scores them, tries to falsify each one, and assigns Green, Yellow, or Red boundaries. It requires every material claim to be labeled PROVEN, INFERRED, or UNKNOWN, with repository citations for the first two.

The result is a narrative analysis in docs/gtm/icp.md and a machine-readable hypothesis in docs/gtm/icp.yaml. The selected ICP should be narrow enough to identify 25 testable organizations. Its status should remain a hypothesis unless customer outcomes support something stronger.

Review gate one.

Check the cited files and symbols. Make sure the winning segment survived falsification instead of merely receiving the most optimistic story. Pay special attention to unknowns about the buyer, urgency, current expenditure, adoption burden, activation, and retention. Those unknowns become inputs to the next two stages.

Step two: audit the market around that ICP.

Next, run the Initial ICP market audit . It reads the two ICP artifacts and translates their operating conditions, triggers, prerequisites, qualification signals, and disqualifiers into a reproducible market definition.

This is where vague category TAM gives way to a bottom-up account census. The prompt distinguishes the structural universe from the problem-bearing population, the current-product serviceable market, the trigger-active annual market, the beachhead, the reachable market, and a capacity-constrained obtainable market.

It also forces a clean separation between customer loss, addressable expenditure, willingness to pay, and conditional vendor revenue. If price is unvalidated, account and workload counts remain the primary result. SOM is constrained by the actual sales motion, implementation capacity, activation, and retention—not an arbitrary percentage of TAM.

The audit produces:

  • docs/gtm/market.md for sources, calculations, scenarios, falsification, and the market decision.
  • docs/gtm/market.yaml for the structured market model.
  • docs/gtm/prospect-universe.csv for traceable, testable purchasing units.

Review gate two.

Inspect the counting unit, inclusion predicates, geography, source dates, overlaps, and low/base/high formulas. A public organization that matches the filters is a testable prospect, not a validated customer. The honest decision may be to pursue, pursue conditionally, narrow or reposition, or stop.

Step three: prepare the validation sprint.

Then run the Initial ICP market validation sprint . This prompt converts the ICP, market audit, and prospect universe into a pre-registered founder-led plan.

By default, it prepares a 30-day sprint across 10–15 purchasing units, with explicit founder, implementation, and pilot-capacity limits. It selects three to five critical hypotheses, screens the cohort, defines a commitment ladder, shapes the smallest commitment-bearing pilot, and establishes thresholds before results arrive.

The output includes the sprint plan, structured hypothesis system, account and evidence ledgers, pilot offer, behavioral interview guide, and account-specific outreach playbook. Payment, activation, value, conversion, retention, and expansion remain separate evidence stages.

This prompt prepares the work. It does not contact prospects, send outreach, run interviews, or conduct pilots. The founder still has to execute the plan and append real evidence.

Review gate three.

Confirm that the proposed pilot fits the current product, the selected accounts test the most important assumptions, and the decision thresholds include confirmation, inconclusive, falsification, and stopping conditions. A sprint should be able to make the team less confident, not only more confident.

Why the sequence matters.

Each stage creates the prerequisites for the next. The ICP files become the market audit's structured hypothesis. The market files and prospect universe become the validation sprint's source model. Because the artifacts remain in the repository, the reasoning is inspectable, versionable, and easier to revise as evidence changes.

More importantly, the sequence prevents three common category errors:

  • Implementation fit is not market demand. A product can serve a segment beautifully that does not care enough to change.
  • Market population is not willingness to pay. A large list of qualified accounts does not establish urgency, budget, or commitment.
  • A validation plan is not validation. Evidence appears only when real buyers share access, time, data, authority, or money—and when the product creates a measured outcome.

Run all three with one prompt.

If your coding agent can open public URLs, the wrapper below runs the complete sequence without pasting thousands of words into the initial instruction. The three linked pages remain the canonical prompts. The wrapper tells the agent to execute them, not summarize them.

One-prompt version

Run the ICP-to-validation sequence. 

You are working inside a complete product repository.

Read every applicable AGENTS.md file and repository instruction first. Then read and execute the complete canonical prompts at the following URLs, in this exact order:

1. Identify the codebase-supported ICP:
https://grnmn.com/prompts/icp-v0-1-inferred-from-codebase/

2. Audit the market for that ICP:
https://grnmn.com/prompts/initial-icp-market-audit/

3. Prepare the initial market-validation sprint:
https://grnmn.com/prompts/initial-icp-market-validation-sprint/

Treat the instructions at each URL as authoritative and complete. Do not merely summarize them.

Finish and verify each stage before starting the next. Preserve every earlier deliverable. Do not modify application code, access secrets or unauthorized data, invent customer or market evidence, conduct outreach, run pilots, or claim that the market has been validated. Use current external research only where the canonical prompts permit it.

If a URL cannot be accessed or a required stage cannot be completed safely, stop and report the exact blocker. Do not invent substitute instructions or evidence.

At the end, validate all YAML and CSV artifacts and report:

- every file created or updated
- the selected ICP and beachhead
- the market-audit decision
- the strongest unresolved assumptions
- product- and pilot-readiness status
- the exact first execution gate
- the founder's next three actions

Do not describe the resulting ICP or market as validated unless the required customer behavior has actually been observed.

If the agent cannot read the web, open each linked prompt and use its copy button instead. Run them in order and do not start the market audit until the ICP artifacts are complete.

What the sequence leaves behind. 

docs/gtm/
├── icp.md
├── icp.yaml
├── market.md
├── market.yaml
├── prospect-universe.csv
├── validation-sprint.md
├── validation-sprint.yaml
├── validation-accounts.csv
├── validation-evidence.csv
├── pilot-offer.md
├── interview-guide.md
└── outreach-playbook.md

Read these as one evidence chain, not twelve independent documents. The ICP supplies the claim, the market audit makes the claim countable, and the sprint defines what real behavior must happen next.

The output is a better question.

At the end of this workflow, you should not have a magically “validated ICP.” You should have a codebase-supported hypothesis, a sourced view of its market, a concrete set of accounts, and a disciplined way to learn whether the customer will commit and succeed.

That is a much stronger place to operate from. The claim becomes specific enough to test, the unknowns become visible, and the next action is determined by evidence rather than founder preference.