Skip to main content
OrchestKit v7.1.10 — 79 skills, 30 agents, 105 hooks · Claude Code 2.1.69+
OrchestKit
Skills

Prd

Product Requirements Documents with structured 8-section templates, user stories, acceptance criteria, and value proposition validation. Use when writing PRDs, defining product requirements, creating user stories with INVEST criteria, or building go/no-go decision frameworks.

Command medium

Primary Agent: product-strategist

PRD — Product Requirements Document

Translate product vision and research into clear, actionable engineering specifications. Produces PRD-[product-name].md output files following an 8-section structure.

Output file naming: PRD-[product-name].md (e.g., PRD-sso-invite-flow.md)

The 8-Section PRD Template

# PRD: [Feature Name]

**Author:** [Name] | **Status:** Draft | In Review | Approved | Shipped | **Date:** YYYY-MM-DD

## 1. Summary
One paragraph: what we're building and why it matters now.

## 2. Contacts
| Role | Name | Responsibility |
|------|------|----------------|
| PM | | Decision owner |
| Engineering Lead | | Technical delivery |
| Design | | UX/UI |

## 3. Background
- What triggered this initiative? (data, customer request, strategic bet)
- Relevant prior work or research
- Constraints and assumptions

## 4. Objective
1. [Primary goal with measurable outcome]
2. [Secondary goal]

**Non-Goals (explicit out-of-scope):**
- [What we are NOT doing]

## 5. Market Segments
| Segment | Size | Priority | Notes |
|---------|------|----------|-------|
| | | | |

## 6. Value Propositions
| User Type | Job-to-be-Done | Pain Relieved | Gain Created |
|-----------|----------------|---------------|--------------|
| | | | |

## 7. Solution

### User Stories (P0 — Must Have)
- [ ] As a [persona], I want [goal], so that [benefit].

### User Stories (P1 — Should Have)
- [ ] ...

### Acceptance Criteria
See story-level criteria below each story.

### Dependencies
| Dependency | Owner | Status | ETA |
|------------|-------|--------|-----|

### Risks & Mitigations
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|

## 8. Release
| Milestone | Date | Status |
|-----------|------|--------|
| PRD Approved | | |
| Dev Complete | | |
| Launch | | |

**Success Metrics:**
| Metric | Current | Target | Timeline |
|--------|---------|--------|----------|

User Stories

Standard Format

As a [type of user],
I want [goal/desire],
so that [benefit/value].

INVEST Criteria

Every story must pass all six checks before it's "ready":

CriterionCheck
IndependentNo hard dependencies on other in-flight stories
NegotiableDetails are a conversation starter, not a contract
ValuableClearly answers "so what?"
EstimableTeam can size it without major unknowns
SmallCompletable in 1-5 days
TestableHas explicit acceptance criteria

Incorrect — vague story:

As a user, I want better reporting.

Correct — INVEST story with acceptance criteria:

As a sales manager,
I want to see my team's pipeline grouped by stage,
so that I can identify bottlenecks and coach accordingly.

Acceptance Criteria:
- [ ] Shows deals grouped by stage with count and total value per stage
- [ ] Filters by date range (default: current quarter)
- [ ] Updates in real-time when deals change stages
- [ ] Accessible at /pipeline for all users with the "manager" role

Acceptance Criteria (Given/When/Then)

Use Gherkin format for testable criteria:

Scenario: Successful login with valid credentials
  Given I am on the login page
  And I have a valid account
  When I enter my email and password
  And I click "Sign In"
  Then I should be redirected to the dashboard
  And I should see a "Welcome back" message

Value Proposition Canvas Integration

Before writing the solution section, complete the value canvas to ensure fit:

Customer Profile (right)          Value Map (left)
─────────────────────────         ─────────────────────────
Jobs-to-be-Done          ◄────    Products & Services
• Functional jobs                 • Features and capabilities
• Social jobs
• Emotional jobs

Pains                    ◄────    Pain Relievers
• Obstacles and risks             • How we eliminate friction
• Undesired outcomes

Gains                    ◄────    Gain Creators
• Required and expected           • How we create benefits
  outcomes

