skills/magnus919_agent-skills
1
0
Fork 0
mirror of https://github.com/magnus919/agent-skills.git synced 2026-09-11 19:47:12 +03:00
Code Issues Packages Projects Releases Wiki Activity

feat: add product-methodology skill (#27)

Browse Source 
Closes #6.\n\nImplemented with OpenCode and specialist research; corrected and binding-reviewed by Jasper.
This commit is contained in:
Magnus Hedemark
2026-07-13 02:23:05 -04:00
committed by GitHub
parent 3b0b743687
commit d89bf34cb8
13 changed files with 965 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
AGENTS.md
+1
View File
@@ -126,6 +126,7 @@ When the user mentions these keywords, load the corresponding skill:
| "open source", "contributing", "how to contribute", "submit a PR", "file an issue", "CONTRIBUTING.md", "bug report template", "PR template" | [opensource-contributions](opensource-contributions/SKILL.md) |
| "pydanticai", "pydantic AI", "pydantic graph", "AI agent", "LLM agent", "agent framework", "function tool", "tool-using agent", "agent with tools", "agent with dependencies", "structured output", "streaming agent", "agent graph", "state machine graph", "GraphBuilder", "BaseNode", "multi-agent", "agent delegation", "LLM evals", "model testing", "TestModel", "FunctionModel", "capabilities" | [pydanticai](pydanticai/SKILL.md) |
| "product discovery", "stakeholder interview", "requirements discovery", "user research", "customer interview", "requirements gathering", "discovery phase", "stakeholder mapping", "interview guide", "discovery conversation", "transcript to spec", "requirements conflict", "what would have to be true", "pre-mortem", "laddering", "assumption busting" | [product-discovery](product-discovery/SKILL.md) |
| "prioritize", "RICE", "MoSCoW", "opportunity solution tree", "decision log", "write a spec", "product spec", "PRD", "stakeholder communication", "executive brief", "feature prioritization", "backlog ranking", "release scope", "build vs buy", "product decision" | [product-methodology](product-methodology/SKILL.md) |
| "workflow", "figure out my workflow", "analyze my process", "what do I actually do", "catalog my workflow", "formalize my process", "workflow architect", "onboard me to my own process" | [workflow-architect](bundles/workflow-architect/SKILL.md) |
| "default alive", "default dead", "runway", "burn rate", "burn multiple", "financial projection", "startup finances", "cash on hand", "breakeven", "how long until", "profitability" | [yc-default-alive-calculator](yc-default-alive-calculator/SKILL.md) |
| "growth rate", "weekly growth", "monthly growth", "startup growth", "compound growth", "traction", "are we growing", "growth benchmark", "how fast should we grow", "YC growth", "product-market fit", "acceleration", "growth trajectory" | [yc-weekly-growth-compass](yc-weekly-growth-compass/SKILL.md) |
README.md
+4
View File
@@ -191,6 +191,10 @@ PeerTube federated video platform from the terminal. Browse videos and channels,
Discover product requirements from human stakeholders — map who to talk to, ask questions that surface hidden assumptions, detect gaps in real time, resolve conflicts, and translate conversations into structured specs. Phase 0 upstream of any spec-driven pipeline. Ships 8 reference files covering stakeholder mapping, question patterns, gap detection, conflict resolution, transcript-to-spec distillation, AI-conducted discovery, power dynamics, and time-constrained discovery; plus 5 templates (discovery plan, interview guide, distillation worksheet, gap register, interpretation log).
### [product-methodology](product-methodology/SKILL.md)
Product management frameworks for translating validated evidence into prioritized backlogs, documented decisions, specifications, and stakeholder communications. Covers RICE scoring, MoSCoW prioritization, opportunity solution trees, decision logs, spec drafting, and audience-specific stakeholder communication. Ships 7 reference files covering each framework and a source index, plus 2 fillable templates (decision log and spec). Picks up where product-discovery ends.
### [prowlarr-cli](prowlarr-cli/SKILL.md)
Manage your Prowlarr indexer hub from the terminal — list and inspect indexers, view query/grab statistics, check health, manage connected *arr applications, and test indexer connectivity.
product-methodology/README.md
+53
View File
@@ -0,0 +1,53 @@
# Product Methodology — Prioritize, Decide, Specify, Communicate
Translate validated evidence into prioritized backlogs, documented decisions, actionable specifications, and audience-specific stakeholder communications.
## Why Install This Skill
Product teams don't struggle to generate ideas — they struggle to decide what to build, why, and how to communicate those decisions. This skill gives your agent a practical method for:
- **Scoring feature proposals** with RICE (Reach × Impact × Confidence / Effort) so you can compare unrelated ideas on a common scale
- **Scoping time-boxed releases** with MoSCoW (Must/Should/Could/Won't) so the team knows exactly where the boundary is
- **Mapping customer needs to solutions** with opportunity solution trees — without jumping to the wrong answer
- **Documenting decisions** with structured records that survive the next reorg
- **Writing specifications** that engineers, designers, and stakeholders can all work from
- **Communicating with different audiences** in the format each one needs — recommendation-first for executives, context-first for engineers, listening-first for customers
It picks up where product discovery ends and hands off to design and UX with a clean spec.
## What You Get
| Path | What it provides |
|---|---|
| `SKILL.md` | Pipeline overview, trigger conditions, reference guide, and provenance table |
| `references/rice-framework.md` | Full RICE scoring methodology: formula, dimension tables, pitfalls, and example |
| `references/moscow-prioritization.md` | MoSCoW categories, capacity heuristics, and guidance on when to use it instead of RICE |
| `references/opportunity-solution-trees.md` | OST structure, five-step practice, riskiest-assumption testing, anti-patterns |
| `references/decision-log.md` | When to write a decision log, full template, good/bad examples |
| `references/spec-template.md` | Complete spec structure: problem statement, success metrics, scope, edge cases, risks |
| `references/stakeholder-communication.md` | Audience-specific formats: executives, engineers, designers, customers, everyone |
| `references/source-index.md` | Provenance, portability boundary, and authoritative source links |
| `templates/DECISION_LOG.md` | Fillable decision log with YAML frontmatter and the sections provided by this methodology |
| `templates/SPEC.md` | Fillable spec template with YAML frontmatter and guidance text |
## Quick Start
This is a reference-only skill. No setup, API key, or dependency is required. Start with the pipeline in `SKILL.md`, then load the reference for the specific task.
## Triggers
- Prioritize a backlog of features, initiatives, or proposals
- Compare unrelated feature ideas with a common scoring framework
- Scope a time-boxed release with Must/Should/Could/Won't boundaries
- Document a product decision with rationale and expected outcomes
- Write a specification (PRD) for a feature or integration
- Communicate a product decision to executives, engineers, designers, or customers
- Map customer opportunities to potential solutions with opportunity solution trees
## Requirements
No software dependencies or credentials. This skill assumes you have validated evidence (interview notes, usage data, competitive analysis). If you're still discovering requirements, start with the `product-discovery` skill.
## Source and Maintenance
This skill was ported from [`magnus919/hermes-profiles`](https://github.com/magnus919/hermes-profiles) at commit [`867a555`](https://github.com/magnus919/hermes-profiles/commit/867a555). See [`references/source-index.md`](references/source-index.md) for the portability boundary and source review details.
product-methodology/SKILL.md
+88
View File
@@ -0,0 +1,88 @@
---
name: product-methodology
description: >-
Product management frameworks for translating validated evidence into
prioritized backlogs, decisions, specifications, and stakeholder
communications. Covers RICE, MoSCoW, opportunity solution trees, decision
logs, spec drafting, and audience-specific stakeholder communication.
license: MIT
metadata:
source_repo: https://github.com/magnus919/hermes-profiles
source_commit: 867a555
---
# Product Methodology
This skill begins where discovery ends. When you have validated evidence from stakeholder conversations, competitive research, or usage data, it guides you through prioritization, decision-making, specification, and communication.
## Pipeline
```
VALIDATED EVIDENCE → [PRIORITIZE] → [DECIDE] → [SPECIFY] → [COMMUNICATE]
| | | |
RICE + MoSCoW Decision log Spec Stakeholder
template template briefs
```
## Reference Guide
Load only the reference relevant to the task:
| Reference | Load when |
|---|---|
| [RICE scoring](references/rice-framework.md) | You need to compare unrelated feature proposals by Reach × Impact × Confidence / Effort |
| [MoSCoW prioritization](references/moscow-prioritization.md) | Scope is tight for a time-boxed release and you need crisp Must/Should/Could/Won't boundaries |
| [Opportunity solution trees](references/opportunity-solution-trees.md) | The problem space is messy and you need to connect customer needs to build decisions without jumping to solutions |
| [Decision log](references/decision-log.md) | You've made a decision with tradeoffs that will be questioned later — log the context and expected outcome |
| [Spec template](references/spec-template.md) | You need a requirements document that engineers, designers, and stakeholders can all work from |
| [Stakeholder communication](references/stakeholder-communication.md) | You're preparing a message for execs, engineers, designers, or customers — each audience needs a different format |
| [Source index](references/source-index.md) | Reviewing provenance, porting scope, and authoritative source links |
## Templates
| Template | Load when |
|---|---|
| [Decision log template](templates/DECISION_LOG.md) | You need a fillable decision log entry with frontmatter |
| [Spec template](templates/SPEC.md) | You need a fillable spec document with the sections provided by this methodology |
## Trigger Conditions
Load this skill when:
- Prioritizing a backlog of feature proposals or initiatives
- Making a product decision that needs a documented rationale
- Writing a specification for a feature or integration
- Communicating a product decision to different audiences (executives, engineers, designers, customers)
- Mapping customer opportunities to potential solutions
- Scoping a time-boxed release with clear boundaries
- A stakeholder asks "why did we decide this?" and there's no record
## When Not to Use
- **Stakeholder discovery and interviews** — load `product-discovery` first. This skill starts from validated evidence, not raw stakeholder conversations.
- **Interaction design, task flows, or usability** — `product-design-and-ux` is the downstream concern (currently a proposed skill, not yet shipped in this catalog). This skill produces the spec; design-and-ux produces the interaction model.
## Working Method
1. Confirm you have validated evidence (interview notes, usage data, competitive analysis). If not, route to `product-discovery`.
2. Prioritize with RICE when comparing unrelated proposals; use MoSCoW when scoping a time-boxed delivery.
3. Log decisions as structured records with context, options, rationale, and expected outcomes.
4. Write specs that define the problem, success metrics, scope boundaries, open questions, and edge cases.
5. Communicate decisions in the format each audience needs — recommendation-first for executives, context-first for engineers, listening-first for customers.
## Portability
This skill is intentionally host-neutral. It requires no profile system, output format, scripts, or external services. Load references directly by path — use the host agent's normal file-loading mechanism.
## Provenance
| Framework | Origin | Source |
|---|---|---|
| RICE | Intercom (Sean McBride, 2016) | [intercom.com/blog/rice-simple-prioritization-for-product-managers](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) |
| MoSCoW | Dai Clegg, Oracle UK (1994); later adopted by DSDM | [Agile Business Consortium: MoSCoW prioritisation](https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html) |
| Opportunity Solution Trees | Teresa Torres (Product Talk) | [producttalk.org/opportunity-solution-tree](https://www.producttalk.org/opportunity-solution-tree/) |
| Decision log | Synthesized from ADR practice and product management conventions | — |
| Spec template | Synthesized from common PRD practice | — |
| Stakeholder communication | Synthesized from product management communication practice | — |
This skill was ported from [`magnus919/hermes-profiles`](https://github.com/magnus919/hermes-profiles) at commit [`867a555`](https://github.com/magnus919/hermes-profiles/commit/867a555). See [`references/source-index.md`](references/source-index.md) for the portability boundary.
product-methodology/references/decision-log.md
+137
View File
@@ -0,0 +1,137 @@
# Decision Log
Lightweight records for product decisions. Not every decision needs one — but the ones that will be questioned or forgotten do.
## When to Write One
Write a decision log entry when:
- The decision had tradeoffs that could be second-guessed later
- The decision involved multiple stakeholders with different opinions
- The decision sets a precedent for future work
- The decision commits significant resources or creates a difficult-to-reverse dependency
- You want to revisit the decision after enough evidence can accumulate
## The Template
```
# Decision: [Title]
**Date:**
**Status:** Proposed / Accepted / Deprecated / Superseded
## Context
What led to this decision? Include the problem, the constraints, and any relevant data. Write enough that someone reading this in 6 months understands why this was even a question.
## Options Considered
### Option A: [Name]
Pros:
- [pro]
- [pro]
Cons:
- [con]
- [con]
### Option B: [Name]
Pros: ...
Cons: ...
### Option C: [Name] (if applicable)
Pros: ...
Cons: ...
## Decision
Chosen: Option [A/B/C]
Rationale: Why this one over the others? What was the decisive factor?
## Expected Outcome
What do we expect to happen as a result of this decision? Be specific enough that you can check later.
- We expect [metric] to move from [baseline] to [target] by [date]
- We expect [behavior/outcome]
## Follow-up
- **Review date:** [When to check if the decision was right]
- **Signal to watch:** [What data would tell us we made the right call]
- **Signal to reconsider:** [What data would tell us we made the wrong call]
## Sign-off
- [Stakeholder/role] — [date]
```
## Examples
### Good hypothetical example
```
# Decision: Prioritize CSV export over dark mode for Q3
Date: 2026-04-15
Status: Accepted
## Context
We have capacity for one medium feature in Q3. Customer support tickets show
15 requests/month for data export vs 3/month for dark mode. Sales calls
consistently mention "we need to get our data out" as a blocker for
enterprise deals. Dark mode is requested by existing users who like the
product; CSV export is requested by prospects who can't buy without it.
## Options Considered
### A: CSV export
Pro: Unblocks 3 enterprise deals in pipeline ($240K ARR)
Pro: Low engineering effort (2 weeks — well-understood pattern)
Con: Less visible to existing users
### B: Dark mode
Pro: High visibility, generates positive social media mentions
Pro: Frequently requested by power users
Con: Higher effort (4-5 weeks — needs design system work)
Con: Doesn't unblock any revenue
## Decision
Option A. The revenue signal is unambiguous. CSV export is a buying
criteria; dark mode is a preference. If CSV export ships in Q3, the
pipeline deals close this year.
## Expected Outcome
- Enterprise pipeline deals close by Q4 2026 ($240K)
- CSV export usage reaches 20% of power users within 2 months
- Support tickets for "how do I export data" drop to near zero
## Follow-up
Review date: 2026-10-01
Signal to watch: CSV export usage rate
Signal to reconsider: If enterprise deals don't mention CSV export as a
blocker in calls, we misprioritized the feature request volume vs revenue
signal
```
### Bad hypothetical example
```
Decision: Build CSV export
The team wants it. RICE score was high.
- A. Developer
```
This entry is useless because:
- No context (what problem? what options?)
- No tradeoffs (what was the cost of NOT building it?)
- No expected outcome (how do we know if it worked?)
- No review date (it disappears into the archive)
A decision log without substance is just a to-do list.
product-methodology/references/moscow-prioritization.md
+83
View File
@@ -0,0 +1,83 @@
# MoSCoW Prioritization
A method for aligning a team on scope for a specific time-boxed delivery. Every item is classified into one of four buckets. Developed by Dai Clegg at Oracle UK (1994) and later adopted by the DSDM Consortium.
> **Source:** [Wikipedia: MoSCoW method](https://en.wikipedia.org/wiki/MoSCoW_method)
## The Four Categories
### Must Have
Non-negotiable. Without these, the release has no value. If a Must Have slips, the date slips.
**Test:** "If we ship without this, would we regret delaying the whole release?"
**Examples:** Authentication for a login-required product. Payment processing for an e-commerce launch.
**Guidance:**
- DSDM commonly recommends keeping Must Haves near or below 60% of expected effort to preserve contingency; treat this as a planning heuristic, not a universal allocation
- If everything is Must Have, nothing is Must Have — push back
- Must Haves are the first thing built and the last thing cut
### Should Have
Important but not vital. These deliver significant value and should be included if possible, but the release is viable without them.
**Test:** "If we ship without this, will users notice? (Yes, but they won't leave.)"
**Examples:** Secondary sort options on a search results page. Email notifications for account changes.
**Rules:**
- Should Haves are the first to get descoped when Must Haves overrun
- They should have a clear workaround or fallback
- A Should Have that survives 2+ consecutive releases without being built is probably a Could Have
### Could Have
Nice-to-have. These are the first to cut when time runs short. Including them is a bonus, not an expectation.
**Test:** "If we ship without this, would anyone actively complain?"
**Examples:** Custom themes. Advanced filtering. Keyboard shortcuts.
**Rules:**
- Could Haves are where you put your stretch goals
- Zero shame in cutting every Could Have
- If a Could Have generates repeated stakeholder pressure, it's probably misclassified
### Won't Have (This Time)
Explicitly out of scope. The most important category — it makes the other three meaningful by establishing a boundary.
**Test:** "Are we confident we won't build this even if we finish early?" (If yes, it's a Won't Have. If no, it's a Could Have.)
**Examples:** Cross-platform sync in v1. Admin dashboard for a v1 consumer product.
**Rules:**
- Won't Haves get a reason and a potential timeline ("v2 if we hear demand")
- They protect the team from scope creep by making the boundary explicit
- Revisit every quarter — some Won't Haves become Must Haves as context changes
## An Illustrative Capacity Heuristic
| Category | Illustrative capacity |
|----------|----------------|
| Must Have | 60% |
| Should Have | 20% |
| Could Have | 20% |
| Won't Have | (not allocated) |
The 60/20/20 split is DSDM guidance for maintaining contingency, not a formula that proves a plan is viable. Adapt it to the delivery context and confidence in estimates. If Must Haves consume nearly all expected capacity, make the tradeoff explicit:
1. **Cut scope** — move some to Should Have or Won't Have
2. **Extend timeline** — but be explicit that this is the tradeoff
## When to Use MoSCoW vs RICE
| Use MoSCoW When | Use RICE When |
|----------------|---------------|
| Scope is fixed (deadline-driven release) | Effort is fixed (you can build anything, within capacity) |
| You need crisp boundaries for a team | You need defensible priorities for stakeholders |
| Items are all in the same problem space | Items span unrelated domains |
| The team needs a shared understanding of scope | You need a numerical comparison to settle disagreements |
## The Anti-Pattern
**Everything is a Must Have.** This is the most common failure mode. It means nobody trusts that Should Haves will actually get built, so everyone pads their requirements. The fix is to demonstrate that Should Haves really do get built — which means actually cutting something on the Must Have list first.
If a stakeholder insists everything is Must Have, write the items down, compare them with available capacity, and ask which ones should move if the estimates or date cannot change. This reframes the constraint from abstract to concrete without pretending the illustrative ratio is an observed capacity limit.
product-methodology/references/opportunity-solution-trees.md
+86
View File
@@ -0,0 +1,86 @@
# Opportunity Solution Trees
Teresa Torres's framework for connecting desired outcomes to the things you build — without jumping to solutions.
> **Source:** [Product Talk — Opportunity Solution Trees](https://www.producttalk.org/opportunity-solution-tree/). Framework by Teresa Torres, developed and refined through coaching practice (~2014–2016). See also her book *Continuous Discovery Habits* (2020).
## The Structure
```
Desired Outcome
└─ Opportunity 1 (customer need, pain point, or desire)
├─ Solution A
│ └─ Experiment 1
│ └─ Experiment 2
└─ Solution B
└─ Experiment 1
└─ Opportunity 2
├─ Solution C
│ └─ Experiment 1
└─ Solution D
```
**Top level:** The desired outcome — something you want to be true ("increase trial-to-paid conversion from 12% to 18%").
**Middle level:** Opportunities — customer needs, pain points, or desires that, if addressed, would move the outcome. NOT solutions. "Customers don't understand the pricing page" is an opportunity. "Redesign the pricing page" is a solution.
**Bottom level:** Solutions — things you could build. Each solution is a hypothesis. Below each solution are the experiments you'd run to validate it.
## The Core Practice
### 1. Start with the outcome
Write down the measurable outcome you're trying to move. Be specific. "Improve onboarding" is too vague. "Increase the percentage of users who complete onboarding from 40% to 65%" is specific.
### 2. Discover opportunities
Talk to customers. Analyze usage data. Look for where users get stuck, where they develop workarounds, where they express frustration. Each distinct need is an opportunity node.
**Good opportunity statements:**
- "New users don't understand what value they'll get before signing up"
- "Users can't easily share their work with colleagues"
- "Power users need to automate repetitive tasks"
**Bad opportunity statements (they're actually solutions):**
- "We need a video on the landing page" → solution, not opportunity
- "Users need bulk editing" → solution, not opportunity (the opportunity is "users manage too many items one at a time")
### 3. Generate solutions for each opportunity
For each opportunity, generate multiple materially different solutions. Include non-technical options such as process changes, content, or partnerships. The point is to avoid anchoring on the first idea; no fixed count guarantees sufficient exploration.
### 4. Test the riskiest assumption first
For each solution, identify the assumption that is both most critical and least certain. Design the smallest experiment that tests that assumption.
| Riskiest Assumption | Smallest Test |
|--------------------|---------------|
| Users want this | Landing page with "Notify me" button |
| Technically feasible | Quick prototype |
| Users will understand it | A small formative usability test, sized to the decision and participant diversity needed |
| It's better than current workaround | Side-by-side comparison test |
### 5. Update the tree as you learn
Experiments produce evidence. Update each node with what you learned. Prune branches that don't survive contact with reality. Add new opportunities that emerge from learning.
## When to Use
Opportunity Solution Trees are the right tool when:
- The problem space is messy and you're not sure what to build
- Stakeholders are jumping to solutions without validating the problem
- You've built several features that didn't move the outcome
- You need a shared map of the territory to align the team
## The Anti-Pattern: Solutioning too early
The most common failure: someone names an opportunity and the room immediately jumps to "let's build X." The tree structure makes this visible — if your tree has one opportunity and six solutions under it, you skipped discovery. Go back and find more opportunities before evaluating solutions.
## Relationship to Other Frameworks
| Framework | Role |
|-----------|------|
| RICE | Prioritizes which opportunities/solutions to pursue next |
| MoSCoW | Scopes a specific tree branch for a release |
| Customer interviews | Feeds opportunities into the tree |
| Spec template | Documents the selected solution for implementation |
product-methodology/references/rice-framework.md
+91
View File
@@ -0,0 +1,91 @@
# RICE Scoring Framework
A method for prioritizing feature proposals by scoring them across four dimensions: Reach, Impact, Confidence, and Effort. Developed by Intercom (Sean McBride, 2016).
> **Source:** [Intercom blog — RICE: Simple prioritization for product managers](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/)
## The Formula
```
RICE Score = (Reach × Impact × Confidence) / Effort
```
Score is unitless — used only for relative comparison. A score of 50 is not "good"; it's better than 30 and worse than 100.
## Dimensions
### Reach — How many people does this affect?
Measured in users or customers per unit time. Be specific about the time window.
| Signal | Illustrative reach | Example |
|--------|--------------|---------|
| Affects all users | 10,000+/quarter | Login flow improvement |
| Affects a segment | 1,000–10,000/quarter | New export format for power users |
| Affects very few | 100–1,000/quarter | Admin UI improvement |
| Niche edge case | < 100/quarter | Specific error message improvement |
The values above are hypothetical and exist only to demonstrate a consistent unit. Use observed product data for the actual population and period. Don't inflate Reach by counting everyone as "affected." A feature must plausibly change their experience to count them.
### Impact — How much does it matter to the people it reaches?
A qualitative score converted to a multiplier. Use a standard scale to keep comparisons consistent.
| Score | Label | Meaning |
|-------|-------|---------|
| 3 | Massive | Transformative for the target users |
| 2 | High | Significant improvement |
| 1 | Medium | Noticeable improvement |
| 0.5 | Low | Marginal improvement |
| 0.25 | Minimal | Barely noticeable |
**Pitfall:** Impact is about the people reached, not total business value. A 0.5 impact × 10,000 reach = 5,000; a 3 impact × 100 reach = 300. The high-reach/low-impact item scores higher. This is by design — it surfaces broad improvements over narrow deep ones.
### Confidence — How sure are you about your Reach and Impact estimates?
Expressed as a percentage. Low confidence should penalize the score heavily.
| Score | Label | Meaning |
|-------|-------|---------|
| 100% | High | Direct evidence closely matches the estimate, such as production metrics or a relevant experiment |
| 80% | Medium | Credible but incomplete evidence, such as interviews, surveys, or an analogous launch |
| 50% | Low | Limited evidence or a weak analogy |
These confidence values follow Intercom's published scale, but the evidence descriptions are practical interpretations. Don't use 100% merely because the team agrees. Record the evidence behind the value, and treat low-confidence scores as a reason to learn before committing.
### Effort — How much time from the full team?
Estimate effort in one consistent unit, such as person-weeks or person-months. Include design, engineering, QA, documentation, and release work. Derive values from the team doing the work; generic size-to-duration tables create false precision.
## When to Use RICE vs Other Frameworks
| Use RICE When | Don't Use RICE When |
|--------------|---------------------|
| You have enough data to estimate four dimensions credibly | Estimates are pure guesses across the board |
| You're comparing unrelated feature proposals | All options are variations of the same thing |
| You need to defend priorities to stakeholders | The decision is a quick call between two obvious choices |
| You're planning a quarter+ roadmap | You're planning a single sprint |
## Common RICE Pitfalls
### Score inflation across the board
All scores drift up over time as teams get optimistic. **Reset periodically.** If everything scores above 100, your scale has shifted. Re-anchor against a known baseline ("last quarter's top feature was a 47 — does this really beat it by 3x?").
### Effort as a schedule, not a cost
Effort should be team-weeks, not calendar-weeks. A feature that takes 2 weeks of engineering work but 4 weeks of calendar time because of dependencies should be scored at 2 weeks. The dependency is a separate concern.
### Cherry-picking the easy dimension
If Reach is obviously high, don't pad Impact and Confidence to match. Each dimension should be estimated independently. If you find yourself adjusting Confidence to fit a desired score, you're anchoring.
### The denominator trap
Effort is the denominator, so uncertain estimates can materially change ranking. Preserve a range or run a sensitivity check rather than choosing whichever endpoint produces the preferred score.
## Example
| Item | Reach | Impact | Confidence | Effort | Score |
|------|-------|--------|------------|--------|-------|
| Add CSV export | 2,000/q | 2 (High) | 80% | 2 wks | (2000×2×0.8)/2 = 1600 |
| Dark mode | 10,000/q | 1 (Med) | 50% | 6 wks | (10000×1×0.5)/6 = 833 |
| Rebuild search | 10,000/q | 3 (Massive) | 20% | 12 wks | (10000×3×0.2)/12 = 500 |
CSV export wins despite lower Reach because high Confidence + low Effort creates a better ratio. The search rebuild has the most potential but needs validation before it's worth the bet.
product-methodology/references/source-index.md
+48
View File
@@ -0,0 +1,48 @@
# Source Index — product-methodology
Provenance, portability boundary, and source review for the `product-methodology` skill.
## Source of Truth
This skill was ported from [`magnus919/hermes-profiles`](https://github.com/magnus919/hermes-profiles) at commit [`867a555`](https://github.com/magnus919/hermes-profiles/commit/867a555), path `skills/product-methodology/`.
## Portability Boundary
The source skill was Hermes-specific. The following transformations were applied:
| Source element | Destination | Change |
|---|---|---|
| `SKILL.md` (Hermes-specific: artifact pyramid output, `skill_view()` calls, Kanban references) | Rewritten as thin progressive-disclosure index | Removed all Hermes-specific instructions; rewrote as portable reference table |
| `references/artifact-pyramid-mapping.md` | Removed | Hermes-specific output format — not portable |
| `references/customer-interview-guide.md` | Removed | Belongs to `product-discovery` skill, not product-methodology |
| `references/rice-framework.md` | Kept | Added attribution to Intercom; content is portable methodology |
| `references/moscow-prioritization.md` | Kept | Added attribution to Dai Clegg; content is portable methodology |
| `references/opportunity-solution-trees.md` | Kept | Added attribution to Teresa Torres; content is portable methodology |
| `references/decision-log.md` | Kept | Content is synthesized practice — no changes needed |
| `references/spec-template.md` | Kept | Content is synthesized practice — no changes needed |
| `references/stakeholder-communication.md` | Kept | Content is synthesized practice — no changes needed |
| (new) `references/source-index.md` | Created | This file |
| `templates/DECISION_LOG.md` | Extracted from `references/decision-log.md` | Fillable template with YAML frontmatter |
| `templates/SPEC.md` | Extracted from `references/spec-template.md` | Fillable template with YAML frontmatter |
## Framework Provenance
| Framework | Origin | Primary source | Treatment |
|---|---|---|---|
| RICE | Intercom (Sean McBride, 2016) | [Intercom: RICE prioritization](https://www.intercom.com/blog/rice-simple-prioritization-for-product-managers/) | Paraphrased with attribution; the source article's wording and examples are not reproduced. |
| MoSCoW | Dai Clegg, Oracle UK (1994); later adopted by DSDM | [Agile Business Consortium: MoSCoW prioritisation](https://www.agilebusiness.org/dsdm-project-framework/moscow-prioritisation.html) | Paraphrased with attribution; capacity guidance is presented as a planning heuristic, not a universal rule. |
| Opportunity Solution Trees | Teresa Torres (Product Talk) | [Product Talk: Opportunity Solution Trees](https://www.producttalk.org/opportunity-solution-tree/) | Paraphrased with attribution; proprietary diagrams and book text are not reproduced. |
| Decision log | Synthesized from ADR practice | [ADR pattern (Michael Nygard, 2011)](https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) | Original synthesis informed by the cited pattern. |
| Spec template | Synthesized from PRD conventions | — | Original synthesis from common product-documentation practice. |
| Stakeholder communication | Synthesized from PM communication practice | — | Original synthesis from common communication practice. |
## Review Date
Source review completed July 2026. Framework URLs verified live.
## Boundary with Adjacent Skills
| Skill | Relationship | Status |
|---|---|---|
| `product-discovery` | Upstream — feeds validated evidence into methodology | Ships in this catalog |
| `product-design-and-ux` | Downstream — consumes specs from methodology | Proposed (issue #24); not yet shipped in this catalog |
product-methodology/references/spec-template.md
+120
View File
@@ -0,0 +1,120 @@
# Spec Template
A requirements document that engineers, designers, and stakeholders can all work from. The goal is not to specify every pixel and code path — it's to align on what we're building, what we're not building, and what we haven't figured out yet.
---
# Feature Title
**Status:** Draft / In Review / Approved
**Owner:**
**Last updated:**
## Problem Statement
What problem are we solving, and for whom? One paragraph. If you can't describe the problem without mentioning your proposed solution, you haven't thought about it enough.
**Don't write:** "We need a bulk edit feature so users can edit multiple items at once."
**Write:** "Power users managing 50+ projects spend 4+ hours per week updating individual project settings. Each setting change requires 4 clicks and a page load. This creates a ceiling on how many projects a single user can manage."
## Success Metrics
How will we know this worked? Use evidence appropriate to the decision, often combining a quantitative metric, a qualitative signal, and a countermetric.
- **Primary metric:** [e.g., Time spent per project settings update]
- **Target:** [e.g., Reduce from 4 hours to 30 minutes per week]
- **Qualitative signal:** [e.g., Users stop asking for bulk edit in support tickets]
- **Countermetric to watch:** [e.g., Don't increase accidental edits — measure undo/redo rate]
## Scope
### What we're building
3-6 bullet points describing what this feature actually does. Engineer-readable. No implementation details.
- Users can select multiple projects from a list view
- Users can apply a setting change to all selected projects at once
- Users can preview changes before applying
- Users can undo the last bulk operation
- Changes are logged per-project for audit trail
### What we're NOT building
Explicitly. This protects the team from scope creep.
- No scheduled/recurring bulk operations (future)
- No bulk operations across different item types (projects + tasks together)
- No template-based bulk operations
- No role-based permissions on bulk operations (all project editors can bulk-edit)
## Open Questions
Every spec should have open questions. If you have zero open questions, you either understand the problem perfectly or (more likely) you didn't think about the hard parts.
- [ ] What's the maximum number of items that can be selected before performance degrades?
- [ ] Should bulk operations generate separate audit entries per item, or one aggregated entry?
- [ ] Are there any permission scenarios where a user can see items they can't bulk-edit?
- [ ] How does this interact with the existing "project lock" feature?
## Deferred Decisions
Things we've explicitly decided not to decide yet, with the reasoning.
| Decision | Why deferred | When to revisit |
|----------|-------------|-----------------|
| Undo window duration | UX research needed | After first user tests |
| Mobile layout | Mobile usage is <5% of power user traffic | When mobile traffic exceeds 15% |
## Design Constraints
Hard constraints that any solution must work within. These come from the team, not from the PM.
- **Engineering:** Edit operation must complete within 5 seconds for 100 items
- **Design:** Must work on both full-width and half-width viewport configurations
- **Data/Infra:** Audit trail must maintain existing immutability guarantees
- **Accessibility:** Must meet applicable WCAG 2.2 AA success criteria, including keyboard and focus behavior
## Edge Cases
Known edge cases the solution should handle. Addressed or deferred.
| Edge case | Status |
|-----------|--------|
| User selects items they don't have edit permission on | Skip in preview, notify user |
| Bulk operation partially fails | Roll back all, notify user |
| User navigates away during pending operation | Cancel operation, warn user |
| Items are deleted by another user mid-selection | Refresh selection, exclude deleted items |
## Technical Notes
Engineer-facing implementation guidance. The PM doesn't dictate architecture, but can surface context the team needs.
- The existing project settings API supports single-item PATCH — bulk PATCH endpoint needed
- Audit event schema already includes `action:bulk_update` — no schema migration needed
- Undo will need a new `bulk_operation_id` correlation field on audit events
## Dependencies
- Bulk PATCH endpoint (API team, sprint +1)
- Design review for preview modal
- Copy review for confirmation messages
- Accessibility audit for keyboard navigation flow
## Timeline & Milestones
| Milestone | Target | Exit criteria |
|-----------|--------|---------------|
| API endpoint ready | Sprint+2 | Bulk PATCH passes integration tests |
| Frontend prototype | Sprint+3 | Selection + preview flow works in staging |
| User test | Sprint+4 | Defined participants complete the critical task without blocking usability failures |
| Release | Sprint+5 | GA with metrics tracking enabled |
## Risks
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Parallel edits conflict | Medium | High | Pessimistic locking on project settings |
| Performance at 1000+ items | Low | Medium | Cap selection at 200 items for v1 |
| Users accidentally apply wrong settings | Medium | High | Preview step plus an undo window validated against the workflow |
All example names, numbers, dates, milestones, and thresholds in this reference are hypothetical. Replace them with evidence and constraints from the product and delivery team; they are not default acceptance criteria or estimates.
product-methodology/references/stakeholder-communication.md
+109
View File
@@ -0,0 +1,109 @@
# Stakeholder Communication
Different audiences need different information in different containers. The skill of a PM is not just knowing what to say — it's knowing what to say to whom.
## To Executives
### The Format
```
RECOMMENDATION: [one sentence]
WHY: [2-3 sentences]
WHAT WE NEED: [specific ask, with deadline]
BAD NEWS: [if any, surfaced early]
```
### The Rules
**Lead with the recommendation.** Executives don't need to walk through your analysis to get to your conclusion. Give them the answer first. If they want the methodology, they'll ask.
**Surface bad news early.** Before it becomes a crisis. An exec who hears about a slip from a customer before hearing it from you has already lost trust. The format:
> We're going to miss the [date] launch for [feature]. We caught this [when]. The root cause is [specific — no blame]. Here's what we're doing: [plan]. We'll know more by [date].
**No decisions hidden in status reports.** If you need a decision, make it a separate request. Don't bury "by the way, should we..." in a weekly update.
**Include the counterargument.** If you're recommending option A, briefly say why someone might pick option B and why you chose A anyway. It pre-empts the question and shows you considered alternatives.
### Anti-patterns
- **Deck-first thinking.** You don't need slides to communicate. A well-structured paragraph is faster to read and harder to misinterpret.
- **The twenty-slide tour.** You explored options A, B, C, and D. Tell them you chose A and why. Don't walk them through each option.
- **Optimism bias.** "We might make up the time" is not a plan. Give them the current forecast, not the hope.
## To Engineers
### The Format
A spec document (see [spec-template.md](spec-template.md)). But the living communication — day to day — follows different rules.
### The Rules
**Be specific and be honest.** Flag what you know, what you don't know, and which decisions are deferred. Engineers have been burned by PMs who pretend to have answers they don't have.
**Explain the "why" behind priority changes.** Not just "leadership decided" — the actual reasoning and tradeoffs that were considered. Engineers who understand the business context make better technical decisions.
**Don't make commitments on their behalf.** "Engineering said this would take two weeks" is fine. "I told stakeholders it would take two weeks" is a commitment you made without their input.
**Bring constraints early.** Technical, business, timeline — inform engineering before they start designing, not after they've built the wrong thing.
**Flag the open questions.** Every spec should have a section called "Open Questions." Engineers will find them anyway — listing them upfront builds trust.
### Anti-patterns
- **Ticket-taker mode.** "Here's the spec, build it." The best engineering work comes from engaging them in the problem, not just the solution.
- **Scope surprise.** Adding requirements after the estimate is done. If scope changes, re-estimate.
- **No response.** An engineer asks a question about the spec and receives no acknowledgment within the team's agreed response window. Answer even if the answer is "I need to check," and state when you'll follow up.
## To Designers
### The Format
Outcome descriptions, not pixel specs.
### The Rules
**Be specific about outcomes, flexible about implementation.** Describe what success looks like in measurable terms without dictating the UI. "Users need to understand which team members are available right now" is a good brief. "We need a green dot next to each avatar" is a bad one.
**Bring constraints early.** Technical, business, timeline. Give designers the constraints before they start exploring, so their work isn't rejected later for reasons outside their control.
**Review as a partner, not an approver.** Frame feedback in terms of user behavior, not personal preference. "This interaction doesn't handle the case where the user hasn't completed onboarding" is useful. "I don't like this shade of blue" is not.
**Protect exploration time.** The same way you protect engineering flow. A designer who has to defend every hour of exploration will stop exploring.
### Anti-patterns
- **"Make it pop."** If you can't describe what's wrong, you probably can't describe what's right either.
- **Skipping the problem space.** Bringing designers in only after requirements are locked wastes their best skill — solving problems in ambiguity.
- **Unbounded feedback rounds.** Repeated review cycles can signal unclear constraints, unresolved decision authority, or feedback arriving from the wrong audience.
## To Customers
### The Format
Listening mode. Ask about the last time. Watch without guiding. Pay attention to hesitation, frustration, workarounds.
### The Rules
**Ask about behavior, not opinions.** "Tell me about the last time you tried to do X" produces truth. "Would you use Y if we built it?" produces politeness.
**Don't defend your product.** If a customer struggles, that's data. If you jump in to show them the "right way," you've lost the signal.
**Promises are debt.** "We'll fix that" is a commitment. "That's interesting — tell me more" is learning. Don't confuse the two.
**Close the loop.** If a customer gave you time for an interview, tell them what came of it. Even if the answer is "we learned it wasn't the right problem to solve." It builds trust for the next conversation.
### Anti-patterns
- **Sales mode.** Your product has flaws. A customer pointing them out is not an attack — it's research data.
- **Solution fishing.** "Would you pay for X?" No one knows until they're asked to actually pay. Ask about their current costs instead.
## To Everyone
| Principle | Why |
|-----------|-----|
| Surface bad news early | Bad news doesn't get better with time |
| Say "I don't know" when you don't | Pretending wastes everyone's time |
| Explain the reasoning, not just the decision | Understanding builds trust |
| Write it down | Verbal agreements have half-lives |
| Follow up with a timestamp | "I'll check" means nothing without a follow-up |
product-methodology/templates/DECISION_LOG.md
+65
View File
@@ -0,0 +1,65 @@
---
title: ""
status: "Proposed"
date: ""
authors: []
---
# Decision: [Title]
## Context
<!-- What led to this decision? Include the problem, the constraints, and any relevant data. Write enough that someone reading this in 6 months understands why this was even a question. -->
## Options Considered
### Option A: [Name]
**Pros:**
- <!-- pro -->
- <!-- pro -->
**Cons:**
- <!-- con -->
- <!-- con -->
### Option B: [Name]
**Pros:**
- <!-- pro -->
- <!-- pro -->
**Cons:**
- <!-- con -->
- <!-- con -->
### Option C: [Name] (if applicable)
**Pros:**
- <!-- pro -->
**Cons:**
- <!-- con -->
## Decision
**Chosen:** Option <!-- A / B / C -->
**Rationale:** <!-- Why this one over the others? What was the decisive factor? -->
## Expected Outcome
<!-- What do we expect to happen as a result of this decision? Be specific enough that you can check later. -->
- <!-- We expect [metric] to move from [baseline] to [target] by [date] -->
- <!-- We expect [behavior/outcome] -->
## Follow-up
- **Review date:** <!-- When to check if the decision was right -->
- **Signal to watch:** <!-- What data would tell us we made the right call -->
- **Signal to reconsider:** <!-- What data would tell us we made the wrong call -->
## Sign-off
- <!-- [Stakeholder/role] — [date] -->
product-methodology/templates/SPEC.md
+80
View File
@@ -0,0 +1,80 @@
---
title: ""
status: "Draft"
owner: ""
updated: ""
---
# <!-- Feature Title -->
## Problem Statement
<!-- What problem are we solving, and for whom? One paragraph. If you can't describe the problem without mentioning your proposed solution, you haven't thought about it enough. -->
## Success Metrics
- **Primary metric:** <!-- e.g., Time spent per project settings update -->
- **Target:** <!-- e.g., Reduce from 4 hours to 30 minutes per week -->
- **Qualitative signal:** <!-- e.g., Users stop asking for bulk edit in support tickets -->
- **Countermetric to watch:** <!-- e.g., Don't increase accidental edits — measure undo/redo rate -->
## Scope
### What we're building
<!-- Bullet points describing what this feature actually does. Engineer-readable. No implementation details. -->
- <!-- e.g., Users can select multiple projects from a list view -->
- <!-- e.g., Users can apply a setting change to all selected projects at once -->
### What we're NOT building
<!-- Explicitly. This protects the team from scope creep. -->
- <!-- e.g., No scheduled/recurring bulk operations (future) -->
## Open Questions
- [ ] <!-- What's the maximum number of items? -->
- [ ] <!-- Should bulk operations generate separate audit entries? -->
## Deferred Decisions
| Decision | Why deferred | When to revisit |
|----------|-------------|-----------------|
| <!-- e.g., Undo window duration --> | <!-- UX research needed --> | <!-- After first user tests --> |
## Design Constraints
<!-- Hard constraints that any solution must work within. -->
- **Engineering:** <!-- e.g., Edit operation must complete within 5 seconds for 100 items -->
- **Design:** <!-- e.g., Must work on both full-width and half-width viewport configurations -->
- **Data/Infra:** <!-- e.g., Audit trail must maintain existing immutability guarantees -->
- **Accessibility:** <!-- e.g., Must meet applicable WCAG 2.2 AA criteria, including keyboard and focus behavior -->
## Edge Cases
| Edge case | Status |
|-----------|--------|
| <!-- e.g., User selects items they don't have edit permission on --> | <!-- Skip in preview, notify user --> |
## Technical Notes
<!-- Engineer-facing implementation guidance. Surface context the team needs. -->
## Dependencies
- <!-- e.g., Bulk PATCH endpoint (API team, sprint +1) -->
## Timeline & Milestones
| Milestone | Target | Exit criteria |
|-----------|--------|---------------|
| <!-- API endpoint ready --> | <!-- Sprint+2 --> | <!-- Bulk PATCH passes integration tests --> |
## Risks
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| <!-- e.g., Parallel edits conflict --> | <!-- Medium --> | <!-- High --> | <!-- Pessimistic locking --> |