From pmm-execution
A self-improving pre-mortem risk engine for PMMs running cross-functional risk analysis on any strategic project. Covers: PRD, product launch, pricing change, new marketing channel, GTM pivot, new market entry. Run by a PMM facilitating cross-functional teams. Trigger on: "pre-mortem", "risk analysis", "what could go wrong", "stress-test this plan", "launch readiness", "pressure-test", "failure modes", "risks before we launch", "pre-launch review", "what are we missing", "GTM risk", "pricing risk", "market entry risk", or any request to identify, categorise, or mitigate strategic risk before a major move.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pmm-execution:pre-mortemThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A PMM-led, cross-functional pre-mortem tool.
A PMM-led, cross-functional pre-mortem tool. Not a checklist. A structured thinking system that forces teams to imagine failure before it happens — and convert that into action.
Built on Gary Klein's pre-mortem methodology. Sharpened for B2B GTM contexts. Patched from two live mock sessions. Version 2.0.0.
Before intake, check .agents/product-marketing-context.md.
If it exists — load silently. Extract:
## ICP Prioritisation → who failure would hurt most, and how## Positioning → is the strategic narrative coherent with this initiative?## Objections & Anti-Personas → pre-load as signal for demand-side risks## Revenue Levers → which lever does this target? Risk lens shifts by lever.## GTM Motion & Growth Loops → which motion is this dependent on? What breaks if it fails?## Beachhead Segment → if new market entry, flag tension against current beachhead## Marketing Advantages → are you relying on an advantage that's unproven or weak?## Product Strategy Canvas → trade-offs accepted hide risks. Read them.Confidence awareness:
If any loaded section is 🔴 Placeholder, flag before intake:
"⚠️ The [section] in your PMM context is marked Placeholder. That's the exact area where pre-mortems surface the worst surprises. Flag that assumption now — don't discover it during risk analysis."
If context file is missing:
Surface once, non-blocking:
"No PMM context found. Run
hs-product-marketing-context BUILDto make this significantly sharper. Continuing — but expect more assumption-based risks than evidence-based ones."
Cross-reference these when building or following up on a pre-mortem:
⚠️ Most users start with the wrong frame. Always run this first. Never generate risks before completing intake and reflecting back.
Ask in one conversational message:
"Before I build the risk map, a few things I need to be sharp on:
What type of initiative is this? (Product launch / Pricing change / New channel / GTM pivot / New market entry / Other)
What does success look like in 90 days? Be specific — a number, a behaviour, a deal closed.
What are the decision gates — not just the launch date? There's often more than one point of no return. Name the announcement date, but also: when does resource get committed? When does the first public signal go out? When does reversal become expensive?
Who's in the room for this pre-mortem? (PMM only / PMM + Product / full GTM / PMM + Finance / other) Note: missing Sales or CS will be flagged as a structural blind spot.
Do you have a plan document? Drop it. If not, give me 3–4 sentences on what you're doing and why."
If they share a document:
Read it fully. Extract core assumptions, timelines, and success metrics. Do not start risk analysis until you understand the plan.
If they describe verbally:
Reflect back in 3 sentences before proceeding. Ask them to correct anything wrong. This is not polish — it's assumption-surfacing.
After reflecting back the initiative, ask one additional question:
"One more: what would have to be true for this initiative to be the wrong move entirely? Not what could go wrong in execution — what would have to be true about the market, the customer, or the business for this to be a mistake regardless of how well you execute?"
If the team cannot answer clearly:
"⚠️ If the team can't articulate what would make this initiative wrong, the thesis is assumed — not validated. That's where the deepest risks live. We'll surface them in the failure frame."
This question surfaces the gap between the stated rationale and the actual thesis. Most initiatives have a thinner thesis than they present. The real reason for the initiative is often executive momentum, opportunistic signal, or competitive anxiety — not validated market demand.
Before writing the failure scenario, ask:
"What would failure unambiguously look like to your CEO or CRO? Not a bad quarter — the specific outcome that would make them say 'we shouldn't have done this.'"
Use their answer to anchor the failure scenario. Do not invent a failure scenario without this calibration. A scenario that doesn't match their definition of failure will not shift the team out of defensive optimism.
Before generating risks, run this framing exercise:
"Imagine it's [primary decision gate + 60 days]. The initiative has failed.
Not dramatically — no one got fired, no press coverage. Just: [insert calibrated failure scenario from intake].
The team is in a retrospective. One question is on the table: 'What did we know — or should have known — that we ignored?'
That's what we're surfacing right now, while there's still time to act."
⚠️ This reframe is not optional. It shifts teams from defensive optimism to honest diagnosis. Do not skip it. Do not rush through it.
Watch for the tell:
When a PMM or product lead says "honestly" before answering the failure frame, the next sentence is almost always a Tiger that was being avoided — not an Elephant.
File it as a Tiger immediately. Avoidance of a known risk is not uncertainty — it's a decision not to act.
Generate risks across five lenses. Each lens maps to a cross-functional domain. Tag every risk with its lens — untagged risks don't get owned.
Apply initiative type modifiers from Section ⑩ before generating.
For New Market Entry: run the local knowledge audit in Section ⑩ before generating Lens 1 and Lens 2 risks.
Does the market actually want this? Will the right customers find it and adopt it?
Does this make you stronger relative to alternatives — or does it expose you?
Can the go-to-market motion actually deliver this?
Is the internal machine aligned enough to execute this?
Can you tell if it worked — and fast enough to course-correct?
Classify each generated risk into one of three categories.
⚠️ Paper Tiger integrity rule: A PMM's confidence in their existing customer relationship, brand strength, or internal alignment is never sufficient evidence to classify a commercial, competitive, or perception risk as a Paper Tiger. Familiarity is not validation. Confidence is not data. If a risk is being downgraded because it feels unlikely — push back.
🔴 Elephant upgrade rule: If the team has access to the evidence needed to investigate an Elephant and has chosen not to gather it — that is avoidance, not uncertainty. Upgrade it to a Tiger immediately. Avoidance of a known unknown is a known risk.
🔴 Investigator rule: Every Elephant must have a named investigator and a due date at the moment of classification — not at the end of the session. An Elephant with no investigator automatically becomes a Tiger.
Elephant classification format (enforce at point of classification):
🐘 [Risk name]
What needs to be found out: [specific question]
Investigator: [name / function]
Due date: [specific date]
If unresolved by due date: becomes 🚨 Tiger
PMM facilitation prompt:
"What's the thing you're personally most worried about that nobody else has said out loud yet?"
That question surfaces Elephants faster than any framework.
For every Tiger, assign an urgency level:
| Level | Meaning | Action required |
|---|---|---|
| 🚨 Launch-Blocking | Must be resolved before launch. Unresolved = recommend delay. | Full mitigation plan |
| ⚡ Fast-Follow | Must be resolved within 30 days post-launch | Owner + due date now |
| 📊 Track | Monitor post-launch. Act if it materialises. | Threshold metric |
On Launch-Blocking Tigers with 🔴 mitigation confidence:
State it without softening:
"⚠️ This Tiger has no credible mitigation assigned. Launching without resolving it is a strategic bet, not a plan. This is a hard launch blocker until a credible, owned mitigation exists."
QG escalation rule:
If any Launch-Blocking Tiger carries 🔴 mitigation confidence, the PMM Recommendation cannot be 🟢 Go. It must be 🟡 Conditional Go or 🔴 No-Go. A 🔴 mitigation score on a launch blocker is not a detail — it is the recommendation.
For each Launch-Blocking Tiger, produce this format with explicit line breaks:
### 🚨 Tiger: [Risk name]
**What breaks:**
[One clear consequence per line. Not bundled prose.]
[If multiple consequences, list each on a new line.]
**Why it's real:**
[Evidence or direct reasoning — not assertion.]
[Quote the PMM if they named it directly.]
**Mitigation:**
[A deliverable, a decision, or a conversation with a named output.]
[Not "look into this." Concrete and completable.]
**Owner:**
[Function + specific person if known]
**Due date:**
[Specific date — or "before [named milestone]"]
**Confidence in mitigation:**
🟢 Credible — specific, owned, no external dependencies
🟡 Partial — plan exists but has a dependency or timing risk
🔴 Weak — vague, unowned, or not achievable before launch
If confidence is 🔴:
"⚠️ The mitigation for [Tiger name] is weak. This is an unresolved launch blocker. The PMM Recommendation will reflect this."
Deliver as formatted markdown. Emoji callouts are navigational — not decorative. Every section break represents a topic shift. Do not bundle multiple topics into a single paragraph. Line breaks between every named field in action plans.
## 🔬 Pre-Mortem: [Initiative Name]
**Type:** [Initiative type]
**Announcement date:** [Date]
**Key decision gates:**
- [Gate 1: description + date]
- [Gate 2: description + date]
**PMM facilitator:** [Name]
**Session date:** [Date]
---
### 💀 The Failure Scenario
[2–3 sentences. Specific metric. Named consequence. Named audience.
Anchored to the CEO/CRO definition of failure from intake.
Not "things went badly" — a concrete picture of what bad looks like.]
---
### 🐯 Tigers (Real Risks)
| # | Risk | Lens | Urgency | One-line summary |
|---|---|---|---|---|
| R-01 | [Name] | [Lens] | 🚨 / ⚡ / 📊 | [One sentence] |
---
### 📄 Paper Tigers (Acknowledged — Not Acted On)
| # | Risk | Why it's not a blocking risk |
|---|---|---|
| PT-01 | [Name] | [Specific reason] |
---
### 🐘 Elephants (Unspoken — Needs Investigation)
| # | Risk | What to find out | Investigator | Due date | If unresolved |
|---|---|---|---|---|---|
| E-01 | [Name] | [Question] | [Owner] | [Date] | 🚨 Tiger |
---
### 🚨 Action Plans — Launch-Blocking Tigers
[Full action plan blocks — one per Tiger, Section ⑥ format]
---
### ⚡ Fast-Follow Watch List
| Tiger | Owner | Due date | Threshold metric |
|---|---|---|---|
| [Name] | [Owner] | [Date] | [What triggers action] |
---
### 📋 PMM Recommendation
[🟢 Go / 🟡 Conditional Go / 🔴 No-Go]
[Explicit rationale.]
[If Conditional Go: the one condition, and the date it expires.]
[If No-Go: what specifically changes the recommendation.]
[If politically complex: reframe as a validation sprint — see Section ⑧.]
---
### 📊 Pre-Mortem Confidence Score
Overall readiness: 🟢 High / 🟡 Medium / 🔴 Low
**What would move the score up:**
[One specific action — not a general direction]
A pre-mortem without a recommendation is just a worry list.
The PMM has the clearest view across market, message, and motion. The recommendation must be explicit — and it must be honest.
🟢 Go
No Launch-Blocking Tigers unresolved.
Fast-follows owned and dated.
🟡 Conditional Go
One or more Launch-Blocking Tigers with a credible mitigation in progress.
State the condition:
"Go — conditional on [specific mitigation] confirmed by [date]. If not confirmed, this reverts to 🔴 No-Go automatically."
🔴 No-Go
One or more Launch-Blocking Tigers with no credible mitigation.
State it without softening:
"Not ready. The risk to [revenue / reputation / positioning] outweighs the benefit of launching on schedule. Recommend delay until [specific condition] is resolved."
A No-Go in a politically complex situation — where the initiative has executive momentum, a CEO directive, or a conference commitment — is not easy to deliver.
The pre-mortem is the cover, not the obstacle.
Frame it:
"We ran a pre-mortem. The recommendation is a [X]-day validation sprint before full launch — because that's how we make [initiative name] work, not how we slow it down.
Here's what we validate. Here's the go/no-go condition at the end of the sprint. Here's what we announce now vs. what we hold."
This reframes delay as diligence. It gives leadership a defined decision point — which is what they actually need. And it protects the PMM from being the person who said no to growth.
knowledge/INDEX.md — route to relevant initiative type folderhypotheses/active.md — check if any hypothesis can be tested todaysessions/log.md — pull prior context on this company or initiativeknowledge/[initiative-type]/knowledge.mdhypotheses/active.mdknowledge/[type]/rules.mdcraft/false-dismissals.mdsessions/log.mdSelf-Improvement Trigger format — surface before encoding, never silently:
🔁 SELF-IMPROVEMENT TRIGGER
Pattern observed:
[What I noticed across this session]
Proposed update:
[Specific change — exact wording of what would be added or changed]
Location:
[File path]
Awaiting your approval before encoding.
⚠️ Never encode without explicit user approval.
Step 1 — Unstructured prompt first. Always.
"Before I ask you three things — is there anything that came up today that you want to say out loud before we close? Anything the session surfaced that you haven't voiced yet?"
Wait for the answer. Do not rush to the structured questions. The most strategically important insight of the session usually surfaces here.
Step 2 — Three structured questions:
"1. Was there a risk that surprised you — one you hadn't considered before today?
Was there a Tiger I flagged that you think is actually a Paper Tiger?
Was there an Elephant the team already knew about but hadn't named?"
Step 3 — Propose encodes. Always explicitly:
"Here's what I'm proposing to add to the knowledge base: [List proposed Self-Improvement Triggers] Confirm before I encode?"
knowledge/ before generating. Don't resurface resolved risks.Runs after output generation. Flags before delivering — never after.
| Check | Standard | Pass = |
|---|---|---|
| Thesis interrogation | Team answered "what would have to be true for this to be wrong?" | Yes — or gap explicitly flagged |
| Failure scenario calibration | Scenario anchored to CEO/CRO definition of failure | Yes |
| Failure scenario specificity | Named metric, behaviour, or outcome — not "things went badly" | Yes |
| Decision gates | Multiple gates named, not just announcement date | Yes |
| Risk coverage | All five lenses represented | At least one risk per lens |
| Tiger credibility | Each Tiger backed by evidence or reasoning — not worry | Yes, with source stated |
| Paper Tiger integrity | Any Paper Tiger downgraded by feel rather than evidence? | No — pushback if yes |
| Elephant format | Every Elephant has: what to find out / investigator / due date / upgrade condition | Yes — at point of classification |
| Elephant upgrade check | Any Elephant where evidence accessible and team chose not to gather it? | Upgraded to Tiger |
| Launch-Blocking Tigers | Each has full action plan, Section ⑥ format, with line breaks | Yes |
| Mitigation confidence | Any 🔴 confidence flagged and escalated to PMM Recommendation | Yes |
| QG escalation | Any 🔴 mitigation on launch blocker → Recommendation is not 🟢 Go | Enforced |
| PMM Recommendation | Explicit Go / Conditional Go / No-Go with rationale | Yes |
| No-Go framing | If No-Go, reframe as validation sprint for leadership delivery | Yes |
| Confidence score | Score included with one specific uplift action | Yes |
| Output formatting | Line breaks between What breaks / Why it's real / Mitigation / Owner / Date | Yes |
| PMM context integration | Risks cross-referenced with ICP, positioning, GTM motion if context loaded | Yes |
On flag: Surface the failure. Do not deliver incomplete output.
On pass: Deliver output. Log QG: Pass in sessions/log.md.
Apply before risk generation.
| Initiative Type | Dominant Lenses | Watch especially for |
|---|---|---|
| Product Launch | Market & Customer / GTM & Execution | ICP misfit, message-market fit, sales belief gap, activation path, AI accuracy claims, conference pre-seeding |
| Pricing Change | Market & Customer / Organisational | Churn trigger, sales confidence gap, anchor disruption, existing customer framing |
| New Marketing Channel | GTM & Execution / Data & Measurement | Attribution gap, CAC assumptions, channel-ICP fit, leading indicator definition |
| GTM Pivot | Organisational / Competitive & Strategic | Sales compensation design, internal trust, resource reallocation, positioning drift, revenue disruption in transition. Note: Lens 4 is the primary lens for GTM pivots — most failures are internal, not external. Run it first. |
| New Market Entry | Market & Customer / Competitive & Strategic | Regulatory gaps, ICP translation, local competitive landscape, brand zero-base, team structural fit |
Local knowledge audit:
"Do you have anyone in this session with on-the-ground knowledge of [target market]? A customer, a partner, a local hire, a validated market study?"
If no:
"⚠️ All Market & Customer and Competitive & Strategic risks for this market entry are assumption-based — not evidence-based. Every risk in those two lenses is flagged 🔴 confidence until local validation exists."
Also check:
Every pre-mortem output saved to sessions/ carries:
_Initiative: [name]_
_Type: [initiative type]_
_Session date: YYYY-MM-DD_
_PMM facilitator: [name]_
_Announcement date: YYYY-MM-DD_
_Key decision gates: [list]_
_Confidence score: 🟢 / 🟡 / 🔴_
_QG: Pass / Fail_
_Version: N_
| Skill | When to cross-reference |
|---|---|
hs-product-marketing-context | Always — read before intake |
hs-gaccs-brief | Tiger: messaging or campaign risk surfaced |
hs-competitive-battlecard | Tiger: competitive displacement or response risk |
hs-brainstorm-okrs | Tiger: success metric ambiguity or KR design gap |
experiment-doc-builder | Elephant: assumption needs validation before launch |
hs-gtm-launch-planner | Tiger: launch sequencing or tier readiness risk |
hs-ci-stakeholder-briefing | Tiger: competitive response risk at leadership level |
Patch from Session 3 (GTM pivot mock):
Patched from two mock sessions (product launch + new market entry). 13 gaps addressed.
Structural patches:
Classification logic patches:
Craft patches:
Initial build.
npx claudepluginhub stefanoskarakasis/product-marketing-skills --plugin pmm-executionCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.