add marketplace plugin structure
This commit is contained in:
mohitagw15856
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: feature-prioritisation
|
||||
description: Applies prioritisation frameworks (RICE, MoSCoW, Kano, ICE, Opportunity Scoring) to rank features and backlog items. Use when asked to prioritise features, rank a backlog, decide what to build next, or evaluate tradeoffs. Triggers on "prioritise features", "what should we build", "backlog grooming", "RICE score", "MoSCoW".
|
||||
---
|
||||
|
||||
# Feature Prioritisation Skill
|
||||
|
||||
Apply the right prioritisation framework to any backlog and produce a clear, defensible ranking with rationale — not just a sorted list.
|
||||
|
||||
## Framework Selection Guide
|
||||
|
||||
Ask the user which framework they prefer, or recommend based on context:
|
||||
|
||||
| Situation | Recommended Framework |
|
||||
|---|---|
|
||||
| Need a quick, data-driven score | RICE |
|
||||
| Stakeholder alignment meeting | MoSCoW |
|
||||
| Understanding customer delight vs expectations | Kano |
|
||||
| Early-stage startup, fast decisions | ICE |
|
||||
| Identifying underserved customer needs | Opportunity Scoring |
|
||||
| Strategic portfolio decisions | Value vs Effort Matrix |
|
||||
|
||||
---
|
||||
|
||||
## RICE Scoring
|
||||
|
||||
**Formula:** (Reach × Impact × Confidence) ÷ Effort
|
||||
|
||||
| Factor | Definition | Scale |
|
||||
|---|---|---|
|
||||
| Reach | Users impacted per quarter | Actual number |
|
||||
| Impact | Effect on goal per user | 0.25 / 0.5 / 1 / 2 / 3 |
|
||||
| Confidence | How certain are you? | 50% / 80% / 100% |
|
||||
| Effort | Person-months required | Actual number |
|
||||
|
||||
Output table:
|
||||
| Feature | Reach | Impact | Confidence | Effort | RICE Score | Priority |
|
||||
|---|---|---|---|---|---|---|
|
||||
|
||||
---
|
||||
|
||||
## MoSCoW Method
|
||||
|
||||
Categorise each feature as:
|
||||
- **Must Have** — non-negotiable for launch/sprint; product fails without it
|
||||
- **Should Have** — important but not critical; workarounds exist
|
||||
- **Could Have** — nice to have; include only if time allows
|
||||
- **Won't Have (this time)** — explicitly out of scope now; may revisit
|
||||
|
||||
Always ask: "Must have for *what*?" — define the scope (launch, sprint, quarter) before categorising.
|
||||
|
||||
---
|
||||
|
||||
## ICE Scoring (Startup/fast mode)
|
||||
|
||||
**Formula:** Impact + Confidence + Ease (each 1–10)
|
||||
|
||||
Quick, subjective — good for early decisions before data exists.
|
||||
|
||||
---
|
||||
|
||||
## Kano Model
|
||||
|
||||
Classify features into:
|
||||
- **Basic (Must-be):** Expected; absence causes dissatisfaction
|
||||
- **Performance:** More = better satisfaction; linear relationship
|
||||
- **Excitement (Delighters):** Unexpected; creates delight; absence is neutral
|
||||
- **Indifferent:** Users don't care either way
|
||||
- **Reverse:** Some users want it, others don't
|
||||
|
||||
Recommend building: all Basic features first → Performance features for key use cases → 1–2 Excitement features per release.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Feature Prioritisation — [Product/Team] — [Date]
|
||||
|
||||
**Framework Used:** [RICE / MoSCoW / ICE / Kano / Custom]
|
||||
**Scope:** [Sprint / Quarter / Release]
|
||||
**Goal being prioritised against:** [Metric or objective]
|
||||
|
||||
[Scored table using selected framework]
|
||||
|
||||
**Recommended Build Order:**
|
||||
1. [Feature] — [1-line rationale]
|
||||
2. [Feature] — [1-line rationale]
|
||||
3. ...
|
||||
|
||||
**Explicitly Deprioritised:**
|
||||
- [Feature] — Reason: [brief]
|
||||
|
||||
**Assumptions Made:**
|
||||
- [Any estimates or judgements used in scoring]
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always anchor prioritisation to a specific goal or metric — never prioritise in a vacuum
|
||||
- Flag when two features have similar scores but very different risk profiles
|
||||
- If stakeholder politics are influencing prioritisation, name it explicitly and suggest separating the framework score from the final decision
|
||||
- Recommend revisiting priorities every 2 weeks minimum
|
||||
- Never produce a single-column ranked list without rationale — explain the top 3 and bottom 3 decisions
|
||||
@@ -0,0 +1,69 @@
|
||||
---
|
||||
name: okr-builder
|
||||
description: Creates well-structured OKRs (Objectives and Key Results) for product teams, startups, and individuals. Use when asked to write OKRs, set quarterly goals, define key results, or review existing OKRs. Triggers on "OKR", "objective and key results", "quarterly goals", "north star metric".
|
||||
---
|
||||
|
||||
# OKR Builder Skill
|
||||
|
||||
Write ambitious, measurable OKRs that connect product work to company strategy. Avoid vanity metrics, output-focused key results, and objectives that sound like task lists.
|
||||
|
||||
## OKR Fundamentals
|
||||
|
||||
**Objective:** Qualitative, inspiring, time-bound. Answers "where are we going?"
|
||||
**Key Result:** Quantitative, specific, measurable. Answers "how will we know we've arrived?"
|
||||
|
||||
### The Test for a Good KR
|
||||
- Can it be scored 0.0–1.0 at the end of the period?
|
||||
- Does it measure outcome, not output? ("Revenue from new customers increased by 30%" not "Launch 3 features")
|
||||
- Is it ambitious but achievable? (Aim for 70% attainment as the gold standard)
|
||||
- Is it within the team's control?
|
||||
|
||||
## Common OKR Anti-Patterns to Flag and Fix
|
||||
|
||||
| Anti-Pattern | Example | Better Version |
|
||||
|---|---|---|
|
||||
| Task masquerading as KR | "Launch onboarding redesign" | "New user activation rate increases from 42% to 65%" |
|
||||
| Vanity metric | "Get 10,000 app downloads" | "30-day retention for new users reaches 40%" |
|
||||
| Binary KR | "Ship API v2" | "API v2 adopted by 80% of active integrations" |
|
||||
| Too many KRs | 6+ per objective | Max 3–4 KRs per objective |
|
||||
| No baseline | "Improve NPS" | "NPS increases from 32 to 50" |
|
||||
|
||||
Always flag anti-patterns and offer a rewrite.
|
||||
|
||||
## Output Format
|
||||
|
||||
### [Quarter] OKRs — [Team/Product Area]
|
||||
|
||||
---
|
||||
|
||||
**Objective 1: [Inspiring, qualitative statement]**
|
||||
|
||||
*Why this matters:* [1–2 sentence strategic context]
|
||||
|
||||
| # | Key Result | Baseline | Target | Measurement Method |
|
||||
|---|---|---|---|---|
|
||||
| KR1 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
|
||||
| KR2 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
|
||||
| KR3 | [Measurable outcome] | [Current state] | [Target] | [How measured] |
|
||||
|
||||
*Owner:* [Name/Role]
|
||||
*Check-in cadence:* Weekly
|
||||
|
||||
---
|
||||
|
||||
Repeat for each objective. Recommend 2–4 objectives per team per quarter.
|
||||
|
||||
## Scoring Guide to Include
|
||||
|
||||
At quarter end, score each KR:
|
||||
- 0.7–1.0 = Excellent (0.7 is the "sweet spot" — if all KRs score 1.0, they weren't ambitious enough)
|
||||
- 0.4–0.6 = Made progress but missed
|
||||
- 0.0–0.3 = Missed — needs retrospective discussion
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always ask for the company-level or product-level North Star metric before writing OKRs
|
||||
- Recommend no more than 3 objectives per team per quarter
|
||||
- If user provides output-based goals, always reframe as outcomes
|
||||
- Include a "health check" section flagging which KRs have no current baseline data
|
||||
- Remind user: OKRs are not performance reviews — they should be ambitious enough that missing them is okay
|
||||
@@ -0,0 +1,118 @@
|
||||
---
|
||||
name: pricing-strategy
|
||||
description: Structures pricing strategy decisions, packaging options, and pricing page design for SaaS and digital products. Use when reviewing or setting pricing, designing pricing tiers, evaluating freemium vs paid, or preparing a pricing change. Triggers on "pricing strategy", "pricing tiers", "freemium", "pricing page", "how should we price", "pricing change".
|
||||
---
|
||||
|
||||
# Pricing Strategy Skill
|
||||
|
||||
Build pricing that reflects value delivered — not cost to build. Structure every pricing decision with customer segmentation, value metric identification, competitive context, and a packaging recommendation.
|
||||
|
||||
## Pricing Foundations
|
||||
|
||||
Three questions to answer before any pricing decision:
|
||||
1. **Who is our buyer?** (Role, company size, willingness to pay)
|
||||
2. **What value do we deliver?** (Quantifiable outcome — time saved, revenue generated, risk reduced)
|
||||
3. **What is our pricing model?** (Per seat, usage-based, flat, hybrid)
|
||||
|
||||
---
|
||||
|
||||
## Pricing Models
|
||||
|
||||
| Model | Best For | Risk |
|
||||
|---|---|---|
|
||||
| **Per Seat** | Collaboration tools, team software | Disincentivises adoption as team grows |
|
||||
| **Usage-Based** | APIs, infrastructure, consumption tools | Revenue unpredictability for both sides |
|
||||
| **Flat Rate** | Simple tools, early-stage | Leaves money on table from power users |
|
||||
| **Tiered** | Products with clear user segments | Feature gatekeeping frustrates users |
|
||||
| **Freemium** | Viral/PLG products with low marginal cost | Conversion to paid is hard to engineer |
|
||||
| **Value-Based** | Enterprise, outcomes-driven products | Requires strong ROI story |
|
||||
|
||||
---
|
||||
|
||||
## Freemium Decision Framework
|
||||
|
||||
Use freemium when:
|
||||
- ✅ Marginal cost per free user is near zero
|
||||
- ✅ Product is inherently viral (network effects or sharing)
|
||||
- ✅ Free tier creates genuine value (not just a demo)
|
||||
- ✅ Clear upgrade trigger exists (feature, volume, or team size)
|
||||
- ✅ Conversion benchmark is realistic (2–5% free-to-paid is typical)
|
||||
|
||||
Avoid freemium when:
|
||||
- ❌ Support cost per free user is high
|
||||
- ❌ No natural upgrade trigger in the product
|
||||
- ❌ Core value requires features you'd need to gate
|
||||
|
||||
---
|
||||
|
||||
## Packaging / Tiering Framework
|
||||
|
||||
Recommended 3-tier structure for SaaS:
|
||||
|
||||
| Tier | Target | Price Signal | Key Features | Lock-in Mechanism |
|
||||
|---|---|---|---|---|
|
||||
| **Free / Starter** | Individual, early discovery | $0 | Core value, usage-limited | Invite colleagues, export limit |
|
||||
| **Pro / Growth** | SMB, growing teams | $[X]/seat/mo | Full features, higher limits | Team collaboration, integrations |
|
||||
| **Business / Enterprise** | Mid-market, enterprise | $[X]/seat/mo or custom | Admin, SSO, SLAs, dedicated support | Security, compliance, volume |
|
||||
|
||||
Tier design rules:
|
||||
- Each tier should be genuinely sufficient for its target segment
|
||||
- The upgrade trigger should be felt naturally — not manufactured
|
||||
- Price jumps of 3–5x between tiers are normal and defensible
|
||||
|
||||
---
|
||||
|
||||
## Competitive Pricing Context
|
||||
|
||||
| Competitor | Model | Price | Key Differentiator |
|
||||
|---|---|---|---|
|
||||
| [Name] | [Model] | [Price] | [What they lead with] |
|
||||
|
||||
Positioning options:
|
||||
- **Premium:** Price 20–40% above market. Justify with enterprise features, support, or brand.
|
||||
- **Parity:** Match the market leader. Win on product or distribution.
|
||||
- **Value:** Price below market. Win on volume. Dangerous without strong unit economics.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Pricing Strategy Recommendation — [Product] — [Date]
|
||||
|
||||
**Current State:** [What pricing exists today, if any]
|
||||
**Problem to Solve:** [Why pricing is being reviewed]
|
||||
|
||||
**Recommended Pricing Model:** [Model name + rationale]
|
||||
|
||||
**Value Metric:** [The single unit that scales with customer value — e.g., "active users", "API calls", "documents processed"]
|
||||
|
||||
**Proposed Tiers:**
|
||||
|
||||
[Table using 3-tier structure above]
|
||||
|
||||
**Free-to-Paid Upgrade Trigger:** [Specific moment or threshold that creates natural upgrade pressure]
|
||||
|
||||
**Competitive Position:** [Premium / Parity / Value + reasoning]
|
||||
|
||||
**Pricing Change Rollout (if applicable):**
|
||||
- Grandfathering: [Yes / No — recommendation and rationale]
|
||||
- Communication plan: [How to tell customers + timing]
|
||||
- Rollback plan: [Under what conditions you'd revert]
|
||||
|
||||
**Risks:**
|
||||
- [Risk] → Mitigation: [Action]
|
||||
|
||||
**Metrics to Monitor Post-Change:**
|
||||
- Conversion rate (free to paid)
|
||||
- Churn rate by tier
|
||||
- Average revenue per user (ARPU)
|
||||
- Expansion revenue
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never price based on cost — price based on value delivered to the customer
|
||||
- Always A/B test price changes where possible; use geographic holdouts if A/B isn't feasible
|
||||
- Recommend annual pricing with 15–20% discount — improves cash flow and reduces churn
|
||||
- If enterprise pricing is "contact us", recommend adding a price floor to qualify inbound
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
name: rice-impact-matrix
|
||||
description: Score features using RICE and plot against strategic alignment for nuanced prioritisation
|
||||
tool_integration: Miro, Jira
|
||||
---
|
||||
# RICE + Strategic Alignment Skill
|
||||
|
||||
## Purpose
|
||||
Produce a prioritisation output that balances quantitative RICE scoring with qualitative strategic fit — because the highest RICE score isn't always the right next bet.
|
||||
|
||||
## Two-Stage Process
|
||||
|
||||
### Stage 1: RICE Scoring
|
||||
- Reach: Users affected per quarter
|
||||
- Impact: 3/2/1/0.5/0.25 scale
|
||||
- Confidence: 100% / 80% / 50%
|
||||
- Effort: Person-months
|
||||
- RICE = (R × I × C) / E
|
||||
|
||||
### Stage 2: Strategic Alignment Score
|
||||
Rate each initiative against your current strategic priorities (provide these as input):
|
||||
- Directly supports top OKR: +3
|
||||
- Supports secondary OKR: +2
|
||||
- Neutral: +1
|
||||
- Contradicts strategic direction: -1
|
||||
|
||||
### Final Priority Score
|
||||
Combined Score = RICE Score + (Strategic Alignment × 10)
|
||||
|
||||
## Output Format
|
||||
|
||||
### Priority Matrix — [Quarter]
|
||||
| Initiative | RICE Score | Strategic Alignment | Combined Score | Quadrant | Recommendation |
|
||||
|------------|------------|--------------------|--------------------|----------|----------------|
|
||||
| [name] | [score] | [score] | [combined] | [Now/Next/Later/Drop] | [action] |
|
||||
|
||||
#### Quadrant Definitions
|
||||
- **Now:** High RICE + High Strategic Alignment → Build this quarter
|
||||
- **Next:** High RICE + Lower Alignment → Queue for next quarter
|
||||
- **Later:** Lower RICE + High Alignment → Revisit when capacity allows
|
||||
- **Drop:** Low RICE + Low Alignment → Remove from backlog
|
||||
|
||||
#### Recommendations
|
||||
[Top 5 initiatives with rationale for sequencing]
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: rice-prioritisation
|
||||
description: Score and rank product initiatives using the RICE framework
|
||||
tool_integration: Jira
|
||||
---
|
||||
# RICE Prioritisation Skill
|
||||
|
||||
## Purpose
|
||||
Apply consistent, criteria-based RICE scoring to a list of features or initiatives to produce an objective prioritisation ranking.
|
||||
|
||||
## RICE Definitions (adapt to your context)
|
||||
- **Reach:** Number of users affected per quarter (use actual DAU/MAU data where available)
|
||||
- **Impact:** Effect on your primary metric — use scale: 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal
|
||||
- **Confidence:** How certain are we about R and I estimates? 100%=high, 80%=medium, 50%=low
|
||||
- **Effort:** Person-months required across all functions
|
||||
|
||||
## RICE Formula
|
||||
RICE Score = (Reach × Impact × Confidence) / Effort
|
||||
|
||||
## Process
|
||||
1. For each initiative provided, gather or estimate R, I, C, E values
|
||||
2. Flag where estimates are weak and note what data would improve them
|
||||
3. Calculate RICE score for each
|
||||
4. Rank highest to lowest
|
||||
5. Flag any "quick wins" (high RICE score, low effort) and "moonshots" (high impact, high effort)
|
||||
6. Note dependencies between items that affect sequencing
|
||||
|
||||
## Output Format
|
||||
|
||||
### RICE Prioritisation: [Backlog/Quarter]
|
||||
| Initiative | Reach | Impact | Confidence | Effort | RICE Score | Notes |
|
||||
|------------|-------|--------|------------|--------|------------|-------|
|
||||
| [name] | [n] | [score] | [%] | [months] | [score] | [flags] |
|
||||
|
||||
#### Recommended Sequence
|
||||
[Top 5 initiatives with rationale]
|
||||
|
||||
#### Data Gaps to Address
|
||||
[What information would most improve scoring accuracy]
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
name: roadmap-narrative
|
||||
description: Transform a prioritised initiative list into a compelling strategic roadmap narrative
|
||||
tool_integration: Notion, Miro
|
||||
---
|
||||
# Roadmap Narrative Skill
|
||||
|
||||
## Purpose
|
||||
Convert a ranked list of product initiatives into a clear, strategic narrative that connects individual items to company goals and communicates a coherent product direction.
|
||||
|
||||
## Process
|
||||
1. Review the prioritised initiative list and company OKRs provided
|
||||
2. Identify 2-3 strategic themes that group the initiatives naturally
|
||||
3. For each theme, articulate: the problem it addresses, the customer it serves, the metric it moves
|
||||
4. Write a quarter-level narrative that shows progression — how does H1 set up H2?
|
||||
5. Draft an executive summary (3-4 sentences max) that non-technical stakeholders can repeat
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Roadmap: [Quarter/Half/Year]
|
||||
**Strategic Context:** [1 paragraph: market moment, key challenge, our response]
|
||||
|
||||
#### Theme 1: [Theme Name]
|
||||
- Strategic rationale
|
||||
- Initiatives included
|
||||
- Primary metric impacted
|
||||
- Dependencies
|
||||
|
||||
[Repeat for each theme]
|
||||
|
||||
**Executive Summary (shareable):**
|
||||
[3-4 sentences that could be shared in an all-hands or board update]
|
||||
|
||||
## Tone Guidelines
|
||||
- Avoid jargon — write for a CFO, not an engineer
|
||||
- Lead with customer outcomes, not features
|
||||
- Be honest about what's NOT on the roadmap and why
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: roadmap-presentation
|
||||
description: Creates structured roadmap presentations and narratives for executive, stakeholder, and team audiences. Use when asked to build a product roadmap, present roadmap to leadership, create a roadmap slide, or communicate quarterly plans. Triggers on "roadmap presentation", "product roadmap", "quarterly roadmap", "roadmap slide", "roadmap for leadership".
|
||||
---
|
||||
|
||||
# Roadmap Presentation Skill
|
||||
|
||||
Build roadmaps that tell a strategy story — not just a list of features with dates. Every roadmap output is audience-calibrated: executives get outcomes, teams get specificity, customers get value.
|
||||
|
||||
## Audience Calibration
|
||||
|
||||
Always ask who the audience is before building:
|
||||
|
||||
| Audience | They care about | Format |
|
||||
|---|---|---|
|
||||
| **Executive / Board** | Business outcomes, revenue, risk, strategic alignment | Outcome-led, 3 columns (Now / Next / Later), no sprint detail |
|
||||
| **Cross-functional stakeholders** | Dependencies, timelines, their team's involvement | Theme-based, with dependency callouts |
|
||||
| **Engineering team** | Specificity, sequencing, technical constraints | Detailed, with epics and rough sizing |
|
||||
| **Customers / External** | Value delivered, no internal detail | Benefits-focused, no dates — "Coming soon / In progress / Done" |
|
||||
|
||||
---
|
||||
|
||||
## The Now / Next / Later Framework
|
||||
|
||||
Standard output structure:
|
||||
|
||||
**NOW** (Current quarter — high confidence, committed)
|
||||
- What we're building and why
|
||||
- Expected outcomes
|
||||
|
||||
**NEXT** (Following quarter — medium confidence, directional)
|
||||
- Themes and initiatives
|
||||
- Key hypotheses being tested
|
||||
|
||||
**LATER** (6–12 months — low confidence, aspirational)
|
||||
- Strategic bets
|
||||
- Dependencies that need to resolve first
|
||||
|
||||
⚠️ Never put specific dates on "Later" items. Use quarters or halves.
|
||||
|
||||
---
|
||||
|
||||
## Roadmap Narrative Template
|
||||
|
||||
Every roadmap needs a narrative, not just a timeline. Structure it as:
|
||||
|
||||
1. **Where we are** — current product state and key metrics
|
||||
2. **The problem we're solving** — what's holding customers or the business back
|
||||
3. **Our strategic bets** — the themes that guide this roadmap
|
||||
4. **What we're building** — Now / Next / Later breakdown
|
||||
5. **How we'll know it's working** — success metrics per theme
|
||||
6. **What we're not doing** — explicit deprioritisation with rationale
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Product Roadmap — [Product Area] — [Quarter/Year]
|
||||
|
||||
**Audience:** [Executive / Team / Customer]
|
||||
**Roadmap Owner:** [PM Name]
|
||||
**Last Updated:** [Date]
|
||||
**Confidence Level:** Now = High | Next = Medium | Later = Low
|
||||
|
||||
---
|
||||
|
||||
**Strategic Context:**
|
||||
> [2–3 sentences: what company/product goal does this roadmap serve?]
|
||||
|
||||
**Guiding Themes This Period:**
|
||||
1. [Theme 1] — [1-line rationale]
|
||||
2. [Theme 2] — [1-line rationale]
|
||||
3. [Theme 3] — [1-line rationale]
|
||||
|
||||
---
|
||||
|
||||
**NOW — [Quarter]**
|
||||
|
||||
| Theme | Initiative | Outcome Expected | Team | Status |
|
||||
|---|---|---|---|---|
|
||||
| [Theme] | [What we're building] | [Metric it moves] | [Owner] | In Progress / Starting |
|
||||
|
||||
**NEXT — [Quarter]**
|
||||
|
||||
| Theme | Initiative | Hypothesis | Dependencies |
|
||||
|---|---|---|---|
|
||||
| [Theme] | [What we plan to build] | [If we build X, we expect Y] | [What needs to be true first] |
|
||||
|
||||
**LATER — [H2 / Next Year]**
|
||||
|
||||
| Theme | Strategic Bet | Why Later |
|
||||
|---|---|---|
|
||||
| [Theme] | [What we might build] | [What's blocking or uncertain] |
|
||||
|
||||
---
|
||||
|
||||
**What We're NOT Building (and Why):**
|
||||
- [Requested initiative] — Deprioritised because: [reason]
|
||||
- [Requested initiative] — Deprioritised because: [reason]
|
||||
|
||||
**Success Metrics for This Roadmap:**
|
||||
| Metric | Now Target | End of Year Target |
|
||||
|---|---|---|
|
||||
| [Metric] | [X] | [Y] |
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never let a roadmap become a commitment list — frame everything outside "Now" as directional
|
||||
- Always include a "not doing" section — it prevents the roadmap from becoming a wish list in disguise
|
||||
- For executive audiences: lead with the outcome the roadmap delivers to the business, not the features
|
||||
- Recommend a roadmap review cadence: monthly for Now items, quarterly for Next/Later
|
||||
- If dates are demanded for Later items: use quarters (Q3 2026), not specific dates
|
||||
Reference in New Issue
Block a user