Product Frameworks

Name: Product Frameworks
Author: yonatangross

yonatangross/orchestkit

148 installs
213 repo stars
Updated August 4, 2026
yonatangross/orchestkit

Apply structured product frameworks—jobs-to-be-done, RICE, opportunity trees—to define MVP scope, prioritize features, and align team decisions before coding begins.

About

Applies established product management frameworks within orchestkit to frame problems, prioritize features with RICE and opportunity trees, define MVP scope, and align validation hypotheses before development investment begins.

JTBD problem framing
RICE prioritization
Opportunity solution trees
MVP boundary definition
Metric-driven hypotheses

Product Frameworks by the numbers

148 all-time installs (skills.sh)
+2 installs in the week ending Jul 28, 2026 (Skillselion tracking)
Ranked #1,186 of 3,282 Productivity & Planning skills by installs in the Skillselion catalog
Data as of Aug 5, 2026 (Skillselion catalog sync)

npx skills add https://github.com/yonatangross/orchestkit --skill product-frameworks

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/yonatangross/orchestkit/product-frameworks.svg)](https://skillselion.com/skills/yonatangross/orchestkit/product-frameworks)

Installs	148
repo stars	★ 213
Last updated	August 4, 2026
Repository	yonatangross/orchestkit ↗

What it does

Apply structured product frameworks—jobs-to-be-done, RICE, opportunity trees—to define MVP scope, prioritize features, and align team decisions before coding begins.

Files

assets/
checklists/
references/
rules/

SKILL.mdMarkdownGitHub ↗

Product Frameworks

Comprehensive product management frameworks covering business analysis, market intelligence, strategy, prioritization, metrics, personas, requirements, and user research. Each category has individual rule files in rules/ loaded on-demand.

Quick Reference

Category	Rules	Impact	When to Use
Business & Market	4	HIGH	ROI/NPV/IRR calculations, TCO analysis, TAM/SAM/SOM sizing, competitive landscape
Strategy & Prioritization	5	HIGH	Value proposition canvas, go/no-go gates, RICE scoring, WSJF ranking, opportunity cost
Metrics & OKRs	5	HIGH	OKR writing, KPI trees, leading/lagging indicators, instrumentation, experiment design
Research & Requirements	4	HIGH	User personas, journey maps, interview guides, PRDs

Total: 18 rules across 4 categories

Quick Start

## ROI Quick Calculation
ROI = (Net Benefits - Total Costs) / Total Costs x 100%

## RICE Prioritization
RICE Score = (Reach x Impact x Confidence) / Effort

## OKR Structure
Objective: Qualitative, inspiring goal
  KR1: Quantitative measure (from X to Y)
  KR2: Quantitative measure (from X to Y)

## User Story Format
As a [persona], I want [goal], so that [benefit].

Business & Market

Financial analysis and market intelligence frameworks for investment decisions.

`business-roi` -- ROI, NPV, IRR, payback period calculations with Python examples
`business-cost-benefit` -- TCO analysis, build vs buy comparison, sensitivity analysis
`market-tam-sam-som` -- TAM/SAM/SOM market sizing with top-down and bottom-up methods
`market-competitive` -- Porter's Five Forces, SWOT, competitive landscape mapping

Strategy & Prioritization

Strategic decision frameworks and quantitative prioritization methods.

`strategy-value-prop` -- Value Proposition Canvas, JTBD framework, fit assessment
`strategy-go-no-go` -- Stage gate criteria, scoring template, decision thresholds
`prioritize-rice` -- RICE scoring with reach, impact, confidence, effort scales
`prioritize-wsjf` -- WSJF cost of delay, time criticality, MoSCoW method
`prioritize-opportunity-cost` -- Opportunity cost matrix, cost of delay analysis, trade-off flagging

Metrics & OKRs

Goal-setting and measurement frameworks for metrics-driven teams.

`metrics-okr` -- OKR structure, writing objectives and key results, examples
`metrics-kpi-trees` -- Revenue and product health KPI trees, North Star metric
`metrics-leading-lagging` -- Leading vs lagging indicators, balanced dashboards
`metrics-instrumentation` -- Metric definition template, event naming, alerting
`metrics-experiment-design` -- Experiment design, guardrail metrics, staged rollout plans

Research & Requirements

User research methods and requirements documentation patterns.

`research-personas` -- User persona template, empathy maps, persona examples
`research-journey-mapping` -- Customer journey maps, service blueprints, experience curves
`research-user-interviews` -- Interview guides, usability testing, surveys, card sorting
`research-requirements-prd` -- PRD template, user stories, acceptance criteria, INVEST

Output Templates

Structured JSON output formats for consistent deliverables. Load: Read("${CLAUDE_SKILL_DIR}/references/output-templates.md") for PRD, business case, metrics framework, prioritization report, and research report templates.

Related Skills

ork:assess - Assess project complexity and risks
ork:brainstorm - Generate product ideas and features

Version: 2.0.0 (March 2026)

Business Case Template

Copy and complete for each investment decision.

# Business Case: [Feature/Project Name]

**Date:** YYYY-MM-DD
**Author:** [Name]
**Version:** 1.0
**Status:** DRAFT | REVIEW | APPROVED

---

## Executive Summary

**Investment Request:** $[Amount]
**Expected ROI:** [X]%
**Payback Period:** [X] months
**Recommendation:** INVEST / DO NOT INVEST / CONDITIONAL

[2-3 sentence summary]

---

## Investment Summary

| Metric | Value |
|--------|-------|
| Total Investment | $X |
| Expected Return (3yr) | $Y |
| ROI | Z% |
| Payback Period | N months |
| Confidence | HIGH/MEDIUM/LOW |

---

## Cost Breakdown

### One-Time Costs
| Category | Amount | Basis |
|----------|--------|-------|
| Development | $X | [calculation] |
| Design | $X | [calculation] |
| Infrastructure Setup | $X | [calculation] |
| **Total One-Time** | **$X** | |

### Annual Recurring Costs
| Category | Year 1 | Year 2 | Year 3 |
|----------|--------|--------|--------|
| Infrastructure | $X | $X | $X |
| Maintenance | $X | $X | $X |
| Support | $X | $X | $X |
| **Total Annual** | **$X** | **$X** | **$X** |

### Opportunity Cost
[What else could be built with these resources?]

---

## Benefit Projection

### Revenue Benefits
| Category | Year 1 | Year 2 | Year 3 | Basis |
|----------|--------|--------|--------|-------|
| New Customers | $X | $X | $X | [assumption] |
| Expansion | $X | $X | $X | [assumption] |
| Retention | $X | $X | $X | [assumption] |

### Cost Savings
| Category | Year 1 | Year 2 | Year 3 | Basis |
|----------|--------|--------|--------|-------|
| Support | $X | $X | $X | [assumption] |
| Operations | $X | $X | $X | [assumption] |

### Intangible Benefits
- [Benefit 1]
- [Benefit 2]

---

## Sensitivity Analysis

| Scenario | Assumption | ROI | Payback |
|----------|------------|-----|---------|
| Conservative (50% benefit) | [describe] | X% | N months |
| Base Case | [describe] | Y% | M months |
| Optimistic (150% benefit) | [describe] | Z% | P months |

**Key Variables:**
1. [Variable most affecting outcome]
2. [Second most important]

---

## Risks

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| [Risk 1] | HIGH/MED/LOW | $X | [mitigation] |
| [Risk 2] | HIGH/MED/LOW | $X | [mitigation] |

---

## Recommendation

### Decision: [INVEST / DO NOT INVEST / CONDITIONAL]

### Rationale:
[Explain why]

### Conditions (if conditional):
1. [Condition 1]
2. [Condition 2]

---

## Appendix

### Assumptions
1. [Assumption 1]
2. [Assumption 2]

### Data Sources
- [Source 1]
- [Source 2]

### Alternative Options Considered
| Option | Pros | Cons | Why Not |
|--------|------|------|---------|
| [Option 1] | | | |
| [Option 2] | | | |

Market Research Report Template

# Market Research: [Domain/Opportunity]

**Date:** YYYY-MM-DD
**Author:** market-intelligence agent
**Confidence:** HIGH/MEDIUM/LOW

---

## Executive Summary

[3-4 sentences summarizing key findings and recommendations]

---

## Market Sizing

### TAM (Total Addressable Market)

| Method | Value | Methodology |
|--------|-------|-------------|
| Top-Down | $X | [Source + calculation] |
| Bottom-Up | $Y | [Source + calculation] |
| **Reconciled** | **$Z** | [How reconciled] |

### SAM (Serviceable Addressable Market)

| Filter | % of TAM | Result |
|--------|----------|--------|
| Geography | X% | $A |
| Segment | Y% | $B |
| Use case | Z% | $C |
| **SAM** | | **$C** |

### SOM (Serviceable Obtainable Market)

| Constraint | Impact | 3-Year Target |
|------------|--------|---------------|
| Competition | X% share realistic | $D |
| Capacity | Sales can support | $E |
| **SOM** | | **min($D,$E)** |

---

## Competitive Landscape

### Direct Competitors

| Competitor | Strengths | Weaknesses | Market Share |
|------------|-----------|------------|--------------|
| [A] | | | ~X% |
| [B] | | | ~Y% |
| [C] | | | ~Z% |

### Positioning Map

[Insert 2x2 positioning map]


### Competitive Gaps

- [Gap 1 we can exploit]
- [Gap 2 opportunity]

---

## Market Trends

| Trend | Impact | Timeline |
|-------|--------|----------|
| [Trend 1] | HIGH/MED/LOW | NOW/6mo/12mo |
| [Trend 2] | HIGH/MED/LOW | NOW/6mo/12mo |

---

## SWOT Analysis

| Strengths | Weaknesses |
|-----------|------------|
| • [S1] | • [W1] |
| • [S2] | • [W2] |

| Opportunities | Threats |
|---------------|---------|
| • [O1] | • [T1] |
| • [O2] | • [T2] |

---

## Recommendations

1. **[Recommendation 1]** - [Priority: HIGH/MED/LOW]
   - Rationale: [Why]

2. **[Recommendation 2]** - [Priority: HIGH/MED/LOW]
   - Rationale: [Why]

---

## Data Sources

- [Source 1]
- [Source 2]
- [Source 3]

---

## Handoff

**Next:** product-strategist (for strategic assessment)

Metric Definition Template

Use this template to formally define each KPI.

# Metric: [Metric Name]

**ID:** [METRIC-001]
**Owner:** [Team/Person]
**Last Updated:** YYYY-MM-DD

---

## Definition

[Precise definition of what this metric measures. Be specific enough that two people would calculate the same value.]

---

## Formula

Metric = Numerator / Denominator

Where:

Numerator: [definition]
Denominator: [definition]


**Example Calculation:**

Monthly Active Users = Unique users who performed at least 1 action in 30-day window = Count(DISTINCT user_id WHERE last_action_date >= today - 30)


---

## Data Source

| Field | Value |
|-------|-------|
| System | [e.g., PostgreSQL, Mixpanel, Stripe] |
| Table/Event | [e.g., events.user_actions] |
| Query Owner | [Team responsible] |
| Refresh Frequency | [Real-time, Hourly, Daily] |

---

## Segments

Break down by:
- [ ] Customer tier (Free, Pro, Enterprise)
- [ ] Geography (NA, EMEA, APAC)
- [ ] Cohort (signup month)
- [ ] Platform (Web, iOS, Android)
- [ ] [Custom segment]

---

## Historical Context

| Period | Value | Notes |
|--------|-------|-------|
| Q1 2025 | X | [Context] |
| Q2 2025 | Y | [Context] |
| Q3 2025 | Z | [Context] |

---

## Targets

| Period | Target | Stretch |
|--------|--------|---------|
| Q1 2026 | X | Y |
| Q2 2026 | A | B |

---

## Leading/Lagging

**Type:** Leading / Lagging

**If Leading, predicts:** [Which lagging metric]
**If Lagging, predicted by:** [Which leading metrics]

---

## Alerting

| Threshold | Severity | Action |
|-----------|----------|--------|
| < X | Warning | [Action to take] |
| < Y | Critical | [Action to take] |

---

## Related Metrics

- **Parent:** [Higher-level metric this rolls into]
- **Children:** [Lower-level metrics that compose this]
- **Related:** [Correlated metrics]

---

## Dashboard Location

[Link to where this metric is displayed]

---

## Notes

[Any additional context, caveats, or known issues with this metric]

Persona Template

# Persona: [Name]

**Last Updated:** YYYY-MM-DD
**Based on:** [N] interviews, analytics data

---

## At a Glance

| Attribute | Value |
|-----------|-------|
| Role | [Job title] |
| Experience | [Years in role] |
| Company | [Type/size] |
| Tech Savviness | Low / Medium / High |

---

## Photo

[Include representative image - not a real person]

---

## Quote

> "[Characteristic statement that captures their mindset]"

---

## Background

[2-3 sentences about their professional context, what they do daily, and what matters to them]

---

## Goals

### Primary Goal
[What does success look like for them?]

### Secondary Goals
1. [Goal 2]
2. [Goal 3]

---

## Pain Points

1. **[Pain 1]** - [Severity: HIGH/MEDIUM]
   - [Brief description]

2. **[Pain 2]** - [Severity: HIGH/MEDIUM]
   - [Brief description]

3. **[Pain 3]** - [Severity: MEDIUM/LOW]
   - [Brief description]

---

## Behaviors

### Workflow
- [Typical daily/weekly pattern]
- [Key activities related to your product]

### Tools They Use
- [Tool 1]
- [Tool 2]
- [Tool 3]

### Information Sources
- [Where they learn/get updates]

### Usage Context
- **When:** [Time of day, triggers]
- **Where:** [Desktop, mobile, context]
- **How often:** [Frequency]

---

## Motivations

- [What drives their decisions]
- [What they value most]
- [What success means to them]

---

## Frustrations

- [What annoys them]
- [Common complaints]
- [Dealbreakers]

---

## Scenario

[Brief story of how they might use your product in a typical situation]

Context: [Situation] Trigger: [What prompts action] Action: [What they do] Outcome: [What they expect]


---

## Key Insight

**[The most important thing to remember about this persona]**

This insight should help the team make decisions about:
- Feature prioritization
- Design choices
- Communication tone

---

## Design Implications

| Persona Need | Design Response |
|--------------|-----------------|
| [Need 1] | [How we address it] |
| [Need 2] | [How we address it] |

---

## Supporting Data

- [N]% of users match this profile
- Average [metric]: [value]
- Common support tickets: [themes]

---

## Related Personas

- **Similar to:** [Other persona] (but differs in [way])
- **Distinct from:** [Other persona] (because [reason])

PRD Template

# PRD: [Feature Name]

**Author:** [Name]
**Last Updated:** YYYY-MM-DD
**Status:** Draft | In Review | Approved | Shipped
**Version:** 1.0

---

## Overview

### Problem Statement

[1-2 paragraphs: What problem are we solving? Who has it? What's the impact?]

### Goals

1. **Primary:** [Goal with measurable outcome]
2. **Secondary:** [Supporting goal]
3. **Secondary:** [Supporting goal]

### Non-Goals (Out of Scope)

- [What we're explicitly NOT doing]
- [Feature for future consideration]
- [Related but separate problem]

### Success Metrics

| Metric | Current | Target | Timeline |
|--------|---------|--------|----------|
| [Metric 1] | [Baseline] | [Goal] | [When] |
| [Metric 2] | [Baseline] | [Goal] | [When] |

---

## User Stories

### P0 - Must Have (MVP)

**US-001: [Title]**

As a [persona], I want to [action], so that [benefit].


**Acceptance Criteria:**
- [ ] Given [context], when [action], then [result]
- [ ] Given [context], when [action], then [result]

---

**US-002: [Title]**
[Repeat format]

---

### P1 - Should Have

**US-003: [Title]**
[Repeat format]

---

### P2 - Nice to Have

**US-004: [Title]**
[Repeat format]

---

## Design

### User Flow

[Link to Figma or embed diagram]

Step 1 → Step 2 → Step 3 → Step 4


### Wireframes

[Links or embedded images]

### Technical Design

[Link to technical spec or RFC]

---

## Non-Functional Requirements

| Category | Requirement |
|----------|-------------|
| Performance | [e.g., Page load < 2s at p95] |
| Scalability | [e.g., Support 10K concurrent users] |
| Security | [e.g., Data encrypted at rest] |
| Accessibility | [e.g., WCAG 2.1 AA compliant] |
| Browser Support | [e.g., Chrome, Firefox, Safari latest 2] |

---

## Dependencies

| Dependency | Owner | Status | ETA |
|------------|-------|--------|-----|
| [Dependency 1] | [Team] | [Status] | [Date] |
| [Dependency 2] | [Team] | [Status] | [Date] |

---

## Risks & Mitigations

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| [Risk 1] | HIGH/MED/LOW | HIGH/MED/LOW | [Strategy] |
| [Risk 2] | HIGH/MED/LOW | HIGH/MED/LOW | [Strategy] |

---

## Timeline

| Milestone | Target Date | Status |
|-----------|-------------|--------|
| PRD Approved | | |
| Design Complete | | |
| Dev Complete | | |
| QA Complete | | |
| Launch | | |

---

## Open Questions

| # | Question | Owner | Due Date | Resolution |
|---|----------|-------|----------|------------|
| 1 | [Question] | [Name] | [Date] | [Pending/Resolved] |

---

## Appendix

- [Link to user research]
- [Link to competitive analysis]
- [Link to technical RFC]
- [Link to design files]

---

## Change Log

| Version | Date | Author | Changes |
|---------|------|--------|---------|
| 1.0 | YYYY-MM-DD | [Name] | Initial draft |

Research Report Template

# Research Report: [Study Title]

**Date:** YYYY-MM-DD
**Researcher:** [Name]
**Method:** [Interviews / Usability Testing / Survey / etc.]

---

## Executive Summary

[3-4 sentences: What did we study? What did we learn? What should we do?]

---

## Study Overview

### Research Questions

1. [Primary question]
2. [Secondary question]

### Methodology

| Aspect | Detail |
|--------|--------|
| Method | [e.g., Semi-structured interviews] |
| Participants | [N] [description] |
| Duration | [X] sessions, [Y] min each |
| Dates | [Date range] |

### Participant Summary

| ID | Role | Experience | Segment |
|----|------|------------|---------|
| P1 | [Role] | [Years] | [Segment] |
| P2 | [Role] | [Years] | [Segment] |
| ... | | | |

---

## Key Findings

### Finding 1: [Title]

**Insight:** [One sentence summary]

**Evidence:**
- [Observation or data point]
- [Quote] - P3
- [Behavior observed]

**Impact:** HIGH / MEDIUM / LOW

---

### Finding 2: [Title]

[Repeat structure]

---

### Finding 3: [Title]

[Repeat structure]

---

## Themes

### Theme 1: [Theme Name]

[Description of the theme and what it means]

**Supporting Quotes:**
> "[Quote]" - P1
> "[Quote]" - P4

---

### Theme 2: [Theme Name]

[Repeat structure]

---

## Quantitative Summary (if applicable)

| Metric | Value | Benchmark |
|--------|-------|-----------|
| Task success rate | X% | Y% |
| Time on task | X min | Y min |
| SUS score | X | 68 (avg) |
| NPS | X | Y |

---

## Recommendations

### Recommendation 1: [Title]

**Finding it addresses:** [Finding 1]

**Recommendation:** [Specific action to take]

**Impact:** HIGH / MEDIUM / LOW
**Effort:** HIGH / MEDIUM / LOW

---

### Recommendation 2: [Title]

[Repeat structure]

---

## Limitations

- [Limitation 1 - e.g., small sample size]
- [Limitation 2 - e.g., specific user segment]
- [Limitation 3 - e.g., prototype fidelity]

---

## Next Steps

- [ ] [Action item 1] - Owner: @name
- [ ] [Action item 2] - Owner: @name
- [ ] [Follow-up research needed]

---

## Appendix

### A. Discussion Guide

[Link or embed]

### B. Raw Data

[Link to secure storage]

### C. Participant Quotes

[Collection of notable quotes organized by theme]

RICE Scoring Spreadsheet Template

Copy this table structure for prioritization sessions.

Scoring Table

Feature	Reach	Impact	Confidence	Effort	RICE Score	Rank
Feature A	8	2.0	0.8	2	6.4	1
Feature B	5	3.0	0.5	4	1.9	3
Feature C	10	1.0	1.0	1	10.0	2

Score Definitions

Reach (users/quarter)

10: All users (100%)
8: Most users (80%)
5: Half users (50%)
3: Some users (30%)
1: Few users (10%)

Impact (on goal)

3.0: Massive (3x improvement)
2.0: High (2x improvement)
1.0: Medium (notable)
0.5: Low (minor)
0.25: Minimal

Confidence (in estimates)

1.0: High (data-backed)
0.8: Medium (some validation)
0.5: Low (gut feel)
0.3: Moonshot

Effort (person-weeks)

0.5: < 1 week
1: 1 week
2: 2 weeks
4: 1 month
8: 2 months

Formula

RICE = (Reach × Impact × Confidence) / Effort

Notes Column Template

Feature	Rationale	Dependencies	Owner
Feature A	User interviews + analytics	None	@engineer
Feature B	Strategic bet	Feature A	@pm

Priority Tiers

Based on RICE score:

Tier	RICE Range	Action
P0	> 8.0	Do immediately
P1	4.0 - 8.0	Do this quarter
P2	1.0 - 4.0	Do when capacity
P3	< 1.0	Backlog / reconsider

Strategic Assessment Template

Copy and fill in for each product opportunity.

## Strategic Assessment: [Feature/Product Name]

**Date:** YYYY-MM-DD
**Assessor:** [Name]
**Status:** DRAFT | REVIEW | APPROVED

---

## Executive Summary

[2-3 sentence summary of recommendation]

---

## Value Proposition

### Target User
[Specific user segment]

### Problem Statement
[What problem are we solving?]

### Solution
[How do we solve it?]

### Differentiation
[Why us vs alternatives?]

### Validation Status
- [ ] Hypothesis only
- [ ] Qualitative validation (interviews)
- [ ] Quantitative validation (data)

---

## Strategic Alignment

| Dimension | Fit | Evidence |
|-----------|-----|----------|
| Vision | HIGH/MED/LOW | |
| OKRs | HIGH/MED/LOW | |
| Portfolio | HIGH/MED/LOW | |
| Resources | HIGH/MED/LOW | |

---

## Build vs Buy vs Partner

### Recommendation: [BUILD/BUY/PARTNER]

### Alternatives Considered

| Option | Pros | Cons | Why Rejected |
|--------|------|------|--------------|
| | | | |
| | | | |

---

## Risks

| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| | HIGH/MED/LOW | HIGH/MED/LOW | |
| | HIGH/MED/LOW | HIGH/MED/LOW | |

---

## Recommendation

### Decision: GO / NO-GO / CONDITIONAL

### Confidence: HIGH / MEDIUM / LOW

### Conditions (if conditional):
1.
2.

### Rationale:
[Explain the recommendation]

---

## Value Hypothesis

**Hypothesis:** [We believe X will cause Y]

**Validation Method:** [How we'll test]

**Success Criteria:** [What success looks like]

---

## Next Steps

- [ ] [Action item 1]
- [ ] [Action item 2]

---

## Appendix

- Link to market research
- Link to competitive analysis
- Link to user research

Prioritization Session Checklist

Use before and during prioritization sessions.

Pre-Session (1 day before)

[ ] Backlog cleaned and deduplicated
[ ] Each item has clear description
[ ] Effort estimates available
[ ] Impact data gathered (analytics, research)
[ ] Right stakeholders invited
[ ] Scoring framework selected (RICE/ICE/WSJF)
[ ] Previous priorities reviewed

During Session

Setup (10 min)

[ ] Align on goal being prioritized for
[ ] Confirm framework and scoring criteria
[ ] Set time box (2 hours max)

Scoring (60-90 min)

[ ] Each item scored independently first
[ ] Discuss outliers and disagreements
[ ] Document rationale for scores
[ ] Flag items needing more research

Ranking (20 min)

[ ] Sort by priority score
[ ] Review top 10 for sanity check
[ ] Identify dependencies
[ ] Note items moved for strategic reasons

Output (10 min)

[ ] Top priorities documented
[ ] Trade-offs recorded
[ ] Human decisions flagged
[ ] Next review date set

Post-Session

[ ] Priorities shared with team
[ ] Roadmap updated
[ ] Dependencies communicated
[ ] Calendar reminder for re-prioritization

Red Flags During Session

Red Flag	Action
No data for estimates	Stop, gather research first
One voice dominating	Ensure equal input
Scope creep on items	Separate into distinct items
Gaming the scores	Recalibrate criteria
Too many "high priority"	Force ranking

Framework Selection Guide

Situation	Recommended Framework
Steady-state product work	RICE
Quick rough prioritization	ICE
Time-sensitive decisions	WSJF
Many stakeholders	MoSCoW
Portfolio-level	Kano + RICE

Research Study Checklist

Complete checklist for running user research studies.

Planning Phase

Research Questions

[ ] Primary research questions defined
[ ] Secondary questions listed
[ ] Questions are specific and answerable
[ ] Method matches questions

Methodology

[ ] Method selected (interviews, usability, survey, etc.)
[ ] Appropriate for research questions
[ ] Timeline established
[ ] Resources allocated

Participants

[ ] Target participant profile defined
[ ] Inclusion criteria clear
[ ] Exclusion criteria clear
[ ] Sample size determined (5-8 for qual, 100+ for quant)
[ ] Recruitment channel identified
[ ] Incentive amount set

Preparation Phase

Materials

[ ] Discussion guide/test plan written
[ ] Prototype or artifact ready (if testing)
[ ] Recording consent form prepared
[ ] Note-taking template ready
[ ] Incentive fulfillment process set

Recruitment

[ ] Screener survey created
[ ] Recruitment started
[ ] Participants scheduled
[ ] Calendar invites sent
[ ] Reminder emails scheduled

Logistics

[ ] Room booked (if in-person)
[ ] Video call link generated (if remote)
[ ] Recording software tested
[ ] Note-taker confirmed
[ ] Backup plan for no-shows

Execution Phase

Before Each Session

[ ] Review participant profile
[ ] Test recording
[ ] Materials ready
[ ] Note-taker briefed

During Session

[ ] Consent obtained
[ ] Recording started
[ ] Follow discussion guide
[ ] Notes captured in real-time
[ ] Probing questions asked

After Each Session

[ ] Quick debrief (5 min)
[ ] Top takeaways noted
[ ] Recording saved
[ ] Incentive sent
[ ] Thank you sent

Analysis Phase

Data Processing

[ ] Notes cleaned up
[ ] Recordings uploaded
[ ] Transcripts generated (if needed)
[ ] Data organized by participant

Synthesis

[ ] Affinity mapping completed
[ ] Themes identified
[ ] Patterns documented
[ ] Quotes extracted
[ ] Insights generated

Output

[ ] Report/presentation created
[ ] Key findings highlighted
[ ] Recommendations provided
[ ] Limitations acknowledged
[ ] Next steps proposed

Sharing Phase

[ ] Stakeholders identified
[ ] Presentation scheduled
[ ] Report distributed
[ ] Raw data archived
[ ] Findings added to research repository
[ ] Follow-up research identified

{
  "version": "2.0.0",
  "organization": "OrchestKit",
  "date": "February 2026",
  "abstract": "Comprehensive product management frameworks covering business case analysis, market intelligence, product strategy, prioritization, OKRs/KPIs, personas, journey mapping, requirements engineering, and user research methods.",
  "ruleCount": 16,
  "categories": 4,
  "consolidatedFrom": [
    "business-case-analysis",
    "market-analysis-patterns",
    "product-strategy-frameworks",
    "prioritization-frameworks",
    "okr-kpi-patterns",
    "persona-journey-mapping",
    "requirements-engineering",
    "user-research-methods"
  ]
}

Build vs Buy vs Partner Decision Framework

Systematic approach for evaluating capability acquisition options.

Decision Matrix

Factor	BUILD	BUY	PARTNER
Core differentiator?	✅ Yes	❌ No	⚠️ Maybe
Competitive advantage?	✅ Yes	❌ No	⚠️ Depends
In-house expertise?	✅ Have	❌ Lack	⚠️ Some
Time to market critical?	❌ Slow	✅ Fast	✅ Fast
Budget constrained?	❌ Higher upfront	✅ Lower upfront	⚠️ Varies
Long-term control needed?	✅ Full	❌ Limited	⚠️ Negotiated
Customization required?	✅ Full	⚠️ Limited	⚠️ Depends

Scoring Template

## Build vs Buy vs Partner: [Capability Name]

### Scoring (1-5 each dimension)

| Dimension | BUILD | BUY | PARTNER |
|-----------|-------|-----|---------|
| Strategic Importance | | | |
| Capability Maturity | | | |
| Time to Value | | | |
| Total Cost (3yr) | | | |
| Risk Level | | | |
| **TOTAL** | | | |

### Recommendation: [BUILD/BUY/PARTNER]

### Rationale:
[Explain the decision]

### Conditions:
- [ ] [Condition 1]
- [ ] [Condition 2]

Cost Considerations

BUILD Costs

Development (engineering time)
Opportunity cost (what else could be built)
Maintenance (10-20% annual)
Infrastructure
Hiring/training

BUY Costs

License/subscription fees
Integration development
Vendor lock-in risk
Customization limitations
Annual price increases

PARTNER Costs

Revenue share
Dependency risk
Integration complexity
Coordination overhead
Brand association risk

Decision Tree

Is this a core differentiator?
├── YES → BUILD (protects competitive advantage)
└── NO → Is there a mature solution available?
         ├── YES → BUY (fastest time to value)
         └── NO → Is there a strategic partner?
                  ├── YES → PARTNER (shared risk/reward)
                  └── NO → BUILD (must create capability)

Red Flags by Option

BUILD Red Flags

No in-house expertise
Underestimated complexity
"We can do it better"
Core expertise elsewhere

BUY Red Flags

Heavy customization needed
Vendor lock-in concerns
Poor vendor track record
Integration nightmares

PARTNER Red Flags

Misaligned incentives
Competitor partnerships
Unclear value split
Dependency on partner roadmap

2026 Best Practices

Revisit decisions quarterly (market changes fast)
Consider AI/ML tool availability before building
Evaluate open-source alternatives
Factor in security/compliance requirements
Include exit strategy in evaluation

Competitive Analysis Guide

Framework for systematic competitor research.

Competitor Categories

DIRECT COMPETITORS
└── Same problem, same solution approach
└── Example: Cursor vs GitHub Copilot

INDIRECT COMPETITORS
└── Same problem, different solution
└── Example: AI coding vs traditional IDE plugins

POTENTIAL COMPETITORS
└── Adjacent players who could enter
└── Example: Cloud providers adding AI tools

Competitive Analysis Framework

1. Identify Competitors

# GitHub search for similar projects
gh search repos "langgraph workflow" --sort stars --limit 10

# Check related topics
gh api search/repositories?q=topic:ai-agents --jq '.items[].full_name'

2. Build Competitor Profiles

## Competitor: [Name]

### Overview
- Founded: [Year]
- Funding: $[Amount]
- Team size: [N]
- Headquarters: [Location]

### Product
- Core offering: [Description]
- Target segment: [Who they serve]
- Pricing: [Model and range]
- Technology: [Key tech stack]

### Positioning
- Value proposition: [Their pitch]
- Key differentiators: [What they claim]
- Messaging: [How they talk about themselves]

### Strengths
- [Strength 1]
- [Strength 2]

### Weaknesses
- [Weakness 1]
- [Weakness 2]

### Market Presence
- GitHub stars: [N]
- Monthly growth: [%]
- Community activity: [Active/Moderate/Low]

3. Feature Comparison Matrix

Feature	Us	Competitor A	Competitor B	Competitor C
Core capability 1	✅	✅	❌	✅
Core capability 2	✅	❌	✅	⚠️
Integration X	✅	✅	✅	❌
Pricing (entry)	$X	$Y	$Z	$W
Open source	✅	❌	✅	❌

4. Positioning Map

                    EASE OF USE
                        │
           ┌────────────┼────────────┐
           │    Us      │    [B]     │
HIGH ──────┼────────────┼────────────┼────── LOW
POWER      │            │            │   POWER
           │    [A]     │    [C]     │
           └────────────┼────────────┘
                        │
                    COMPLEXITY

5. SWOT Analysis

           HELPFUL              HARMFUL
         ┌─────────────┬─────────────┐
INTERNAL │ STRENGTHS   │ WEAKNESSES  │
         │ • Our tech  │ • Resources │
         │ • Our team  │ • Gaps      │
         ├─────────────┼─────────────┤
EXTERNAL │ OPPORTUN.   │ THREATS     │
         │ • Market    │ • [Comp A]  │
         │ • Trends    │ • Risks     │
         └─────────────┴─────────────┘

GitHub Signals to Track

# Star count and growth
gh api repos/owner/repo --jq '{stars: .stargazers_count}'

# Issue activity (community engagement)
gh api repos/owner/repo --jq '{open_issues: .open_issues_count}'

# Recent releases (shipping velocity)
gh release list --repo owner/repo --limit 5

# Contributor count
gh api repos/owner/repo/contributors --jq 'length'

Update Frequency

Signal	Check Frequency
Star growth	Weekly
Release notes	Per release
Pricing changes	Monthly
Feature launches	Per announcement
Full analysis	Quarterly

Interview Guide Template

Use this template to prepare for user interviews.

# Interview Guide: [Research Topic]

**Project:** [Project name]
**Date:** YYYY-MM-DD
**Interviewer:** [Name]
**Note-taker:** [Name]

---

## Research Questions

What do we want to learn?

1. [Primary research question]
2. [Secondary research question]
3. [Secondary research question]

---

## Participant Profile

| Criterion | Requirement |
|-----------|-------------|
| Role | [e.g., Product Manager] |
| Experience | [e.g., 2+ years] |
| Industry | [e.g., B2B SaaS] |
| Tool usage | [e.g., Uses [tool] weekly] |

---

## Interview Flow

### Warm-up (5 min)

**Script:**

"Thank you for taking the time to speak with me today. I'm [name] and I'm researching [topic]. This conversation will help us understand [goal].

There are no right or wrong answers - we want to learn from your experience. Is it okay if I record this for my notes? The recording won't be shared outside the team."


**Questions:**
- Tell me a bit about your role and what you do day-to-day.
- How long have you been in this role?

---

### Context Setting (10 min)

**Goal:** Understand their current workflow and context.

**Questions:**
1. Walk me through the last time you [relevant activity].
2. What tools or methods do you currently use for [task]?
3. How often do you [activity]?
4. Who else is involved in this process?

**Probes:**
- Can you tell me more about that?
- What happened next?
- How did that make you feel?

---

### Deep Dive (25 min)

**Goal:** Explore pain points and needs.

**Questions:**
1. What's the hardest part about [task]?
2. Can you tell me about a time when [task] went wrong?
3. What do you wish you could do that you can't today?
4. If you had a magic wand, what would you change?

**Jobs to be Done:**
- When [situation], what are you trying to accomplish?
- What does success look like for you?

---

### Concept Testing (optional, 15 min)

**Goal:** Get reaction to prototype or concept.

**Setup:**

"I'm going to show you something we're working on. It's an early concept, so don't worry about polish. I want to hear your honest reaction."


**Questions:**
1. What are your initial reactions?
2. What would you expect to happen if you [action]?
3. How would this fit into your current workflow?
4. What's missing that you'd need?

---

### Wrap-up (5 min)

**Questions:**
1. Is there anything else you'd like to share?
2. What's the one thing we should make sure to get right?
3. Who else should we talk to about this?

**Script:**

"Thank you so much for your time. This has been really helpful. Here's your [incentive]. We may follow up with additional questions - would that be okay?"


---

## After Interview

### Quick Debrief (5 min after)

- Top 3 takeaways:
- Surprises:
- Quotes to remember:

### Full Notes (within 24 hours)

- Clean up notes
- Highlight key quotes
- Tag themes
- Upload recording

Journey Map Workshop Guide

Facilitation guide for customer journey mapping sessions.

Workshop Structure

Total Time: 3-4 hours

1. Setup & Objectives (15 min)
2. Journey Stages Definition (30 min)
3. Touchpoint Mapping (45 min)
4. Emotional Journey (30 min)
5. Pain Points & Opportunities (45 min)
6. Prioritization (30 min)
7. Wrap-up & Next Steps (15 min)

Pre-Workshop Preparation

Materials

Large whiteboard or wall space
Sticky notes (5 colors)
Markers
Persona cards
Research findings summary
Journey map template (printed large)

Participants to Invite

Product Manager
Designer
Engineer (customer-facing features)
Customer Success/Support
Sales (if B2B)
Marketing
Real customer (ideal but optional)

Pre-Read

Existing user research
Support ticket analysis
Analytics highlights
Persona documentation

Journey Map Canvas

STAGE:      | Awareness | Consideration | Purchase | Onboarding | Use | Advocacy |
────────────┼───────────┼───────────────┼──────────┼────────────┼─────┼──────────┤
DOING       │           │               │          │            │     │          │
────────────┼───────────┼───────────────┼──────────┼────────────┼─────┼──────────┤
THINKING    │           │               │          │            │     │          │
────────────┼───────────┼───────────────┼──────────┼────────────┼─────┼──────────┤
FEELING     │   😐      │     🤔        │    😬    │     😊     │ 😃  │    🥰    │
────────────┼───────────┼───────────────┼──────────┼────────────┼─────┼──────────┤
TOUCHPOINTS │           │               │          │            │     │          │
────────────┼───────────┼───────────────┼──────────┼────────────┼─────┼──────────┤
PAIN POINTS │           │               │          │            │     │          │
────────────┼───────────┼───────────────┼──────────┼────────────┼─────┼──────────┤
OPPORTUN.   │           │               │          │            │     │          │

Workshop Flow

1. Setup & Objectives (15 min)

Facilitator Script:

"Today we're mapping the journey of [persona] as they
[goal/task]. Our objective is to identify pain points
and opportunities to improve their experience.

We'll use this journey map as our canvas. Let's start
by reviewing who [persona] is and what they're trying
to accomplish."

Review:

Persona overview
Journey scope (start and end points)
Research highlights

2. Journey Stages Definition (30 min)

Activity: Define 5-7 stages of the journey

Questions:

What triggers the journey? (Entry point)
What are the major phases?
What signals the end of each stage?
What does "success" look like? (Exit point)

Common B2B SaaS Stages:

Awareness → Evaluation → Purchase → Onboarding →
Adoption → Expansion → Advocacy/Churn

Common B2C Stages:

Discover → Research → Try → Buy → Use → Share

3. Touchpoint Mapping (45 min)

Activity: For each stage, map what the user DOES

Questions per stage:

What action does the user take?
What information do they seek?
What decisions do they make?
What channels do they use?

Sticky Note Prompts:

"Searches for..."
"Clicks on..."
"Asks about..."
"Compares..."
"Signs up for..."

4. Emotional Journey (30 min)

Activity: Map the emotional experience at each stage

For each touchpoint, ask:

How does the user feel at this moment?
What are they worried about?
What would delight them?

Emotion Scale:

😃 Delighted - Exceeded expectations
😊 Satisfied - Met expectations
😐 Neutral - No strong feeling
😟 Frustrated - Below expectations
😠 Angry - Major failure

Draw the emotional curve across stages.

5. Pain Points & Opportunities (45 min)

Pain Points (Red sticky notes):

Where does friction occur?
What causes frustration?
Where do users drop off?
What support tickets mention?

Opportunities (Green sticky notes):

How could we eliminate this pain?
What would delight users here?
What's the "magic moment" potential?
Quick wins vs. long-term improvements?

6. Prioritization (30 min)

Impact/Effort Matrix:

              HIGH IMPACT
                   │
        ┌──────────┼──────────┐
        │  DO NEXT │ DO FIRST │
LOW ────┼──────────┼──────────┼──── HIGH
EFFORT  │  MAYBE   │  PLAN    │    EFFORT
        └──────────┼──────────┘
                   │
              LOW IMPACT

Dot Voting:

Each person gets 5 dots
Vote on most valuable opportunities
Discuss top voted items

7. Wrap-up (15 min)

Document:

Top 3 pain points
Top 3 opportunities
Quick wins (< 1 sprint)
Key insights

Assign:

Owner for journey map document
Follow-up actions
Review date

Post-Workshop

Within 24 Hours

[ ] Photograph/export the physical map
[ ] Create digital version
[ ] Share with attendees

Within 1 Week

[ ] Create detailed journey map document
[ ] Prioritized improvement backlog
[ ] Share with broader team

Ongoing

[ ] Update as product evolves
[ ] Review quarterly
[ ] Validate with new research

OKR Workshop Guide

Facilitation guide for setting effective OKRs.

Workshop Structure

Total Time: 3-4 hours

1. OKR Foundations (20 min)
2. Review Company/Team Context (20 min)
3. Objective Brainstorming (45 min)
4. Key Result Definition (60 min)
5. Alignment Check (30 min)
6. Finalization (25 min)

Pre-Workshop Preparation

Materials Needed

Company/team strategy docs
Previous quarter OKR results
Whiteboard or Miro
Sticky notes (2 colors)
Timer
OKR template printouts

Pre-Read for Participants

Company OKRs (if cascade)
Previous quarter results
Strategic priorities for the period

1. OKR Foundations (20 min)

Facilitator Script

"OKRs help us focus on what matters most and align our efforts.
Today we'll set [N] Objectives with [M] Key Results each.

Key principles:
- Objectives are QUALITATIVE and INSPIRATIONAL
- Key Results are QUANTITATIVE and MEASURABLE
- Aim for 70% achievement (stretch, not sandbagging)
- Focus on outcomes, not outputs"

OKR Anatomy

OBJECTIVE: Qualitative, inspiring, time-bound
├── What do we want to achieve?
├── Why does it matter?
└── Is it ambitious but achievable?

KEY RESULT: Quantitative, measurable, has deadline
├── How will we know we succeeded?
├── Is it specific and unambiguous?
└── Can we track progress?

2. Review Context (20 min)

Questions to Discuss

1. What are the company's top priorities this quarter? 2. What did we learn from last quarter? 3. What constraints do we have (resources, dependencies)? 4. What opportunities should we capture?

Alignment Cascade

Company OKRs
    │
    ▼
Department OKRs (aligns to company)
    │
    ▼
Team OKRs (aligns to department)
    │
    ▼
Individual OKRs (optional, aligns to team)

3. Objective Brainstorming (45 min)

Silent Brainstorm (15 min)

Each participant writes 3-5 potential objectives
One objective per sticky note
Focus on outcomes, not activities

Share & Cluster (15 min)

Each person shares their objectives
Group similar objectives together
Identify themes

Vote & Select (15 min)

Dot voting (3 dots per person)
Select top 3-5 objectives
Discuss and refine wording

Objective Quality Check

Criterion	✓
Qualitative (no numbers)
Inspirational (energizing)
Time-bound (quarterly)
Actionable (within our control)
Aligned (to company/team strategy)

4. Key Result Definition (60 min)

For Each Objective (15 min each)

1. Brainstorm metrics (5 min)

What would prove we achieved this?
What leading indicators matter?
What lagging indicators confirm success?

2. Set targets (5 min)

What's our current baseline?
What's a stretch target (70% achievable)?
What's the minimum acceptable?

3. Refine wording (5 min)

Is it specific and measurable?
Is the target ambitious but realistic?
Can we track this?

Key Result Formula

[Verb] [metric] from [baseline] to [target] by [deadline]

Examples:
- Increase NPS from 32 to 50
- Reduce time-to-value from 14 days to 3 days
- Achieve 95% feature adoption in first 30 days

KR Quality Check

Criterion	✓
Quantitative (has number)
Measurable (we can track it)
Has baseline
Has target
Outcome-focused (not output)
70% achievable stretch

5. Alignment Check (30 min)

Vertical Alignment

Does this OKR support a higher-level objective?
Is the connection clear?

Horizontal Alignment

Do any OKRs conflict with other teams?
Are there dependencies we need to coordinate?

Sanity Check Questions

If we achieve all KRs, will we achieve the Objective?
Can we actually measure each KR?
Are we tracking too many things?

6. Finalization (25 min)

Final OKR Template

## Objective: [Inspiring statement]

**Key Results:**
1. [Verb] [metric] from [X] to [Y]
   - Baseline: X
   - Target: Y
   - Owner: @name

2. [Verb] [metric] from [X] to [Y]
   - Baseline: X
   - Target: Y
   - Owner: @name

3. [Verb] [metric] from [X] to [Y]
   - Baseline: X
   - Target: Y
   - Owner: @name

Post-Workshop Actions

[ ] Document final OKRs
[ ] Set up tracking dashboard
[ ] Schedule weekly check-ins
[ ] Schedule mid-quarter review
[ ] Share with stakeholders

Output Templates

Structured JSON output formats for consistent product deliverables. Each template shows the required structure with 1-2 example entries. Agents and skills producing these artifacts should conform to these schemas.

PRD Output

From requirements translation workflows.

{
  "prd": {
    "title": "Feature Name",
    "version": "1.0",
    "author": "PM Name",
    "status": "draft",
    "last_updated": "2026-03-01"
  },
  "problem_statement": "One-paragraph description of the user problem being solved.",
  "solution": "High-level solution approach.",
  "scope": {
    "in": ["User authentication via SSO", "Role-based access control"],
    "out": ["Custom SAML provider", "Mobile biometric auth"]
  },
  "user_stories": [
    {
      "id": "US-001",
      "persona": "Team Admin",
      "story": "As a team admin, I want to invite members via email, so that onboarding is self-service.",
      "acceptance_criteria": [
        "Invite email sent within 30 seconds",
        "Invited user can set password on first visit",
        "Admin sees pending/accepted status"
      ],
      "priority": "must-have"
    }
  ],
  "edge_cases": ["User invited to multiple teams simultaneously", "Expired invite link reuse"],
  "non_functional": {
    "performance": "Invite flow completes in < 2s p95",
    "security": "Invite tokens expire after 72 hours",
    "accessibility": "WCAG 2.1 AA"
  },
  "github_issues_to_create": [
    { "title": "Implement SSO invite flow", "labels": ["feature", "auth"], "estimate": "3d" }
  ]
}

Business Case Output

From business case analysis workflows.

{
  "investment_summary": {
    "total_investment": "$150,000",
    "expected_return": "$450,000",
    "payback_period": "8 months",
    "roi": "200%",
    "confidence": "medium"
  },
  "cost_breakdown": [
    { "category": "Engineering", "amount": "$100,000", "type": "one-time" },
    { "category": "Infrastructure", "amount": "$2,000/mo", "type": "recurring" }
  ],
  "benefit_projection": [
    { "benefit": "Support ticket reduction", "annual_value": "$180,000", "confidence": "high" },
    { "benefit": "Upsell conversion lift", "annual_value": "$270,000", "confidence": "medium" }
  ],
  "sensitivity_analysis": {
    "conservative": { "roi": "80%", "payback": "14 months" },
    "base": { "roi": "200%", "payback": "8 months" },
    "optimistic": { "roi": "350%", "payback": "5 months" }
  },
  "risks": [
    { "risk": "Integration delays", "probability": "medium", "impact": "high", "mitigation": "Prototype first" }
  ],
  "recommendation": "Proceed with phased rollout. Break-even achieved under conservative scenario."
}

Metrics Framework Output

From metrics architecture workflows.

{
  "okrs": [
    {
      "objective": "Improve activation rate for new teams",
      "key_results": [
        { "kr": "Increase Day-7 activation from 40% to 60%", "owner": "Growth" },
        { "kr": "Reduce time-to-first-value from 3 days to 1 day", "owner": "Product" }
      ]
    }
  ],
  "kpis": {
    "leading": ["Daily signups", "Onboarding completion rate", "Feature adoption in week 1"],
    "lagging": ["Monthly revenue", "Net retention rate", "Customer lifetime value"]
  },
  "instrumentation_plan": [
    {
      "event": "onboarding_step_completed",
      "properties": ["step_name", "duration_seconds", "skipped"],
      "trigger": "User completes or skips an onboarding step"
    }
  ],
  "hypothesis_validation": {
    "hypothesis": "Guided onboarding increases Day-7 activation by 20%",
    "primary_metric": "day_7_activation_rate",
    "guardrail_metrics": ["support_ticket_volume", "onboarding_drop_off_rate"]
  },
  "guardrail_metrics": ["Page load time p95 < 2s", "Error rate < 0.1%", "Support tickets per 1000 users < 5"],
  "review_cadence": "Weekly metrics review, monthly OKR check-in, quarterly strategy review"
}

Prioritization Report Output

From prioritization analysis workflows.

{
  "scored_features": [
    {
      "feature": "AI-powered search",
      "reach": 8,
      "impact": 2.0,
      "confidence": 0.8,
      "effort": 3,
      "rice_score": 4.27,
      "notes": "Prototype tested with 5 users"
    },
    {
      "feature": "CSV bulk import",
      "reach": 4,
      "impact": 1.0,
      "confidence": 1.0,
      "effort": 1,
      "rice_score": 4.0,
      "notes": "Top support request"
    }
  ],
  "opportunity_cost_analysis": [
    { "if_delayed": "AI-powered search", "cost_per_month": "$25,000 in lost conversions" }
  ],
  "dependencies": [
    { "feature": "AI-powered search", "depends_on": ["Search indexing upgrade"] }
  ],
  "trade_offs_for_human": [
    {
      "decision": "AI search vs bulk import first",
      "option_a": { "pros": ["Higher RICE", "Competitive differentiator"], "cons": ["3x effort", "Dependency risk"] },
      "option_b": { "pros": ["Quick win", "No dependencies"], "cons": ["Lower strategic value"] },
      "recommendation": "Human decides based on Q2 OKR alignment"
    }
  ],
  "recommended_sequence": ["CSV bulk import", "Search indexing upgrade", "AI-powered search"]
}

Research Report Output

From user research workflows.

{
  "personas": [
    {
      "name": "Alex the Admin",
      "role": "IT Administrator",
      "goals": ["Reduce onboarding time", "Maintain security compliance"],
      "pain_points": ["Manual user provisioning", "No audit trail"],
      "behaviors": ["Checks admin dashboard daily", "Prefers CLI over GUI"],
      "quotes": ["I spend 2 hours a week just adding new users."]
    }
  ],
  "journey_map": [
    {
      "stage": "Onboarding",
      "steps": [
        {
          "action": "Receives invite email",
          "thinking": "Is this legitimate?",
          "feeling": "cautious",
          "pain_points": ["Generic email looks like spam"],
          "opportunities": ["Branded email with admin's name"]
        }
      ]
    }
  ],
  "user_stories": [
    "As an IT admin, I want SCIM provisioning, so that user accounts sync automatically."
  ],
  "metrics": {
    "task_success_rate": "85%",
    "time_on_task": "4.2 minutes",
    "satisfaction_score": "3.8/5"
  },
  "recommendations": [
    { "priority": "high", "finding": "Onboarding email mistaken for spam", "action": "Add company branding and admin name" }
  ]
}

RICE Scoring Guide

Comprehensive guide for using RICE prioritization effectively.

RICE Formula

RICE Score = (Reach × Impact × Confidence) / Effort

Reach Scoring

Estimate how many users/customers will be affected per quarter.

Score	% of Users	Description
10	100%	All users
8	80%	Most users
5	50%	Half of users
3	30%	Some users
1	10%	Few users

Calculating Reach

Reach = (Users affected) / (Total users) × 10

Example:
- Total MAU: 10,000
- Users who use search: 8,000
- Reach for search improvement: 8,000/10,000 × 10 = 8

Impact Scoring

How much will this move the needle on your goal?

Score	Impact Level	Description
3.0	Massive	3x or more improvement
2.0	High	2x improvement
1.0	Medium	Notable improvement
0.5	Low	Minor improvement
0.25	Minimal	Barely noticeable

Impact Assessment Questions

1. What metric does this affect? 2. By how much will it change? 3. What's the baseline? 4. What's the target?

Confidence Scoring

How certain are you about Reach and Impact estimates?

Score	Confidence	Evidence Level
1.0	High	Data-backed (analytics, A/B tests)
0.8	Medium	Some validation (user interviews, surveys)
0.5	Low	Gut feel (experienced intuition)
0.3	Moonshot	Speculative (new territory)

Confidence Calibration

Used similar feature before? → +0.2
Have user research? → +0.2
Have analytics data? → +0.2
New domain/technology? → -0.2
Many unknowns? → -0.2

Effort Scoring

Person-weeks of work to ship (design, development, testing).

Score	Effort	Timeline
0.5	Trivial	< 1 week
1	Small	1 week
2	Medium	2 weeks
4	Large	1 month
8	XL	2 months
16	XXL	Quarter

Effort Estimation Tips

Include all disciplines (design, eng, QA)
Add buffer for unknowns (1.2-1.5x)
Consider dependencies
Account for coordination overhead

Example Scoring

## Feature: Advanced Search Filters

### Reach: 8
- 80% of users use search at least once/week
- Source: Analytics dashboard

### Impact: 2.0
- Support tickets about search: 40/week
- Expected reduction: 50%
- Secondary: +10% search completion rate

### Confidence: 0.8
- Have user interview data (5 users)
- Similar feature at competitor successful
- No A/B test yet

### Effort: 2
- Design: 0.5 weeks
- Backend: 1 week
- Frontend: 0.5 weeks

### RICE Score
(8 × 2.0 × 0.8) / 2 = 6.4

Common Mistakes

Mistake	Solution
Overestimating reach	Use actual data, not hopes
Impact without baseline	Define current state first
100% confidence	Nothing is certain
Underestimating effort	Include all work, add buffer
Comparing across goals	Only compare within same goal

When NOT to Use RICE

Mandatory compliance/security work
Technical debt paydown
Infrastructure investments
Strategic bets with long payoff

ROI Calculation Guide

Comprehensive guide for calculating Return on Investment for product decisions.

Basic ROI Formula

ROI = ((Net Benefit) / Total Investment) × 100%

Net Benefit = Total Benefits - Total Costs

Detailed Cost Breakdown

One-Time Costs (CAPEX)

Development Costs
├── Engineering hours × hourly rate
├── Design/UX hours × hourly rate
├── QA/Testing hours × hourly rate
├── Project management overhead (15-20%)
└── Infrastructure setup

Example:
- 4 engineers × 40 hrs/week × 4 weeks × $100/hr = $64,000
- 1 designer × 40 hrs/week × 2 weeks × $90/hr = $7,200
- QA (20% of eng) = $12,800
- PM overhead (15%) = $12,600
Total Development: $96,600

Recurring Costs (OPEX)

Operational Costs (Annual)
├── Infrastructure (hosting, compute)
├── Maintenance (10-20% of dev cost)
├── Support (tickets × cost/ticket)
├── Monitoring/observability
└── Security/compliance

Example:
- Infrastructure: $12,000/year
- Maintenance (15%): $14,490/year
- Support: 50 tickets/month × $20 = $12,000/year
Total Annual: $38,490

Opportunity Costs

What else could we do with these resources?

Delayed features (revenue impact)
Team context switching
Technical debt not addressed
Market timing missed

Benefit Categories

Quantifiable Revenue Benefits

Revenue Benefits
├── New customer acquisition
│   └── New customers × ARPU × 12 months
├── Upsell/expansion
│   └── Existing customers × upsell rate × additional ARPU
├── Reduced churn
│   └── Customers retained × ARPU × months retained
└── Price increase enablement
    └── Customers × price increase

Quantifiable Cost Savings

Cost Savings
├── Reduced support tickets
│   └── Tickets reduced × cost/ticket
├── Faster onboarding
│   └── Time saved × support hourly rate
├── Automation savings
│   └── Hours automated × employee hourly rate
└── Infrastructure efficiency
    └── Resources freed × cost

Intangible Benefits

Document but don't include in ROI calculation:

Market positioning
Developer experience
Brand/reputation
Technical foundation for future features

Example ROI Calculation

## Investment: Search Feature Improvement

### Costs (3-Year Total)
| Category | Year 1 | Year 2 | Year 3 | Total |
|----------|--------|--------|--------|-------|
| Development | $96,600 | $0 | $0 | $96,600 |
| Infrastructure | $12,000 | $12,600 | $13,230 | $37,830 |
| Maintenance | $14,490 | $15,215 | $15,975 | $45,680 |
| **Total Costs** | $123,090 | $27,815 | $29,205 | **$180,110** |

### Benefits (3-Year Total)
| Category | Year 1 | Year 2 | Year 3 | Total |
|----------|--------|--------|--------|-------|
| New Revenue | $120,000 | $180,000 | $240,000 | $540,000 |
| Cost Savings | $36,000 | $42,000 | $48,000 | $126,000 |
| **Total Benefits** | $156,000 | $222,000 | $288,000 | **$666,000** |

### ROI Calculation
- Total Investment: $180,110
- Total Benefits: $666,000
- Net Benefit: $485,890
- ROI: (485,890 / 180,110) × 100% = **270%**
- Payback Period: $180,110 / ($666,000/36 months) = **9.7 months**

Payback Period

Payback Period = Total Investment / Monthly Net Benefit

Good: < 12 months
Acceptable: 12-24 months
Risky: > 24 months

Sensitivity Analysis

Always calculate three scenarios:

Scenario	Assumption	ROI
Conservative (P10)	50% of expected benefits	X%
Base Case (P50)	Expected benefits	Y%
Optimistic (P90)	150% of expected benefits	Z%

Common Mistakes

Mistake	Correction
Forgetting opportunity cost	Include what else could be built
Single-point estimates	Use ranges and scenarios
Ignoring maintenance	Add 10-20% annually
Counting intangibles	Keep separate from hard ROI
Not discounting future	Apply discount rate for NPV

TAM/SAM/SOM Market Sizing Guide

Comprehensive guide for market size estimation.

Definitions

TAM (Total Addressable Market)
└── "If we had 100% of the entire market"
└── The total market demand for a product/service

SAM (Serviceable Addressable Market)
└── "Segment we can actually reach"
└── TAM filtered by geography, segment, channel

SOM (Serviceable Obtainable Market)
└── "Realistic capture in 3 years"
└── SAM filtered by competition, capacity, go-to-market

Visual Hierarchy

┌─────────────────────────────────────────────────┐
│                    TAM                           │
│                 $10 Billion                      │
│  ┌─────────────────────────────────────────┐    │
│  │                SAM                       │    │
│  │             $500 Million                 │    │
│  │  ┌────────────────────────────────────┐ │    │
│  │  │              SOM                    │ │    │
│  │  │           $10 Million               │ │    │
│  │  └────────────────────────────────────┘ │    │
│  └─────────────────────────────────────────┘    │
└─────────────────────────────────────────────────┘

TAM Calculation Methods

Top-Down Approach

Start with industry reports and filter down.

Example: AI Developer Tools
1. Global software developer population: 27M (Statista 2026)
2. Developers using AI tools: 60% = 16.2M
3. Average spend on AI tools: $300/year
4. TAM = 16.2M × $300 = $4.86B

Bottom-Up Approach

Start with unit economics and scale up.

Example: AI Developer Tools
1. Target customer: Enterprise dev team (10+ devs)
2. Estimated teams globally: 500,000
3. Average contract value: $10,000/year
4. TAM = 500,000 × $10,000 = $5B

Cross-Reference

Always use both methods and reconcile:

Method	TAM	Notes
Top-Down	$4.86B	Based on Statista data
Bottom-Up	$5.0B	Based on enterprise segments
Reconciled	$4.9B	Average, validated range

SAM Calculation

Filter TAM by your actual reach:

Example: AI Developer Tools (US/EU focus)
TAM: $4.9B

Filters:
- Geography (US/EU only): 40% → $1.96B
- Segment (Enterprise only): 30% → $588M
- Use case (Python/TS devs): 80% → $470M

SAM: $470M

SOM Calculation

What you can realistically capture:

Example: AI Developer Tools
SAM: $470M

Constraints:
- Market share goal (3 years): 3%
- Competitive pressure: -20%
- Sales capacity: supports $15M ARR
- Go-to-market reach: 70%

Conservative SOM: min($470M × 3%, $15M, $470M × 70% × 3%)
= min($14.1M, $15M, $9.87M)
= $9.87M → Round to $10M

SOM: $10M (3-year target)

Data Sources

Primary Sources (Higher Confidence)

Gartner, Forrester, IDC reports
Company financials (public competitors)
Industry associations
Government statistics

Secondary Sources (Lower Confidence)

Press releases
Expert interviews
Survey data
LinkedIn data (company sizes)

Confidence Levels

Confidence	Evidence
HIGH	Multiple corroborating sources, recent data
MEDIUM	Single authoritative source, 1-2 years old
LOW	Extrapolated, assumptions, old data

Common Mistakes

Mistake	Correction
TAM = "everyone"	Define specific customer segment
Ignoring competition	SOM must account for competitors
Old data	Use most recent (<2 years)
Single method	Cross-validate top-down and bottom-up
Confusing TAM/SAM	TAM is total, SAM is your reach

User Story Workshop Guide

Facilitation guide for effective user story writing sessions.

Workshop Structure

Total Time: 2-3 hours

1. Context Setting (15 min)
2. Persona Review (15 min)
3. Story Mapping (45 min)
4. Story Writing (45 min)
5. Acceptance Criteria (30 min)
6. Prioritization (20 min)
7. Wrap-up (10 min)

1. Context Setting (15 min)

Facilitator Script

"Today we're writing user stories for [feature]. Our goal is to
break down the work into independent, valuable pieces that can
be estimated and prioritized.

Remember: We're focusing on WHAT users need, not HOW we'll build it."

Materials Needed

Large whiteboard or Miro board
Sticky notes (3 colors: personas, stories, criteria)
Sharpies
Timer
Persona cards (printed)

2. Persona Review (15 min)

Review the primary persona(s) for this feature:

Quick Refresher:
- Who is [Persona Name]?
- What are their top 3 goals?
- What are their top 3 pain points?
- What context do they work in?

Activity

Each participant writes 1 "Job to be Done" for the persona on a sticky note.

3. Story Mapping (45 min)

Backbone Creation

USER JOURNEY: [Feature Name]

Discovery → Setup → First Use → Regular Use → Mastery
    │          │         │           │           │
    ▼          ▼         ▼           ▼           ▼
[Stories] [Stories] [Stories]  [Stories]   [Stories]

Process

1. Identify journey stages (10 min) 2. Add activities under each stage (15 min) 3. Break activities into stories (20 min)

4. Story Writing (45 min)

Template

As a [persona],
I want to [action/goal],
so that [benefit/outcome].

INVEST Check (for each story)

Criterion	Question	✓
Independent	Can this be built separately?
Negotiable	Are details discussable?
Valuable	Does this deliver user value?
Estimable	Can the team size this?
Small	Does this fit in a sprint?
Testable	Can we verify it's done?

Common Story Splits

If story is too big...	Split by...
Multiple user types	Different personas
Multiple actions	Workflow steps
Multiple data types	Data variations
Multiple platforms	Platform/device
Complex rules	Simple → complex rules

5. Acceptance Criteria (30 min)

Given-When-Then Format

Scenario: [Scenario name]
  Given [precondition/context]
  When [action taken]
  Then [expected result]
  And [additional result]

Example

Scenario: User filters search results by date
  Given I have search results displayed
  And the date filter is visible
  When I select "Last 7 days"
  Then only results from the last 7 days are shown
  And the filter shows "Last 7 days" as selected
  And the result count updates

Edge Cases to Consider

Empty states (no data)
Error conditions
Boundary values
Permission variations
Network failures

6. Prioritization (20 min)

MoSCoW Quick Sort

Category	Meaning	Time allocation
Must	MVP, launch blocker	60%
Should	Important, not blocking	20%
Could	Nice to have	15%
Won't	Out of scope	5% (document why)

Dot Voting

Each participant gets 3 dots
Vote on most valuable stories
Count votes, sort by priority

7. Wrap-up (10 min)

Deliverables Checklist

[ ] Stories mapped to journey
[ ] Each story has acceptance criteria
[ ] Stories prioritized (MoSCoW)
[ ] Dependencies identified
[ ] Next steps assigned

Follow-up Actions

[ ] Transfer to issue tracker
[ ] Schedule estimation session
[ ] Share with stakeholders

Value Proposition Canvas Guide

Detailed guide for using the Value Proposition Canvas to align products with customer needs.

Canvas Structure

┌─────────────────────────────────────────────────────────────┐
│                    VALUE PROPOSITION MAP                     │
├─────────────────────────────────────────────────────────────┤
│  CUSTOMER PROFILE         │  VALUE MAP                      │
│  ┌─────────────────────┐  │  ┌─────────────────────────┐    │
│  │ Jobs to be Done     │◄─┼──│ Products & Services     │    │
│  │ • Functional jobs   │  │  │ • Features              │    │
│  │ • Social jobs       │  │  │ • Capabilities          │    │
│  │ • Emotional jobs    │  │  │ • Integrations          │    │
│  ├─────────────────────┤  │  ├─────────────────────────┤    │
│  │ Pains               │◄─┼──│ Pain Relievers          │    │
│  │ • Obstacles         │  │  │ • Eliminates            │    │
│  │ • Risks             │  │  │ • Reduces               │    │
│  │ • Negative outcomes │  │  │ • Prevents              │    │
│  ├─────────────────────┤  │  ├─────────────────────────┤    │
│  │ Gains               │◄─┼──│ Gain Creators           │    │
│  │ • Required gains    │  │  │ • Creates               │    │
│  │ • Expected gains    │  │  │ • Increases             │    │
│  │ • Desired gains     │  │  │ • Enables               │    │
│  └─────────────────────┘  │  └─────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘

Jobs to be Done Categories

Job Type	Definition	Example
Functional	Tasks to accomplish	"Deploy code to production"
Social	How to be perceived	"Be seen as innovative"
Emotional	How to feel	"Feel confident in decisions"

Pain Severity Ranking

CRITICAL  ────────────────────────────►  MINOR
│                                            │
│  Blocking     Painful      Annoying       │
│  (must fix)   (should fix) (nice to fix)  │

Gain Importance Ranking

REQUIRED  ────────────────────────────►  NICE-TO-HAVE
│                                            │
│  Expected     Desired      Unexpected     │
│  (table stakes) (differentiators) (delighters)

Fit Assessment

Fit Level	Criteria
Problem-Solution Fit	Evidence that value prop addresses real jobs/pains
Product-Market Fit	Evidence customers will pay for solution
Business Model Fit	Evidence of sustainable business model

Workshop Facilitation

1. Preparation (30 min before)

Print large canvas
Prepare sticky notes (different colors for jobs/pains/gains)
Gather customer research

2. Customer Profile First (45 min)

Each participant adds sticky notes silently (10 min)
Group discussion and clustering (20 min)
Prioritization voting (15 min)

3. Value Map Second (45 min)

Map features to jobs/pains/gains
Identify gaps
Prioritize what to build

4. Fit Assessment (30 min)

Score fit for each connection
Identify highest-value opportunities
Document assumptions to validate

Common Mistakes

Mistake	Correction
Starting with solution	Start with customer jobs
Listing features	Focus on outcomes
Ignoring emotional jobs	Include all job types
Single customer segment	Separate canvas per segment
No prioritization	Vote on importance

2026 Updates

AI-assisted job identification from support tickets
Automated pain/gain extraction from user interviews
Real-time fit scoring with analytics data

WSJF (Weighted Shortest Job First) Guide

Framework for prioritizing when time-to-market matters.

WSJF Formula

WSJF = Cost of Delay / Job Size

Higher WSJF = Higher priority (do first)

Cost of Delay Components

Cost of Delay = User Value + Time Criticality + Risk Reduction

User Value (1-10)

How much do users need this?

Score	Description
10	Critical - users leaving without it
7-9	High - major pain point
4-6	Medium - nice improvement
1-3	Low - minor enhancement

Time Criticality (1-10)

How urgent is the timing?

Score	Description
10	Hard deadline (regulatory, event)
7-9	Competitive window closing
4-6	Sooner better, but flexible
1-3	No time pressure

Risk Reduction (1-10)

Does delay increase risk?

Score	Description
10	Major risk if delayed (security, stability)
7-9	Significant risk accumulation
4-6	Moderate risk growth
1-3	Risk doesn't change with time

Job Size (1-10)

Relative size compared to other work.

Score	Description
1-2	XS - days
3-4	S - 1-2 weeks
5-6	M - 2-4 weeks
7-8	L - 1-2 months
9-10	XL - quarter+

Example Calculation

## Feature: Security Patch for CVE

### User Value: 6
- Affects enterprise customers
- Not user-facing but required for compliance

### Time Criticality: 9
- CVE published, 90-day disclosure window
- Competitors already patched

### Risk Reduction: 10
- Active exploitation in the wild
- Potential data breach

### Cost of Delay: 6 + 9 + 10 = 25

### Job Size: 3
- Known fix, straightforward implementation
- ~1 week of work

### WSJF: 25 / 3 = 8.33

When to Use WSJF

Multiple time-sensitive items competing
Opportunity windows exist
Dependencies create bottlenecks
Need to justify "why now"

WSJF vs RICE

Use WSJF When	Use RICE When
Time matters	Value matters
Deadlines exist	Steady-state prioritization
Dependencies complex	Independent features
Opportunity cost high	User reach important

Visualization

              HIGH Time Criticality
                      │
           ┌──────────┼──────────┐
           │    DO    │   DO     │
           │   FIRST  │  SECOND  │
HIGH ──────┼──────────┼──────────┼────── LOW
User Value │    DO    │   DO     │  User Value
           │  THIRD   │  LAST    │
           └──────────┼──────────┘
                      │
              LOW Time Criticality

Rule Categories

1. Business & Market (business, market) -- HIGH -- 4 rules

Financial analysis and market intelligence frameworks for investment decisions.

business-roi.md -- ROI, NPV, IRR, payback period calculations with Python examples
business-cost-benefit.md -- TCO analysis, build vs buy comparison, sensitivity analysis, business case template
market-tam-sam-som.md -- TAM/SAM/SOM market sizing with top-down and bottom-up methods
market-competitive.md -- Porter's Five Forces, SWOT analysis, TOWS matrix, competitive positioning maps

2. Strategy & Prioritization (strategy, prioritize) -- HIGH -- 5 rules

Strategic decision frameworks and quantitative prioritization methods.

strategy-value-prop.md -- Value Proposition Canvas, JTBD framework, customer profile, fit assessment
strategy-go-no-go.md -- Stage gate criteria, weighted scoring, decision thresholds, build/buy/partner matrix
prioritize-rice.md -- RICE scoring (Reach, Impact, Confidence, Effort), ICE framework, Kano model
prioritize-wsjf.md -- WSJF cost of delay, time criticality, MoSCoW method, framework selection
prioritize-opportunity-cost.md -- Opportunity cost matrix, cost of delay analysis, trade-off flagging, feature sequencing

3. Metrics & OKRs (metrics) -- HIGH -- 5 rules

Goal-setting and measurement frameworks for metrics-driven teams.

metrics-okr.md -- OKR structure, writing objectives and key results, quarterly examples
metrics-kpi-trees.md -- Revenue and product health KPI trees, North Star metric, input metrics
metrics-leading-lagging.md -- Leading vs lagging indicators, the leading-lagging chain, balanced dashboards
metrics-instrumentation.md -- Metric definition template, data sources, segments, alerting thresholds
metrics-experiment-design.md -- Experiment design template, guardrail metrics, North Star input/output framework, staged rollout

4. Research & Requirements (research) -- HIGH -- 4 rules

User research methods and requirements documentation patterns.

research-personas.md -- User persona template, empathy maps, persona examples, maintenance schedule
research-journey-mapping.md -- Customer journey maps, service blueprints, experience curves
research-user-interviews.md -- Interview guides, usability testing, surveys, card sorting, research repository
research-requirements-prd.md -- PRD template, user stories, acceptance criteria, INVEST, definition of ready/done

Cost-Benefit & Total Cost of Ownership

Build vs. Buy TCO Comparison

## Build Option (3-Year TCO)

### Year 1
| Category | Cost |
|----------|------|
| Development team (4 FTEs x $150K) | $600,000 |
| Infrastructure setup | $50,000 |
| Tools & licenses | $20,000 |
| **Year 1 Total** | **$670,000** |

### Year 2-3 (Maintenance)
| Category | Annual Cost |
|----------|-------------|
| Maintenance team (2 FTEs) | $300,000 |
| Infrastructure | $60,000 |
| Technical debt | $50,000 |
| **Annual Total** | **$410,000** |

### 3-Year Build TCO: $1,490,000

---

## Buy Option (3-Year TCO)

| Category | Annual Cost |
|----------|-------------|
| SaaS license (100 users x $500) | $50,000 |
| Implementation (Year 1 only) | $100,000 |
| Training | $20,000 |
| Integration maintenance | $30,000 |
| **Year 1** | **$200,000** |
| **Year 2-3** | **$100,000/year** |

### 3-Year Buy TCO: $400,000

Hidden Costs to Include

Category	Build	Buy
Opportunity cost	Yes - team could work on other things	No
Learning curve	Yes - building expertise	Yes - learning vendor
Switching costs	N/A	Yes - vendor lock-in
Downtime risk	Yes - you own uptime	Partial - SLA coverage
Security/compliance	Yes - your responsibility	Shared - vendor handles some

Business Case Template

# Business Case: [Project Name]

## Executive Summary
[2-3 sentence summary of investment and expected return]

## Financial Analysis

### Investment Required
| Item | One-Time | Annual |
|------|----------|--------|
| Software license | | $X |
| Implementation | $X | |
| Training | $X | |
| Integration | $X | $X |
| **Total** | **$X** | **$X** |

### Expected Benefits
| Benefit | Annual Value | Confidence |
|---------|--------------|------------|
| Time savings (X hrs x $Y/hr) | $X | High |
| Error reduction | $X | Medium |
| Revenue increase | $X | Low |
| **Total** | **$X** | |

### Key Metrics
| Metric | Value |
|--------|-------|
| 3-Year TCO | $X |
| 3-Year Benefits | $X |
| NPV (10% discount) | $X |
| IRR | X% |
| Payback Period | X months |
| ROI | X% |

## Risk Analysis
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|
| | | | |

## Recommendation
[GO / NO-GO with rationale]

Sensitivity Analysis

Test how results change with different assumptions.

Scenario	Discount Rate	Year 1 Benefits	NPV
Base case	10%	$200,000	$258,157
Conservative	15%	$150,000	$102,345
Optimistic	8%	$250,000	$412,890
Pessimistic	12%	$120,000	$32,456

Cost Breakdown Framework

One-Time Costs (CAPEX)

Development Costs
+-- Engineering hours x hourly rate
+-- Design/UX hours x hourly rate
+-- QA/Testing hours x hourly rate
+-- Project management overhead (15-20%)
+-- Infrastructure setup

Recurring Costs (OPEX)

Operational Costs (Annual)
+-- Infrastructure (hosting, compute)
+-- Maintenance (10-20% of dev cost)
+-- Support (tickets x cost/ticket)
+-- Monitoring/observability
+-- Security/compliance

Incorrect — Ignoring hidden costs and opportunity cost:

## Cost Analysis
Total development cost: $500,000
Expected benefit: $1M over 3 years
ROI: 100% - APPROVED

Correct — Comprehensive TCO with hidden costs:

## 3-Year TCO Analysis
Development: $500,000
Maintenance (Years 2-3): $300,000/year = $600,000
Opportunity cost (team could build $800K revenue feature): $800,000
Total TCO: $1,900,000

Benefits: $1,000,000
Net: -$900,000 - REJECTED

ROI & Financial Metrics

Financial frameworks for justifying investments and evaluating projects.

Return on Investment (ROI)

ROI = (Net Benefits - Total Costs) / Total Costs x 100%

Example:

Project cost: $500,000
Annual benefits: $200,000 over 5 years

Total benefits: $1,000,000
ROI = ($1,000,000 - $500,000) / $500,000 x 100% = 100%

Limitation: Does not account for time value of money.

Net Present Value (NPV)

Gold standard for project evaluation -- discounts future cash flows to present value.

NPV = Sum(Cash Flow_t / (1 + r)^t) - Initial Investment

def calculate_npv(
    initial_investment: float,
    cash_flows: list[float],
    discount_rate: float = 0.10  # 10% typical
) -> float:
    npv = -initial_investment
    for t, cf in enumerate(cash_flows, start=1):
        npv += cf / ((1 + discount_rate) ** t)
    return npv

# Example: $500K investment, $200K/year for 5 years
npv = calculate_npv(500_000, [200_000] * 5, 0.10)
# NPV = $258,157 (positive = good investment)

Decision Rule:

NPV > 0: Accept (creates value)
NPV < 0: Reject (destroys value)
NPV = 0: Indifferent

Internal Rate of Return (IRR)

The discount rate at which NPV equals zero.

def calculate_irr(cash_flows: list[float]) -> float:
    """cash_flows[0] is initial investment (negative)"""
    from scipy.optimize import brentq

    def npv_at_rate(r):
        return sum(cf / (1 + r) ** t for t, cf in enumerate(cash_flows))

    return brentq(npv_at_rate, -0.99, 10.0)

# Example: -$500K initial, then $200K/year for 5 years
irr = calculate_irr([-500_000, 200_000, 200_000, 200_000, 200_000, 200_000])
# IRR ~ 28.6%

Decision Rule:

IRR > hurdle rate: Accept
IRR < hurdle rate: Reject

Typical Hurdle Rates:

Conservative enterprise: 10-12%
Growth company: 15-20%
Startup: 25-40%

Payback Period

Payback Period = Initial Investment / Annual Cash Flow

Typical Expectations:

SaaS investments: 6-12 months
Enterprise platforms: 12-24 months
Infrastructure: 24-36 months

Common Pitfalls

Pitfall	Mitigation
Overestimating benefits	Use conservative estimates, document assumptions
Ignoring soft costs	Include training, change management, productivity dip
Underestimating timeline	Add 30-50% buffer to implementation estimates
Sunk cost fallacy	Evaluate future costs/benefits only
Confirmation bias	Have skeptic review the case

Incorrect — Using simple ROI without time value of money:

Investment: $500,000
Total benefits over 5 years: $1,000,000
ROI = ($1M - $500K) / $500K = 100% - APPROVED

Correct — Using NPV to account for time value:

npv = calculate_npv(
    initial_investment=500_000,
    cash_flows=[200_000] * 5,
    discount_rate=0.10
)
# NPV = $258,157 (positive, but much less than naive ROI)
# Accept if NPV > 0 and meets hurdle rate

Competitive Analysis

Frameworks for analyzing competition and understanding industry dynamics.

Porter's Five Forces

                    +---------------------+
                    |  Threat of New      |
                    |     Entrants        |
                    |    (Barrier height) |
                    +---------+-----------+
                              |
                              v
+-----------------+    +-----------------+    +-----------------+
|   Bargaining    |    |   Competitive   |    |   Bargaining    |
|   Power of      |<---|    Rivalry      |--->|   Power of      |
|   Suppliers     |    |  (Intensity)    |    |    Buyers       |
+-----------------+    +---------+-------+    +-----------------+
                              |
                              v
                    +---------------------+
                    |  Threat of          |
                    |   Substitutes       |
                    | (Alternative ways)  |
                    +---------------------+

Force Analysis Template

## Porter's Five Forces: [Industry]

### 1. Competitive Rivalry -- Intensity: HIGH / MEDIUM / LOW
| Factor | Assessment |
|--------|------------|
| Number of competitors | |
| Industry growth rate | |
| Product differentiation | |
| Exit barriers | |

### 2. Threat of New Entrants -- Threat Level: HIGH / MEDIUM / LOW
| Barrier | Strength |
|---------|----------|
| Economies of scale | |
| Brand loyalty | |
| Capital requirements | |
| Network effects | |

### 3-5. [Supplier power, Buyer power, Substitutes]
[Same structure]

### Overall Industry Attractiveness: X/10

SWOT Analysis

+-------------------------+-------------------------+
|       STRENGTHS         |       WEAKNESSES        |
|       (Internal +)      |       (Internal -)      |
| * What we do well       | * Where we lack         |
| * Unique resources      | * Resource gaps          |
| * Competitive advantages| * Capability limits     |
+-------------------------+-------------------------+
|      OPPORTUNITIES      |         THREATS         |
|       (External +)      |       (External -)      |
| * Market trends         | * Competitive pressure  |
| * Unmet needs           | * Regulatory changes    |
| * Technology shifts     | * Economic factors      |
+-------------------------+-------------------------+

SWOT to Strategy (TOWS Matrix)

	Strengths	Weaknesses
Opportunities	SO Strategies: Use strengths to capture opportunities	WO Strategies: Overcome weaknesses to capture opportunities
Threats	ST Strategies: Use strengths to mitigate threats	WT Strategies: Minimize weaknesses and avoid threats

Competitive Landscape Map

                    HIGH PRICE
                        |
         Premium        |        Luxury
         Leaders        |        Niche
    +-------------+     |     +-------------+
    |  [Comp A]   |     |     |  [Comp B]   |
    +-------------+     |     +-------------+
                        |
LOW --------------------+-------------------- HIGH
FEATURES                |                   FEATURES
                        |
    +-------------+     |     +-------------+
    |  [Comp C]   |     |     |    [US]     |
    +-------------+     |     +-------------+
         Budget         |       Value
         Options        |       Leaders
                        |
                    LOW PRICE

Competitor Profile Template

## Competitor: [Name]

### Overview
- **Founded:** [Year]
- **Funding:** $[Amount]
- **Employees:** [N]

### Product
- **Core offering:** [Description]
- **Key features:** [List]
- **Pricing:** [Model]
- **Target customer:** [Segment]

### Strengths / Weaknesses
1. [Strength/Weakness]
2. [Strength/Weakness]

### Threat Assessment: HIGH / MEDIUM / LOW

GitHub Signals to Track

# Star count and growth
gh api repos/owner/repo --jq '{stars: .stargazers_count}'

# Recent releases (shipping velocity)
gh release list --repo owner/repo --limit 5

# Contributor count
gh api repos/owner/repo/contributors --jq 'length'

Update Frequency

Signal	Check Frequency
Star growth	Weekly
Release notes	Per release
Pricing changes	Monthly
Feature launches	Per announcement
Full analysis	Quarterly

Incorrect — Vague competitive assessment:

## Competitors
- Company A: Big player, lots of features
- Company B: Cheaper option
- Company C: New entrant

Correct — Structured competitive analysis with SWOT:

## Competitor: Company A

### Strengths / Weaknesses
+ Established brand, 60% market share
+ Enterprise features (SSO, RBAC)
- Legacy UI, poor mobile experience
- Slow release cycle (quarterly)

### Threat Assessment: HIGH
- Direct competitor in enterprise segment
- Strong sales team, existing relationships

### Our Differentiation
- Modern UX, mobile-first
- Weekly releases, faster iteration

TAM/SAM/SOM Market Sizing

Market sizing from total opportunity to achievable share.

Framework Overview

+-------------------------------------------------------+
|                         TAM                            |
|        Total Addressable Market                        |
|     (Everyone who could possibly buy)                  |
|  +---------------------------------------------------+|
|  |                      SAM                           ||
|  |       Serviceable Addressable Market               ||
|  |    (Segment you can actually reach)                ||
|  |  +-----------------------------------------------+||
|  |  |                   SOM                          |||
|  |  |     Serviceable Obtainable Market              |||
|  |  |   (Realistic share you can capture)            |||
|  |  +-----------------------------------------------+||
|  +---------------------------------------------------+|
+-------------------------------------------------------+

Metric	Definition	Example
TAM	Total market demand globally	All project management software: $10B
SAM	Your target segment	Enterprise PM software in North America: $3B
SOM	What you can realistically capture	First 3 years with current resources: $50M

Calculation Methods

Top-Down Approach

TAM = (# of potential customers) x (annual value per customer)
SAM = TAM x (% addressable by your solution)
SOM = SAM x (realistic market share %)

Bottom-Up Approach

SOM = (# of customers you can acquire) x (average deal size)
SAM = SOM / (your expected market share %)
TAM = SAM / (segment % of total market)

Example Analysis

## Market Sizing: AI Code Review Tool

### TAM (Total Addressable Market)
- Global developers: 28 million
- % using code review tools: 60%
- Addressable developers: 16.8 million
- Average annual spend: $300/developer
- **TAM = $5.04 billion**

### SAM (Serviceable Addressable Market)
- Focus: Enterprise (>500 employees)
- Enterprise developers: 8 million (48% of addressable)
- Willing to pay premium: 40%
- Target developers: 3.2 million
- **SAM = $960 million**

### SOM (Serviceable Obtainable Market)
- Year 1-3 realistic market share: 2%
- **SOM = $19.2 million**

Cross-Referencing Methods

Always use both methods and reconcile:

Method	TAM	Notes
Top-Down	$4.86B	Based on industry reports
Bottom-Up	$5.0B	Based on enterprise segments
Reconciled	$4.9B	Average, validated range

SOM Constraints

SAM: $470M

Constraints:
- Market share goal (3 years): 3%
- Competitive pressure: -20%
- Sales capacity: supports $15M ARR
- Go-to-market reach: 70%

Conservative SOM: min($470M x 3%, $15M, $470M x 70% x 3%)
= min($14.1M, $15M, $9.87M)
= $10M (3-year target)

Confidence Levels

Confidence	Evidence
HIGH	Multiple corroborating sources, recent data
MEDIUM	Single authoritative source, 1-2 years old
LOW	Extrapolated, assumptions, old data

Common Mistakes

Mistake	Correction
TAM = "everyone"	Define specific customer segment
Ignoring competition	SOM must account for competitors
Old data	Use most recent (<2 years)
Single method	Cross-validate top-down and bottom-up
Confusing TAM/SAM	TAM is total, SAM is your reach

Incorrect — Unrealistic SOM without constraints:

TAM: $10B
SAM (our segment): $3B
SOM (10% market share): $300M

This is achievable in 3 years!

Correct — SOM constrained by realistic factors:

SAM: $3B

Constraints:
- Sales capacity: supports $15M ARR max
- Competitive pressure: 5 strong incumbents
- Realistic market share (Year 3): 0.5%

Conservative SOM: min($3B × 0.5%, $15M) = $15M

Experiment Design & Guardrail Metrics

Structured experiment patterns extracted from metrics architecture practice. Complements the basic experiment template in metrics-instrumentation with deeper guardrail and rollout patterns.

Experiment Design Template

## Experiment: [Name]

### Hypothesis
If we [change], then [metric] will [direction] by [amount]
because [reasoning based on evidence].

### Metrics
- **Primary:** [The metric you are trying to move]
- **Secondary:** [Supporting metrics that add context]
- **Guardrails:** [Metrics that MUST NOT degrade -- see below]

### Design
- **Type:** A/B test | multivariate | feature flag rollout
- **Sample size:** [N per variant, calculated for statistical power]
- **Duration:** [Minimum weeks to reach significance]
- **Segments:** [User cohorts to analyze separately]

### Success Criteria
- Primary metric improves by >= [X]% with p < 0.05
- No guardrail metric degrades by > [threshold]
- Secondary metrics trend positive or neutral

### Rollout Plan
1. **10%** -- 1 week canary, monitor guardrails daily
2. **50%** -- 2 weeks, confirm statistical significance
3. **100%** -- full rollout with continued monitoring

Guardrail Metrics Pattern

Guardrails prevent shipping a "win" that causes hidden damage. Every experiment must define guardrails before launch.

Performance Guardrails

Guardrail	Threshold	Alert Action
Page load time (p95)	Must not increase > 200ms	Auto-pause experiment
API error rate	Must stay < 0.5%	Page on-call
Client crash rate	Must stay < baseline + 0.1%	Kill switch

Business Guardrails

Guardrail	Threshold	Alert Action
Conversion rate	Must not drop > 2% relative	Escalate to PM
Support ticket volume	Must not increase > 10%	Review UX
Revenue per user	Must not decrease	Escalate to leadership

Alert Threshold Template

## Guardrail: [Metric Name]

- **Baseline:** [Current value over last 30 days]
- **Warning:** [X% degradation from baseline]
- **Critical:** [Y% degradation -- auto-pause experiment]
- **Owner:** [Team or person who responds]
- **Response SLA:** Warning = 24h, Critical = 1h

North Star Metric Framework

Distinguish between input metrics (actionable, leading) and output metrics (outcome, lagging). Experiments should target input metrics while guarding output metrics.

Output (North Star): Weekly Active Teams
    |
    +-- Input: New team signups (acquisition)
    +-- Input: Teams completing onboarding (activation)
    +-- Input: Features used per team/week (engagement)
    +-- Input: Teams inviting members (virality)
    +-- Input: Teams upgrading to paid (monetization)

Experiment Targeting

Target input metrics -- they are directly actionable
Guard output metrics -- they confirm the input metric change translates to real value
Monitor adjacent inputs -- ensure one input improvement does not cannibalize another

Pre-Launch Checklist

[ ] Hypothesis documented with expected effect size
[ ] Primary, secondary, and guardrail metrics defined
[ ] Sample size calculated for minimum detectable effect
[ ] Staged rollout plan with kill criteria at each stage
[ ] Dashboard or alerts configured for guardrail metrics
[ ] Rollback procedure documented

Incorrect -- launching without guardrails:

Experiment: New checkout flow
Hypothesis: Will increase conversions
Plan: Ship to 100% of users on Monday
Success: Conversions go up

Correct -- structured experiment with guardrails:

Experiment: New checkout flow
Hypothesis: Reducing steps from 4 to 2 will increase
  checkout completion by 15% because 60% of users
  drop off between steps 2 and 3.
Primary: Checkout completion rate
Guardrails: Revenue per transaction, refund rate, page load p95
Rollout: 10% for 1 week, 50% for 2 weeks, 100%
Kill criteria: Any guardrail degrades > 5% relative

Metric Instrumentation & Definition

Formal patterns for defining, implementing, and monitoring KPIs.

Metric Definition Template

## Metric: [Name]

### Definition
[Precise definition of what this metric measures]

### Formula

Metric = Numerator / Denominator


### Data Source
- System: [Where data comes from]
- Table/Event: [Specific location]
- Owner: [Team responsible]

### Segments
- By customer tier (Free, Pro, Enterprise)
- By geography (NA, EMEA, APAC)
- By cohort (signup month)

### Frequency
- Calculation: Daily
- Review: Weekly

### Targets
| Period | Target | Stretch |
|--------|--------|---------|
| Q1 | 10,000 | 12,000 |
| Q2 | 15,000 | 18,000 |

### Related Metrics
- Leading: [Metric that predicts this]
- Lagging: [Metric this predicts]

Event Naming Conventions

Standard Format

[object]_[action]

Examples:
- user_signed_up
- feature_activated
- subscription_upgraded
- search_performed
- export_completed

Required Properties

{
  "event": "feature_activated",
  "timestamp": "2026-02-13T10:30:00Z",
  "user_id": "usr_123",
  "properties": {
    "feature_name": "advanced_search",
    "plan_tier": "pro",
    "activation_method": "onboarding_wizard"
  }
}

Instrumentation Checklist

Events

[ ] Key events identified
[ ] Event naming consistent (object_action)
[ ] Required properties defined
[ ] Optional properties listed
[ ] Privacy considerations addressed

Implementation

[ ] Analytics tool selected
[ ] Events documented
[ ] Engineering ticket created
[ ] QA plan for events

Alerting Thresholds

## Alert: [Metric Name]

| Threshold | Severity | Action |
|-----------|----------|--------|
| < Warning | Warning | Investigate within 24 hours |
| < Critical | Critical | Immediate escalation |
| > Spike | Info | Review for anomaly |

### Escalation Path
1. On-call engineer investigates
2. Team lead notified if not resolved in 2 hours
3. VP notified for P0 metrics breach

Dashboard Design

Principles

Principle	Application
Leading indicators prominent	Top of dashboard, real-time
Lagging indicators for context	Below, trend-based
Drill-down available	Click to segment
Historical comparison	Week-over-week, month-over-month
Anomaly highlighting	Auto-flag deviations

Experiment Design

## Experiment: [Name]

### Hypothesis
We believe [change] will cause [metric] to [improve by X%]

### Success Metric
- Primary: [Metric to move]
- Guardrail: [Metric that must not degrade]

### Sample Size
- Minimum: [N] per variant
- Duration: [X] weeks
- Confidence: 95%

### Rollout Plan
1. 5% canary for 1 week
2. 25% for 2 weeks
3. 50% for 1 week
4. 100% rollout

Incorrect — Inconsistent event naming:

{
  "event": "UserSignup",
  "event": "feature-activated",
  "event": "Subscription_Upgraded"
}

Correct — Consistent object_action naming:

{
  "event": "user_signed_up",
  "event": "feature_activated",
  "event": "subscription_upgraded"
}

KPI Trees & North Star Metric

Hierarchical breakdown of metrics showing cause-effect relationships.

Revenue KPI Tree

                         Revenue
                            |
          +-----------------+-----------------+
          |                 |                 |
     New Revenue      Expansion         Retained
          |            Revenue           Revenue
          |                |                 |
    +-----+-----+    +-----+-----+    +-----+-----+
    |           |    |           |    |           |
  Leads x    Conv  Users x   Upsell  Existing x (1-Churn)
  Rate       Rate   ARPU      Rate    Revenue     Rate

Product Health KPI Tree

                    Product Health Score
                            |
         +------------------+------------------+
         |                  |                  |
    Engagement          Retention         Satisfaction
         |                  |                  |
    +----+----+       +----+----+       +----+----+
    |         |       |         |       |         |
   DAU/     Time    Day 1    Day 30    NPS    Support
   MAU      in App  Retention Retention       Tickets

North Star Metric

One metric that captures core value delivery.

Examples by Business Type

Business Type	North Star Metric	Why
SaaS	Weekly Active Users	Indicates ongoing value
Marketplace	Gross Merchandise Value	Captures both sides
Media	Time spent reading	Engagement = value
E-commerce	Purchase frequency	Repeat = satisfied
Fintech	Assets under management	Trust + usage

North Star + Input Metrics

## Our North Star Framework

**North Star:** Weekly Active Teams (WAT)

**Input Metrics:**
1. New team signups (acquisition)
2. Teams completing onboarding (activation)
3. Features used per team per week (engagement)
4. Teams inviting new members (virality)
5. Teams on paid plans (monetization)

**Lagging Validation:**
- Revenue growth
- Net retention rate
- Customer lifetime value

Building a KPI Tree

Step 1: Start with the Business Outcome

What is the top-level metric leadership cares about? (Revenue, Users, Engagement)

Step 2: Decompose into Components

Break the metric into its mathematical components (multiplied or added).

Step 3: Identify Input Metrics

For each component, identify what leading indicators predict it.

Step 4: Assign Owners

Each metric should have a clear team owner.

Step 5: Set Targets

Baseline + target for each metric in the tree.

Best Practices

Keep trees 3 levels deep -- deeper than that and it loses clarity
Every metric has an owner -- no orphan metrics
Leading indicators at the leaves -- actionable by teams
Lagging indicators at the root -- confirms outcomes
Dashboard the tree -- make it visible to the whole organization

Incorrect — Flat metrics without hierarchy:

Q1 Goals:
- Increase revenue
- Improve engagement
- Reduce churn

Correct — KPI tree with cause-effect relationships:

Revenue (Lagging)
├── New Revenue = Leads × Conv Rate (Leading)
├── Expansion = Users × Upsell Rate (Leading)
└── Retained = Existing × (1 - Churn Rate) (Lagging)

Leading & Lagging Indicators

Understanding the difference is crucial for effective measurement.

Definitions

Type	Definition	Characteristics
Leading	Predictive, can be directly influenced	Real-time feedback, actionable
Lagging	Results of past actions	Confirms outcomes, hard to change

Examples by Domain

Sales Pipeline:
  Leading: # of qualified meetings this week
  Lagging: Quarterly revenue

Customer Success:
  Leading: Product usage frequency
  Lagging: Customer churn rate

Engineering:
  Leading: Code review turnaround time
  Lagging: Production incidents

Marketing:
  Leading: Website traffic, MQLs
  Lagging: Customer acquisition cost (CAC)

The Leading-Lagging Chain

Leading                                           Lagging
----------------------------------------------------------->

Blog posts    Website     MQLs      SQLs      Deals     Revenue
published  -> traffic  -> generated -> created -> closed -> booked
   |            |           |          |         |         |
   v            v           v          v         v         v
 Actionable  Actionable   Somewhat   Less      Hard      Result
             (SEO, ads)   (content)  control   control

Balanced Metrics Dashboard

Leading Indicators (Weekly Review)

Metric	Current	Target	Status
Active users (DAU)	12,500	15,000	Yellow
Feature adoption rate	68%	75%	Yellow
Support ticket volume	142	<100	Red
NPS responses collected	89	100	Green

Lagging Indicators (Monthly Review)

Metric	Current	Target	Status
Monthly revenue	$485K	$500K	Yellow
Customer churn	5.2%	<5%	Yellow
NPS score	42	50	Green
CAC payback months	14	12	Red

Using Both Effectively

Pair Leading with Lagging

For every lagging indicator you care about, identify 2-3 leading indicators that predict it.

## Metric Pairs

Lagging: Customer Churn Rate
Leading:
  1. Product usage frequency (weekly)
  2. Support ticket severity (daily)
  3. NPS score trend (monthly)

Lagging: Revenue Growth
Leading:
  1. Pipeline value (weekly)
  2. Demo-to-trial conversion (weekly)
  3. Feature adoption rate (weekly)

Review Cadence

Indicator Type	Review Frequency	Action Timeline
Leading	Daily/Weekly	Immediate course correction
Lagging	Monthly/Quarterly	Strategic adjustments

Best Practices

Start with the lagging metric you want to improve
Identify 2-3 leading indicators that predict it
Set up automated dashboards for leading indicators
Review leading indicators weekly with the team
Use lagging indicators to validate that leading indicators actually predict outcomes
Adjust leading indicators when correlation breaks down

Incorrect — Only tracking lagging indicators:

Monthly Review:
- Revenue: $485K (missed $500K target)
- Churn: 5.2% (above 5% target)

[Too late to fix - no early warning]

Correct — Paired leading + lagging indicators:

Weekly (Leading):
- Active users: 12,500 → trend down, investigate
- Feature adoption: 68% → below 75%, action needed

Monthly (Lagging):
- Revenue: Validated prediction accuracy
- Churn: Confirms leading indicators correlation

OKR Framework

Objectives and Key Results align teams around ambitious goals with measurable outcomes.

OKR Structure

Objective: Qualitative, inspiring goal
+-- Key Result 1: Quantitative measure of progress
+-- Key Result 2: Quantitative measure of progress
+-- Key Result 3: Quantitative measure of progress

Writing Good Objectives

Characteristic	Good	Bad
Qualitative	"Delight enterprise customers"	"Increase NPS to 50"
Inspiring	"Become the go-to platform"	"Ship 10 features"
Time-bound	Implied quarterly	Vague timeline
Ambitious	Stretch goal (70% achievable)	Sandbagged (100% easy)

Writing Good Key Results

Characteristic	Good	Bad
Quantitative	"Reduce churn from 8% to 4%"	"Improve retention"
Measurable	"Ship to 10,000 beta users"	"Launch beta"
Outcome-focused	"Increase conversion by 20%"	"Add 5 features"
Leading indicators	"Weekly active users reach 50K"	"Revenue hits $1M" (lagging)

Key Result Formula

[Verb] [metric] from [baseline] to [target] by [deadline]

Examples:
- Increase NPS from 32 to 50
- Reduce time-to-value from 14 days to 3 days
- Achieve 95% feature adoption in first 30 days

OKR Example

## Q1 OKRs

### Objective 1: Become the #1 choice for enterprise teams

**Key Results:**
- KR1: Increase enterprise NPS from 32 to 50
- KR2: Reduce time-to-value from 14 days to 3 days
- KR3: Achieve 95% feature adoption in first 30 days
- KR4: Win 5 competitive displacements from [Competitor]

### Objective 2: Build a world-class engineering culture

**Key Results:**
- KR1: Reduce deploy-to-production time from 4 hours to 15 minutes
- KR2: Achieve 90% code coverage on critical paths
- KR3: Zero P0 incidents lasting longer than 30 minutes
- KR4: Engineering satisfaction score reaches 4.5/5

Alignment Cascade

Company OKRs
    |
    v
Department OKRs (aligns to company)
    |
    v
Team OKRs (aligns to department)
    |
    v
Individual OKRs (optional, aligns to team)

Best Practices

OKRs for goals, KPIs for health: Use together, not interchangeably
Leading indicator focus: Key Results should be leading indicators
Cascade with autonomy: Align outcomes, let teams choose their path
Regular calibration: Weekly check-ins on leading, monthly on lagging
3-5 objectives max per team per quarter
3-5 KRs per objective: Enough to measure, not too many to track

Common Pitfalls

Pitfall	Mitigation
Vanity metrics	Focus on metrics that drive decisions
Too many KPIs	Limit to 5-7 per team
Gaming metrics	Pair metrics that balance each other
Static goals	Review and adjust quarterly
No baselines	Establish current state before setting targets

Incorrect — Outputs instead of outcomes:

Objective: Build a great product

Key Results:
- Ship 10 features
- Write 50 unit tests
- Hold 20 customer interviews

Correct — Outcome-focused key results:

Objective: Become the #1 choice for enterprise teams

Key Results:
- Increase enterprise NPS from 32 to 50
- Reduce time-to-value from 14 days to 3 days
- Achieve 95% feature adoption in first 30 days

Opportunity Cost & Trade-Off Analysis

Patterns for making prioritization decisions that account for what you give up, not just what you gain. Complements RICE and WSJF scoring with opportunity cost reasoning.

Value-Effort Matrix

A 2x2 matrix for rapid feature sequencing based on expected value and required effort.

               HIGH VALUE
                   |
    Do Next        |     Do First
    (High value,   |     (High value,
     high effort)  |      low effort)
                   |
  -----------------+-----------------
                   |
    Consider       |     Quick Win
    (Low value,    |     (Low value,
     high effort)  |      low effort)
                   |
               LOW VALUE
  HIGH EFFORT                LOW EFFORT

Quadrant	Action	Example
Do First	Ship immediately -- high ROI	Fix broken onboarding step
Quick Win	Batch into next sprint	Add CSV export button
Do Next	Plan and resource properly	Platform migration
Consider	Challenge whether to do at all	Redesign rarely-used admin page

Scoring for Placement

Value (1-10): Combine user impact, strategic alignment, revenue potential
Effort (1-10): Engineering weeks, cross-team coordination, risk
Threshold: Value >= 6 is "high value", Effort >= 6 is "high effort"

Cost of Delay Analysis

Quantify what it costs to NOT do something each time period it is delayed.

## Cost of Delay: [Feature Name]

### Revenue Impact
- Lost revenue per month of delay: $X
- Source: [Pipeline data, churn analysis, competitive loss]

### User Impact
- Users affected: N
- Workaround cost per user per month: X hours

### Strategic Impact
- Competitive window closes in: N months
- Regulatory deadline: [date or N/A]

### Total Cost of Delay
$X/month (quantified) + [qualitative strategic cost]

Delay Cost Categories

Type	How to Estimate	Example
Revenue delay	Pipeline deals blocked by missing feature	$50K/month in stalled deals
Churn risk	Customers citing this in exit surveys	3 enterprise accounts at risk
Competitive	Competitor ships first, window shrinks	Market share loss
Compliance	Fines or market access loss after deadline	GDPR: $20M max fine
Compounding	Delay makes future work harder	Tech debt interest

Trade-Off Flagging Template

When two options compete for the same resources, surface the trade-off explicitly for human decision-makers. Do not make the call -- present the data.

## Trade-Off: [Decision Title]

### Context
[Why this trade-off exists -- shared resources, timeline conflict, etc.]

### Option A: [Name]
- **Pros:** [List 2-3 concrete benefits with data]
- **Cons:** [List 2-3 concrete downsides with data]
- **RICE Score:** [If available]
- **Cost of Delay:** [$/month]

### Option B: [Name]
- **Pros:** [List 2-3 concrete benefits with data]
- **Cons:** [List 2-3 concrete downsides with data]
- **RICE Score:** [If available]
- **Cost of Delay:** [$/month]

### Recommendation
Human decides. Key factors to weigh:
1. [Factor 1 -- e.g., Q2 OKR alignment]
2. [Factor 2 -- e.g., team capacity next sprint]
3. [Factor 3 -- e.g., customer commitment]

Sequencing Principles

When features have dependencies or shared resources, use these sequencing rules:

1. Highest cost-of-delay first -- unless blocked by dependencies 2. Unblock others early -- a low-value enabler that unblocks 3 high-value items ships first 3. Reduce risk early -- unknowns first, known work later (fail fast) 4. Batch small items -- group Quick Wins into a single sprint to clear the backlog

Incorrect -- prioritizing by gut feel:

Priority list:
1. AI search (CEO wants it)
2. Dashboard redesign (designer is excited)
3. CSV import (seems easy)

Correct -- opportunity cost matrix with explicit trade-offs:

Priority list (by cost of delay):
1. CSV import -- $30K/month blocked deals, 1 week effort (Do First)
2. AI search -- $25K/month competitive risk, 6 week effort (Do Next)
3. Dashboard redesign -- $0 cost of delay, nice-to-have (Consider)

Trade-off flagged: AI search vs platform migration for same
eng team in Q2. See trade-off analysis doc for decision.

Related skills

Grill MeHave an agent relentlessly pressure-test their plan or design until every decision branch is resolved and shared understanding is reached.691k196k

Grill With DocsPressure-test architecture decisions against their live codebase and living documentation before writing production code.585k196k

Lark CalendarLet their coding agents read, create, and manage events inside Lark (Feishu) Calendar directly from natural language instructions.493k

Lark ImLet their coding agent send instant notifications, post updates, and receive commands directly inside Lark (Feishu) workspaces.493k

Lark ContactLet their AI coding agents read and write contacts, send messages, and manage user data inside Lark (Feishu).493k

Lark AttendanceAutomatically fetch and report daily attendance data from Lark (Feishu) into their own tools or agents.493k

Productivity & Planningpmworkflow

About

Product Frameworks by the numbers

Add your badge

What it does

Files

Product Frameworks

Quick Reference

Quick Start

Business & Market

Strategy & Prioritization

Metrics & OKRs

Research & Requirements

Output Templates

Related Skills

Business Case Template

Market Research Report Template

Metric Definition Template

Persona Template

PRD Template

Research Report Template

RICE Scoring Spreadsheet Template

Scoring Table

Score Definitions

Reach (users/quarter)

Impact (on goal)

Confidence (in estimates)

Effort (person-weeks)

Formula

Notes Column Template

Priority Tiers

Strategic Assessment Template

Business Case Checklist

Cost Analysis

Benefit Analysis

Financial Metrics

Risk Assessment

Scenarios

Stakeholder Readiness

Documentation

Market Research Checklist

Market Sizing

Competitive Analysis

SWOT Analysis

Market Trends

Output Deliverables

Quality Checks

Metrics Framework Checklist

OKR Quality

Objectives

Key Results

KPI Design

Each KPI Has

Leading vs Lagging

North Star Metric

Instrumentation Plan

Events

Implementation

Dashboard & Reporting

Experiment Design

Review Cadence

Persona Quality Checklist

Research Foundation

Persona Content

Demographics (Not Too Much)

Goals

Pain Points

Behaviors

Quote

Key Insight

Actionability

Format & Accessibility

Maintenance

Anti-Patterns to Avoid

PRD Review Checklist

Problem Definition

Solution

Scope

User Stories

Acceptance Criteria

Non-Functional Requirements