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