Menu
Product management analysis for engineering-informed decision framing. Use when a task needs product framing, feature prioritization based on user impact and engineering reality, scope control to prevent complexity creep, or structured now/next/later sequencing with explicit tradeoffs.
AI agent architecture and development patterns including tool use, memory systems, planning loops, and multi-agent orchestration. Use when building AI agents, designing tool interfaces, or implementing agent evaluation.
Prompt engineering principles and techniques for LLM applications including system prompts, chain-of-thought, few-shot learning, and prompt evaluation. Use when designing prompts, optimizing LLM outputs, or building prompt pipelines.
API design principles for REST, GraphQL, and gRPC including versioning, pagination, error handling, and documentation. Use when designing new APIs, reviewing API contracts, or migrating between API styles.
System architecture design including requirements analysis, trade-off evaluation, ADRs, and system decomposition. Use when designing new systems, evaluating architectures, or documenting design decisions.
Business analysis expertise for translating business needs into technical requirements. Use when eliciting requirements from stakeholders, modeling business processes, writing functional specifications, performing gap analysis, defining data dictionaries, or creating acceptance test scenarios from business rules.
Scrum and agile facilitation expertise for engineering teams. Use when planning sprints, facilitating retrospectives, removing blockers, tracking velocity and burndown, improving team processes, or coaching teams on agile principles and practices.
| name | product-manager |
| description | Product management analysis for engineering-informed decision framing. Use when a task needs product framing, feature prioritization based on user impact and engineering reality, scope control to prevent complexity creep, or structured now/next/later sequencing with explicit tradeoffs. |
| summary_l0 | Frame product decisions with feature prioritization, scope control, and roadmap sequencing |
| overview_l1 | This skill provides product management analysis for engineering-informed decision framing. Use it when a task needs product framing, feature prioritization based on user impact and engineering reality, scope control to prevent complexity creep, or structured now/next/later sequencing with explicit tradeoffs. Key capabilities include feature prioritization using impact/effort frameworks, scope control and complexity prevention, now/next/later roadmap sequencing, tradeoff analysis with explicit documentation, user impact assessment, engineering feasibility integration into product decisions, and MVP scope definition. The expected output is structured product decisions with prioritized features, scope boundaries, sequencing plans, and documented tradeoffs. Trigger phrases: product framing, feature prioritization, scope control, roadmap, now/next/later, tradeoff analysis, MVP scope, product decision, user impact, complexity creep. |
Structured product management frameworks for engineering teams. This skill provides decision templates, prioritization models, and planning tools that connect user outcomes to engineering execution.
Use this skill for:
Trigger phrases: "product framing", "prioritize features", "scope the MVP", "what should we build", "user story", "acceptance criteria", "roadmap", "now next later", "RICE score", "feature priority", "launch plan", "stakeholder alignment"
Provides a seven-step product management workflow that translates user problems into engineering plans with clear scope, explicit tradeoffs, and measurable outcomes.
Before building anything, establish a shared understanding of the user problem. Every feature should trace back to a user outcome, not a stakeholder request or a technical preference.
User Problem Statement Template:
PROBLEM STATEMENT
─────────────────
Who: [Target user persona or segment]
Situation: [Context in which the problem arises]
Problem: [What the user cannot do, or what causes friction]
Impact: [Consequence of the problem remaining unsolved]
Evidence: [Data, quotes, support tickets, or observations]
Jobs-to-Be-Done (JTBD) Framework:
Frame every feature request as a job the user is trying to accomplish. This prevents solution-first thinking.
When [situation], I want to [motivation], so I can [expected outcome].
Examples:
Outcome vs Output Distinction:
| Dimension | Output (avoid as goal) | Outcome (target this) |
|---|---|---|
| Definition | A deliverable or artifact | A change in user behavior or metric |
| Example | "Ship search feature" | "Users find relevant results in under 3 seconds" |
| Measurable by | Completion (done/not done) | Metric movement (before/after) |
| Risk | Shipping something nobody uses | Slower to define but validates real value |
Success Metrics Definition:
For each problem, define metrics before writing code:
SUCCESS METRICS
───────────────
Primary metric: [The single number that proves the problem is solved]
Leading indicator: [Early signal that correlates with the primary metric]
Guardrail metric: [What must NOT degrade as a side effect]
Measurement plan: [How and when each metric will be collected]
Target: [Specific threshold that defines success]
Timeline: [When you expect to see movement]
Discovery Checklist:
Scope creep is the primary reason engineering projects miss deadlines. Define explicit boundaries before implementation begins.
MVP Scoping Framework:
An MVP is not a bad version of the full product. It is the smallest thing that tests whether the core assumption is true.
MVP DEFINITION
──────────────
Core assumption: [What belief must be validated?]
Minimum to test: [Smallest feature set that validates the assumption]
Not included: [Features explicitly deferred]
Success signal: [What result proves the assumption correct?]
Failure signal: [What result disproves it?]
Time box: [Maximum calendar time for this MVP]
In/Out Table:
Use this table at the start of every project to create an explicit contract about scope.
SCOPE TABLE: [Feature Name]
────────────────────────────
IN SCOPE | OUT OF SCOPE (this release)
──────────────────────────────────|────────────────────────────
[Feature A] | [Feature X - deferred to v2]
[Feature B] | [Feature Y - nice to have]
[Feature C] | [Feature Z - separate initiative]
Rules for the In/Out table:
Scope Creep Detection Signals:
Watch for these patterns during implementation:
| Signal | Example | Response |
|---|---|---|
| "While we're at it" | "While we're adding search, let's add filters too" | Add to backlog, evaluate separately |
| "It's just a small change" | "Can we also handle edge case X?" | Estimate cost, compare to deadline |
| "Users will expect" | "Users will expect dark mode" | Validate with data, not assumptions |
| "We should future-proof" | "Let's make it configurable for all cases" | Build for current need, refactor later |
| Expanding personas | "What about admin users too?" | Scope to primary persona first |
Ship Now vs Later Decision Framework:
When debating whether to include something in the current release:
SHIP-NOW-OR-LATER DECISION
───────────────────────────
Feature: [Name]
YES NO
Blocks the core use case? [ ] [ ]
Affects >50% of users? [ ] [ ]
Costs <2 days to build? [ ] [ ]
Hard to add retroactively? [ ] [ ]
Required for compliance? [ ] [ ]
Score: [count of YES answers]
- 4-5 YES: Ship now
- 2-3 YES: Discuss with team, lean toward now if time permits
- 0-1 YES: Ship later
Use structured scoring to replace opinion-based prioritization. Choose the framework that fits your team's maturity and data availability.
RICE Scoring:
Best for teams with usage data and medium-to-large backlogs.
RICE SCORE = (Reach x Impact x Confidence) / Effort
Reach: Number of users affected per quarter (use real data)
Impact: 0.25 (minimal), 0.5 (low), 1 (medium), 2 (high), 3 (massive)
Confidence: 100% (high), 80% (medium), 50% (low) - be honest
Effort: Person-weeks (round up, include testing and review)
| Feature | Reach | Impact | Confidence | Effort | RICE Score |
|---|---|---|---|---|---|
| Example A | 5000 | 2 | 80% | 3 | 2667 |
| Example B | 1000 | 3 | 50% | 1 | 1500 |
| Example C | 8000 | 0.5 | 100% | 2 | 2000 |
ICE Scoring:
Simpler alternative when you lack precise reach data. Good for early-stage products.
ICE SCORE = Impact x Confidence x Ease
Impact: 1-10 (how much will this move the target metric?)
Confidence: 1-10 (how sure are we about impact and feasibility?)
Ease: 1-10 (how easy is this to implement? 10 = trivial)
Impact/Effort Matrix:
Visual tool for quick triage of a small number of items (under 20).
HIGH IMPACT
|
Quick Wins | Strategic Bets
(do first) | (plan carefully)
|
─────────────+──────────────
|
Fill-ins | Avoid
(do if idle)| (deprioritize)
|
LOW IMPACT
X-axis: Effort (left = low, right = high)
Y-axis: Impact (bottom = low, top = high)
MoSCoW Method:
Best for fixed-deadline projects where scope is the variable.
MOSCOW CLASSIFICATION: [Release Name]
──────────────────────────────────────
MUST HAVE (release fails without these)
- [Feature A]
- [Feature B]
SHOULD HAVE (important but workarounds exist)
- [Feature C]
- [Feature D]
COULD HAVE (nice-to-have, include if time permits)
- [Feature E]
WON'T HAVE (explicitly excluded this release)
- [Feature F] - reason: [deferred to Q3]
Weighted Scoring with Engineering Constraints:
When engineering reality must factor into prioritization alongside business value:
WEIGHTED PRIORITY SCORE
───────────────────────
Weight Feature A Feature B Feature C
User impact 30% 8 6 9
Revenue potential 20% 7 9 5
Engineering complexity 20% 3 (inverse) 7 (inverse) 4 (inverse)
Strategic alignment 15% 9 5 8
Technical debt payoff 15% 2 8 6
────────────────────────────────────────────────────────────────────
Weighted score 5.75 6.90 6.35
Note: For engineering complexity, invert the score (10 = trivial, 1 = extremely complex) so that easier items score higher.
Ambiguous requirements cause rework. Write requirements that an engineer can implement and a tester can verify without asking follow-up questions.
User Story Format:
As a [user persona],
I want to [action or capability],
so that [benefit or outcome].
Rules for good user stories:
Acceptance Criteria Template:
Write acceptance criteria using the Given/When/Then format. Each criterion must be independently testable.
ACCEPTANCE CRITERIA: [Story Title]
───────────────────────────────────
AC-1: [Short descriptive name]
Given [precondition or initial state]
When [action performed by the user or system]
Then [expected observable result]
AC-2: [Short descriptive name]
Given [precondition]
When [action]
Then [result]
AC-3: [Error case]
Given [precondition]
When [invalid action or error trigger]
Then [system handles gracefully: error message, fallback, etc.]
Testable Criteria Checklist:
Every acceptance criterion must pass these checks:
Edge Case Identification Template:
Use this matrix to systematically find edge cases before implementation:
EDGE CASE MATRIX: [Feature Name]
─────────────────────────────────
Category | Edge Case | Expected Behavior
──────────────────|─────────────────────────────|──────────────────
Empty input | User submits blank form | Validation error shown
Boundary values | Input at max length | Accepted; truncation warning
Concurrent access | Two users edit same record | Last-write-wins with conflict notice
Permission denied | User lacks required role | 403 with explanation
Network failure | API timeout during save | Retry with user notification
Data migration | Legacy records missing field | Default value applied
Scale | 10x expected volume | Degrades gracefully, no crash
Non-Functional Requirements (NFRs):
NFRs are often discovered during production incidents. Define them upfront.
NON-FUNCTIONAL REQUIREMENTS: [Feature Name]
────────────────────────────────────────────
Category | Requirement | Measurement
────────────────|───────────────────────────────────────|────────────
Performance | Page loads in <2s at P95 | Lighthouse, APM
Availability | 99.9% uptime during business hours | Uptime monitor
Security | All inputs validated server-side | Security audit
Accessibility | WCAG 2.1 AA compliance | axe-core scan
Scalability | Supports 10x current user count | Load test
Data retention | User data deletable within 30 days | Compliance audit
Observability | Errors logged with correlation ID | Log search
Misalignment between stakeholders causes more project delays than technical complexity. Use explicit frameworks to prevent ambiguity about who decides what.
RACI Matrix:
Define roles for every major decision and deliverable.
RACI MATRIX: [Project Name]
───────────────────────────
PM Eng Lead Designer QA Exec
Scope decisions A C C I I
Technical approach C A I C I
UX design C C A C I
Release timing A R I C I
Quality sign-off C C I A I
Go/no-go decision R C I C A
R = Responsible (does the work)
A = Accountable (makes the final call)
C = Consulted (provides input before decision)
I = Informed (notified after decision)
Rules:
Decision Log Template:
Record every significant decision to prevent re-litigation.
DECISION LOG
────────────
ID: DEC-001
Date: [YYYY-MM-DD]
Decision: [What was decided]
Context: [Why this decision was needed]
Options: [Options considered with brief pros/cons]
Chosen: [Which option and why]
Decided by: [Name and role]
Reversible: [Yes/No - and what would trigger reversal]
Cross-Functional Dependency Map:
DEPENDENCY MAP: [Project Name]
──────────────────────────────
Deliverable | Depends On | Owner | Status | Risk
─────────────────────|─────────────────────────|─────────────|───────────|──────
API endpoint | Schema design | Backend | Done | Low
Frontend integration | API endpoint | Frontend | Blocked | High
Load testing | Staging environment | DevOps | In progress| Med
Documentation | API endpoint + UX final | Tech Writer | Not started| Low
Communication Cadence:
COMMUNICATION PLAN: [Project Name]
───────────────────────────────────
Audience | Channel | Frequency | Content | Owner
────────────────|─────────────|──────────────|────────────────────────────|──────
Core team | Standup | Daily | Blockers, progress | Eng Lead
Stakeholders | Status email| Weekly | Milestones, risks, asks | PM
Leadership | Slide deck | Biweekly | KPIs, timeline, decisions | PM
Customers | Changelog | At launch | What's new, migration notes| PM
Escalation Paths:
ESCALATION FRAMEWORK
────────────────────
Level 1: Team-level (Eng Lead resolves within 1 business day)
Triggers: Blocked tasks, minor scope questions, technical disagreements
Level 2: Cross-team (PM + Eng Lead + counterpart, resolve within 2 days)
Triggers: Dependency delays, resource conflicts, scope changes >2 days
Level 3: Leadership (Director/VP, resolve within 3 days)
Triggers: Timeline at risk, budget overrun, strategic pivot needed
Rule: Every escalation includes a written summary of the problem, options considered, and a recommended path forward. Never escalate without a recommendation.
A roadmap is a communication tool, not a commitment to exact dates. Use time horizons and dependency awareness to create realistic plans.
Now/Next/Later Framework:
ROADMAP: [Product Area]
───────────────────────
NOW (current sprint/iteration, committed)
- [Feature A] - solves [problem], measured by [metric]
- [Feature B] - prerequisite for [Feature D]
NEXT (1-2 sprints out, high confidence)
- [Feature C] - depends on [Feature A] completion
- [Feature D] - validated by [research/data]
LATER (3+ sprints, directional, subject to change)
- [Feature E] - pending validation of [assumption]
- [Feature F] - blocked by [external dependency]
WILL NOT DO (explicitly rejected)
- [Feature G] - reason: [low impact, high cost]
Rules for the Now/Next/Later roadmap:
Dependency-Aware Sequencing:
SEQUENCING PLAN
───────────────
Phase 1 (Week 1-2): Foundation
[Task A] ──→ [Task B] ──→ [Task C]
│
▼
Phase 2 (Week 3-4): Core Features
[Task D] ──→ [Task E]
[Task F] (parallel, no dependencies)
Phase 3 (Week 5): Integration and Polish
[Task G] (requires Task E + Task F)
[Task H] (requires Task C)
Critical path: A → B → D → E → G
Float tasks (can slip without affecting deadline): F, H
Milestone Definition:
MILESTONE TEMPLATE
──────────────────
Name: [M1: Core API Complete]
Target date: [YYYY-MM-DD]
Definition: [All CRUD endpoints deployed to staging with passing tests]
Deliverables: [List of specific artifacts]
Exit criteria: [What must be true to declare this milestone done]
Dependencies: [What must be complete before this milestone starts]
Risk: [Primary risk and mitigation]
Risk-Adjusted Timeline:
Add buffers based on uncertainty, not optimism.
TIMELINE ESTIMATION
───────────────────
Task | Best Case | Likely | Worst Case | Risk-Adjusted
──────────────────|───────────|────────|────────────|──────────────
Task A | 2d | 3d | 5d | 3.5d
Task B | 1d | 2d | 4d | 2.5d
Task C | 3d | 5d | 10d | 6d
Integration | 1d | 2d | 5d | 3d
──────────────────|───────────|────────|────────────|──────────────
Total | 7d | 12d | 24d | 15d
Risk-Adjusted = (Best + 4*Likely + Worst) / 6 (PERT estimate)
Buffer policy: Add 20% to the risk-adjusted total for unknowns.
Communicate the risk-adjusted estimate externally, not the best case.
Feature Flagging Strategy:
Decouple deployment from release to reduce launch risk.
FEATURE FLAG PLAN: [Feature Name]
─────────────────────────────────
Flag name: [feature-name-enabled]
Default state: OFF
Rollout stages:
1. Internal team only (dogfooding) - 1 week
2. 5% of users (canary) - 3 days
3. 25% of users (early adopter ring) - 1 week
4. 100% of users (general availability) - permanent
Rollback trigger: [Error rate >1% or P95 latency >500ms]
Flag removal: [Remove flag and dead code within 30 days of GA]
Owner: [Name]
Launching is not the finish line. It is the start of validation. Plan for measurement, iteration, and (if needed) rollback.
Launch Checklist:
PRE-LAUNCH CHECKLIST: [Feature Name]
─────────────────────────────────────
Category | Item | Status
──────────────────|─────────────────────────────────────────|───────
Engineering | All acceptance criteria passing | [ ]
Engineering | Load test completed at 2x expected load | [ ]
Engineering | Feature flag tested (on/off/rollback) | [ ]
Engineering | Monitoring and alerts configured | [ ]
Engineering | Runbook written for on-call team | [ ]
Quality | QA sign-off on staging | [ ]
Quality | Accessibility audit passed | [ ]
Quality | Security review completed | [ ]
Documentation | User-facing docs updated | [ ]
Documentation | Internal knowledge base updated | [ ]
Documentation | API changelog entry written | [ ]
Communication | Release notes drafted | [ ]
Communication | Support team briefed | [ ]
Communication | Stakeholders notified of launch date | [ ]
Rollback | Rollback plan documented and tested | [ ]
Rollback | Data migration reversal verified | [ ]
Feature Flag Rollout Plan:
ROLLOUT SCHEDULE: [Feature Name]
────────────────────────────────
Stage | Audience | Duration | Success Gate | Rollback Gate
─────────|──────────────────|──────────|─────────────────────────|──────────────
Canary | Internal team | 3 days | No P0/P1 bugs | Any P0 bug
Ring 1 | 5% of users | 5 days | Error rate <0.5% | Error rate >2%
Ring 2 | 25% of users | 5 days | P95 latency <300ms | P95 >800ms
Ring 3 | 50% of users | 3 days | NPS/CSAT stable | NPS drop >5pts
GA | 100% of users | Permanent| Metric targets met | Exec decision
A/B Test Design:
When validating a feature with an experiment:
A/B TEST PLAN: [Experiment Name]
────────────────────────────────
Hypothesis: [Changing X will improve Y by Z%]
Primary metric: [Conversion rate, engagement, retention, etc.]
Guardrail metrics: [Metrics that must not degrade]
Control group: [Current experience, 50% of traffic]
Treatment group: [New feature enabled, 50% of traffic]
Sample size: [Minimum users needed for statistical significance]
Duration: [Minimum runtime, typically 2-4 weeks]
Significance: [p < 0.05 or 95% confidence interval]
Decision rule: [Ship if primary metric improves >X% with significance]
Owner: [Name]
Success Metric Dashboard:
Define what to monitor post-launch and where to find it.
POST-LAUNCH DASHBOARD: [Feature Name]
──────────────────────────────────────
Metric | Source | Baseline | Target | Alert Threshold
──────────────────────|──────────────|──────────|─────────|────────────────
Adoption rate | Analytics | 0% | 30%/30d | <10% at day 14
Error rate | APM | 0.1% | <0.5% | >1%
P95 response time | APM | 150ms | <300ms | >500ms
User satisfaction | Survey/NPS | N/A | >4.0/5 | <3.0
Support ticket volume | Help desk | 5/week | <10/week| >20/week
Post-Launch Review Template:
Conduct a review 2-4 weeks after launch.
POST-LAUNCH REVIEW: [Feature Name]
───────────────────────────────────
Date: [YYYY-MM-DD]
Participants: [Names and roles]
1. RESULTS
- Primary metric: [Target] vs [Actual]
- Secondary metrics: [Summary]
- Unexpected findings: [Any surprises]
2. WHAT WENT WELL
- [Item 1]
- [Item 2]
3. WHAT COULD IMPROVE
- [Item 1 with specific action]
- [Item 2 with specific action]
4. FOLLOW-UP ACTIONS
| Action | Owner | Due Date |
|---------------------------|------------|------------|
| [Action 1] | [Name] | [Date] |
| [Action 2] | [Name] | [Date] |
5. DECISION
- [ ] Keep as-is (metrics met)
- [ ] Iterate (metrics partially met, specific improvements identified)
- [ ] Roll back (metrics not met, user impact negative)
- [ ] Expand (metrics exceeded, roll out to additional segments)
Not sure which framework to use? Start here.
| Situation | Recommended Framework | Step |
|---|---|---|
| "What problem are we solving?" | JTBD + Problem Statement | Step 1 |
| "Is this in scope?" | In/Out Table | Step 2 |
| "What should we build first?" | RICE (data-rich) or ICE (early stage) | Step 3 |
| "When is this done?" | Acceptance Criteria (Given/When/Then) | Step 4 |
| "Who decides?" | RACI Matrix | Step 5 |
| "What order?" | Now/Next/Later + Dependency Map | Step 6 |
| "Are we ready to ship?" | Launch Checklist + Rollout Plan | Step 7 |
Bad: "We need to add a Kafka queue for real-time updates"
Good: "Users need to see changes within 5 seconds. What's the simplest way?"
Bad: In scope: search, filters, sorting, pagination, saved searches, export
Good: In scope: search + filters (validates core use case)
Out of scope: sorting, pagination, saved searches, export (v2)
Bad: "The page should load quickly"
Good: "Given a user on a 4G connection, when the page loads, then first contentful paint is under 1.5 seconds"
Bad: "Success = 20% increase in signups"
Good: "Success = 20% increase in signups AND no decrease in 30-day retention"
Bad: "Q3: Feature X, Q4: Feature Y" (treated as deadline commitments)
Good: "Now: Feature X (committed). Next: Feature Y (high confidence). Later: Feature Z (directional)."
| Rationalization | Reality |
|---|---|
| "The team already knows what to build, framing is overhead" | Solution-first momentum ships a Kafka queue when the user only needed updates within 5 seconds. The JTBD statement is what stops the team from building infrastructure nobody asked for. |
| "We'll add 'just one more thing' to this release" | "While we're at it" is the documented scope-creep signal that turns a 2-week MVP into a 6-week project. Every In-item that moves in must push an Out-item out or the deadline slips silently. |
| "Success is shipping the feature on time" | Output is not outcome. A feature shipped on schedule that nobody adopts is a failure the guardrail metric would have caught; define the metric before code, not after launch. |
| "We can prioritize by gut feel, the backlog is small" | Opinion-based ranking re-litigates the same decision every standup. A RICE or ICE score makes the tradeoff explicit and survives the loudest stakeholder in the room. |
| "Acceptance criteria can be filled in during implementation" | "The page should load quickly" is untestable, so QA cannot sign off and the engineer guesses the threshold. Given/When/Then with a concrete number is the contract that prevents rework. |
Version: 1.0.0 Last Updated: March 2026
This skill is optimized for an iterative approach: