Define Carol: The Ideal Customer Everything Aims At

Carol may not exist in her purest form — she is an ideal, artificially constructed from the most favorable characteristics. But she is not a fantasy: every marker in her definition is derived from what the previous steps established about who needs an extreme version of your strengths, who is disqualified by your weaknesses, and what moment turns fit into purchase. This skill assembles that definition, holds every line to an actionability bar, and writes the one file the rest of the company works from.

The mental model

The five-step derivation, completed here

1. Strengths and weaknesses — an honest accounting of who you are.
2. Keystones — customer circumstances that require an extreme version of a strength, with the segments that typify them.
3. Deal-breakers — the disqualifiers, the anti-market, and the honing qualifiers they force onto keystone segments.
4. Inciting events — what moves a keystone-fit customer from could-buy to buying-today.
5. Carol — this step: the composite of keystones, deal-breakers, and inciting events, expressed as behavioral and attitudinal characteristics a team can act on.

Beyond demographics

Traditional market descriptions — company size, geography, age, B2B-vs-B2C — usually misdescribe the target. The sitcom whose demographic profile said "women over forty-five" was meanwhile becoming a cult hit with young men who loved sharp, character-driven insult comedy; the demographic was true of the average viewer and useless for finding the next one. An email client's real target isn't a company size or a country — it's people who get hundreds of mails a day, or people with assistants who process mail, or people running systematic outbound. What defines a target market is what the best customers actually share: the shape of the keystones, deal-breakers, and inciting events. Demographics enter only when genuinely determinative — back-office software for dentists in Norway may honestly say "dentists in Norway." The test is predictive power: does the marker separate the best customers from the worst, or does it merely describe everyone politely?

A menu of non-demographic dimensions

Demographics are the lazy axes; the dimensions below are the kind that actually separate the best customers from the worst. Use the menu two ways: to test a candidate marker — "speed" is not a segment, so ask which of these it really is (an emergency-vs-deliberate trigger? a decision-cycle difference? a problem-ownership one?) — and to name the axis on which two segments diverge before deciding whether one Carol can honestly span them. These are examples, not the full universe. Treat them two ways at once: use the ones that fit the context directly, and take the rest as models for generating others of the same kind that this specific business demands — the sharpest marker is frequently a dimension no list contains. This is a starter set to prime the thinking, never a checklist to complete and never the boundary of what counts; in any given case most won't apply, and the honest answer is usually "don't know" or "don't care." (Drawn from Choosing a target market, which offers these as a primer, not an inventory.)

The person and their role

• Individual vs team — one product can face two markets; sometimes "both" (a free single-player mode hooks people, teams are where the money is — Asana, Notion).
• Role inside the company — customer-facing or inward-facing; what others expect of them.
• Title(s) — usually a variety, especially across industries or company sizes.
• Maker vs administrator — creating/making/delivering, or managing/monitoring/analyzing/reporting?
• Problem ownership — who "owns" the problem you solve; is it one role or distributed; is the problem-owner also the solution-owner?
• Technical acumen — from "engineers who argue about algorithms" to "technophobes reluctantly using devices they hate."
• Learning style — video, docs, 1:1 training, or figure-it-out; shapes onboarding, support, and marketing.

What success means to them

• Job-to-be-done success — what objective numbers they're held to; which are vital vs operational, satisfied vs maximized; what number changing would get them promoted or fired.
• Personal success — what fulfills them, what they'll tolerate friction for, what makes them advocate for you internally (their Needs Stack).
• Professional success — how they're evaluated and promoted; early- vs mid- vs late-career priorities differ regardless of company size.
• Corporate goals — revenue growth rate, revenue size, profit dollars, profit percent, market share, Rule-of-40, cost savings, GPM.

The organization

