Product Management

Product Management (Jan 2026)

This skill turns the assistant into an operator, not a lecturer.

Everything here is:

• Executable: templates, checklists, decision flows
• Decision-first: measurable outcomes, explicit trade-offs, clear ownership
• Organized: resources for depth; templates for immediate copy-paste

---

Modern Best Practices (Jan 2026):

• Evidence quality beats confidence: label signals strong/medium/weak; write what would change your mind.
• Outcomes > output: roadmaps are bets with measurable impact and guardrails, not feature inventories.
• Metrics must be defined (formula + timeframe + data source) to be actionable.
• Privacy, security, and accessibility are requirements, not afterthoughts.
• Hybrid decision loops: AI surfaces anomalies, patterns, and forecasts; humans apply context, ethics, and long-term strategy.
• Accountability: product is often held responsible for business outcomes; confirm the operating model in your org and validate benchmarks with current sources.
• Portfolio diversification: a common heuristic is 70% core, 20% adjacent, 10% transformational; adapt to strategy and constraints.

When to Use This Skill

Use this skill when the user asks to do real product work, such as:

• “Create / refine a PRD / spec / business case / 1-pager”
• “Turn this idea into a roadmap” / “Outcome roadmap for X”
• “Design a discovery plan / interview script / experiment plan”
• “Define success metrics / OKRs / metric tree”
• “Position this product against competitors”
• “Run a difficult conversation / feedback / 1:1 / negotiation”
• “Plan a product strategy / vision / opportunity assessment”

Do not use this skill for:

• Book summaries, philosophy, or general education
• Long case studies or storytelling

---

Quick Reference

---

Decision Tree: Choosing the Right Workflow

User needs: [Product Work Type]
    ├─ Discovery / Validation?
    │   ├─ Customer insights? → Customer interview template
    │   ├─ Hypothesis testing? → Assumption test template
    │   └─ Opportunity mapping? → Opportunity Solution Tree
    │
    ├─ Strategy / Vision?
    │   ├─ Long-term direction? → Product vision template
    │   ├─ Market positioning? → Positioning template (Dunford)
    │   ├─ Big opportunity? → Opportunity assessment
    │   └─ Amazon-style spec? → PR/FAQ template
    │
    ├─ Planning / Roadmap?
    │   ├─ Outcome-driven? → Outcome roadmap (Now/Next/Later)
    │   ├─ Theme-based? → Theme roadmap
    │   └─ Metrics / OKRs? → Metric tree + OKR template
    │
    ├─ Prioritization / Focus?
    │   ├─ What to build next? → Prioritization scorecard (RICE/ICE)
    │   ├─ What to stop? → Kill criteria template + quarterly review
    │   ├─ Scope too large? → Scope negotiation patterns
    │   └─ PMF check? → PMF survey + retention curve analysis
    │
    └─ Leadership / Team Ops?
        ├─ 1:1 meeting? → 1-1 template
        ├─ Giving feedback? → Feedback template (SBI model)
        ├─ Post-incident? → A3 debrief
        ├─ Stakeholder pushback? → Stakeholder management patterns
        └─ Negotiation? → Negotiation one-sheet (Voss)

---

Do / Avoid (Jan 2026)

Do

• Start from the decision: what are we deciding, by when, and with what evidence.
• Define metrics precisely (formula + timeframe + data source) and add guardrails.
• Use discovery to de-risk value before building; prioritize by evidence, not opinions.
• Write “match vs ignore” competitive decisions, not feature grids.

Avoid

• Roadmap theater (shipping lists) without outcomes and learning loops.
• Vanity KPIs (raw signups, impressions) without activation/retention definitions.
• "Build-first validation" (shipping MVPs without falsifiable hypotheses).
• Collecting customer data without purpose limitation, retention, and access controls.
• Building for engineering elegance instead of user value (technical founder trap).
• Feature creep without kill criteria (every feature should have a pre-defined stop condition).
• Saying "yes" to stakeholder requests without trade-off analysis.
• Measuring PMF once instead of continuously across segments.

Prioritization & Saying No

The most common founder-PM failure: building everything, killing nothing, and running out of time before impact.

Prioritization Frameworks

Pick one. Use it consistently. The framework matters less than the discipline of scoring everything the same way.

Kill Criteria

Every initiative should have pre-defined conditions for stopping:

• Usage threshold: If <X% of target users adopt within Y weeks, stop.
• Cost ceiling: If development exceeds X hours/dollars, pause and re-evaluate.
• Time limit: If not shipped within X weeks, kill or radically descope.
• Metric guardrail: If [guardrail metric] degrades by >X%, roll back.

Use assets/prioritization/kill-criteria-template.md to define these before starting.

Feature Bridge Migration

When replacing an existing feature with a new one, don't hard-kill the old feature. Use a bridge migration pattern to prevent user loss.

Bridge mode: Run both old and new features simultaneously. Route users to the new experience by default but keep the old path accessible (via link, fallback, or settings toggle).

Substitution-based kill rule: 1. Define the absorption metric: % of old-feature users who now use the new feature for the same job. 2. Set the kill threshold: new feature absorbs ≥80% of old-feature users. 3. Set the duration: threshold must hold for 14 consecutive days with no retention regression. 4. Only kill the old feature when all three conditions are met.

BRIDGE MIGRATION SEQUENCE:

1. Ship new feature alongside old feature
2. Default new users to new experience
3. Migrate existing users gradually (progressive rollout)
4. Monitor: absorption rate, retention by cohort, support tickets
5. Old feature absorbs ≥80% for 14 days + no retention drop?
   ├─ Yes → Kill old feature, remove code
   └─ No → Investigate gaps, iterate new feature, extend bridge

When NOT to bridge: Security vulnerabilities, compliance requirements, or features with near-zero usage (<1% MAU). These can be killed directly with notice.

Scope Negotiation

When stakeholders push for more scope:

• Reframe as trade-offs: "We can add X if we cut Y — which matters more?"
• Anchor on outcomes: "The goal is [metric]. Does this addition move it?"
• Offer phased delivery: "V1 without this; measure; add in V2 if data supports it."
• Document non-goals explicitly in every spec.

"What to Stop Doing" Quarterly Review

Every quarter, review the product with assets/strategy/quarterly-product-review.md:

• Which features have <5% usage? → Candidate for removal
• Which initiatives produced no measurable outcome? → Stop or pivot
• Which ongoing costs (maintenance, support) exceed their value? → Sunset
• What are you doing "because we always have" but nobody asked for? → Question

For detailed prioritization patterns and worked examples: see references/prioritization-frameworks.md.

---

Product-Market Fit Measurement

PMF is not a binary event. It's a signal you measure across multiple dimensions.

Sean Ellis Test

Survey users: "How would you feel if you could no longer use [product]?"

• Very disappointed: Target >40% for PMF signal
• Somewhat disappointed: Useful but not dependent
• Not disappointed: Not finding value

Use assets/discovery/pmf-survey-template.md for the full survey (combines Sean Ellis + NPS + usage questions).

Retention Curve Analysis

• Plot cohort retention over time (weekly or monthly depending on product cadence)
• Flattening curve = PMF signal (users who stay, stay)
• Declining curve = No PMF (even retained users eventually leave)
• Segment by ICP: you may have PMF in one segment but not another

Engagement Scoring

Define activation precisely (formula + timeframe + data source):

• What actions constitute "activated"? (not just signed up)
• What's the activation window? (first 7 days, first 14 days?)
• What engagement depth separates power users from casual?

Feature Audit

Periodically audit feature usage to identify what to keep, improve, or remove:

• Top 20% features by usage → invest, polish
• Middle 60% → maintain, don't expand
• Bottom 20% → candidate for removal or redesign
• Features with high support cost relative to usage → redesign or sunset

Segmented PMF

PMF varies by segment. Measure separately for:

• ICP vs non-ICP customers
• Free vs paid users
• Self-serve vs sales-assisted
• By company size, industry, or geography

For detailed PMF measurement methodology: see references/pmf-measurement.md.

---

Stakeholder Management

Founders manage board members, investors, early customers, co-founders, and (eventually) team leads — often without formal PM training.

Key patterns:

• Board / investors: Update monthly with metrics + decisions + asks. Use narrative format, not slide decks. Lead with "what we learned" not "what we shipped."
• Early customers: They are partners, not just users. Share roadmap intent (not commitments). Ask for input on priorities, not feature requests.
• Co-founder alignment: Weekly sync on priorities. Disagree and commit. Document decisions.
• Saying no to stakeholders: "We're not doing X because [reason tied to strategy]. Here's what we're doing instead and why."

For detailed stakeholder management patterns: see references/stakeholder-management.md.

---

What Good Looks Like

• Evidence: 5–10 real user touchpoints or equivalent primary data for material bets.
• Scope: clear non-goals and acceptance criteria that can be tested.
• Learning: post-launch review with metric deltas, guardrail impact, and next decision.

PRDs and Specs

For PRDs/specs and writing-quality requirements, use the templates in ../docs-ai-prd/:

• PRD templates: ../docs-ai-prd/assets/prd/prd-template.md and ../docs-ai-prd/assets/prd/ai-prd-template.md

Optional: AI / Automation

Use only when explicitly requested and policy-compliant.

• AI system lifecycle: assets/ai/ai-lifecycle-template.md
• Agentic workflow docs: assets/ai/agentic-ai-orchestration.md
• AI product patterns: references/ai-product-patterns.md

Navigation

Resources

• references/discovery-best-practices.md
• references/roadmap-patterns.md
• references/delivery-best-practices.md
• references/strategy-patterns.md
• references/positioning-patterns.md
• references/data-product-best-practices.md
• references/interviewing-patterns.md
• references/metrics-best-practices.md
• references/leadership-decision-frameworks.md
• references/operational-guide.md
• references/prioritization-frameworks.md
• references/pmf-measurement.md
• references/stakeholder-management.md
• data/sources.json

Templates

• Discovery: assets/discovery/customer-interview-template.md, assets/discovery/assumption-test-template.md, assets/discovery/opportunity-solution-tree.md, assets/discovery/pmf-survey-template.md
• Prioritization: assets/prioritization/prioritization-scorecard.md, assets/prioritization/kill-criteria-template.md
• Strategy/Vision: assets/strategy/product-vision-template.md, assets/strategy/opportunity-assessment.md, assets/strategy/positioning-template.md, assets/strategy/PRFAQ-template.md, assets/strategy/quarterly-product-review.md
• Data: assets/data/data-product-canvas.md
• Roadmaps: assets/roadmap/outcome-roadmap.md, assets/roadmap/theme-roadmap.md
• Metrics: assets/metrics/metric-tree.md, assets/metrics/okr-template.md
• Ops/Leadership: assets/ops/1-1-template.md, assets/ops/feedback-template.md, assets/ops/a3-debrief.md, assets/ops/negotiation-one-sheet.md

Related Skills

• ../docs-ai-prd/SKILL.md — PRD, stories, and prompt/playbook templates
• ../software-architecture-design/SKILL.md — System design guidance for specs and PRDs
• ../software-frontend/SKILL.md — UI implementation considerations for product specs
• ../software-backend/SKILL.md — Backend/API implications of product decisions
• ../startup-growth-playbooks/SKILL.md — PLG case studies for activation design

---

Operational Guide

See references/operational-guide.md for detailed patterns, template walkthroughs, example flows, and execution checklists. Keep SKILL.md as the navigation hub; use assets/ when producing artifacts.

---

External Resources

See data/sources.json for official frameworks (Lean Startup, OST, PR/FAQ, OKRs) and AI/LLM safety references.

---

Use the quick reference and decision tree above to choose a template, then follow the operational guide for depth.

---

Trend Awareness Protocol

IMPORTANT: When users ask recommendation questions about product management tools, frameworks, or practices, use a web search tool to check current trends before answering. If web search is unavailable, use data/sources.json and state clearly what you verified vs assumed.

Trigger Conditions

• "What's the best tool for [roadmapping/product analytics/discovery]?"
• "What should I use for [OKRs/metrics/customer feedback]?"
• "What's the latest in product management?"
• "Current best practices for [discovery/roadmaps/prioritization]?"
• "Is [framework/tool] still relevant in 2026?"
• "[Linear] vs [Jira] vs [other]?" or "[Amplitude] vs [Mixpanel]?"
• "Best approach for [AI product management/agentic products]?"

Required Searches

1. Search: "product management best practices 2026" 2. Search: "[specific tool] vs alternatives 2026" 3. Search: "product management trends January 2026" 4. Search: "[discovery/roadmap/OKR] frameworks 2026"

What to Report

After searching, provide:

• Current landscape: What PM tools/frameworks are popular NOW
• Emerging trends: New tools, methods, or patterns gaining traction
• Deprecated/declining: Frameworks/tools losing relevance
• Recommendation: Based on fresh data, not just static knowledge

Example Topics (verify with fresh search)

