---
id: c10-customer-market-framing
title: Customer Market Framing
module: GROW-S10
module_slug: grow-s10-commercialization-architecture
cluster: Coordination
type: template
version: v0.1.0
status: Gate-reviewed
tier: membership
contract_role: ""
canonical_url: "https://grow.goodcombinator.ai/library/registry/c10-customer-market-framing"
download_url: "https://grow.goodcombinator.ai/library/registry/c10-customer-market-framing.md"
license: CC-BY-4.0 (proposed — owner confirmation required)
source: GROW by Good Combinator
retrieved_at: 2026-05-29
---

# Customer and Market Framing

The Customer and Market Framing template produces the ICP (Ideal Customer Profile) for a specific capability identified in `c10-capability-inventory`. It forces explicit separation between the target user (who works with the product daily), the economic buyer (who signs the contract), and the budget owner (whose line item funds it) — three roles that are frequently conflated and almost never the same person in a govtech or enterprise sale. Without this separation, go-to-market motion defaults to pitching the wrong person with the wrong message. Outputs from this template feed `c10-revenue-model-design` (pricing model selection) and `c10-gtm-architecture` (sales motion and pilot design).

## Fillable Template

```yaml
icp_id: <kebab-case, e.g., fl-special-district-clerk>
capability_ref: <capability_id from c10-capability-inventory>
version: <semver>
last_reviewed: <ISO date>

# ── Target User ──────────────────────────────────────────────────────────────
target_user:
  role: <job title or function>
  org_type: <e.g., FL special district, county municipality, AI-first consulting firm>
  day_one_pain: >
    <two to three sentences describing the specific frustration they feel before
    your product exists; cite observable symptoms — time lost, error rate,
    manual steps, compliance risk>
  current_workaround: <what they do today; be specific>
  success_state: >
    <what their day looks like after adopting the capability; must be
    measurable — cite a time saving, error reduction, or audit outcome>
  technical_sophistication: <low | medium | high>
  change_resistance: <low | medium | high>
  change_resistance_notes: <why they resist or embrace change>

# ── Economic Buyer ────────────────────────────────────────────────────────────
economic_buyer:
  role: <title; the person who can approve the purchase>
  org_type: <same or different from target_user org_type>
  primary_motivation: <cost reduction | risk reduction | revenue growth | compliance | mission>
  buying_trigger: >
    <the event or condition that causes them to start looking for a solution
    right now; e.g., audit finding, new statute, headcount freeze, grant window>
  objection_primary: <the single most common objection they will raise>
  objection_response: <how the offer defuses it; cite evidence or proof-of-value>

# ── Budget Owner ──────────────────────────────────────────────────────────────
budget_owner:
  role: <title; may be same as economic_buyer>
  budget_line: <what budget line funds this; e.g., IT/software, compliance, operations>
  budget_cycle: <fiscal year structure; when decisions lock>
  typical_spend_range_usd: <annual range for comparable tools; use (illustrative) if estimated>
  grant_funding_eligible: <yes | no | maybe>
  grant_sources: <cite program names and IDs if applicable; flag [VERIFY]>

# ── Market Sizing ─────────────────────────────────────────────────────────────
market_sizing:
  beachhead_segment: >
    <the smallest, most defensible initial wedge; enough accounts to prove
    the model without over-extending>
  beachhead_account_count: <number or range; (illustrative) if estimated>
  expansion_path: >
    <how you move from beachhead to adjacent segments after proof-of-value>
  tam_notes: >
    <rough total addressable market framing; cite primary sources if available;
    flag (illustrative) if estimated>

# ── Alternatives and Switching Friction ───────────────────────────────────────
competitive_context:
  current_alternatives:
    - name: <incumbent solution or workflow>
      why_inadequate: <specific gap your capability fills>
  switching_friction:
    - <data migration, staff retraining, contract lock-in, procurement cycle>
  moat_alignment: >
    <cross-reference to the moat_source in c10-capability-inventory; confirm
    the moat addresses the switching-friction risk>

# ── Urgency ───────────────────────────────────────────────────────────────────
urgency:
  urgency_level: <low | medium | high | critical>
  urgency_driver: >
    <what makes the buyer act now rather than later; e.g., statutory deadline,
    grant expiry, competitive pressure, recent incident>
  urgency_decay: >
    <what happens if they wait 6 months; is urgency durable or episodic>
```

## Worked Example — Stormwater Pre-Screener ICP

The following ICP targets the initial beachhead for the `stormwater-permit-prescreener` capability. All dollar figures are `(illustrative)`.

