Windsurf + Aider targets, MCP server, and demo placement (#33)
Broadens both reach (more tools) and content types (an MCP server), continuing the multi-platform story. Windsurf + Aider: - build-exports.mjs gains two platforms: exports/windsurf/*.md (workspace rules, trigger: model_decision) and exports/aider/*.md (conventions for `aider --read`). Now 5 platforms (ChatGPT, Gemini, Cursor, Windsurf, Aider). - install.sh + bin/cli.mjs install both (windsurf -> .windsurf/rules, aider -> .aider/skills with a --read hint); generated README index is excluded from copies. - One-line windsurf-install.sh / aider-install.sh wrappers for parity. MCP server (new content type): - mcp/server.mjs — zero-dependency stdio MCP server exposing list_skills, search_skills, get_skill. Published as a second bin (pm-claude-skills-mcp). Logs to stderr; reads bundled skills/ at startup. mcp/README.md documents client config. Also: README hero "See it in action" demo placement (ready to swap in a GIF; recording guide in web/docs-assets/README.md), Works-With table + exports + install docs updated, CHANGELOG Unreleased. package.json files/bin updated. Claude-Session: https://claude.ai/code/session_016JWn5jRD5tcEFKrubjQ6Px Co-authored-by: Claude <noreply@anthropic.com>
This commit is contained in:
mohitagw15856
GitHub
@@ -0,0 +1,87 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Structure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan."
|
||||
---
|
||||
|
||||
# Ambiguity Resolver Skill
|
||||
|
||||
Turn vague briefs and half-formed opportunities into structured, actionable problem statements — so you can reply with clarity instead of asking for three more meetings.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The vague brief or opportunity description** (even a single sentence is enough)
|
||||
- **Who asked for this** (stakeholder context shapes the framing)
|
||||
- **Known constraints** (timeline, budget, team size — if any are known)
|
||||
|
||||
## Three-Stage Process
|
||||
|
||||
### Stage 1: Reframe
|
||||
- Restate the vague input as 3-5 explicit questions that need answering
|
||||
- Identify the unstated assumptions hidden in the brief
|
||||
- Surface the real decision this feeds into (what will someone do differently once this is resolved?)
|
||||
|
||||
### Stage 2: Scope
|
||||
- Define what is explicitly IN scope
|
||||
- Define what is explicitly OUT of scope (equally important)
|
||||
- Identify the deadline pressure: is this urgent/important, important/not urgent, or unclear?
|
||||
- Name who owns the final decision and who needs to be consulted
|
||||
|
||||
### Stage 3: Action
|
||||
- Define the minimum viable research: 2-3 activities maximum that would give enough signal to move forward with confidence
|
||||
- Time estimate for each activity
|
||||
- What each activity would tell you (and what it wouldn't)
|
||||
- Proposed check-in point: when to regroup before committing to more
|
||||
|
||||
**Validate** — Confirm every reframed question maps to at least one research activity. Verify scope boundaries are specific enough to say "no" to something concrete.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Problem Brief: [Opportunity Area]
|
||||
|
||||
**Restated as questions:**
|
||||
1. [Question 1]
|
||||
2. [Question 2]
|
||||
3. [Question 3]
|
||||
|
||||
**Unstated assumptions we should surface:**
|
||||
- [Assumption 1]
|
||||
- [Assumption 2]
|
||||
|
||||
**In scope:** [Clear boundary]
|
||||
**Out of scope:** [Clear boundary]
|
||||
**Decision owner:** [Name/role]
|
||||
**Timeline:** [Real deadline if known, or "unclear — recommend setting one"]
|
||||
|
||||
**Minimum viable research:**
|
||||
| Activity | Time required | What it tells us | What it won't tell us |
|
||||
|----------|--------------|------------------|-----------------------|
|
||||
| [activity] | [time] | [insight] | [limitation] |
|
||||
|
||||
**Proposed check-in:** After [activity], regroup to decide whether to proceed or pivot.
|
||||
|
||||
## Example (Partial)
|
||||
|
||||
Input: *"We need to figure out what to do about our enterprise customers."*
|
||||
|
||||
**Restated as questions:**
|
||||
1. Are enterprise customers churning, underperforming on expansion, or both?
|
||||
2. Is this a product gap, a support/service gap, or a pricing/packaging issue?
|
||||
3. What does "do something" look like — a new initiative, a policy change, or a resource shift?
|
||||
|
||||
**In scope:** Enterprise accounts ($50K+ ARR) showing declining health scores in the last two quarters
|
||||
**Out of scope:** SMB segment, new enterprise acquisition strategy
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not reframe the brief into questions that are still too broad to research — each reframed question must be answerable by a specific activity
|
||||
- [ ] Do not list a research activity without stating what it would tell you and what it would NOT tell you
|
||||
- [ ] Do not leave the decision owner as "leadership" or "the team" — name a specific person or role
|
||||
- [ ] Do not omit an explicit out-of-scope boundary — without it, scope will expand organically and the brief becomes meaningless
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every reframed question is specific enough to research (not "how do we improve things?")
|
||||
- [ ] Scope boundaries name something concrete that is excluded
|
||||
- [ ] Research activities are achievable within the stated timeline
|
||||
- [ ] Decision owner is identified (not "leadership" — a specific person or role)
|
||||
+72
@@ -0,0 +1,72 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Monitor competitor signals and surface strategic implications for your roadmap. Use when asked to monitor competitors, track the competitive landscape, produce a competitive briefing, or understand what has changed in the market this week or month. Produces a structured intelligence brief with high/medium/low priority signals, roadmap implications, and a strategic landscape summary."
|
||||
---
|
||||
|
||||
# Competitive Intelligence Monitor Skill
|
||||
|
||||
Turn scattered competitor updates into structured weekly intelligence — not just "what they did" but "what changed since last week and what it means for us."
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Competitors to monitor** (list of company names)
|
||||
- **Your current roadmap or strategic priorities** (to assess relevance of signals)
|
||||
- **Previous brief or last run summary** (for diff mode — what's new vs. last time)
|
||||
- **Time period** (this week, this month)
|
||||
|
||||
## Signal Categories to Monitor
|
||||
- **Product signals:** New features, removals, UX changes, beta programmes
|
||||
- **Pricing signals:** Changes to tiers, free limits, enterprise terms
|
||||
- **Hiring signals:** Job postings revealing strategic bets
|
||||
- **Partnership signals:** Integrations, acquisitions, ecosystem moves
|
||||
- **Messaging signals:** Changes in positioning, audience, value proposition
|
||||
|
||||
## Process
|
||||
|
||||
### First Run (Full Report)
|
||||
1. For each competitor provided, scan all five signal categories
|
||||
2. Categorise each signal found
|
||||
3. Assess: reactive (responding to market) or proactive (setting direction)?
|
||||
4. Rate threat level: High / Medium / Low / Watch
|
||||
5. Connect each signal to a specific item on the provided roadmap
|
||||
6. Recommend response: Accelerate / Deprioritise / Monitor / Investigate
|
||||
7. **Validate** — Every High signal must have a specific recommended action and owner. "Monitor" is only acceptable for Low and Watch ratings.
|
||||
|
||||
### Subsequent Runs (Diff Only)
|
||||
1. Compare current signals against previous run summary
|
||||
2. Output ONLY what is new or changed since last run
|
||||
3. Flag if a previously Low signal has escalated to High
|
||||
4. Keep output under 300 words — brevity is the point
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Competitive Intelligence Brief — [Date]
|
||||
**New Since Last Run:** [n signals]
|
||||
|
||||
#### 🔴 High Priority
|
||||
**[Competitor]:** [Signal] → [Implication] → [Recommended action + owner]
|
||||
|
||||
#### 🟡 Watch
|
||||
**[Competitor]:** [Signal] → [Why it matters now]
|
||||
|
||||
#### ✅ No Change
|
||||
[Competitors with no new signals this week]
|
||||
|
||||
**This Week's Strategic Summary:**
|
||||
[2 sentences max — what is the overall competitive landscape doing?]
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not mark a signal as Low priority simply because it is new and unfamiliar — unknown competitive moves often deserve investigation before dismissal
|
||||
- [ ] Do not provide "monitor" as the recommended response for a High-priority signal — High signals require a specific action with a named owner
|
||||
- [ ] Do not include signals from competitors that are not relevant to the stated roadmap or strategic priorities — noise reduces the brief's usefulness and trains the team to ignore it
|
||||
- [ ] Do not produce a diff-mode brief that is longer than the full report — if the diff output exceeds 300 words, it is a full report, not a diff
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every High-priority signal has a specific response action and owner
|
||||
- [ ] Signals are categorised (not just listed as "they did X")
|
||||
- [ ] Roadmap connections are specific (not "generally relevant")
|
||||
- [ ] Diff mode output is under 300 words
|
||||
- [ ] Strategic summary describes the landscape trend, not just repeats individual signals
|
||||
@@ -0,0 +1,60 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Analyse competitor moves and translate them into strategic implications for your product roadmap. Use when a competitor announces a new feature, pricing change, partnership, or strategic shift, or when producing a periodic competitive intelligence report. Produces a categorised signal analysis with reactive-vs-proactive assessment, threat ratings, specific roadmap implications, and recommended responses with owners."
|
||||
---
|
||||
|
||||
# Competitor Signal Tracker Skill
|
||||
|
||||
Turn scattered competitor information into structured strategic intelligence — not just "what they did" but "what it means for us."
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Competitor name(s)** and the signals/updates to analyse
|
||||
- **Your product's current roadmap or strategic priorities** (to assess relevance)
|
||||
- **Time period** the signals cover (this week, this month, etc.)
|
||||
|
||||
## Signal Categories to Track
|
||||
- **Product signals:** New features, removals, UX changes, beta programmes
|
||||
- **Pricing signals:** Changes to tiers, free limits, enterprise terms
|
||||
- **Hiring signals:** Job postings that reveal strategic bets (e.g., hiring ML engineers = AI investment)
|
||||
- **Partnership signals:** Integrations, acquisitions, ecosystem moves
|
||||
- **Messaging signals:** Changes in positioning, target audience, value proposition
|
||||
|
||||
## Process
|
||||
1. For each competitor update provided, categorise the signal type
|
||||
2. Assess: Is this reactive (responding to market) or proactive (setting direction)?
|
||||
3. Rate strategic threat level: High / Medium / Low / Watch
|
||||
4. Connect to your roadmap: does this accelerate, validate, or challenge any of your bets?
|
||||
5. Recommend a response: Accelerate existing initiative / Deprioritise / Monitor / Investigate further
|
||||
6. **Validate** — Confirm every High threat has a specific recommended response with an owner. "Monitor" is not an acceptable response for High-rated threats.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Competitive Intelligence Report — [Date]
|
||||
|
||||
#### [Competitor Name]
|
||||
**Signal:** [What they did]
|
||||
**Signal Type:** [Product / Pricing / Hiring / Partnership / Messaging]
|
||||
**Reactive or Proactive:** [assessment]
|
||||
**Threat Level:** [High / Medium / Low / Watch]
|
||||
**Implication for Us:** [Specific connection to our roadmap or strategy]
|
||||
**Recommended Response:** [Action + owner + timeline]
|
||||
|
||||
#### Strategic Summary
|
||||
[2-3 sentences on the overall competitive landscape shift this period]
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not rate a signal as High threat without explaining the specific roadmap item or customer segment it threatens — unjustified threat ratings lose credibility over time
|
||||
- [ ] Do not treat a hiring signal as definitive proof of a strategic bet — hiring signals require corroboration from product, messaging, or pricing signals before acting on them
|
||||
- [ ] Do not conflate a competitor's announcement with a competitor's shipped capability — press releases and blog posts often describe aspirations, not production features
|
||||
- [ ] Do not recommend "accelerate existing initiative" for every High signal — sometimes the right response is to differentiate harder in an adjacent area rather than race the competitor directly
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every signal is categorised (not just described)
|
||||
- [ ] Threat level is justified — not assigned arbitrarily
|
||||
- [ ] High-threat signals have specific recommended responses (not "monitor")
|
||||
- [ ] Implications connect to specific roadmap items or strategic bets
|
||||
- [ ] Strategic summary gives a landscape-level view, not just a list of individual signals
|
||||
@@ -0,0 +1,68 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Transform detailed product updates into concise executive briefings. Use when asked to write an executive update, leadership update, product update for the exec team, or a C-suite product briefing. Produces a structured 250-word briefing with headline, key metrics, progress, risks, decisions needed, and next steps."
|
||||
---
|
||||
|
||||
# Executive Update Skill
|
||||
|
||||
Produce a stakeholder update that busy executives will actually read — structured around what they care about: decisions, risks, and numbers.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product update or notes** (raw input to transform — even bullet points work)
|
||||
- **Audience** (CEO, board, specific exec, or general leadership)
|
||||
- **Period** (this week / sprint / month / quarter)
|
||||
- **Key metrics** (what numbers matter to this audience)
|
||||
|
||||
## Executive Communication Principles
|
||||
- Lead with the headline, not the context
|
||||
- Every update should answer: "So what does this mean for the business?"
|
||||
- Flag decisions needed clearly — don't bury asks in paragraphs
|
||||
- Be honest about risks — executives hate surprises more than bad news
|
||||
|
||||
## Process
|
||||
1. Read the full product update provided
|
||||
2. Identify: key metric movements, decisions required, risks to flag, wins to celebrate
|
||||
3. Write in reverse pyramid style — most important first
|
||||
4. Limit to 250 words maximum for the main body
|
||||
5. Add a "Decisions Needed" section with clear options and your recommendation
|
||||
6. **Validate** — Confirm every decision needed has a specific option and recommendation (not just "TBD"), and every risk has a mitigation or watch plan
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Product Update — [Date / Sprint / Month]
|
||||
**Headline:** [One sentence on the most important thing]
|
||||
|
||||
**By the Numbers:**
|
||||
- [Metric 1]: [value] ([vs. target / last period])
|
||||
- [Metric 2]: [value] ([vs. target / last period])
|
||||
- [Metric 3]: [value] ([vs. target / last period])
|
||||
|
||||
**Progress This Period:**
|
||||
[3-4 bullet points, outcome-focused not activity-focused]
|
||||
|
||||
**Risks & Watch Items:**
|
||||
[2-3 bullets — be direct, include mitigation]
|
||||
|
||||
**Decisions Needed:**
|
||||
1. [Decision] — Options: [A] or [B] — Recommendation: [your view] — Needed by: [date]
|
||||
|
||||
**What's Next:**
|
||||
[2-3 bullets on next period priorities]
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Whole update is under 250 words (if not, cut ruthlessly)
|
||||
- [ ] Every metric includes a comparison point (vs. target or last period)
|
||||
- [ ] Every risk has a mitigation or watch action
|
||||
- [ ] Every decision needed has at least two options and a recommendation
|
||||
- [ ] Written for a CFO or CEO — no jargon, all outcomes
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not lead with context or background — executives read the headline first; bury the important thing below two sentences of setup and they will miss it
|
||||
- [ ] Do not present metrics without a comparison point — a number without context (vs. target, vs. last period) cannot be interpreted and will prompt follow-up questions
|
||||
- [ ] Do not soften or spin risks — executives rely on these updates to make resource and escalation decisions; sanitised risk sections destroy the update's utility
|
||||
- [ ] Do not present a "Decisions Needed" item without a recommendation — asking an executive to decide without your view forces them to do the analytical work the PM should have done
|
||||
- [ ] Do not exceed 250 words in the main body — length signals the author has not done the compression work; every word over 250 reduces the chance the update is read
|
||||
+68
@@ -0,0 +1,68 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Map stakeholders for a product decision and produce a tailored influence strategy with talking points. Use when asked to get alignment, build consensus, get buy-in from engineering or finance or legal, navigate organisational resistance, or plan stakeholder conversations for a major initiative. Produces a stakeholder map, recommended conversation sequence, and tailored talking points per stakeholder."
|
||||
---
|
||||
|
||||
# Stakeholder Influence Mapper Skill
|
||||
|
||||
Turn a product initiative into a structured influence plan — who needs to be aligned, in what order, and exactly what to say to each person in their language.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Initiative description** (what you want to do and why)
|
||||
- **List of key stakeholders** (name, role, relationship to initiative)
|
||||
- **Timeline pressure** (when do you need a decision?)
|
||||
- **Any known objections or political context** (what you're already aware of)
|
||||
|
||||
## Process
|
||||
1. Build stakeholder map with: role, primary concern, decision authority (blocker / influencer / informed), current stance (supportive / neutral / resistant / unknown)
|
||||
2. Identify the critical path of conversations — who must be won before others
|
||||
3. For each stakeholder, lead with their concern, not your ask
|
||||
4. Prepare one likely objection per stakeholder and a prepared response
|
||||
5. Flag any stakeholders who should NOT be approached until others are aligned
|
||||
6. **Validate** — Confirm every "blocker" stakeholder has a specific tactic (not just "have a conversation"), and that the sequence accounts for political dependencies
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Stakeholder Map: [Initiative Name]
|
||||
|
||||
| Stakeholder | Role | Primary Concern | Authority | Current Stance |
|
||||
|-------------|------|-----------------|-----------|----------------|
|
||||
| [name] | [role] | [concern] | [type] | [stance] |
|
||||
|
||||
### Recommended Conversation Sequence
|
||||
1. **[Name first]** — because [reason they unlock others]
|
||||
2. **[Name second]** — once [first] is aligned
|
||||
[continue...]
|
||||
|
||||
### Talking Points by Stakeholder
|
||||
|
||||
#### [Stakeholder Name]
|
||||
**Lead with:** [Their concern, not your feature]
|
||||
**Your ask:** [One specific thing you need from them]
|
||||
**Likely objection:** [What they'll push back on]
|
||||
**Prepared response:** [How to address it without being defensive]
|
||||
**What success looks like:** [What alignment from them looks like]
|
||||
|
||||
## Notes
|
||||
- Never send the same message to all stakeholders — calibrate every time
|
||||
- Engineering leads want technical feasibility acknowledged first
|
||||
- Finance stakeholders want ROI framing before anything else
|
||||
- Legal/compliance stakeholders want risk mitigation addressed upfront
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every blocker has a specific tactic (not just "have a chat")
|
||||
- [ ] Conversation sequence accounts for political dependencies
|
||||
- [ ] Each stakeholder's talking points lead with their concern, not your agenda
|
||||
- [ ] At least one "do not approach until X is aligned" flag is considered
|
||||
- [ ] The ask from each stakeholder is a single, specific thing (not a vague "support")
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not approach high-influence blockers before aligning their sponsors — approach order determines outcome
|
||||
- [ ] Do not create talking points that lead with your agenda — always lead with the stakeholder's stated concern
|
||||
- [ ] Do not treat every stakeholder as equally important — focus depth on the decision-makers and key influencers
|
||||
- [ ] Do not omit the "do not approach until X is aligned" flags — sequencing mistakes can permanently close doors
|
||||
- [ ] Do not build the map based only on org chart position — influence often lives outside formal authority
|
||||
+77
@@ -0,0 +1,77 @@
|
||||
---
|
||||
trigger: model_decision
|
||||
description: "Generate the strategic story connecting a product roadmap to company goals in a form non-technical stakeholders can repeat. Use when asked to explain the roadmap, present strategy to leadership or the board, write the why behind the roadmap, create a narrative for all-hands, or make the roadmap tell a story. Produces a themed narrative with executive summary, progression arc, hard-question preparation, and what's-not-on-the-roadmap section."
|
||||
---
|
||||
|
||||
# Strategic Narrative Generator Skill
|
||||
|
||||
Turn a prioritised initiative list into a strategic narrative — the story that explains not just what you're building but why, why now, and why this sequence.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Prioritised initiative list** (with rough timelines)
|
||||
- **Current OKRs or strategic priorities** (1-3)
|
||||
- **Audience** (board, leadership team, all-hands, investors)
|
||||
- **Competitive or market context** (optional but improves output significantly)
|
||||
|
||||
## Process
|
||||
1. Identify 2-3 natural strategic themes from the initiative list
|
||||
2. For each theme: articulate the problem, the customer it serves, and the metric it moves
|
||||
3. Build the progression narrative: how does Q1 set up Q2? How does H1 set up H2?
|
||||
4. Write executive summary in under 100 words (the version someone can repeat)
|
||||
5. Anticipate the 3 hardest questions a sceptical board member would ask — draft answers
|
||||
6. Identify what's NOT on the roadmap and why
|
||||
7. **Validate** — Confirm every initiative maps to a theme. If an initiative is orphaned, either create a theme for it or flag it as a narrative gap.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### Product Strategy Narrative: [Period]
|
||||
|
||||
**The One-Paragraph Context:**
|
||||
[Market moment + key challenge + our response — for the CFO, not the engineer]
|
||||
|
||||
**Strategic Theme 1: [Name]**
|
||||
- The problem: [customer pain in plain language]
|
||||
- Our response: [initiatives in this theme]
|
||||
- The metric it moves: [specific and measurable]
|
||||
- Why now: [timing rationale]
|
||||
|
||||
**Strategic Theme 2: [Name]**
|
||||
[Same structure]
|
||||
|
||||
**The Progression Story:**
|
||||
[How each quarter sets up the next — this is the narrative arc]
|
||||
|
||||
**Executive Summary (under 100 words — shareable):**
|
||||
[Version someone can quote at a board meeting]
|
||||
|
||||
**Questions to Prepare For:**
|
||||
1. [Hard question] → [Prepared answer]
|
||||
2. [Hard question] → [Prepared answer]
|
||||
3. [Hard question] → [Prepared answer]
|
||||
|
||||
**What's Not on the Roadmap (and Why):**
|
||||
[2-3 items — shows strategic discipline, not just prioritisation]
|
||||
|
||||
## Tone
|
||||
- Write for a CFO, not an engineer
|
||||
- Lead with outcomes, not features
|
||||
- Every sentence should answer "so what?"
|
||||
- Avoid jargon — if you can't say it plainly, the strategy isn't clear enough yet
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Executive summary is under 100 words and can stand alone
|
||||
- [ ] Every initiative in the input maps to a strategic theme
|
||||
- [ ] Each theme has a specific, measurable metric (not "improve engagement")
|
||||
- [ ] Progression story shows causal links between quarters, not just chronological listing
|
||||
- [ ] "Not on the roadmap" section includes at least 2 items with clear rationale
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- [ ] Do not produce a narrative that lists initiatives chronologically without showing causal progression — the story must show why each phase enables the next
|
||||
- [ ] Do not use abstract strategic language that cannot be repeated by a non-technical listener — test whether someone could explain it back without the document
|
||||
- [ ] Do not omit the "what's not on the roadmap" section — what you are choosing not to do is as important as what you are doing
|
||||
- [ ] Do not set themes without measurable metrics — a theme without a metric cannot be tracked or held to account
|
||||
- [ ] Do not skip the hard questions section — preparing for objections in advance is the purpose of the narrative exercise
|
||||
Reference in New Issue
Block a user