• Product management tools (Linear, Productboard, Notion, Coda)
• Analytics platforms (Amplitude, Mixpanel, PostHog)
• Discovery and research tools (Maze, UserTesting, Dovetail)
• Roadmapping approaches (outcome-based, theme-based, now/next/later)
• AI product management patterns
• Prioritization frameworks (RICE, ICE, opportunity scoring)
• OKR and metrics tools

Fact-Checking

• Use web search/web fetch to verify current external facts, versions, pricing, deadlines, regulations, or platform behavior before final answers.
• Prefer primary sources; report source links and dates for volatile information.
• If web access is unavailable, state the limitation and mark guidance as unverified.

Agentic AI Orchestration Template

Purpose: Design, operate, and evaluate multi-step, tool-using, agentic AI systems.

Use this when building workflows where AI:

• Breaks down tasks
• Uses tools/APIs
• Collaborates across agents
• Executes steps toward a goal

---

1. Agentic System Overview

Fill this out first.

Goal: User Segment: Primary Task(s): Constraints: Success Definition: Failure Modes: Human Oversight Required (Yes/No):

---

2. Agent Definitions

Use one block per agent.

Agent Name: Role / Responsibility: Inputs: Outputs: Tools/APIs it can call: Memory Access (None / Short-Term / Long-Term): Constraints: Success Criteria: Failure Conditions: Escalation Path:

---

3. Orchestration Pattern (Choose One)

Pattern A — Planner → Executors

Use when tasks require decomposition.

Planner responsibilities: • Break goal into subtasks • Sequence subtasks • Assign tasks to agents • Validate intermediate outputs

Executors: • Perform one subtask at a time • Return structured output • Report blockers or uncertainty

---

Pattern B — Multi-Agent Collaboration

Use for complex or specialized domains.

Typical roles:

• Researcher → gathers info
• Synthesizer → summarizes
• Critic → validates, checks safety
• Executor → takes action

Collaboration Rules: • Turn-taking or parallel • Critic must approve before execution • Researcher must cite sources • Synthesizer must reduce ambiguity

---

Pattern C — Guardrail Critic (Safety Layer)

Use when hallucination or compliance risk is high.

Critic responsibilities: • Factuality check • Policy & safety filter • Bias/harm analysis • Compliance with constraints • Confidence scoring

Critic Output: • Approve / Reject / Request More Info

---

4. Tool & API Access Template

Tool Name: Purpose: Input Format: Output Format: Rate Limits: Safety Constraints: Examples of Valid Calls: Handling of Failures:

---

5. Memory & State Management

Choose one:

• Stateless (best for speed + reliability)
• Short-term memory (store last X steps)
• Long-term memory (vector store, logs)

Template: Memory Type: What gets stored: Retention: Access rules: Privacy constraints:

---

6. Execution Flow Template

This is the “source of truth” for orchestration.

Receive user request Validate inputs Planner generates task plan Executors take tasks sequentially or in parallel Critic validates each output if enabled If failure → fallback / retry / escalate Return final result with confidence score Log to monitoring systems

---

7. Safety Guardrails Template

Input Validation: • Allowed domains: • Forbidden domains: • PII handling: Output Filters: • Hallucination checks: • Factuality grounding: • Policy filters: Action Safety: • Restrictions on external tool use: • Required human approval points: Error Handling: • Retries: • Timeouts: • Escalations:

---

8. Evaluation Metrics (Agentic-Specific)

Task Success Rate: Average Steps per Task: Unnecessary Step Rate: Tool Use Success Rate: Fallback Activation Rate: Safety Violations: Latency per Step: Cost per Completion: Human Override Rate:

Monitoring Frequency:

• Daily for high-volume
• Weekly for moderate volume

---

9. Example (Editable)

Goal: Automate weekly sales forecasting for revenue ops

Constraints: Must be grounded in CRM data; zero hallucinations

Planner: • Break forecasting into: data extraction → cleansing → model selection → prediction → summary • Assign subtasks to Researcher and Modeler

Agents: Researcher: Tools: CRM API, SQL connector Output: cleaned dataset

Modeler: Tools: forecasting model API Output: predictions w/ confidence intervals

Critic: Tasks: data integrity check, bias detection, grounding verification Failure Mode: missing fields or abnormal variances

Executor: Output: final forecast summary + recommended actions

Success Criteria: • Forecast generated with <5% error • End-to-end latency < 8s • No hallucinated values

---

10. Orchestration Checklist

• [ ] Clear goal + constraints
• [ ] Roles defined for each agent
• [ ] Planner logic documented
• [ ] Tools/APIs validated
• [ ] Critic layer added where needed
• [ ] Safety filters active
• [ ] Memory strategy chosen
• [ ] Monitoring metrics defined
• [ ] Failures + escalations documented
• [ ] Ready for prototype run

---

11. Definition of Done (Agentic System)

An agentic system is ready when:

• [ ] Task plan executes end-to-end
• [ ] Agents use tools reliably
• [ ] Safety layer catches invalid outputs
• [ ] Metrics exceed thresholds
• [ ] Costs acceptable
• [ ] Human oversight path validated
• [ ] Logs + monitoring operational
• [ ] Behavior is deterministic & repeatable

---

End of file.

AI Product Lifecycle Template

Purpose: Define, evaluate, and operationalize AI-powered features/products.

This template aligns with predictive AI, generative AI, and agentic AI workflows.

---

1. Overview

Use this template to:

• Frame the AI problem
• Evaluate data readiness
• Choose model approach
• Define evaluation metrics
• Plan delivery + governance
• Ensure safety, cost, and feasibility

---

2. AI Lifecycle Template (Copy/Paste)

1. Problem Framing

User Segment: Problem Statement: Context: Why AI is needed (vs rules/manual): Primary Success Metric: Secondary Metrics: Guardrails (latency, safety, cost):

---

2. Data Readiness

Data Sources: Data Types (structured / text / images / logs): Label Availability: Data Quality Score (1–5): Gaps or Missing Data: Privacy Considerations: Bias Risk Areas: Data Contract (if needed):

---

3. Model Approach

Select one or more:

• Predictive ML (classification/regression)
• Generative LLM
• RAG (Retrieval-Augmented Generation)
• Agentic AI (planner + executor, multi-agent)
• Hybrid approach

Chosen Approach: Why this approach: Baseline Model (if any): Constraints (compute, latency, cost): Expected Accuracy/Factuality: Fallback Path:

---

4. Evaluation Plan

Define measurable, objective tests.

4.1 Offline Evaluation

Test Dataset: Metrics:

Accuracy / Precision / Recall (predictive) Factuality / Hallucination rate (LLM) Relevance@K (RAG) Task success rate (agents) Target Thresholds: Reviewer Sample Size: Edge-Case Handling:

4.2 Online Evaluation (Once Launched)

A/B Test Plan: Primary Online Metric: Secondary Metrics: Guardrail Metrics: User Feedback Loop:

---

5. Safety & Risk

Safety Filters Required (YES/NO): Types (PII removal, toxicity, hallucination guardrails):

Bias Checks: Legal/Compliance Risks: Failure Modes: Human-in-the-Loop Needed? (YES/NO) Escalation Path:

---

6. System Design

Inputs: Model(s) Used: Retrieval Layer (if RAG): Orchestration Layer (if agentic): Tools/APIs Used: Output Format: Timeout Rules: Retry Logic: Versioning Approach:

---

7. Latency & Cost Targets

Latency Target (ms): Max Cost per Request ($): Expected Volume: Caching Strategy: Monitoring Plan:

---

8. Deployment Plan

Rollout Strategy (beta / gated / % traffic): Observability: Logging: Alerts: Drift Detection: Retraining Frequency:

---

9. Open Questions & Dependencies

Outstanding Risks: Team Dependencies: Tech Dependencies: Data Dependencies: Decision Needed By:

---

3. Example (Editable)

1. Problem Framing

Segment: Customer support reps Problem: Reps spend 3–6 min searching for answers AI Need: Summarize internal docs and propose draft replies Primary Metric: Avg handle time (AHT) Guardrails: Factuality > 85%, Latency < 800ms

2. Data Readiness

Sources: Knowledge base, CRM tickets Data Types: Text Label Availability: Partial Data Quality Score: 3/5 Privacy: Redact customer data

3. Model Approach

Chosen: RAG + LLM Why: Must ground answers in internal docs Constraints: Latency, cost Fallback: Show top search results if model uncertain

4. Evaluation Plan

Offline:

Factuality > 85% Hallucination rate < 10% Online: AHT reduction 10–20% CSAT/QA scores stable 5. Safety & Risk

Safety Filters: Enabled (PII, hallucination guardrails) Failure Modes: Wrong advice, outdated docs Human-in-the-loop: YES for red flag cases

6. System Design

Retriever: Vector DB Model: (e.g., Claude, GPT) Output: Suggested reply + citations Timeout: 2s Retry: 1

7. Latency & Cost

Latency Target: 700ms Cost: <$0.01 per query

8. Deployment Plan

Beta: 10% reps Monitoring: Latency, factuality, override rate Drift: Monthly review

9. Dependencies

Need updated KB Need PII scrubber in place

---

4. Checklist (Quality Control)

• [ ] Clear problem + user segment
• [ ] Data sources validated
• [ ] Data quality scored
• [ ] Model approach justified
• [ ] Offline + online metrics defined
• [ ] Safety guardrails set
• [ ] Latency + cost thresholds set
• [ ] Retraining plan defined
• [ ] Failure modes documented
• [ ] Rollout strategy decided

---

5. Definition of Done (AI Lifecycle)

AI spec is ready when:

• [ ] Stakeholders understand the problem
• [ ] Data meets minimum quality
• [ ] Evaluation metrics exceed thresholds
• [ ] Guardrails active
• [ ] Human-in-the-loop defined where needed
• [ ] Deployment path documented
• [ ] No open risks blocking progress

---

End of file.

Data Product Canvas

Purpose: Define a reusable, governed, high-quality data product.

Use for:

• Data platform initiatives
• Data-as-a-product teams (Mesh)
• ML feature stores
• Analytics-ready datasets
• Operational data pipelines

---

1. Data Product Canvas (Copy/Paste)

1. Overview

Name: Owner: Domain: Version: Primary Consumers: Use Cases:

---

2. Problem & Value

Problem This Data Solves: Why It Matters: Who Benefits: Value Metrics (time saved, accuracy increase, cost reduced):

---

3. Inputs

Source Systems: Data Types (structured / semi-structured / logs / text): Ingestion Method (batch / streaming): Freshness Target: Data Contracts in Place? (Y/N) Known Quality Issues:

---

4. Transformations

Business Logic Summary: Transformation Steps: Edge-Case Rules: Dependencies: Testing Strategy (unit tests, schema checks):

---

5. Outputs

Output Format (table, view, API, event stream): Schema: Column Definitions: Sample Records: Intended Queries / ML Features:

---

6. SLAs & Quality

Freshness SLA: Availability SLA: Quality Targets: Completeness: Accuracy: Consistency: Validity: Timeliness:

Guardrails: Max latency: Allowed schema drift: Cost thresholds:

---

7. Governance

Access Rules (RBAC/ABAC): PII Handling: Security Measures: Lineage (source → transform → output): Retention Policy: Audit Requirements:

---

8. Monitoring & Alerts

Metrics Monitored: Alert Thresholds: Alert Recipients: Incident Response Runbook: Drift Detection Rules:

---

9. Adoption & Documentation

Documentation Links: How-To Guides: Query Examples: Success Metrics (adoption, usage, reliability): Feedback Channels:

---

2. Data Product Checklist

Problem & Value

• [ ] Clear value for consumers
• [ ] Problem documented in plain language

Inputs

• [ ] Sources identified
• [ ] Contracts established
• [ ] PII flagged

Transformations

• [ ] Business logic documented
• [ ] Tests in place
• [ ] Lineage mapped

Outputs

• [ ] Schema defined
• [ ] Data dictionary complete
• [ ] Example queries included

SLAs

• [ ] Freshness targets defined
• [ ] Availability targets defined
• [ ] Quality targets set

Governance

• [ ] RBAC configured
• [ ] Privacy rules applied
• [ ] Retention documented

Monitoring

• [ ] Alerts configured
• [ ] Drift detection set
• [ ] Ownership assigned

Adoption

• [ ] Documentation published
• [ ] Consumer onboarding defined
• [ ] Feedback loop established

---

3. Example (Editable)

Data Product Canvas

Name: Shipment Reconciliation Dataset Owner: Data Product Owner – Logistics Domain: Operations Version: v1.0

Consumers: BI team, Ops analysts, ML forecasting team Use Cases: • Weekly SLA compliance reporting • Predicting delay likelihood • Automated reconciliation tasks

Problem & Value

Problem: Shipment data arrives from 5 carriers with inconsistent formats. Why It Matters: Ops teams spend 5+ hours weekly reconciling data. Value Metrics: -80% manual work, +20% SLA compliance.

Inputs

Sources: Carrier APIs, TMS exports, warehouse events Ingestion: Streaming for real-time alerts Freshness Target: < 5 minutes

Transformations

• Normalize carrier schemas • Deduplicate shipments • Compute ETA deltas • Identify anomalies Test Strategy: schema tests + dq checks

