# Asb Carol Define > Facilitates the final step of a proven ideal-customer (ICP) method: synthesizing the working files — strengths and weaknesses, honed keystones, deal-breakers, and inciting events — into CAROL.md, the crisp definition of the ideal customer. The definition leads the file, behavioral and attitudinal, never demographic unless genuinely determinative; every marker must clear the bar that Marketing can target it, Sales can qualify against it, and Product can build features to thrill it. Brief reference sections on keystones, deal-breakers, and inciting events follow, because positioning, marketing, and feature work consume them. When keystone segments diverge, the skill forces the choice of a primary rather than averaging. Load when the user has the working files and says 'define our Carol,' 'write our ideal customer profile,' or 'who is our ICP.' Do NOT load to produce the upstream files (observations through inciting events), or to write the positioning, ads, or feature plans that start FROM this definition. - Skill: `asmartbear/asb-carol-define` (Agent Skill) - Install (CLI): `npx skillmds@latest add asmartbear/asb-carol-define` - Raw SKILL.md: https://api.skillmd.com/api/skills/asmartbear/asb-carol-define/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: asmartbear (https://skillmd.com/u/asmartbear) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/asmartbear/asb-carol-define --- # 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](https://longform.asmartbear.com/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 ```markdown # Carol — > ⚠️ IN PROGRESS — review not started; begin at the definition. > (Later: "draft under review; reviewed through
." Removed > at finalization.) ## Carol - - - - ## How to recognize Carol (qualifiers and disqualifiers) Qualify toward: Disqualify away: ## Why aiming only at Carol wins the whole market ## Keystones (reference) ## Deal-breakers and anti-market (reference) ## Inciting events (reference) ## Provenance ``` ### 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.