Fit check: Every item in the Value Map must correspond to at least one Job, Pain, or Gain. Remove features with no matching customer need.

Go/No-Go Gate Criteria

Use stage gates before committing to build:

## Gate 2: Solution Validation (before starting dev)
- [ ] Value proposition tested with ≥ 3 customer interviews
- [ ] Technical feasibility confirmed by engineering lead
- [ ] Competitive differentiation is clear
- [ ] Unit economics viable (projected CAC < LTV/3)

## Gate 3: Business Case (before sprint planning)
- [ ] ROI > 15% hurdle rate
- [ ] Payback period < 24 months
- [ ] Resource requirements confirmed (FTEs, infra)
- [ ] Risk mitigation plan in place

Scoring thresholds: Go ≥ 7.0 | Conditional Go 5.0–6.9 | No-Go < 5.0

Priority Levels

LevelMeaningCriteria
P0Must have for MVPUsers cannot accomplish core job without this
P1ImportantSignificantly improves experience, high demand
P2Nice to haveEnhances experience, moderate demand
P3FutureBacklog for later consideration

Definition of Ready / Done

Ready (before sprint):

- [ ] User story follows As a/I want/So that format
- [ ] Acceptance criteria are complete and testable
- [ ] Dependencies identified and resolved
- [ ] Story is estimated by the team
- [ ] Design artifacts available (if applicable)

Done (after dev):

- [ ] Code complete and reviewed
- [ ] Unit and integration tests passing
- [ ] Acceptance criteria verified by PM
- [ ] Documentation updated
- [ ] Deployed to staging

Non-Functional Requirements

Always include NFRs in the PRD solution section:

CategoryExample
PerformancePage load < 2s at p95
Scalability10,000 concurrent users
Availability99.9% uptime
SecurityData encrypted at rest and in transit
AccessibilityWCAG 2.1 AA

PRD JSON Output Schema

When producing structured PRD output for automated pipelines:

{
  "prd": {
    "title": "SSO Invite Flow",
    "version": "1.0",
    "author": "PM Name",
    "status": "draft"
  },
  "problem_statement": "Team admins cannot invite members via SSO, blocking enterprise onboarding.",
  "scope": {
    "in": ["Email-based SSO invite", "Role assignment on first login"],
    "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"
    }
  ],
  "non_functional": {
    "performance": "Invite flow completes in < 2s p95",
    "security": "Invite tokens expire after 72 hours"
  }
}

Rules (Load On-Demand)

References

  • ork:user-research — Build user understanding (personas, journey maps, interviews) before writing the PRD
  • ork:product-frameworks — Full PM framework suite (business cases, RICE, OKRs, metrics)

Version: 1.0.0


Rules (3)

Engineer requirements with INVEST user stories and comprehensive PRD documentation — HIGH

Requirements Engineering & PRDs

Patterns for translating product vision into clear, actionable engineering specifications.

User Stories

Standard Format

As a [type of user],
I want [goal/desire],
so that [benefit/value].

INVEST Criteria

CriterionDescriptionExample Check
IndependentCan be developed separatelyNo hard dependencies on other stories
NegotiableDetails can be discussedNot a contract, a conversation starter
ValuableDelivers user/business valueAnswers "so what?"
EstimableCan be sized by the teamClear enough to estimate
SmallFits in a sprint1-5 days of work typically
TestableHas clear acceptance criteriaKnow when it's done

Good vs. Bad Stories

Good:

As a sales manager,
I want to see my team's pipeline by stage,
so that I can identify bottlenecks and coach accordingly.

Acceptance Criteria:
- [ ] Shows deals grouped by stage
- [ ] Displays deal count and total value per stage
- [ ] Filters by date range (default: current quarter)
- [ ] Updates in real-time when deals move stages

Bad (too vague): As a user, I want better reporting. Bad (solution-focused): As a user, I want a pie chart on the dashboard.

Acceptance Criteria

Given-When-Then Format (Gherkin)

Scenario: Successful login with valid credentials
  Given I am on the login page
  And I have a valid account
  When I enter my email "user@example.com"
  And I enter my password "validpass123"
  And I click the "Sign In" button
  Then I should be redirected to the dashboard
  And I should see "Welcome back" message