Outputs

Format: Analytics table + API Schema: shipment_id, event_time, carrier, eta, status, anomaly_flag

SLAs & Quality

Freshness: <5 minutes Availability: 99.9% Quality: Completeness: >95% Accuracy: >98% Validity: <1% violations

Governance

RBAC: Analysts read, ML write, Ops admin PII: Must be stripped Retention: 12 months rolling

Monitoring

Metrics: freshness, errors, anomaly count Alerts: Slack + PagerDuty Drift: compare weekly distributions

Adoption

Docs: Confluence page + DBT docs Feedback: Slack #data-users

---

4. Definition of Done (Data Product Canvas)

A data product canvas is ready when:

• [ ] Inputs, outputs, and transformations are clear
• [ ] SLAs and quality metrics defined
• [ ] Governance documented
• [ ] Monitoring plan established
• [ ] Consumers + use cases identified
• [ ] No unanswered sections
• [ ] Fits on 1–2 pages

---

End of file.

Assumption Test Template

Purpose: Validate the riskiest parts of an idea before investing in delivery.

Use this template to design structured, measurable tests for value, usability, feasibility, and viability.

---

1. Assumption Categories

Value Risk – Do customers care? Will they use it? Usability Risk – Can they figure it out on first try? Feasibility Risk – Can we build it? Does tech support it? Viability Risk – Should we build it? Legal, cost, ops constraints.

---

2. Assumption Mapping Template

Idea / Hypothesis: User Segment: Opportunity (Problem):

Assumptions:

Value: Usability: Feasibility: Viability: Riskiest Assumption: Why it’s riskiest: Evidence we have: Evidence missing:

---

3. Test Card Template

Test Name:

Purpose: Assumption Type: Value / Usability / Feasibility / Viability

Hypothesis: We believe that…

Test Method: (Choose one: concierge / fake door / prototype / usability task / tech spike / pricing test / legal review / shadow mode)

Procedure: Step 1: Step 2: Step 3:

Success Criteria: Fail Condition:

Sample Size: Segment: Duration:

Owner: Status: Next Steps:

---

4. Experiment Types (Operational)

Value Tests

• Fake door
• Landing page with CTA
• Pre-selling / pre-pay
• Pitch test
• Concierge / manual fulfillment
• Price sensitivity test

Usability Tests

• Prototype task walkthrough
• Think-aloud usability test
• Unmoderated task completion
• Success score (completion %)

Feasibility Tests

• Tech spike
• Latency benchmark
• Integration stub
• Load test

Viability Tests

• Legal/privacy review
• Cost modeling
• Brand review
• Operational capacity review

---

5. Prioritizing Tests

Run assumptions in this order:

1. Value – If they don’t care, nothing else matters 2. Usability – If they can’t use it, it won’t succeed 3. Feasibility – Validate core tech constraints 4. Viability – Ensure compliance + business fit

Checklist:

• [ ] One test per assumption
• [ ] Batch small tests first
• [ ] Parallelize where possible

---

6. Example (Editable)

Idea: Guided Setup for New Users Segment: SMB admins Opportunity: “New users get stuck on first configuration.”

Assumptions:

Value: They want guidance (high risk) Usability: They can follow steps Feasibility: Can be built using existing UI components Viability: No legal concerns Riskiest = Value

Test Name: Fake Door CTA Method: Value Hypothesis: We believe 20%+ of new users will click "Start Guided Setup".

Procedure:

Add CTA to onboarding screen Track clicks for 7 days Show “Coming soon” modal Success Criteria: ≥20% click Fail Condition: <10% click Owner: PM Next Step: If pass → usability test If fail → revisit opportunity

---

7. Test Design Checklist

• [ ] Test isolates ONE assumption
• [ ] Has measurable success criteria
• [ ] Has clear fail condition
• [ ] Sample size defined
• [ ] Time-bound
• [ ] No coding unless required
• [ ] Covers highest-risk assumption first
• [ ] Results tied back to Opportunity Solution Tree

---

8. Definition of Done (Assumption Testing)

A test is complete when:

• [ ] One assumption validated or invalidated
• [ ] Clear evidence collected
• [ ] Decision recorded (pivot / persevere / redesign)
• [ ] OST updated
• [ ] Next test queued

---

End of file.

Customer Interview Template

Purpose: Understand real customer behavior, pains, alternatives, and impact.

When to Use

Use this template when:

• Validating problems
• Exploring opportunities
• Understanding workarounds
• Evaluating segment fit
• Generating insight for OST

---

Structure

This template includes:

1. Setup 2. Script 3. Notes structure 4. Commitment test 5. Example 6. Quality checklist

---

1. Interview Setup

Before the call

• [ ] Recruit participants who have experienced the problem
• [ ] Prepare 3–5 behaviors to probe
• [ ] Prototype not needed (unless solution testing)
• [ ] Recording permission ready

Opening Script Thanks for making time. Today I just want to understand how you handle [area]. I’m not here to pitch anything — I won’t ask for opinions on ideas. I’ll ask about things you’ve actually done in the real world.

---

2. Interview Script

2.1 Trigger the Story

Ask about specific, recent behavior.

Tell me about the last time you [did the task]. What were you trying to accomplish? When did this happen? What kicked this off?

2.2 Walk Through Behaviors

Encourage step-by-step narration.

Walk me through it from the beginning. What did you do first? Then what happened? What did you do next? Where did you go? Who else was involved?

2.3 Probe for Pain + Frequency

What was the hardest part? How often does this happen? What makes it annoying or expensive? What have you tried to make this easier?

2.4 Explore Alternatives

What other tools/methods did you try? Why not choose something else? What worked well? What didn’t?

2.5 Impact Assessment

What happens if you don’t solve this? How much time/money does this cost? What’s the consequence of doing nothing?

2.6 Closing

This was super helpful — thank you. Would you be open to reviewing a prototype later? Is there anyone else we should speak with? Could you share any artifacts you used? (e.g., screenshots, files)

---

3. Notes Template

Copy during or after the interview:

Participant: Role/Segment: Date:

Context Trigger: Detailed Steps: Tools Used: Pain Points: Workarounds: Frequency: Impact (time/money/emotional): Alternatives Tried: Quotes (verbatim): Opportunities Identified: Signal Strength: Strong / Medium / Weak Next Actions:

---

4. Commitment Test Options

Use one or more to evaluate true interest:

• Time: “Can we schedule a 20-minute follow-up to review a prototype?”
• Data: “Could you share anonymized data/logs/screenshots?”
• Referrals: “Who else should we talk to?”
• Early Access: “Would you want early access when we test this?”

Pass = actual behavior Fail = polite interest

---

5. Fully Filled Example (Editable)

Participant: Sr. Ops Manager at mid-size logistics company Segment: Freight scheduling Date: Jan 16

Trigger: “Last Thursday I needed to reschedule a delayed shipment.”

Steps:

Logged into TMS Exported CSV Emailed carrier Called warehouse Manually updated ETA Re-exported CSV for weekly report Pain: • Took ~45 min • Manual ETA updates prone to errors • Carrier response delays

Workarounds: • Built personal Google Sheet macros • Created email templates

Impact: • Delay causes $2–5K in penalties • High stress during peak seasons

Alternatives Tried: • Looked at competitor TMS → too expensive

Opportunities: • Automated ETA adjustments • Unified communication surface

Signal Strength: STRONG Next: Prototype workflow automation

---

6. Interview Quality Checklist

• [ ] Participant experienced problem recently
• [ ] You talked < 30% of the time
• [ ] You collected quotes, not summaries
• [ ] No solution pitching
• [ ] At least one concrete story captured
• [ ] Frequency + severity captured
• [ ] Opportunities phrased as problems
• [ ] Signal strength assigned

---

End of file.

Opportunity Solution Tree Template

Purpose: Visualize the path from outcomes → opportunities → solutions → experiments.

Use this template to structure discovery work, prioritize opportunities, and track experiments.

---

1. Structure

Outcome (metric to improve)

↳ Opportunity 1 (customer problem) ↳ Solution Hypothesis A ↳ Experiment A1 ↳ Experiment A2 ↳ Solution Hypothesis B ↳ Experiment B1

↳ Opportunity 2 (customer problem) ↳ Solution Hypothesis C ↳ Experiment C1

---

2. Template (Copy/Paste)

Outcome

Metric: Current Baseline: Target: Why it matters:

Opportunities (Problems)

For Each Opportunity

Opportunity:

Problem Statement: User Segment: Severity (1–5): Frequency (1–5): Evidence (quotes/data):

Solutions (Hypotheses) Hypothesis 1: • What it solves: • Assumptions (value/usability/feasibility/viability): Hypothesis 2: • What it solves: • Assumptions: Experiments For each hypothesis: Test Name: Test Type (value/usability/feasibility/viability): How it works: Success criteria: Fail condition: Status:

---

3. Prioritization Patterns

3.1 Opportunity Scoring

Score each 1–5:

• Severity of pain
• Frequency
• Evidence strength
• Strategic alignment

Priority Score = Sum

---

3.2 Solution Prioritization (Test First What’s Riskiest)

Order tests by:

1. Value Risk (do they care?) 2. Usability Risk 3. Feasibility Risk 4. Viability Risk

---

4. Example (Editable)

Outcome

Metric: Activation Rate (Signup → First Key Action) Baseline: 32% Target: 45% Why: Strong predictor of retention

Opportunity 1

Problem: “New users can’t find where to start.” Evidence: 7 interviews, repeated confusion on Step 1 Severity: 4 Frequency: 5

Solution Hypothesis A

Users need a guided path for the first task. Assumptions:

Value: Users want guidance Usability: They can follow a 3-step prompt Feasibility: Easy to build in 1 sprint Viability: No pricing/legal issues Experiments Test A1:

Type: Usability Method: Prototype task walkthrough Success: 70% complete task without hint Fail: <50% success Test A2:

Type: Value Method: Fake door (“Start Guided Setup” button) Success: >25% click rate Fail: <10% Opportunity 2

Problem: “Users don’t see the initial value soon enough.” Evidence: Analytics + 3 interviews Severity: 3 Frequency: 4 Solutions:

Show quick-win examples Pre-populate sample data Experiments pending

---

5. OST Quality Checklist

• [ ] Outcome metric is clear, measurable
• [ ] Opportunities are written as problems, not ideas
• [ ] All opportunities supported by evidence
• [ ] Solutions are hypotheses, not commitments
• [ ] Experiments tied to assumptions
• [ ] Most risky assumptions tested first
• [ ] OST updated weekly with learnings

---

6. Definition of Done (OST)

An OST is ready when:

• [ ] 1 outcome metric defined
• [ ] 3–7 opportunities mapped
• [ ] 1–3 solution hypotheses per opportunity
• [ ] Experiments defined with pass/fail
• [ ] All items traceable to evidence
• [ ] Priorities clearly marked
• [ ] Not more than 1 page per opportunity

---

End of file.

Product-Market Fit Survey Template

Combined Sean Ellis + NPS + usage survey. Send to active users who have used the product at least 2x in the past 2 weeks. Minimum 40 responses for meaningful data.

---

Survey Questions

Q1: Sean Ellis (Core PMF Indicator)

How would you feel if you could no longer use [Product Name]?

• [ ] Very disappointed
• [ ] Somewhat disappointed
• [ ] Not disappointed

PMF Signal: >40% "Very disappointed"

---

Q2: Primary Use Case

What is the main thing you use [Product Name] for?

[Open text]

Analysis: Cluster responses to identify your actual use cases vs assumed ones.

---

Q3: Key Benefit

What is the primary benefit you get from [Product Name]?

[Open text]

Analysis: Use the most common answers in positioning and marketing copy.

---

Q4: Alternative

What would you use instead if [Product Name] no longer existed?

• [ ] A specific competitor: _______________
• [ ] A general tool (spreadsheet, email, manual process): _______________
• [ ] I wouldn't look for an alternative (I'd just stop doing this)
• [ ] Other: _______________

Analysis: "General tool" and "wouldn't look" = you own the category. Specific competitor = you need to differentiate.

---

Q5: Improvement

If you could change one thing about [Product Name], what would it be?

[Open text]

Analysis: Cluster by theme. High-frequency themes from "Very disappointed" users are your highest-leverage improvements.

---

Q6: NPS

How likely are you to recommend [Product Name] to a colleague or friend?

[Scale: 0-10]

• 0-6: Detractor
• 7-8: Passive
• 9-10: Promoter

NPS = % Promoters - % Detractors

---

Q7: Usage Frequency

How often do you use [Product Name]?

• [ ] Multiple times per day
• [ ] Daily
• [ ] Several times per week
• [ ] Weekly
• [ ] Monthly
• [ ] Rarely

---

Q8 (Optional): Role and Context

What best describes your role?

[Dropdown or open text]

How many people on your team use [Product Name]?

• [ ] Just me
• [ ] 2-5
• [ ] 6-20
• [ ] 20+

---

Analysis Guide

Step 1: Segment Responses

Split all responses by:

• Sean Ellis answer (Very disappointed vs others)
• User segment (ICP match, plan type, company size)
• Usage frequency

Step 2: Profile Your "Very Disappointed" Users

These are your core audience. Analyze:

• What do they use the product for? (Q2)
• What benefit do they get? (Q3)
• What would they use instead? (Q4)
• What do they want improved? (Q5)

Step 3: Compare Segments

Step 4: Action Items

• If >40% Very Disappointed: You have PMF in this segment. Double down. Improve what they love.
• If 25-40%: Promising. Focus on converting "Somewhat" to "Very" — usually means better onboarding or removing friction.
• If <25%: No PMF yet. Pivot, narrow the ICP, or fundamentally change the product.

Step 5: Track Over Time

Run this survey quarterly. Track the trend, not just the snapshot.

Metric Tree Template

Purpose: Connect the company’s North Star → product outcomes → team input metrics.

Use for OKRs, roadmaps, product strategy, and instrumentation planning.

---

1. Metric Tree Structure (Copy/Paste)

North Star Metric (NSM)

Definition: Formula: Why it matters:

↳ Product Outcome 1 Definition: Formula: Baseline: Target: Guardrails: Owner: Teams influencing it:

↳ Team Input Metric A Definition: Baseline: Target: Levers (3–5 actions team can take): Dependencies:

↳ Team Input Metric B ...

↳ Product Outcome 2 ...

↳ Product Outcome 3 ...

---

2. North Star Metric Template

NSM: What it measures: Formula: Customer Value Represented: Business Value Represented: Leading Indicator(s): Lagging Indicator(s): Review Cadence:

---

3. Product Outcome Metric Template

Outcome Name: Definition: Formula: Baseline: Target: Guardrail Metrics: Owner: Linked Themes:

---

4. Input Metric Template

Team-level metric that is controllable within a cycle.

Metric Name: Definition: Baseline: Target: Why This Team Controls It: Levers (Actions Team Can Take): Dependencies: Risks: Review Cadence:

---

5. Metric Tree Patterns

Pattern A — Activation-Led Growth

NSM: Retained Activated Users (WAU who completed key action) ↳ Outcome 1: Activation rate (signup → key action) ↳ Input: Completion of onboarding steps ↳ Input: Time-to-first-value

Pattern B — Engagement-Led Retention

NSM: Weekly Active Teams ↳ Outcome: Weekly key action frequency ↳ Input: Task creation rate ↳ Input: Session depth

Pattern C — Revenue Expansion

NSM: Net Revenue Retention (NRR) ↳ Outcome: Upgrade conversion rate ↳ Input: Paywall views ↳ Input: Feature usage of premium tools

Pattern D — AI Product Quality

NSM: Task Success Rate (for agentic AI) ↳ Outcome: Model Factuality ↳ Input: Retrieval coverage ↳ Input: Prompt grounding rate

---

6. Example Metric Tree (Editable)

NSM: Weekly Active Teams (WAT)

Formula: Unique teams with ≥3 completed workflows per week Why: Strong predictor of retention + expansion

↳ Outcome 1: Activation Rate (32% → 45%) Baseline: 32% Target: 45% Guardrails: Onboarding completion time Owner: PM Lead Inputs: • Step 1 completion rate • Time-to-first workflow created

↳ Outcome 2: Workflow Engagement (avg 2.1 → 3.5 workflows/week) Baseline: 2.1 Target: 3.5 Inputs: • Workflow creation rate • % returning after 7 days • Feature usage (auto-triggers)

↳ Outcome 3: Team Expansion Rate (upgrade + cross-team) Inputs: • Multi-user activation • Role-based permission adoption • Shared workflows created

---

7. Metric Tree Checklist

• [ ] NSM expresses customer value
• [ ] NSM measurable and stable
• [ ] 2–5 product outcomes linked directly to NSM
• [ ] Outcomes have baselines + targets
• [ ] Input metrics are fully team-controlled
• [ ] Guardrail metrics defined for each outcome
• [ ] No vanity metrics (pageviews, downloads)
• [ ] Tree ≤ 1 page

---

8. Decision Tree: Is This a Good Metric?

Is it measurable? ├─ No → Reject └─ Yes ↓ Is it controllable by the responsible team? ├─ No → Make it an outcome metric └─ Yes ↓ Does it reflect meaningful customer value? ├─ No → Remove or revise └─ Yes → Keep

---

9. Definition of Done (Metric Tree)

A metric tree is ready when:

• [ ] NSM is validated with leadership
• [ ] Product outcomes are clear + measurable
• [ ] Each outcome has 1–3 input metrics
• [ ] All metrics have owners
• [ ] Targets are defined with confidence
• [ ] Guardrails prevent regressions
• [ ] Tree used during roadmap planning

---

End of file.

OKR Template

Purpose: Create clear, outcome-driven Objectives and Key Results. Use OKRs to align teams around measurable outcomes — not projects or features.

---

1. OKR Structure (Copy/Paste)

Objective (Qualitative)

A short, inspirational, time-bound statement describing what success looks like.

Why This Objective Matters:

Key Results (Quantitative)

KR1: Baseline: Target: Metric Owner:

KR2: Baseline: Target: Metric Owner:

KR3 (optional): Baseline: Target: Metric Owner:

Guardrail Metrics (if any):

Timeframe: Review Cadence:

---

2. Objective Patterns

Use these fill-in patterns to generate strong Objectives.

Pattern A — Improve a Core User Outcome

Enable [segment] to more easily [job-to-be-done] by improving [experience].

Pattern B — Strengthen Product Quality / Reliability

Deliver a more reliable and predictable experience for [user segment].

Pattern C — Accelerate Growth

Increase [activation/retention/revenue] by helping users get value faster.

Pattern D — Foundational / Platform Investment

Build a scalable foundation that accelerates delivery and reduces risk.

---

3. Key Result Patterns

KR format: metric change within timeframe

Acquisition

• Signup → activation rate: 32% → 45%
• Qualified lead volume: +30%
• Cost per acquisition: -20%

Activation

• Time-to-first-value: 20 min → 5 min
• Step 1 completion rate: 55% → 70%

Engagement / Retention

• Weekly active users: +40%
• Feature adoption: +25%
• Churn: -10%

Monetization

• Upgrade conversion: 3% → 6%
• Expansion revenue: +15%
• ARPU: +20%

Platform / Reliability

• Latency: 900ms → 350ms
• Error rate: -50%
• Incidents: -40%

AI / ML

• Factuality: 70% → 90%
• Hallucination rate: <5%
• Task success rate (agents): 60% → 85%

---

4. Example OKR (Editable)

Objective

Help new users experience value within their first 24 hours.

Why This Matters: Activation strongly predicts retention.

Key Results

KR1: Activation rate from 32% → 45% Baseline: 32% Owner: Growth PM

KR2: Time-to-first-value from 18 min → <5 min Baseline: 18 min Owner: Design Lead

KR3: Step 1 completion from 54% → 75% Baseline: 54% Owner: Onboarding Engineering

Guardrails:

Support tickets must not increase by >10% Latency must remain < 500ms Timeframe: Q2 Review: Weekly

---

5. OKR Anti-Patterns (Do Not Use)

• AVOID: Tasks disguised as KRs (“Ship feature X”)
• AVOID: More than 3–4 KRs per Objective
• AVOID: KRs without owners
• AVOID: No baselines
• AVOID: Not measurable
• AVOID: Mixing outcomes and outputs
• AVOID: Objectives for every team without strategic alignment

---

6. OKR Review Ritual (Operational)

Weekly: • Update metric progress • Discuss blockers • Adjust levers

Monthly: • Evaluate whether KRs are on track • Revisit focus if off-track

Quarter End: • Score KRs (0–1.0) • Capture learnings • Reset next quarter

---

7. OKR Checklist

• [ ] Objective is qualitative and inspiring
• [ ] 2–4 measurable Key Results
• [ ] Baselines and targets provided
• [ ] Each KR has a clear owner
• [ ] Guardrails defined
• [ ] Fits on 1 page
• [ ] Reviewed weekly

---

8. Definition of Done (OKRs)

OKRs are ready when:

• [ ] Outcomes, not outputs
• [ ] Aligned to roadmap themes
• [ ] Targets are aggressive but realistic
• [ ] Entire team understands them
• [ ] Decision-making becomes easier

---

End of file.

1:1 Meeting Template

Purpose: Create clarity, alignment, and continuous improvement with each team member.

Use weekly or biweekly. Focus on people, decisions, blockers, and growth.

---

1. 1:1 Structure (Copy/Paste)

Date: Team Member: Role: Manager:

Check-In • Energy level: • Stress level: • Wins since last 1:1: Priorities & Progress • Key priorities from last week: • What’s on track? • What’s at risk? Blockers • What’s blocking progress? • What support is needed? • What decisions are stuck? Feedback (Both Ways) • Manager → team member: • Team member → manager: • Follow-up actions: Growth & Development • Skill focus: • Opportunities to stretch: • Progress on development goals: Team & Collaboration • Team health check: • Cross-team issues: • Communication gaps: Commitments & Next Steps • Decisions: • New priorities: • Owner + due date:

---

2. Conversation Prompts

Check-In

• “What’s one thing that went well this week?”
• “Any stressors I should know about?”
• “Anything outside of work impacting your bandwidth?”

Progress

• “What are the 1–2 highest-impact things you did last week?”
• “Anything that surprised you?”

Blockers

• “What feels harder than it should be?”
• “What is slowing you or the team down?”
• “Where do you need air cover or decisions?”

Feedback

• “One thing I appreciate is…”
• “One thing to improve is…”
• “What’s one thing I could do better as your manager?”

Growth

• “What skill do you want to level up next?”
• “Where do you want more autonomy?”
• “Any work you want to do more/less of?”

---

3. Example (Editable)

Date: March 12 Team Member: Sarah Role: Senior Designer Manager: Alex

Check-In: Energy: 7/10 Stress: Medium — juggling two projects Wins: Positive feedback from research team Priorities & Progress: On Track: Onboarding redesign At Risk: Dashboard prototype (blocked on API responses) Blockers: • Waiting 4 days on engineering API spec Support Needed: Manager to escalate with backend lead Feedback: Manager → Sarah: Great clarity in last design review Sarah → Manager: Wants earlier involvement in roadmap discussions Growth: Focus: Interaction design + storytelling Opportunity: Present at next quarterly review Team: No conflicts; requests more async decision documentation Commitments: • Manager escalates API delay (today) • Sarah drafts roadmap input notes (by Friday)

---

4. Manager Preparation Checklist

• [ ] Review last week’s commitments
• [ ] Check relevant metrics / performance signals
• [ ] Bring specific feedback examples
• [ ] Bring clarity on priorities
• [ ] Protect the full 30 minutes
• [ ] No status-only conversations

---

5. Team Member Preparation Checklist

• [ ] List top 2–3 priorities
• [ ] Identify blockers
• [ ] Bring questions or requests
• [ ] Prepare feedback for manager
• [ ] Suggest agenda items

---

6. Anti-Patterns (Avoid)

• AVOID: Only discussing status updates
• AVOID: Manager talking > 50% of the time
• AVOID: Keeping feedback vague
• AVOID: Skipping 1:1s during busy weeks
• AVOID: Treating 1:1 as therapy or complaint session
• AVOID: Leaving without decisions or commitments

---

7. Definition of Done (1:1)

A 1:1 is successful when:

• [ ] Both sides shared feedback
• [ ] Blockers identified + addressed
• [ ] Priorities clarified
• [ ] Growth reinforced
• [ ] Decisions documented
• [ ] Concrete next steps with owners set

---

End of file.

A3 Debrief Template

Purpose: Quickly and systematically analyze issues, decisions, or failures to improve future execution.

Use after:

• Incidents
• Failed experiments
• Missed deadlines
• Project pivots
• Launches

Fits on one page.

---

1. A3 Template (Copy/Paste)

Title:

Date: Owner: Team:

Background • What happened? • Why are we analyzing this? Current Situation • Facts only (no opinions) • Impact on customers / team / business Goal / Expected Outcome • What we intended to happen • Target metrics if relevant Root Cause Analysis • Primary root cause: • Contributing factors: • Evidence: Countermeasures • What actions will prevent recurrence? • Owners + deadlines Follow-Up Plan • What to inspect? • How often? • Success indicators Lessons Learned • What did we learn? • What will we do differently next time?

---

2. Root Cause Patterns

Use these patterns to identify root causes quickly.

Pattern A — “5 Whys”

Why did this happen? Why did that happen? Why did that happen? Why did that happen? Root cause:

Pattern B — Categorize by Type

• People: Misaligned expectations, unclear roles
• Process: Missing steps, unclear handoff
• Tools: Bugs, lack of instrumentation
• Communication: No shared understanding
• Assumptions: Invalidated or untested

Pattern C — Evidence Check

A valid root cause MUST have:

• [ ] Evidence
• [ ] Clear link to the outcome
• [ ] Something the team can influence

---

3. Countermeasure Template

Action: Owner: Deadline: Expected Impact: Dependencies: Risks: Success Criteria:

---

4. Example (Editable)

Title: Onboarding Drop-Off Incident

Date: April 2 Owner: PM – Activation Team: Growth + Design

Background Activation dropped from 32% → 20% after onboarding change. Current Situation • Step 2 error rate increased 3x • Affected 40% of new users • Support tickets increased by 18% Goal Keep activation stable while shipping redesign. Root Cause Analysis Primary Root Cause: • API response delay causing form timeout Evidence: • Logs show 1.8s → 8.4s latency spike • Engineering confirmed regression Contributing Factors: • Missing alert for API latency • No fallback message in UI Countermeasures • Fix API regression (Owner: Backend Lead, Due: Apr 3) • Add API latency alert (Owner: SRE, Due: Apr 4) • Add UI fallback state (Owner: Design, Due: Apr 7) Follow-Up Plan • Monitor latency daily for 2 weeks • Track activation trend weekly • Review after 30 days Lessons Learned • Instrumentation required before rollout • Must test onboarding end-to-end with production data

---

5. Debrief Facilitation Script

Use this structure in team debrief meetings:

“Let’s start with what we intended to happen.” “Here’s what actually happened.” “Let’s identify the primary root cause — evidence only.” “Which countermeasures will prevent this next time?” “Who owns what, and by when?” “Let’s agree on how we’ll follow up.”

---

6. Quality Checklist

• [ ] Fits on a single page
• [ ] Uses facts, not opinions
• [ ] Contains a single clear root cause
• [ ] Countermeasures address root cause
• [ ] Owners + dates assigned
• [ ] Follow-up clearly defined
• [ ] Lessons captured for future cycles

---

7. Definition of Done (A3 Debrief)

An A3 is complete when:

• [ ] Team agrees on root cause
• [ ] Countermeasures prevent recurrence
• [ ] Follow-up plan is scheduled
• [ ] Insights feed back into roadmap or process

---

End of file.

Feedback Template

Purpose: Deliver clear, kind, actionable feedback that drives behavior change.

Use during 1:1s, performance reviews, project debriefs, and anytime feedback is needed.

---

1. SBI Framework (Situation → Behavior → Impact)

Use this for 90% of feedback situations.

Situation: “When [context / event]…”

Behavior: “I observed that you [specific behavior]…”

Impact: “This resulted in [outcome / effect]…”

Next Step: “I suggest [new behavior]…” or “Next time, try…”

Example: Situation: “In yesterday’s design review…” Behavior: “You interrupted the presenter 3 times…” Impact: “…which made it hard for the team to follow the discussion.” Next Step: “Let’s wait until slides finish before asking questions.”

---

2. COIN Framework (Context → Observation → Impact → Next)

A variant you can use interchangeably.

Context: Observation: Impact: Next Step:

---

3. Positive Feedback Template

Use to reinforce desirable behaviors.

Context: “When you…”

Behavior: “I noticed you…”

Impact: “This helped…”

Keep Doing: “Please continue doing this because…”

Example: When you documented all edge cases, I noticed the QA team shipped with zero defects. This saved us 2–3 days of back-and-forth. Keep doing this — it sets the bar for the team.

---

4. Improvement Feedback Template

Use when behavior needs to change.

Situation: Behavior: Impact: Expectation: Support: Next Check-In:

Example: Situation: Last sprint deadline Behavior: You merged PRs without tests Impact: We had two outages Expectation: Every PR includes minimum test coverage Support: I can help pair with you this week Next Check-In: Friday

---

5. Real-Time Micro-Feedback Script

Use in the moment (30–60 seconds).

“Can I share something quickly?” “When you [behavior], the impact is [impact].” “Next time, try [specific suggestion].”

---

6. Upward Feedback Template (Team → Manager)

Context: Impact: Request: What would help me be more effective:

Example: Context: Priority changes last week Impact: Team lost two days rewriting specs Request: More visibility when priorities shift What would help: A quick Slack update before decisions finalize

---

7. Difficult Feedback Script (High-Stakes Situations)

“I need to give you some direct feedback. Is now okay?” Describe the facts only. Describe the impact. Describe the expectation clearly. Ask: “How do you see it?” Co-create next steps. Set a follow-up date.

---

8. Checklist for Good Feedback

• [ ] Specific, observable behavior
• [ ] No labels (“lazy”, “unprofessional”)
• [ ] Describes impact
• [ ] Actionable next steps
• [ ] Delivered ASAP (within days)
• [ ] Delivered privately
• [ ] Balanced (positive + constructive)
• [ ] Manager listens more than talks
• [ ] Follow-up scheduled

---

9. Anti-Patterns (Avoid)

• AVOID: Generalizations (“you always…”)
• AVOID: Judgments (“you’re not committed”)
• AVOID: Delayed feedback weeks after event
• AVOID: Feedback without examples
• AVOID: Sandwiching (fake praise → criticism → fake praise)
• AVOID: Making it about personality
• AVOID: Not offering support

---

10. Definition of Done (Feedback)

Feedback is effective when:

• [ ] Receiver understands the behavior clearly
• [ ] Receiver understands the impact
• [ ] A specific change or continuation is defined
• [ ] A follow-up date exists
• [ ] No confusion about expectations

---

End of file.

Negotiation One-Sheet

Purpose: Prepare for any negotiation using a tactical, structured, repeatable format.

Use this template for:

• Stakeholder alignment
• Cross-team tradeoffs
• Vendor negotiations
• Salary/role negotiations
• Conflict resolution

---

1. Negotiation Summary (Copy/Paste)

Negotiation Topic: Counterparty: Date: Desired Outcome (yours): Acceptable Alternatives (yours): Non-Negotiables (yours): Risks:

---

2. Counterparty Map

Identify what the other side values.

Their Goals: Their Pressures: Their Constraints: Their Fears: Their Incentives: Decision Maker (actual):

---

3. BATNA (Best Alternative to a Negotiated Agreement)

Your BATNA: Their BATNA: Your Worst Acceptable Outcome: Their Likely Worst Acceptable Outcome:

---

4. Opening Moves

4.1 Calibrated Questions (Voss Pattern)

Use these to uncover hidden constraints:

• “How am I supposed to do that?”
• “What’s the biggest challenge you see?”
• “What about this is most important to you?”
• “How would you solve this if you were in my shoes?”
• “What’s your flexibility on X?”

4.2 Labels (for emotions/tension)

• “It seems like ___ matters a lot here.”
• “It sounds like you’re worried about ___.”
• “It looks like ___ is blocking us.”

4.3 Mirrors (to gather more info)

Repeat last 1–3 words:

• Helps them reveal additional info
• Slows the conversation

---

5. Accusation Audit (Prepare Before Meeting)

List every negative thing they might think about you.

Before we start, you might think: • … • … • …

Use this first in the meeting.

---

6. Offer Structure (Operational)

Use the “No-Pressure Offer” pattern:

“Here are a few options — feel free to say no to any of them.”

Option A: [Preferred outcome] Option B: [Alternative acceptable] Option C: [Their idea reflected back]

Anchor Range (if applicable): [high → realistic]

---

7. Agreement Conditions

Success Criteria: Risks Removed: Timeline: Who Decides: Next Steps (with dates):

---

8. Example (Editable)

Negotiation Topic: Move design resources to critical onboarding work for Q2 initiative.

Desired Outcome: 1 full-time designer for 6 weeks.

Acceptable Alternatives: • 50% allocation for 8 weeks • Swap support: Eng provides 1 backend dev in exchange

Non-Negotiables: • Delivery must start within 2 weeks

Counterparty Goals: • Keep progress on their roadmap themes

Calibrated Questions: • “What about this request is most challenging for your team?” • “How would you think about resourcing if activation is the top metric?”

Accusation Audit: • “You may think I’m pulling resources without warning.” • “You might feel this puts your timeline at risk.”

Options: A — One full-time designer for 6 weeks B — Half-time designer for 8 weeks C — Swap a backend dev for 4 weeks

Success Criteria: • Q2 onboarding experiments unblocked • No critical slips on their side

---

9. Negotiation Checklist

• [ ] BATNA defined
• [ ] Your desired outcome written down
• [ ] Their pressures understood
• [ ] 5 calibrated questions prepared
• [ ] Accusation audit drafted
• [ ] Options framed (A/B/C)
• [ ] Anchor range defined
• [ ] Next steps + owners established

---

10. Definition of Done (Negotiation)

The negotiation is successful when:

• [ ] Both sides understand constraints clearly
• [ ] Agreement is documented
• [ ] No hidden assumptions remain
• [ ] Clear next steps + dates set
• [ ] Feels sustainable (not forced)

---

End of file.

Kill Criteria Template

Define these BEFORE starting any initiative. Review at the pre-defined checkpoint.

---

Initiative: _______________

Owner: _______________

Start Date: _______________

Review Date: _______________

---

Success Criteria (What "Working" Looks Like)

---

Kill Criteria (What Triggers Stopping)

Usage Threshold

• Kill if: Less than ___% of target users adopt within ___ weeks of launch
• Measurement: _______________

Cost Ceiling

• Kill if: Development investment exceeds ___ person-weeks / $___ before launch
• Kill if: Ongoing maintenance exceeds ___ hours/month after launch
• Measurement: _______________

Time Limit

• Kill if: Not shipped by _______________
• If delayed: Mandatory scope review before continuing

Metric Guardrail

• Kill if: [Guardrail metric] degrades by more than ___%
• Guardrail metrics to monitor: _______________

Qualitative Signal

• Kill if: ___ out of ___ test users report no value in feedback interviews
• Kill if: Support tickets about confusion/complaints exceed ___ per week

---

Decision Options at Review

---

Pre-Mortem (Fill Before Starting)

Most likely reason this initiative fails:

What would have to be true for this to succeed:

Riskiest assumption:

Cheapest way to test the riskiest assumption before full build:

---

Post-Decision Record (Fill at Review Date)

Decision: Continue / Pivot / Kill

Actual results vs criteria:

What we learned:

What we'd do differently:

Prioritization Scorecard

Score each initiative using one framework consistently. Pick RICE (more rigorous) or ICE (faster).

---

RICE Scorecard

Initiative: _______________

Date: _______________

Scored by: _______________

RICE Score: (Reach x Impact x Confidence) / Effort = ___

---

ICE Scorecard (Quick Alternative)

ICE Score: Impact x Confidence x Ease = ___

---

Batch Comparison Table

---

Decision Rules

1. Score all candidates before making decisions (avoid anchoring on the first item) 2. Rank by score, then review top 5 for strategic alignment 3. Check: does the top-ranked item align with our current goals? If not, explain why you're overriding the score 4. Assign kill criteria to each initiative before starting (see kill-criteria-template.md) 5. Re-score quarterly as new data arrives

Confidence Calibration

Before scoring, align on what confidence levels mean:

If confidence is below 50%, the initiative needs validation before prioritization (use discovery skills).

Outcome-Based Roadmap Template

Purpose: Create a roadmap aligned to measurable outcomes instead of features.

Use when planning quarterly/annual direction for teams.

---

1. Roadmap Structure (Copy/Paste)

Product: [Name]

Time Horizon: Now / Next / Later

NOW (0–3 months)

Outcome: Metric Baseline: Metric Target: Themes (Problem Spaces): • • Example Bets (Hypotheses, not commitments): • • Risks / Dependencies:

NEXT (3–9 months)

Outcome: Metric Baseline: Metric Target: Themes: • • Example Bets: • • Risks / Dependencies:

LATER (9–18 months)

Outcome: Strategic Goal: Themes: • • Example Bets: • • Risks / Dependencies:

---

2. Outcome Definition Template

Each outcome must include:

Outcome Statement: Why It Matters: Metric (primary): Metric Baseline: Metric Target: Guardrail Metrics: Owner: Review Cadence:

---

3. Theme (Problem Space) Template

A theme represents a problem, not a feature category.

Theme Name: Problem Statement: Evidence: Affected Segments: Associated Outcome: Risks: Example Bets:

---

4. Bet (Hypothesis) Template

Hypothesis: We believe we can improve [metric] by solving [problem] for [segment] through [approach].

Assumptions (value/usability/feasibility/viability): Experiments Planned: Expected Impact: Dependencies:

---

5. Patterns for Filling a Roadmap

5.1 NOW (Execution)

• Problems validated
• Assumptions tested
• Team staffed
• Clear path to impact

5.2 NEXT (Discovery + Validation)

• Opportunities validated
• Testing riskiest assumptions
• Options compared
• Not committed to delivery

5.3 LATER (Strategy)

• Long-term bets
• Requires deeper validation
• Must align with vision
• Minimal detail

---

6. Example (Editable)

Product: Workflow Automation Platform

Outcome-Based Roadmap

NOW (0–3 months)

Outcome: Activation Rate → from 32% → 45% Themes: • New users struggle with onboarding • Setup is unclear without examples Example Bets: • Guided setup flow (hypothesis test) • Sample project templates Dependencies: • Design bandwidth • Analytics instrumentation

NEXT (3–9 months)