• Organization size — SMB is often bought by larger but not vice-versa; matters most selling top-down or when the org itself is the subject (e.g. HR software).
• Growth trajectory — hyper-growth, steady-state, or declining; each creates different priorities and constraints.
• Regulatory environment — how heavily regulated, and by what; drives feature needs, compliance, and risk tolerance.
• Cultural attributes — productivity vs work-life balance; ethical posture; external innovation vs internal efficiency.
• Crossing-the-Chasm phase — innovator (tinkerer), early adopter (risk for advantage), early majority (wary, needs the whole product), late majority (dragged in by pressure).
• Risk tolerance — new markets require risk-accepting customers; uncorrelated with company size.
• Tech-stack philosophy — open-source, proprietary, cloud-native, or on-prem; usually a values stance, not just a technical need.

How they buy and decide

• Budget type — fixed/annual, flexible, or find-money-when-needed; is there a threshold where the sale changes shape?
• Sales process — top-down vs bottom-up/PLG/freemium (top-down often correlates with size; bottom-up often doesn't).
• Decision cycle — hours, weeks, or quarters.
• Emergency vs deliberate — an urgent trigger (a security breach) vs a researched, compared, piloted decision.
• Business model — subscription, one-time, transaction, usage, freemium, ad-supported; dictates the metrics they care about and how they can pay.

Their tools and workflow

• Integrations — what your product must connect to (workflow, AI, to-do, project management, chat).
• Other software used daily — what characterizes their expectations and experience.
• Processes — the workflows they use or aspire to, especially where they intersect your product.
• Work style — remote/office/hybrid; time-zone-split; hours worked; synchronous vs asynchronous.
• Update cadence — frequent-incremental vs infrequent-substantial; shapes product rhythm.
• Communication culture — email-heavy, Slack-dependent, or meeting-oriented.

The keep-asking-why chain

The first answer is rarely the marker. "Our best customers worry about speed" — speed is a feature, not a segment. Ask why, and keep asking: speed → because for e-commerce, checkout speed is revenue; speed → because for media, pages-per-session is ad revenue; speed → because for B2B landing pages, a whole budget converges on a few thousand visits. The chain ends at a person: someone for whom a faster website directly increases revenue, and who can calculate the dollar value of a hundred milliseconds. That's a definition Marketing can target, Sales can qualify, and Product can build features to thrill — the bar every marker in CAROL.md must clear.

The bullseye: why only-Carol wins everyone

Targeting Carol alone feels like shrinking the market; it is the opposite. Around Carol sits a ring of customers who value most of the same trade-offs and are merely indifferent to the rest — roughly ten times as many. Around them, a far larger ring who weigh the trade-offs and, because you stated yours clearly and confidently, conclude you're their best option — up to a hundred times as many. Clear trade-offs, confidently stated, are how people actually buy; generic positioning aimed at everyone is what loses all three rings at once. If the message can't excite even Carol, it certainly won't convince anyone else. This is the strategic case the definition file states, briefly, so every reader knows why the aim is so narrow.

Diverging segments force a choice

When the honed keystones name genuinely different segments — solo shops and multi-location groups, say, wanting different things at different prices — Carol cannot be their average: a definition set at the midpoint describes nobody who exists. Sometimes the why-chain reveals a shared circumstance underneath and one Carol spans the segments honestly. When it doesn't, the user must choose the primary — informed by where the keystones concentrate, where the observed inciting events are, which segment the profit evidence favors — and the definition says plainly who was chosen and who remains a served-but-secondary market. Choosing is the user's call; refusing to choose (or hiding the choice in vague wording) defeats the exercise.

Vocabulary

• Carol — the ideal customer: a composite, possibly not existing in pure form, whose markers are all derived from the working files.
• Marker — one behavioral, attitudinal, or circumstantial characteristic in the definition; each must be targetable, qualifiable, and buildable-for.
• Qualifiers / disqualifiers — the questions and signals Sales uses to sort a prospect toward or away from Carol, drawn from keystones and deal-breakers.
• Primary segment — when segments diverge, the one Carol is defined for; the others are named as secondary, not blended in.

The definer's posture

Be clear, not clever

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

Restate references; never cite a bare token

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

Two readers, one file — definition first

CAROL.md serves a skimming human (the definition, crisp, up top) and the downstream workers and tools (the reference sections, cited, below). The definition section is register-gated by exclusion: each marker is a bare, specific characteristic — no citations, no derivation story, no "which comes from our strength in…", no hedging. Wrong: "~ Values support quality (derived from S2, though segments differ)." Right: "Runs payroll personally, nights and weekends, with no office staff." The derivation lives in the reference sections, where every keystone, deal-breaker, and event carries its [K]/[D]/[E] numbers back to the working files.

Synthesize; don't re-litigate

The working files already survived their own gates — don't reopen settled classifications or re-press honed segments. The work here is assembly, compression through the why-chain, and the actionability bar. Exception: when synthesis exposes a genuine contradiction between files (a keystone segment the anti-market swallowed; an inciting event pointing at nobody), surface it as a finding and, if it requires upstream rework, say which file and stop short of editing it silently.

Press every marker through the bar

For each candidate marker, check aloud when in doubt: could Marketing target this (an ad channel, a search phrase, a list)? Could Sales qualify it in one or two questions? Could Product name a feature that thrills this person specifically? A marker failing all three is description, not definition — press it through the why-chain (testing it against the dimensions menu) or drop it. A predefined way to press harder: if a devil's-advocate interrogation skill is installed in the environment (for example Rude Q&A / asb-rude-qa, from the same author as this method), invoke it against the draft definition with this brief: attack this ideal-customer definition — find every marker that is demographic laziness, every one too generic to separate the best customers from the worst, every one that no ad could target and no salesperson could qualify, and any place two diverging segments were averaged instead of chosen. Don't accept wishful or hand-wavy defenses. If no such skill is available, run that interrogation yourself, visibly, as a review pass.

The choice is theirs; the refusal to average is not

Where segments diverge, present the evidence for each candidate primary (keystone concentration, observed events, profit signals from the strengths file's differentials) and make the user choose — one honest press if the choice contradicts their evidence, then their call stands, recorded with its reasoning. What never stands: a definition worded vaguely enough to cover both ("growing businesses that value efficiency") — that's the averaging this method exists to prevent, and it doesn't get written, however phrased.

How to use this skill

Phase A — Ingest

Read the four working files (defaults, in the current directory: STRENGTHS-WEAKNESSES.md, KEYSTONES.md, DEALBREAKERS.md, INCITING-EVENTS.md). The minimum viable input is a keystones file with honed segments plus deal-breakers; missing inciting events weaken the definition's buying-moment section (say so; the section notes the gap); missing strengths/weaknesses weakens the trade-offs framing. If even the minimum is absent, don't define from vibes: name the upstream steps invoke-if-installed style (the first is Observations / asb-carol-observations) and offer only a provisional sketch, clearly labeled, if the user insists. Check the keystones change log for honing; unhoned segments mean the definition inherits over-broad markers — flag it. If a CAROL.md exists: in-progress header means resume at the reviewed-through pointer; complete means ask whether to revise.

Output: CAROL.md in the same directory. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current directory) — never scatter files silently.

Phase B — Synthesize and draft whole

Sweep silently: cluster the honed keystone segments (do they share a circumstance, or diverge?); run the why-chain on each candidate marker; harvest qualifiers/disqualifiers from keystones and deal-breakers; pull the buying-moment material from the events file; note contradictions between files. If segments diverge, STOP drafting and run the choice with the user first — the primary decision shapes every line, so it can't wait for review — and record the decision to disk the moment it's made (a one-line CAROL.md stub with the header is enough), so a died session doesn't lose it. Once recorded, the choice doesn't reopen through vague re-wording ("can't it just cover both?") — refuse the averaging; offer to rerun the choice against the evidence if the user genuinely wants to switch primaries.

Then write the complete draft to disk with the in-progress header — the file is the memory — and present it whole for review, a section or two per exchange, top-to-bottom in file order (the reviewed-through pointer assumes that order; a resumed session relies on it). Keep the pointer current on disk after each pass. Before finalization, run the devil's-advocate press (delegated or self-run, per the posture) as a visible review pass over the definition — not silently. Corrections of fact go against the working files (the files win over memory — a resumed session re-reads them for exactly this reason); wording and emphasis are the user's; markers move only through the bar. When a review comment implies an upstream file is wrong (an anti-market segment recast as secondary, an event's status remembered differently), the same rule as synthesis contradictions applies: say which file it belongs to and stop short of editing it silently — CAROL.md never quietly overrides its sources.

The file structure

# Carol — <company / project name>

> ⚠️ IN PROGRESS — review not started; begin at the definition.
> (Later: "draft under review; reviewed through <section>." Removed
> at finalization.)

<One line: synthesized from which files, as of when. If a primary
segment was chosen over others, one line naming the choice.>

## Carol

<The definition. A short prose portrait (2–4 sentences) followed by
the markers — each a bare, specific behavioral/attitudinal/
circumstantial characteristic. No citations, no derivation, no
hedging here. Numbers are welcome when they quantify a predictive
circumstance ("20 or more tipped employees" — the number IS the
keystone threshold); numbers as proxies are not ("$2M+ revenue" —
a list-building heuristic wearing a marker's clothes; press to the
circumstance it stands for).>

- <Marker: circumstance — "runs 3+ locations with staff floating
  between them">
- <Marker: behavior — "does payroll personally, Sunday nights">
- <Marker: attitude — "treats compliance as an existential risk, not
  paperwork">
- <Marker: economics — "values one prevented violation above a year
  of fees">

## How to recognize Carol (qualifiers and disqualifiers)

Qualify toward: <the one-or-two-question sorts, from the keystones —
"do you take the tip credit, and in which states?">
Disqualify away: <the anti-market signals, from the deal-breakers.>

## Why aiming only at Carol wins the whole market

<Three or four sentences: the bullseye — the ~10x ring who share her
trade-offs, the ~100x ring who weigh them and pick you because the
trade-offs were stated clearly; if the message can't excite Carol it
convinces no one. If a primary segment was chosen, name the secondary
markets that remain served-but-not-targeted.>

## Keystones (reference)

<One line each, with [K-numbers] — what circumstance requires which
strength, and the honed segment.>

## Deal-breakers and anti-market (reference)

<One line each with [D-numbers]; the anti-market statement carried
over — deliberately excluded, dissuasive ad language, no features for
the tail.>

## Inciting events (reference)

<One line each with [E-numbers] and status (observed/hypothesized) —
the buying moments, with findability in a word or two. If the events
file was missing or thin: the gap, named, with the validation path.>

## Provenance

<Which files, as of which dates/change-log states; contradictions
surfaced during synthesis and where they were sent.>

Phase C — Finalize

Finalize when every section is reviewed or the user explicitly waives the remainder. Remove the header and read the definition back one final time — it is the part everyone will quote. Close with the handoff: this file is the input to what follows — positioning speaks Carol's language, marketing buys her attention, sales qualifies against her markers, product builds what thrills her — and each reference section is where that work starts. If the definition leans on hypothesized inciting events or unvalidated hypotheses, say so: the companion customer-interview method (its first skill is asb-interview-goals, if installed) is the systematic way to test the definition against real customers — its first canonical goal is literally "What does Carol look like?"

Refusal conditions

• No upstream files. A Carol defined from vibes is a persona poster, not an instrument. Point at the method's first step; offer only a clearly-labeled provisional sketch if pressed.
• Demographic laziness. "SMBs," "millennials," "companies over $1M" don't enter the definition unless genuinely determinative — press through the why-chain to the circumstance that predicts buying, or drop the marker.
• Averaged segments. When keystone segments diverge, wording vague enough to cover both is never written. The choice is made, named, and reasoned — or the divergence is recorded as an open decision and the definition waits.
• Markers that fail the bar. A characteristic no ad can target, no salesperson can qualify, and no feature can thrill is not recorded, however true it feels.
• Doing the downstream work. Positioning statements, ad copy, homepage language, feature roadmaps — declined; the reference sections are their input, and each deserves its own session.
• Skipping the synthesis. "Just polish the persona we already have" without the working files gets the honest answer: this method derives Carol from evidence; a polish of an underived persona inherits its guesses. Offer to run the derivation against whatever files exist.