PRD Template

# PRD: [Feature Name]

**Author:** [Name]
**Status:** Draft | In Review | Approved | Shipped

## Problem Statement
[1-2 paragraphs describing the problem we're solving]

## Goals
1. [Primary goal with measurable outcome]
2. [Secondary goal]

## Non-Goals (Out of Scope)
- [Explicitly what we're NOT doing]

## Success Metrics
| Metric | Current | Target | Timeline |
|--------|---------|--------|----------|
| | | | |

## User Stories

### P0 - Must Have (MVP)
- [ ] Story 1: As a..., I want..., so that...

### P1 - Should Have
- [ ] Story 2: ...

## Dependencies
| Dependency | Owner | Status | ETA |
|------------|-------|--------|-----|

## Risks & Mitigations
| Risk | Probability | Impact | Mitigation |
|------|-------------|--------|------------|

## Timeline
| Milestone | Date | Status |
|-----------|------|--------|
| PRD Approved | | |
| Dev Complete | | |
| Launch | | |

Requirements Priority Levels

LevelMeaningCriteria
P0Must have for MVPUsers cannot accomplish core job without this
P1ImportantSignificantly improves experience, high demand
P2Nice to haveEnhances experience, moderate demand
P3FutureBacklog for later consideration

Definition of Ready

- [ ] User story follows standard format
- [ ] Acceptance criteria are complete and testable
- [ ] Dependencies identified and resolved
- [ ] Design artifacts available (if applicable)
- [ ] Story is estimated by the team
- [ ] Story fits within a single sprint

Definition of Done

- [ ] Code complete and reviewed
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] Acceptance criteria verified
- [ ] Documentation updated
- [ ] Deployed to staging
- [ ] Product owner acceptance

Non-Functional Requirements

CategoryExample Requirement
PerformancePage load time < 2 seconds at 95th percentile
ScalabilitySupport 10,000 concurrent users
Availability99.9% uptime
SecurityAll data encrypted at rest and in transit
AccessibilityWCAG 2.1 AA compliant

Incorrect — Vague user story without acceptance criteria:

As a user, I want better reporting.

Correct — INVEST user story with acceptance criteria:

As a sales manager,
I want to see my team's pipeline by stage,
so that I can identify bottlenecks and coach accordingly.

Acceptance Criteria:
- [ ] Shows deals grouped by stage
- [ ] Displays deal count and total value per stage
- [ ] Filters by date range (default: current quarter)
- [ ] Updates in real-time when deals move stages

Evaluate go/no-go decisions with stage gates and build/buy/partner strategic analysis — HIGH

Go/No-Go & Build/Buy/Partner Decisions

Stage Gate Criteria

## Gate 1: Opportunity Validation
- [ ] Clear customer problem identified (JTBD defined)
- [ ] Market size sufficient (TAM > $100M)
- [ ] Strategic alignment confirmed
- [ ] No legal/regulatory blockers

## Gate 2: Solution Validation
- [ ] Value proposition tested with customers
- [ ] Technical feasibility confirmed
- [ ] Competitive differentiation clear
- [ ] Unit economics viable (projected)

## Gate 3: Business Case
- [ ] ROI > hurdle rate (typically 15-25%)
- [ ] Payback period acceptable (< 24 months)
- [ ] Resource requirements confirmed
- [ ] Risk mitigation plan in place

## Gate 4: Launch Readiness
- [ ] MVP complete and tested
- [ ] Go-to-market plan ready
- [ ] Success metrics defined
- [ ] Support/ops prepared

Scoring Template

CriterionWeightScore (1-10)Weighted
Market opportunity20%
Strategic fit20%
Competitive position15%
Technical feasibility15%
Financial viability15%
Team capability10%
Risk profile5%
TOTAL100%

Decision Thresholds:

  • Go: Score >= 7.0
  • Conditional Go: Score 5.0-6.9 (address gaps)
  • No-Go: Score < 5.0

Build vs. Buy vs. Partner Decision Matrix

FactorBuildBuyPartner
Time to MarketSlow (6-18 months)Fast (1-3 months)Medium (3-6 months)
Cost (Year 1)High (dev team)Medium (license)Variable
Cost (Year 3+)Lower (owned)Higher (recurring)Negotiable
CustomizationFull controlLimitedModerate
Core CompetencyMust be coreNot coreAdjacent
Competitive AdvantageHighLowMedium
RiskExecution riskVendor lock-inPartnership risk

Decision Framework

def build_buy_partner_decision(
    strategic_importance: int,    # 1-10
    differentiation_value: int,   # 1-10
    internal_capability: int,     # 1-10
    time_sensitivity: int,        # 1-10
    budget_availability: int,     # 1-10
) -> str:
    build_score = (
        strategic_importance * 0.3 +
        differentiation_value * 0.3 +
        internal_capability * 0.2 +
        (10 - time_sensitivity) * 0.1 +
        budget_availability * 0.1
    )
    if build_score >= 7:
        return "BUILD: Core capability, invest in ownership"
    elif build_score >= 4:
        return "PARTNER: Strategic integration with flexibility"
    else:
        return "BUY: Commodity, use best-in-class vendor"

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)