Outcome: Weekly Active Teams → from 40% → 55% Themes: • Low habit formation • Teams not aware of automations Example Bets: • In-app nudges triggered by usage • Auto-recommendation of top workflows Dependencies: • AI recommendations data readiness

LATER (9–18 months)

Outcome: Team Expansion Revenue ↑ Themes: • Cross-team adoption blocked by permissions Example Bets: • Role-based access redesign • Org-wide templates Dependencies: • Platform/security integration

---

7. Roadmap Communication Script

Use this exact structure in stakeholder meetings.

Re-anchor on product vision State outcomes (metrics) Walk through NOW themes + bets Walk through NEXT themes + experiments Walk through LATER strategic bets Clarify risks, dependencies, asks Confirm alignment: “Is anything missing?”

---

8. Quality Checklist

• [ ] No features listed
• [ ] Only outcomes + themes + bets
• [ ] Each outcome has a metric and target
• [ ] Themes written as problem statements
• [ ] Bets are hypotheses, not commitments
• [ ] NOW items have validated evidence
• [ ] NEXT items prioritized by risk
• [ ] LATER aligns with vision
• [ ] Roadmap < 2 pages

---

9. Definition of Done (Outcome Roadmap)

A roadmap is ready when:

• [ ] Expressed as outcomes, not outputs
• [ ] All items link to a metric
• [ ] NOW/NEXT/LATER filled with the right fidelity
• [ ] Stakeholders aligned
• [ ] Team-level actions implied but not dictated
• [ ] Updates monthly; refresh quarterly

---

End of file.

Theme-Based Roadmap Template

Purpose: Organize roadmap around problem spaces (“themes”) instead of features.

Use when:

• Product scope is broad
• Several teams work in parallel
• Uncertainty is high
• Leadership wants clarity without feature-level commitments

---

1. Theme Roadmap Structure (Copy/Paste)

Product: [Name]

Time Horizon: [Quarter / Half / Year]

Theme 1: [Problem Space]

Problem Statement: Evidence: Target Segments: Outcome Metric: Baseline → Target: Example Bets (Hypotheses): • • Experiments: • • Risks / Dependencies: Owner:

Theme 2: [Problem Space]

Problem Statement: Evidence: Target Segments: Outcome Metric: Baseline → Target: Example Bets: • • Experiments: • • Risks / Dependencies: Owner:

Theme 3: [Problem Space]

(...repeat as needed)

---

2. Theme Definition Template

A theme MUST be a problem, not a feature category.

Theme Name: Problem Statement: Why This Matters: Who Experiences It: Evidence (interviews + data): Outcome Linked: Risks:

---

3. Example Bets Template (Inside Each Theme)

Use this for all proposed initiatives inside a theme.

Hypothesis: We believe we can improve [metric] by solving [problem] for [segment] through [approach].

Assumptions: Value: Usability: Feasibility: Viability:

Experiments: 1. 2.

Dependencies: Expected Impact:

---

4. Theme Prioritization Pattern

Score each theme 1–5:

• Problem Severity
• Problem Frequency
• Strategic Alignment
• Evidence Strength
• Expected Lift (impact on key metric)

Theme Score = sum (max 25) Prioritize highest-scoring themes.

---

5. Example Theme-Based Roadmap (Editable)

Product: Workflow Automation Platform

Time Horizon: Q2

Theme 1: Onboarding Friction

Problem: New users get stuck during initial setup. Evidence: 7 interviews; drop-off at Step 1 = 42% Outcome Metric: Activation rate: 32% → 45% Example Bets: • Guided setup flow • Sample project templates Experiments: • Prototype usability tests • Fake door CTA Risks: • Design capacity • Analytics instrumentation

Theme 2: Habit Formation

Problem: Teams forget to return after initial value moment. Evidence: WAU/MAU ratio 0.28; churn interviews Outcome Metric: Weekly Active Teams: 40% → 55% Example Bets: • In-app nudges • Workflow recommendations Experiments: • Notification A/B tests • AI suggestion ranking tests Risks: • Data quality

Theme 3: Multi-Team Expansion

Problem: Difficult for cross-functional teams to collaborate. Evidence: Admin interviews; permission confusion Outcome Metric: Paid expansion revenue Example Bets: • Role-based access redesign • Team templates library Experiments: • Permission usability testing • Pricing sensitivity test Risks: • Security team dependency

---

6. Communication Script (Stakeholders)

Restate product vision Present prioritized themes (with problem statements) Show outcome metrics tied to each theme Walk through example bets (hypotheses) Show upcoming experiments Share risks and dependencies Ask: “Are these the right problem spaces?”

---

7. Theme Roadmap Checklist

• [ ] Each theme is a problem, not a feature
• [ ] Themes tied to measurable outcomes
• [ ] Evidence listed for each theme
• [ ] Bets are hypotheses (not commitments)
• [ ] Experiments identified
• [ ] No more than 3–5 themes
• [ ] Fits on 1–2 pages
• [ ] Updated monthly

---

8. Definition of Done (Theme Roadmap)

A theme-based roadmap is ready when:

• [ ] Themes are problem-focused
• [ ] All themes align with strategy
• [ ] Outcomes link directly to themes
• [ ] Bets & experiments articulated
• [ ] Stakeholders aligned on priorities

---

End of file.

Opportunity Assessment Scorecard (Core, Non-AI)

Purpose: evaluate and prioritize customer problems before committing to solutions.

Inputs

• Problem evidence (interviews, tickets, logs, revenue/churn drivers)
• Target segment(s) and current alternatives/workarounds
• Constraints (time, budget, compliance, dependencies)

Outputs

• Scored opportunity with an explicit decision: Proceed / Explore / Park / Discard
• Next steps: the smallest learning plan to de-risk value, usability, feasibility, viability

Core

1. Opportunity Assessment Template (Copy/Paste)

1. Problem Summary

Problem Statement: User Segment: Context (when problem occurs): Frequency: Severity: Impact (time, money, emotion): Evidence (quotes, data):

2. Current Workarounds / Alternatives

Workarounds users rely on: Why these are insufficient: Competitor solutions: Why customers switch away:

3. Market & Customer Signals

% of target customers experiencing this (estimate + method):

Common patterns: Who cares most (segment scoring): Urgency level:

4. Strategic Fit

Alignment with product vision: Alignment with company goals: Dependencies: Risks:

5. Metrics Impacted

List metrics this opportunity affects.

Primary metric: Secondary metrics: Guardrail metrics:

6. Opportunity Size (Rough)

TAM (lightweight estimate): Affected user volume: Time/cost savings per user: Value creation potential:

7. Assumptions & Risks

Value Risks: Usability Risks: Feasibility Risks: Viability Risks:

8. Recommended Next Steps

Proceed / Explore / Discard / Park

Immediate actions: Experiments to run: Stakeholders to align:

---

2. Opportunity Scoring Pattern

Score each on a 1–5 scale:

Impact

1 = small nuisance 5 = critical business outcome

Frequency

1 = rare 5 = daily

Evidence Strength

1 = anecdotal / unverified 3 = consistent qualitative evidence (multiple users) 5 = triangulated evidence (qual + quant + observed behavior)

Strategic Alignment

1 = low 5 = directly supports vision

Total Opportunity Score = Impact + Frequency + Evidence + Alignment (Max 20)

---

3. “Who Cares Most?” Segmentation Score

For each segment, score 1–5:

• Pain severity
• Pain frequency
• Workaround cost
• Segment strategic value
• Budget / willingness

Segment Score = Sum (max 25) Choose segment with highest score.

---

4. Decision Tree: Is This Opportunity Worth Pursuing?

Do many users experience this problem? ├─ No → Low priority └─ Yes ↓ Is the pain severe and costly? ├─ No → Keep on radar └─ Yes ↓ Is there strong evidence (interviews + data)? ├─ No → Run more discovery └─ Yes ↓ Does solving it align with product strategy? ├─ No → Discard/Park └─ Yes → Prioritize

---

5. Example (Editable)

1. Problem Summary

Problem: “Ops managers spend 3–5 hours weekly reconciling shipment data.” Segment: Mid-size logistics companies Frequency: Weekly Severity: 4/5 Impact: Delays cause missed SLAs and penalties Evidence: 6 interviews, analytics logs confirm manual exports

2. Alternatives

Workarounds: Spreadsheets, macros, manual calls Competitors: TMS upgrades (expensive), BI tools (not automated)

3. Market Signals

Affected customers: 200+ accounts Urgency: High during peak season

4. Strategic Fit

Aligns with vision to automate data operations

5. Metrics

Primary: Time-to-value Secondary: Activation rate Guardrail: Support tickets

6. Opportunity Size

~5 hours saved per week per user High operational cost avoided

7. Risks

Value: Do they trust automation? Usability: Will they understand automated changes? Feasibility: API limits? Viability: Pricing impact?

8. Next Steps

Proceed: HIGH PRIORITY Experiments:

Fake door for “Auto-Reconcile” Prototype guided reconciliation workflow

---

6. Opportunity Assessment Checklist

• [ ] Real user problem (not idea-driven)
• [ ] Evidence from interviews + data
• [ ] Financial impact considered
• [ ] Clear segment that cares most
• [ ] Workarounds documented
• [ ] Strong strategic alignment
• [ ] Metrics identified
• [ ] Risks mapped
• [ ] Next steps defined

---

7. Definition of Done (Opportunity Assessment)

An opportunity is ready when:

• [ ] Problem is validated
• [ ] Segment selected with scoring
• [ ] Impact + frequency quantified
• [ ] Alternatives known
• [ ] Strategy fit confirmed
• [ ] Score assigned
• [ ] Decision made (Proceed / Explore / Discard / Park)

---

Decision Rules

• Proceed only if: evidence strength >= 3 (default; use 4-5 for high-cost bets) AND "who cares most" segment is explicit AND success metric is measurable.
• Explore if: evidence is mixed OR willingness-to-pay is unknown OR alternatives are poorly understood.
• Park if: strategic alignment is low but the problem is real.
• Discard if: problem is not severe, not frequent, or better solved by process/policy than product.

Risks

• Bias: building for loud minorities or biased samples
• Misattribution: confusing correlation with causation in metrics
• Compliance/privacy: collecting or storing customer data without a clear purpose/retention plan
• Roadmap theater: scoring without changing decisions

Optional: AI / Automation

Use only if allowed by policy and data handling rules.

• Synthesis: cluster interview notes and summarize themes; keep source links and spot-check quotes.
• Drafting: generate a first-pass assessment from raw notes; humans own scoring and decisions.
• Consistency: check for missing metrics definitions, fuzzy scope, or unsupported claims.

End of file.

Positioning Template

Purpose: Create clear, differentiated product positioning that customers quickly understand.

Use when launching a product, repositioning, entering new markets, or aligning Product + Marketing + Sales.

---

1. Full Positioning Template (Copy/Paste)

For:

Describe the target segment clearly — industry, persona, maturity, behavior.

Who:

Explain the specific context in which they experience the problem.

Our Product Is a:

Category or Frame of Reference (something customers already understand).

That Helps Them:

Describe the key job/outcome they want to achieve.

By:

List 2–4 value themes expressed in customer language.

Unlike:

Reference the competitive alternatives customers choose today.

Our Product:

List 2–3 differentiated attributes with proof points.

---

2. Fill-in Version With Prompts

For: • Which customer segment? • Which subset within that segment?

Who: • What are they trying to do? • What context triggers the need?

Our product is a: • What category helps them “get it” fast?

That helps them: • What outcome matters most? • How do they measure success today?

By: • Value theme 1 (with outcome) • Value theme 2 • Value theme 3

Unlike: • What alternatives do customers use today? • Why do they choose those?

Our product: • Attribute 1 + proof • Attribute 2 + proof • Attribute 3 + proof

---

3. Value Theme Patterns

Use these to translate features into customer outcomes.

Pattern A — Functional Value

Feature → Enables user to [action] → Saves time / reduces cost / increases speed

Pattern B — Emotional Value

Feature → Reduces risk/confusion → User feels confident / in control

Pattern C — Social Value

Feature → Aligns with team / industry standards → Builds credibility

---

4. Differentiator Patterns

Valid differentiators MUST be:

• [ ] Relevant
• [ ] Valuable
• [ ] Provable
• [ ] Competitors underperform on it

Pattern A — Speed

“Completes [task] in [time], vs competitor average [time].”

Pattern B — Quality

“Accuracy rate of X% validated by [evidence].”

Pattern C — Intelligence (AI)

“Our system anticipates [need] using [capability] → reduces [cost/time].”

Pattern D — Integration

“Connects to all major systems without engineering work.”

---

5. Competitive Alternatives Table (Copy/Paste)

Alternative | Customer Job | Strengths | Weaknesses | Why Users Choose It | Why They Switch

Use customer language for strengths/weaknesses.

---

6. Positioning Example (Editable)

For:

Ops managers at mid-market logistics companies Who coordinate shipment schedules weekly And need fast, accurate data to avoid missed SLAs.

Our Product Is a:

Real-time operations data platform

That Helps Them:

Eliminate manual reconciliation and prevent shipment delays