```yaml
icp_id: fl-special-district-engineer-review-reduction
capability_ref: stormwater-permit-prescreener
version: 0.1.0
last_reviewed: 2026-05-29

target_user:
  role: District Clerk / Permit Intake Specialist
  org_type: Florida independent special district (water management / community development)
  day_one_pain: >
    Receives 8–15 permit applications per week; spends 2–4 hours per application
    manually pulling the applicable FDEP rule citations, checking the parcel
    GIS layer, and deciding whether to route to engineer review or return to
    the applicant. A missed citation or a wrong route extends the review cycle
    by days and creates audit risk under FS Chapter 119 [VERIFY].
  current_workaround: >
    Paper checklist maintained in a shared drive; citations checked manually
    against the FDEP online rule viewer; routing decision made by senior clerk
    judgment.
  success_state: >
    Triage time per application drops from 2–4 hours to under 30 minutes;
    engineer-agreement rate on routing stays above 92%; FS Chapter 119 audit
    trail is machine-generated rather than manually assembled (illustrative).
  technical_sophistication: low
  change_resistance: medium
  change_resistance_notes: >
    Clerks are skeptical of AI accuracy on citations; adoption requires a
    side-by-side pilot showing the agent matches senior-clerk decisions on a
    labeled holdout set.

economic_buyer:
  role: District Manager / Executive Director
  org_type: Florida independent special district
  primary_motivation: risk reduction
  buying_trigger: >
    FDEP compliance review or an audit finding that flags inconsistent triage
    documentation; alternatively, a headcount freeze that makes manual triage
    unsustainable at current application volume.
  objection_primary: >
    "We can't have AI making compliance decisions — what if it cites the wrong
    statute?"
  objection_response: >
    The agent never makes a compliance determination autonomously. It drafts
    a triage recommendation with citations; a clerk reviews and approves before
    any applicant-facing output is emitted. The expert-review boundary defined
    in t7-risk-expert-review-plan is enforced at the HITL gate. Every action
    is logged to a FS Chapter 119-compatible audit trail.

budget_owner:
  role: District Manager (same as economic buyer in small districts)
  budget_line: Operations / administrative technology
  budget_cycle: FL fiscal year Oct 1 – Sep 30; decisions typically lock in Q4 (Jul–Sep)
  typical_spend_range_usd: "$8,000–$25,000 / year for comparable workflow tools (illustrative)"
  grant_funding_eligible: maybe
  grant_sources: >
    FL DEP Resilient Florida Program [VERIFY grant eligibility for admin tools];
    ARPA Stormwater set-aside if district has unspent allocation [VERIFY].

market_sizing:
  beachhead_segment: >
    FL independent special districts with stormwater or water management
    authority, annual permit volume 50–300 applications, staff of 3–15.
  beachhead_account_count: "20–40 districts (illustrative; FL has ~1,700 independent special districts [VERIFY])"
  expansion_path: >
    After two successful beachhead pilots with published proof-of-value
    scorecards, expand to county municipalities using FDEP delegated authority,
    then to other permit types (building, environmental resource).
  tam_notes: >
    FL alone has ~1,700 independent special districts [VERIFY]; nationwide,
    special districts number ~90,000 [VERIFY per Census of Governments].
    Not all have stormwater authority, but the compliance-moat and audit-trail
    model generalizes to any rule-bound intake workflow (illustrative).

competitive_context:
  current_alternatives:
    - name: Manual clerk checklist (shared drive / paper)
      why_inadequate: >
        No audit trail, inconsistent rule application, does not scale,
        relies on senior-clerk tenure knowledge.
    - name: Generic workflow automation (e.g., Microsoft Power Automate)
      why_inadequate: >
        No FL-specific rule awareness, no FDEP citation engine, no HITL
        gate for expert-review-required determinations.
  switching_friction:
    - Staff retraining (low — UI designed for non-technical clerks)
    - Data migration (minimal — no legacy database)
    - Procurement cycle (medium — requires district board approval for new vendors)
  moat_alignment: >
    The compliance-moat (FDEP rule layer, FS Chapter 119 audit trail, and the
    jurisdiction-specific logic encoded via t7-govtech-package) is the primary
    switching friction driver. A competitor replicates the UI in weeks;
    replicating the validated rule mapping and audit compliance takes months.

urgency:
  urgency_level: medium
  urgency_driver: >
    FDEP compliance review cycles, increasing application volume from post-
    hurricane rebuild and coastal development pressure on the 30A corridor,
    and growing clerk turnover that fragments institutional rule knowledge.
  urgency_decay: >
    Urgency is durable but not acute; buying windows open at audit findings
    and budget-cycle Q4. Pipeline must be maintained year-round rather than
    waiting for a single trigger.
```

## Usage Notes

Produce one ICP per distinct buyer segment, not one ICP per capability. A single capability may serve two segments (e.g., county government and private permitting consultants) that require entirely separate ICPs. The `icp_id` is referenced by `c10-revenue-model-design` to match pricing models to buyer types. Never conflate target_user and economic_buyer fields — the person who benefits is almost never the person who pays, and messaging that addresses only one will fail with the other. Revisit this template after every pilot: the most reliable ICP update source is a structured win/loss debrief, not internal assumption.