When to Build / Buy / Partner

Build When

  • Creates lasting competitive advantage
  • Core to your value proposition
  • Requires deep customization
  • Data/IP ownership is critical

Buy When

  • Commodity functionality (auth, payments, email)
  • Time-to-market is critical
  • Vendor has clear expertise edge
  • Total cost of ownership favors vendor

Partner When

  • Need capabilities but not full ownership
  • Market access matters (distribution)
  • Risk sharing is valuable
  • Neither build nor buy fits perfectly

Incorrect — Go/No-Go without scoring criteria:

Idea: Build AI feature
Team: Excited about it
Decision: GO

Correct — Systematic stage gate evaluation:

Gate 3: Business Case
- [ ] ROI > 15% hurdle rate: YES (22%)
- [ ] Payback < 24 months: YES (18 months)
- [ ] Resource requirements: 3 FTEs available
- [ ] Risk mitigation: Technical POC validated

Weighted Score: 7.2/10
Decision: GO (>= 7.0 threshold)

Define value propositions using Jobs-to-be-Done framework and product-market fit canvas — HIGH

Value Proposition & Jobs-to-be-Done

Jobs-to-be-Done (JTBD) Framework

People don't buy products -- they hire them to do specific jobs.

JTBD Statement Format

When [situation], I want to [motivation], so I can [expected outcome].

Example:

When I'm commuting to work, I want to catch up on industry news,
so I can appear informed in morning meetings.

Job Dimensions

DimensionDescriptionExample
FunctionalPractical task to accomplish"Transfer money to a friend"
EmotionalHow user wants to feel"Feel confident I didn't make a mistake"
SocialHow user wants to be perceived"Appear tech-savvy to peers"

JTBD Discovery Process

## Step 1: Identify Target Customer
- Who struggles most with this job?
- Who pays the most to get this job done?

## Step 2: Define the Core Job
- What is the customer ultimately trying to accomplish?
- Strip away solutions -- focus on the outcome

## Step 3: Map Job Steps
1. Define what success looks like
2. Locate inputs needed
3. Prepare for the job
4. Confirm readiness
5. Execute the job
6. Monitor progress
7. Modify as needed
8. Conclude the job

## Step 4: Identify Pain Points
- Where do customers struggle?
- What causes anxiety or frustration?
- What workarounds exist?

## Step 5: Quantify Opportunity
- Importance: How important is this job? (1-10)
- Satisfaction: How satisfied with current solutions? (1-10)
- Opportunity = Importance + (Importance - Satisfaction)

Value Proposition Canvas

Customer Profile (Right Side)

+-------------------------------------+
|         CUSTOMER PROFILE            |
|  JOBS                               |
|  * Functional jobs (tasks)          |
|  * Social jobs (how seen)           |
|  * Emotional jobs (how feel)        |
|                                     |
|  PAINS                              |
|  * Undesired outcomes               |
|  * Obstacles                        |
|  * Risks                            |
|                                     |
|  GAINS                              |
|  * Required outcomes                |
|  * Expected outcomes                |
|  * Desired outcomes                 |
|  * Unexpected outcomes              |
+-------------------------------------+