By:

• Providing always-fresh shipment data • Automating reconciliation workflows • Flagging issues automatically before SLA penalties

Unlike:

• Spreadsheets • Manual exports • High-cost enterprise TMS upgrades

Our Product:

• Delivers real-time data (<5 min freshness) • Automates 80% of reconciliation with machine learning • Integrates with 20+ carrier APIs out-of-the-box

---

7. Positioning Checklist

• [ ] Segment is specific (not “everyone”)
• [ ] Category/frame is intuitive
• [ ] Value themes tie directly to outcomes
• [ ] Differentiators are provable with evidence
• [ ] Uses customer language (not features)
• [ ] Lists alternatives customers actually use
• [ ] Validated with customers in message tests
• [ ] Consistent across PM, PMM, Sales

---

8. Definition of Done (Positioning)

Positioning is ready when:

• [ ] Target customer “gets it” within 10 seconds
• [ ] They can repeat it back in their own words
• [ ] They understand what’s different
• [ ] Sales can execute against it
• [ ] It guides roadmap & messaging

---

End of file.

PR/FAQ Template

Purpose: Communicate a new product or feature as if it already launched (Amazon Working Backwards).

Use this for:

• New product proposals
• Major feature pitches
• Vision → delivery alignment
• Exec and cross-functional approvals

---

1. Press Release (PR)

Write as if the product launched today. 1 page max. Customer-first. Zero jargon.

1.1 Boilerplate PR Template

FOR IMMEDIATE RELEASE [Date]

[Product Name] Launches to Help [Target User] Achieve [Outcome]

SEATTLE — Today, [Company] announced [Product Name], a new [category] that helps [target segment] [solve core problem] by [value themes].

With [Product Name], customers can now: • [Key benefit 1] • [Key benefit 2] • [Key benefit 3]

“[Customer quote about the outcome],” said [Persona / Beta User / Customer].

[Product Name] is available starting [date] on [channels]. Learn more at: [URL].

Media Contact: [Name, email]

---

2. FAQ Section

Use to anticipate objections, clarify decisions, and fill gaps.

2.1 Customer FAQs

Q: Who is this for? A: Q: What problem does this solve? A: Q: Why is this better than alternatives? A: Q: How do I get started? A: Q: How much does it cost? A:

2.2 Business FAQs

Q: What’s the business opportunity? A: Q: What metrics will this improve? A: Q: What is the expected ROI? A: Q: What are the guardrail risks? A:

2.3 Product / Technical FAQs

Q: How does it work? A: Q: What are the key features? A: Q: What are the technical risks? A: Q: What dependencies exist? A: Q: What is v1 vs. v2? A:

2.4 GTM FAQs

Q: How will we launch this? A: Q: Who needs to be trained? A: Q: What assets are required? A: Q: What is the rollout timeline? A:

---

3. Success Metrics Template

Primary Outcome Metric: Secondary Metrics: Guardrail Metrics: Measurement Plan:

---

4. Launch Requirements Checklist

Product Readiness

• [ ] v1 scope defined
• [ ] Risks documented (value, usability, feasibility, viability)
• [ ] Prototype validated
• [ ] Engineering estimates complete
• [ ] Instrumentation plan ready

Go-to-Market

• [ ] Pricing & packaging
• [ ] Messaging aligned with positioning
• [ ] Sales enablement materials
• [ ] Support documentation
• [ ] Beta customers identified

Ops

• [ ] Support process ready
• [ ] On-call alerts configured
• [ ] Capacity planning
• [ ] Legal/privacy review complete

---

5. PR/FAQ Example (Editable)

Press Release

FOR IMMEDIATE RELEASE April 5, 2025

FlowSync Launches Automated Reconciliation for Operations Teams

SEATTLE — Today, FlowSync announced ReconcileAI, a new automation engine that helps operations managers eliminate manual data reconciliation and prevent shipment delays.

With ReconcileAI, customers can now: • Sync shipment data across carriers in real-time • Automate 80% of manual reconciliation • Prevent SLA penalties with proactive alerts

“ReconcileAI saved us over 8 hours a week,” said Maria Lopez, Ops Manager at RapidLogix.

ReconcileAI is available starting May 1 on the FlowSync platform.

Learn more at: flowsync.com/reconcileai

FAQ

Q: Who is this for? A: Mid-market logistics operations teams with weekly reconciliation workflows.

Q: Why is this better than alternatives? A: It replaces manual spreadsheets and reduces error rates by 90%.

Q: How does it work? A: It connects to carrier APIs, unifies data, detects discrepancies, and automates corrections.

Q: What metrics will this improve? A: Time-to-value, SLA compliance, retention, and expansion revenue.

Q: What are the risks? A: API rate limits, data accuracy, operator trust, and latency constraints.

---

6. PR/FAQ Quality Checklist

• [ ] PR written in plain language
• [ ] No internal jargon
• [ ] Customer value leads the narrative
• [ ] FAQ answers real objections
• [ ] Success metrics defined
• [ ] v1 scope is clear
• [ ] Launch requirements documented
• [ ] Fits on 1–2 pages

---

7. Definition of Done (PR/FAQ)

A PR/FAQ is ready when:

• [ ] A non-expert can understand it
• [ ] Customers say “I want this”
• [ ] Team can explain v1 scope clearly
• [ ] Risks + dependencies identified
• [ ] Leadership alignment achieved

---

End of file.

Product Vision Template

Purpose: Describe the future state your product is moving toward in 3–5 years.

Use this template for strategy documents, roadmap alignment, and stakeholder communication.

---

1. Product Vision Structure

From → To Narrative Target Customer & Context Core Problems We Exist to Solve Future State (What the world looks like when we succeed) Guiding Principles Non-Goals Success Indicators (3–5 metrics)

---

2. Template (Copy/Paste)

1. From → To Narrative

From: [The current reality customers experience today] To: [The improved future state enabled by our product]

2. Target Customer & Context

Segment(s): Context (when/where they experience the problem): Motivations: Constraints:

3. Core Problems We Exist to Solve

List 2–4 problems — phrased from the customer’s perspective.

4. Future State (3–5 Years)

Describe what the product enables.

In 3–5 years, customers will be able to: • [Outcome 1] • [Outcome 2] • [Outcome 3]

The experience will feel: • [Adjective + proof behavior] • [Adjective + proof behavior]

5. Guiding Principles

Principles define how you make decisions.

[Principle] — [How it shows up in decisions] [Principle] — [How it shows up] [Principle] — [How it shows up]

6. Non-Goals

Clarify what you will NOT do.

We will not… We will not…

7. Success Indicators

Choose 3–5 long-term metrics.

• Metric 1: • Metric 2: • Metric 3: • Metric 4 (optional): • Metric 5 (optional):

Owner + review cadence: Owner: Review cycle (quarterly / semiannual):

---

3. Vision Patterns

Pattern A — “Transform the Workflow”

Use when replacing inefficient processes.

From: Fragmented, manual, repetitive To: Integrated, automated, intelligent

Pattern B — “Unlock New Capability”

Use when enabling something customers can’t do today.

From: Inability to [job] To: Ability to [job] with speed/scale/accuracy

Pattern C — “Intelligent Assistant”

For AI products.

From: Users performing every step To: System anticipating needs + taking first actions

---

4. Example (Editable)

1. From → To Narrative

From: Teams lose hours reconciling data across spreadsheets. To: Teams trust a single, automated source of truth that updates instantly.

2. Target Customer & Context

Segment: Ops managers in growth-stage B2B companies Context: Weekly planning + reporting cycles Motivations: Reduce manual coordination Constraints: Limited data engineering support

3. Core Problems

Data lives across 6+ sources Manual reconciliation causes frequent errors Leaders lack visibility into up-to-date numbers 4. Future State (3–5 Years)

Customers will be able to: • Connect data sources in minutes • See live dashboards with zero maintenance • Automate reconciliation and alerts

The experience will feel: • Predictable — updates without manual work • Trustworthy — data validated and consistent

5. Guiding Principles

Automation-first — eliminate manual steps Transparency — show data lineage and definitions Reliability over breadth — fewer features, high trust 6. Non-Goals

• Not building a BI visualization tool • Not serving enterprise-scale custom pipelines

7. Success Indicators

• Data freshness < 5 minutes • Weekly active teams +50% • Manual reconciliation time -80% • Error rate < 1% Owner: PM Review: Quarterly

---

5. Vision Quality Checklist

• [ ] Defines a meaningful transformation
• [ ] Anchored in customer problems
• [ ] 3–5 year horizon
• [ ] Contains both narrative + measurable indicators
• [ ] Clear guiding principles
• [ ] Explicit non-goals
• [ ] Inspires direction without dictating features

---

6. Definition of Done (Vision)

A vision is ready when:

• [ ] Teams can state it in < 30 seconds
• [ ] Leaders agree on the direction
• [ ] It informs roadmap decisions
• [ ] Metrics chosen reinforce the long-term north star
• [ ] It avoids feature commitments
• [ ] Document fits on 1 page

---

End of file.

Quarterly Product Review

Use this template every quarter to decide what to keep, cut, and double down on.

---

Review Period: Q___ 20___

Date: _______________

Participants: _______________

---

1. Metrics Snapshot

---

2. Feature Usage Audit

List all features/initiatives shipped or maintained this quarter:

Sunset Candidates (Bottom 20% Usage)

---

3. Initiative Review

For each major initiative this quarter:

Initiative: _______________

(Repeat for each initiative)

---

4. What to Stop Doing

Things we're doing "because we always have" or because someone asked once:

---

5. Next Quarter Priorities

Based on this review:

Double Down (Working — Invest More)

1. _______________ 2. _______________

Start (New Bets)

1. _______________ (Kill criteria: _______________) 2. _______________ (Kill criteria: _______________)

Stop (Not Working — Free Up Resources)

1. _______________ 2. _______________

Continue (Maintaining — No Change)

1. _______________ 2. _______________

---

6. Resource Allocation Check

Target heuristic: 70% core, 20% adjacent, 10% transformational (adapt to your stage).

---

7. Decisions & Action Items

AI Product Patterns

Operational guide for building AI, GenAI, and Agentic AI products.

This file includes ONLY:

• Templates
• Checklists
• Step-by-step processes
• Decision trees
• No theory

---

1. AI Product Development Lifecycle (Operational Version)

Use this as the core workflow for any AI product.

Phase 1 — Problem Framing

Checklist

• [ ] Clear target user & job-to-be-done
• [ ] Pain severity validated (interviews)
• [ ] Non-AI alternatives documented
• [ ] Success metric identified (accuracy, latency, cost, engagement, etc.)

Template User: Problem: Current workaround: Why AI is needed: Core success metric: Risks (value / feasibility / viability):

---

Phase 2 — Data Readiness

Checklist

• [ ] Source data identified (internal / external)
• [ ] Data labeling strategy defined
• [ ] Bias risks identified
• [ ] Data quality score (completeness, consistency, timeliness)
• [ ] Legal/permission constraints mapped

Data Readiness Score (1–5) 1 = No usable data 3 = Needs labeling/cleanup 5 = Ready for model training

---

Phase 3 — Model Approach Selection

Use the simplest viable model first.

Menu

• Predictive ML
• Generative LLM
• Agentic multi-step model
• Retrieval-augmented generation (RAG)
• Hybrid (retrieval + action-taking agent)

Selection Checklist

• [ ] Problem needs classification/recommendation → predictive
• [ ] Problem needs content creation → generative
• [ ] Problem requires planning/action → agentic
• [ ] Data is structured → predictive
• [ ] Facts must be grounded → add RAG

---

Phase 4 — Build & Evaluate

Operational Metrics

