asb-carol-inciting-events

Facilitates the fifth step of a proven ideal-customer (ICP) method: mapping inciting events — the specific trigger moments that move a perfect-fit customer from could-buy-someday to buying-today. Takes a keystones file (K1, K2, … with market segments) and, when available, customer-interview findings

By asmartbear · 444 installs

npx skills add asmartbear/asb-skills --skill asb-carol-inciting-events

Source repository · Upstream listing

Inciting Events: What Makes Them Buy Today A prospect can agree the product is a great fit, the keystone is exactly what they want, there are no deal breakers, the price is fair — and still not buy. Their excuse is genuine: "we can't implement this right now; call back in nine months." The person with buying power has one to three top priorities, and you aren't one of them. What promotes you to the top is an inciting event : nobody wakes up randomly deciding today's the day to buy — something happens in their life, a moment of struggle where action must be taken. This skill maps those moments, keystone by keystone. The mental model The inciting event completes the purchase Three forces, in order: inciting events are why people buy anything (the struggle that forces action now), keystones are why they buy from you (the circumstance that makes your strength critical), and deal breakers carve off exclusions . A keystone means the customer could care about the issue; the inciting event is what raises it to a top three priority they want solved today. That is why every real inciting event couples to a keystone — an event with no keystone attached is a trigger to buy something else . The canonical pairs: the speed keystone's events were "the SEO consultant said poor performance is blocking our rankings" and "we saw the study showing faster sites convert more revenue"; the scale keystone's event was "the biggest traffic day of the year crashed the site — never again"; the security keystone's was "we got hacked, it was terrifying, we paid a consultant $300 an hour and we're still not sure it's fixed"; the support keystone's was "we called for help and were told 'all we do is keep your server powered on.'" Observed beats hypothesized — and both get marked The reliable way to identify inciting events is to ask customers what prompted them to start looking and why they chose you — ideally right after purchase, while the answer is fresh. So when interview evidence exists (a findings report, per interview debrief files, onboarding survey answers), harvest it FIRST: real trigger stories, in the customers' words, marked observed with their source. Only then work backward for the gaps, and mark those hypothesized — honest labels, because a hypothesized event is a guess wearing a plan, and the next round of customer conversations should test it. Never dress a brainstorm as evidence. The work backward lenses When hypothesizing, ask: what would compel a customer to act today , with urgency, with budget, with pre approval? Brainstorm through these lenses: Crises that force immediate action — a public breach or data loss; a critical vendor acquired or shut down; a key customer ultimatum; a lawsuit or regulatory investigation; executive turnover; a PR debacle; a competitor announcement that exposes a gap. Seasonal and recurring cycles — annual planning, fiscal year end, tax season, quarterly reviews, compliance audits, conference deadlines, the industry's peak season approaching. Strategic windows — a compliance deadline, a required certification, entering a new market, an acquisition closing, IPO prep, legacy system modernization, new funding creating budget and expectations at once. Personal life changes (for consumer and solo professional products) — becoming a parent, retiring, a health diagnosis, a death in the family, marriage or divorce, starting a business, changing jobs, graduating, buying a first home. Findability makes the file operational For each event, answer: how do you find prospects in this condition? Someone whose site was just hacked isn't searching "secure hosting" — they're searching "how to tell whether my site is hacked" and posting "Help! My site is hacked!" into the void. Findability signals include: official announcements, executive podcast appearances, product launches and press tours, changes in job postings, recurring complaints in reviews or social media, analyst reports, regulatory change notices, leadership changes, funding news — and above all, the exact phrases a person in that moment types into a search box. An event you can't detect from outside is still worth recording, but say so: it can only be exploited in messaging ("if this just happened to you…"), not targeting. Events are often split — the lawsuit half of an enforcement event is public record while the audit notice half is invisible; annotate which parts are targetable and which are messaging only. If the user asks you to research the triggers — recent regulatory changes, funding news, seasonal cycles, competitor moves — confirm them with current results from your search tools; do not rely on internal (training) knowledge, which is stale and misses this year's real events. Vivid or it doesn't advertise In advertising, the inciting event often outperforms the keystone, because it speaks to the customer's current experience — they're reacting to their circumstance, not shopping for product attributes. That only works if the event is written vividly: the specific moment, the emotion, the number. "A hacked website is a personal violation — you pay a consultant $300 an hour and still wonder if it's coming back" advertises; "customers get frustrated with their host" doesn't. Generic events ("realizes they need a better solution") are not recorded, in any form — there is always a specific moment inside a true trigger, and finding it is the work. Vocabulary Inciting event (E1, E2, …) — the specific trigger moment that moves a keystone fit customer to buy now; cites its [K number]. Observed / hypothesized — evidence status: harvested from real customer accounts (with source) vs. worked backward (to be validated). Two sanctioned shadings: "OBSERVED (from memory)" for the user's recall of a real account — genuine evidence, weaker sourcing, re confirm at validation; and a composite of repeated sales call patterns with no single account stays HYPOTHESIZED. A hypothesized event may cite supporting but not triggering evidence ("plausibility supported — not evidenced — by the June debrief's standing dread") without gaining a Source line. Findability — how prospects in the event's condition can be detected or reached from outside, including their likely search phrases. The mapper'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. Harvest before you brainstorm If interview artifacts exist — a findings report with trigger stories, per interview debrief files, exit or onboarding surveys — read them first and pull every trigger story into candidate events before hypothesizing anything — and record harvested events as they confirm, even when they belong to keystones later in the walk; E numbers run in settle order, not keystone order. The user's memory counts too ("what did your last three customers say prompted them to look?"), marked observed from memory. Only where the evidence runs out do the lenses come out. If the user has no interview evidence at all, say plainly that everything in this file will be hypothesized until customers are asked — and that asking is the validation path. Press moments into vividness When the user offers a vague trigger ("when they get fed up with their current tool"), press for the moment: fed up by what incident ? What happened that morning? What did it cost? What did they type into Google that night? 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 with this brief: attack these inciting events — find every one that's a mood rather than a moment, every one no real customer story or plausible circumstance backs, every "hypothesized" that's being treated as fact, and every findability note too vague to act on. Don't accept wishful or hand wavy defenses. If no such skill is available, run that interrogation yourself, visibly — candidates inline, the batch attack at the closing sweep. Couple every event to a keystone An event that couples to no keystone is a flag, not an entry: either it's a trigger to buy something you don't sell, or it's pointing at a keystone the earlier steps missed. Say which it looks like; if the user believes a real keystone is missing, that's a finding to take back to the keystones file — not a reason to record an orphan event. One keystone per exchange Walk the keystones in order, one per exchange; a keystone may yield one or several events. Small opening move: what was read, which keystones already have observed trigger material, then the first keystone. Compress ceremony on request, never structure. How to use this skill Phase A — Ingest Read the keystones file (default: KEYSTONES.md in the current directory — ideally already honed with deal breaker qualifiers; if the change log shows no honing, proceed but note the segments may still be over broad). Ask what customer evidence exists and read whatever is offered: a customer interview findings report, per interview debrief files, survey exports, or just the user's recall of what recent customers said prompted them. If no keystones file exists, don't map triggers for unknown targets: offer the on ramp — run the keystones step first (if a keystones skill from this method's author is installed, for example Keystones / asb carol keystones , name it), or capture a minimal keystone list in chat with the caveat that unvetted keystones yield unvetted events. If an INCITING EVENTS.md exists: in progress header means resume — and anything not in the file was never settled; re derive it from the evidence rather than reconstructing the dead session's half proposal from anyone's memory. Complete means ask whether to revise. (The presence of per interview debrief files in the question mapped format is itself evidence the interview process is in use — harvest them without asking.) Output: INCITING EVENTS.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 — Walk the keystones Open small: what you read, which keystones already carry observed trigger stories in the evidence, then the first keystone. Per keystone: 1. Harvest observed events from the evidence — the customers' own words, with source ("FINAL REPORT.md F5" / "the debrief from the June 12 interview" / "user's recall of the Meridian deal"). 2. Hypothesize the gaps through the lenses, marked as such. 3. Press each event vivid — the moment, the emotion, the number. 4. Findability — how to detect or reach someone in that condition, including their likely search phrases; if it can't be detected from outside, say so. 5. Record with [K number], evidence status, and findability; move to the next keystone. Record to the file as you go. Create INCITING EVENTS.md at the first settled event; keep the header pointer current ("Keystones walked: K1; currently on: K2"). The file is the memory, not the chat. Phase C — Sweep and close Coupling che