Value Map (Left Side)

+-------------------------------------+
|           VALUE MAP                 |
|  PRODUCTS & SERVICES                |
|  * What we offer                    |
|  * Features and capabilities        |
|                                     |
|  PAIN RELIEVERS                     |
|  * How we eliminate pains           |
|  * Risk reduction                   |
|  * Cost savings                     |
|                                     |
|  GAIN CREATORS                      |
|  * How we create gains              |
|  * Performance improvements         |
|  * Social/emotional benefits        |
+-------------------------------------+

Fit Assessment

Fit LevelDescriptionAction
Problem-Solution FitValue map addresses jobs/pains/gainsValidate with interviews
Product-Market FitCustomers actually buy/useMeasure retention, NPS
Business Model FitSustainable unit economicsTrack CAC, LTV, margins

Key Principles

PrincipleApplication
Customer-firstStart with jobs, not features
Evidence-basedValidate assumptions with data
Strategic alignmentEvery initiative serves the mission
Reversible decisionsPrefer options that preserve flexibility

Incorrect — Feature-focused instead of job-focused:

Value Proposition:
"Our app has AI, real-time sync, and dark mode"

Correct — JTBD-based value proposition:

Jobs-to-be-Done:
When I'm commuting to work,
I want to catch up on industry news,
so I can appear informed in morning meetings.

Value Proposition:
"Get curated industry insights in 5-minute audio briefs,
perfectly timed for your commute"

References (2)

Output Templates

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" }
  ]
}

Value Prop Canvas Guide

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 TypeDefinitionExample
FunctionalTasks to accomplish"Deploy code to production"
SocialHow to be perceived"Be seen as innovative"
EmotionalHow 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 LevelCriteria
Problem-Solution FitEvidence that value prop addresses real jobs/pains
Product-Market FitEvidence customers will pay for solution
Business Model FitEvidence 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

MistakeCorrection
Starting with solutionStart with customer jobs
Listing featuresFocus on outcomes
Ignoring emotional jobsInclude all job types
Single customer segmentSeparate canvas per segment
No prioritizationVote 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
Edit on GitHub

Last updated on

On this page

PRD — Product Requirements DocumentThe 8-Section PRD TemplateUser StoriesStandard FormatINVEST CriteriaAcceptance Criteria (Given/When/Then)Value Proposition Canvas IntegrationGo/No-Go Gate CriteriaPriority LevelsDefinition of Ready / DoneNon-Functional RequirementsPRD JSON Output SchemaRules (Load On-Demand)ReferencesRelated SkillsRules (3)Engineer requirements with INVEST user stories and comprehensive PRD documentation — HIGHRequirements Engineering & PRDsUser StoriesStandard FormatINVEST CriteriaGood vs. Bad StoriesAcceptance CriteriaGiven-When-Then Format (Gherkin)PRD TemplateRequirements Priority LevelsDefinition of ReadyDefinition of DoneNon-Functional RequirementsEvaluate go/no-go decisions with stage gates and build/buy/partner strategic analysis — HIGHGo/No-Go & Build/Buy/Partner DecisionsStage Gate CriteriaScoring TemplateBuild vs. Buy vs. Partner Decision MatrixDecision FrameworkDecision TreeWhen to Build / Buy / PartnerBuild WhenBuy WhenPartner WhenDefine value propositions using Jobs-to-be-Done framework and product-market fit canvas — HIGHValue Proposition & Jobs-to-be-DoneJobs-to-be-Done (JTBD) FrameworkJTBD Statement FormatJob DimensionsJTBD Discovery ProcessValue Proposition CanvasCustomer Profile (Right Side)Value Map (Left Side)Fit AssessmentKey PrinciplesReferences (2)Output TemplatesOutput TemplatesPRD OutputBusiness Case OutputMetrics Framework OutputPrioritization Report OutputResearch Report OutputValue Prop Canvas GuideValue Proposition Canvas GuideCanvas StructureJobs to be Done CategoriesPain Severity RankingGain Importance RankingFit AssessmentWorkshop FacilitationCommon Mistakes2026 Updates