• Accuracy / Precision / Recall (prediction tasks)
• Factuality (LLMs)
• Hallucination rate
• Latency (ms)
• Cost-per-inference
• Agent task success rate
• Step efficiency (# steps per successful task)

Evaluation Checklist

• [ ] Offline test set
• [ ] Human review sample (20–100 examples)
• [ ] Red-team evaluation (edge cases)
• [ ] Bias & fairness tests

---

Phase 5 — Pilot & Iterate

Checklist

• [ ] Soft launch to < 5% traffic
• [ ] Human-in-the-loop workflow defined
• [ ] Guardrails (rate limits, content filters)
• [ ] Logging & monitoring (fail cases, retries)
• [ ] User-facing feedback loop

---

Phase 6 — Launch & Monitor

Checklist

• [ ] On-call processes for model issues
• [ ] Drift detection
• [ ] Feedback retraining pipeline
• [ ] Incident response playbook
• [ ] Business KPI tracking

---

2. Agentic AI Patterns

Agentic systems = AI that can take multi-step actions, use tools, and plan.

2.1 Agent Role Template

Agent Name: Goal: Tools/APIs it can call: Constraints: Success criteria: Failure modes: Human oversight needed:

2.2 Common Agent Patterns

Pattern A — Planner → Executor

Use for workflows requiring decomposition.

Planner:

Breaks goal into tasks Determines order Monitors progress Executor(s):

Perform individual steps Report back to planner

Pattern B — Multi-Agent Collaboration

Use for complex domains.

Agents:

• Researcher (info retrieval)
• Synthesizer (summaries)
• Critic (validate outputs)
• Executor (actions)

Pattern C — Guardrail Critic

Use when hallucination risk is high.

Critic does:

• [ ] Factuality checks
• [ ] Policy violations
• [ ] Bias detection
• [ ] Harmful output classification

---

2.3 Multi-Agent Orchestration (2026 Pattern)

Rather than one large LLM handling everything, use "puppeteer" orchestrators that coordinate specialist agents.

Architecture

┌─────────────────────────────────────────────────┐
│              Orchestrator Agent                 │
│  (Plan-and-Execute pattern, frontier model)     │
└────────────┬────────────┬────────────┬──────────┘
             │            │            │
     ┌───────▼───┐  ┌─────▼─────┐  ┌───▼───────┐
     │ Researcher│  │   Coder   │  │  Analyst  │
     │   Agent   │  │   Agent   │  │   Agent   │
     │ (mid-tier)│  │(mid-tier) │  │(mid-tier) │
     └───────────┘  └───────────┘  └───────────┘

Plan-and-Execute Pattern

Use capable model for planning, cheaper models for execution. Can reduce costs by 90%.

Planner (frontier model):
├─ Decomposes goal into tasks
├─ Determines execution order
├─ Monitors progress
└─ Handles exceptions

Executor(s) (mid-tier models):
├─ Perform individual steps
├─ Report status back
└─ Request help if stuck

Protocols (2026)

• MCP (Model Context Protocol) — Anthropic standard for agent tools
• A2A (Agent-to-Agent Protocol) — Google standard for agent communication

Checklist

• [ ] Clear agent boundaries (each agent has single responsibility)
• [ ] Inter-agent communication protocol defined
• [ ] State management across agent boundaries
• [ ] Conflict resolution mechanism
• [ ] Cost-per-inference tracked per agent type
• [ ] Model selection based on task complexity
• [ ] Human escalation path for all agents

Cost Optimization Pattern

---

3. RAG (Retrieval-Augmented Generation) Patterns

3.1 RAG Template

Retriever:

Vector DB Search parameters Filters Generator:

Model (GPT, Claude, etc.) Context window Safety constraints Evaluation:

Relevance@K Factuality score Latency

3.2 RAG Checklist

• [ ] Chunking strategy defined
• [ ] Embedding model selected
• [ ] Max tokens per chunk optimized
• [ ] Prompt includes citations
• [ ] Retrieval fallback flow
• [ ] Timeout and retry logic

---

4. AI Risk & Governance

4.1 AI Risk Checklist

Value Risks

• [ ] Users don’t trust output
• [ ] Hallucinations harm experience
• [ ] Output not actionable

Usability Risks

• [ ] Too slow (latency > accepted threshold)
• [ ] Confusing UI for errors/edge cases

Feasibility Risks

• [ ] Missing or dirty data
• [ ] Model not robust enough

Viability Risks

• [ ] Legal/ethical exposure
• [ ] Customer data retention risk
• [ ] Excessive cost per inference

---

4.2 Governance Template

Usage Policy: Safety Constraints: Human Oversight: Data Privacy Rules: Logging Policy: Escalation Path: Retraining Frequency:

---

5. AI Experiment Types

5.1 Offline Evaluation

• Use test sets
• Human review panel
• Robustness tests
• Prompt variation tests

5.2 Online Experiments

• A/B tests
• Interleaving tests (ranking use cases)
• Shadow mode (run model behind the scenes)
• Human override tracking

5.3 Agentic Experiments

• Task completion rate
• Unexpected action detection
• Step count deviation
• Human-in-the-loop approval rate

---

6. AI Discovery Patterns

6.1 AI Opportunity Assessment Template

User segment: Task: Pain: AI value type:

Predict Generate Decide Take Action Evidence problem exists: Why AI is needed: Risks: Success metrics:

6.2 When NOT to Use AI

• Problem does not require variability or intelligence
• Deterministic rules handle it well
• Data insufficient
• High-stakes with no oversight
• Speed/latency constraints too strict

---

7. Decision Trees

7.1 Should You Use AI?

Is the problem high-value and high-frequency? ├─ No → Do not use AI └─ Yes ↓ Does AI outperform rules/manual? ├─ No → Prototype rule-based approach └─ Yes ↓ Do you have (or can get) the data? ├─ No → Data project first └─ Yes → Move to design

---

7.2 Should You Use Agentic AI?

Does the task require multi-step planning? ├─ Yes → Agentic candidate └─ No ↓ Does the model need to use external tools/APIs? ├─ Yes → Agentic candidate └─ No ↓ Is hallucination risk manageable with guardrails? ├─ No → Wait / redesign └─ Yes → Agentic approved

---

8. Definition of Done (AI Product)

A model or agent is ready when:

• [ ] Problem validated through interviews
• [ ] Data readiness confirmed
• [ ] Evaluation metrics pass thresholds
• [ ] Safety guardrails implemented
• [ ] Cost-per-inference acceptable
• [ ] Human-in-the-loop path defined
• [ ] Drift monitoring in place
• [ ] Success metric tied to business KPI

---

9. AI PM Tools (Jan 2026)

Tools to augment PM workflows. AI assists; human decides.

9.1 Tool Categories

9.2 AI Tool Selection Checklist

• [ ] Integrates with existing stack (Jira, Slack, Figma, etc.)
• [ ] Output is editable and auditable
• [ ] Human review built into workflow
• [ ] Data stays within compliance boundaries
• [ ] Cost per seat justified by time savings
• [ ] No vendor lock-in on generated content

9.3 Hybrid Decision Loop Pattern

AI and human have distinct roles:

AI Role:
├─ Surface anomalies in data
├─ Identify patterns across feedback
├─ Generate forecasts and scenarios
├─ Draft artifacts (PRDs, stories, roadmaps)
└─ Flag outliers for review

Human Role:
├─ Apply business context
├─ Make ethical judgment calls
├─ Set long-term strategy
├─ Approve customer-facing decisions
└─ Own accountability

Checklist

• [ ] AI output always reviewed before shipping
• [ ] Human approval gate for customer-impacting changes
• [ ] Disagreements resolved by human, not AI
• [ ] AI recommendations include confidence level
• [ ] Audit trail of AI suggestions vs. human decisions

9.4 Product Explainability

Products are increasingly evaluated by AI systems (search, recommendations, assistants) before humans interact.

Checklist

• [ ] Product purpose is machine-readable (structured data, clear metadata)
• [ ] Value proposition stated in plain language (no jargon)
• [ ] Limitations and constraints documented
• [ ] API/integration surface is self-describing
• [ ] Documentation optimized for both human and AI consumption

---

End of file.

Data Product Best Practices

Operational guidance for designing, building, and managing data products.

This file contains ONLY:

• Templates
• Checklists
• Patterns
• Decision flows
• Zero theory

---

1. Data Product Definition (Operational Version)

A data product is a reusable, trustworthy dataset or data-powered capability with:

• Clear owners
• Defined consumers
• Quality guarantees
• SLAs (freshness, availability)
• Interfaces (APIs, queries, events)

---

2. Data Product Canvas

Copy-ready template:

Name: Domain: Primary Consumers: Problem this data solves:

Inputs:

Data sources Ingestion frequency Contracts with source systems Transformations (logic rules): Outputs:

Tables/views/APIs Intended use cases SLAs:

Freshness Quality thresholds Availability Quality Dimensions:

Completeness Validity Consistency Timeliness Accuracy Ownership:

Data Product Owner Maintainers Governance:

Policies Access rules Security Success Metrics:

Adoption Query volume Time saved Incident reduction

---

3. Data Product Lifecycle (Operational)

3.1 Phase 1 — Problem Framing

Checklist

• [ ] Clear consumer use case identified
• [ ] Source systems known
• [ ] Data privacy considerations documented
• [ ] Business metric impacted

---

3.2 Phase 2 — Sourcing & Ingestion

Checklist

• [ ] Data contracts in place
• [ ] Ingestion frequency mapped (batch / streaming)
• [ ] Source data profiling completed
• [ ] PII handling rules defined

Ingestion Template Source: Format: Latency target: Transformation tool: Load pattern (full vs incremental):

---

3.3 Phase 3 — Transformation & Modeling

Use simple modeling first (avoid premature complexity).

Checklist

• [ ] Business logic documented
• [ ] Transformation tests created
• [ ] Edge cases identified
• [ ] Definitions aligned with analytics/BI teams
• [ ] Data lineage documented

Patterns

• Dimensional modeling
• Event-driven modeling
• Feature store preparation for ML

---

3.4 Phase 4 — Serving Layer

Deliverables

• [ ] API / table / view schema
• [ ] Access policies
• [ ] Metadata (column definitions, descriptions)

Checklist

• [ ] Data permissions & entitlements
• [ ] Cost per query monitored
• [ ] Versioning plan

---

3.5 Phase 5 — Monitoring & Quality

Quality Dimensions

• Completeness
• Accuracy
• Timeliness
• Consistency
• Validity

Quality Alerts Template Metric: [Accuracy / Freshness / Completeness] Threshold: Alerting channel: Owner: Runbook link:

---

4. Data Quality Score (Operational)

Score each 1–5:

Completeness: 1 = <60% fields populated, 5 = >98% Accuracy: 1 = Known errors, 5 = Verified by cross-sources Timeliness: 1 = >24h lag, 5 = Near real-time Consistency: 1 = Frequent mismatches, 5 = Schema stable + aligned Validity: 1 = High rule violations, 5 = <1% violations

Overall Data Quality Score = Average of all dimensions

---

5. Golden Data Platform Requirements

(From Milhomem’s operational guidance)

Use this list when designing or evaluating your data platform.

Functional Requirements

• [ ] Automated ingestion
• [ ] Schema enforcement
• [ ] Data catalog & lineage
• [ ] Transformation orchestration
• [ ] Data quality monitoring
• [ ] Version control for transformations
• [ ] Secure access + governance
• [ ] Self-service analytics
• [ ] ML feature store support

Non-Functional Requirements

• [ ] Scalability
• [ ] High availability
• [ ] Cost optimization
• [ ] Data encryption
• [ ] RBAC/ABAC permissions
• [ ] Audit logs

---

6. Data Contract Template

Field: Definition: Type: Nullable: Allowed Values: Owner: Change Management Rules: Downstream Impact:

Checklist:

• [ ] Each upstream dataset has a contract
• [ ] Versioned
• [ ] Breaking changes announced prior
• [ ] Automated schema checks in pipeline

---

7. Data Governance Patterns

7.1 Governance Checklist

• [ ] Certified datasets labeled
• [ ] Sensitive data flagged
• [ ] PII handling standards followed
• [ ] Role-based access control implemented
• [ ] Data retention rules defined
• [ ] Audit logs enabled

7.2 Decision Workflow for Data Access Requests

Verify user’s role + need Check PII/sensitive fields Approve minimal access surface Set expiration date Log access approval

---

8. ML Data Pipeline Patterns

8.1 Feature Store Template

Feature Name: Description: Source Table: Transformation Logic: Freshness Target: Owner: Training/Serving Consistency Check:

8.2 Training Data Checklist

• [ ] Representative samples
• [ ] Balanced labels
• [ ] Leakage checked
• [ ] Drift test performed
• [ ] Bias assessed

---

9. Decision Trees

9.1 Should You Create a Data Product?

Is there a repeating analytics or ML use case? ├─ No → Do not create └─ Yes ↓ Do multiple consumers need the data? ├─ No → Local dataset only └─ Yes ↓ Does it require SLAs or governance? ├─ Yes → Build as data product └─ No → Keep ad-hoc

---

9.2 Batch vs Streaming

Do consumers need real-time? ├─ Yes → Streaming └─ No ↓ Can source systems support events? ├─ Yes → Streaming └─ No → Batch

---

10. Definition of Done (Data Product)

A data product is ready when:

• [ ] Clear consumer use case
• [ ] Documented definitions & business logic
• [ ] Quality dimensions ≥ target
• [ ] Schema, metadata, lineage published
• [ ] Access governance in place
• [ ] Monitoring + alerts configured
• [ ] SLAs defined & agreed
• [ ] Adoption plan ready

---

End of file.

Delivery Best Practices (Hand-off to Execution)

• Planning & scope
• Define acceptance criteria, non-goals, and constraints
• Align dependencies and owners; record open risks and mitigations
• Backlog quality
• Slice work by user outcome; avoid large “epics” without definition
• Definition of Ready/Done visible to the team
• Engineering handoff
• PRD/spec links, API/contract notes, data flows, success metrics
• Edge cases, error states, and rollout/rollback plan documented
• Execution cadence
• Daily surfacing of blockers; visible burn-down or flow metrics
• WIP limits per team; explicit policy for unplanned work
• Quality gates
• Test strategy per change, feature flags, canary/gradual rollout
• Monitoring/alerting added with new functionality
• Review & learning
• After-action reviews for incidents/launches; track follow-ups to closure