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 |
You need to compare unrelated feature proposals by Reach × Impact × Confidence / Effort |
| MoSCoW prioritization |
Scope is tight for a time-boxed release and you need crisp Must/Should/Could/Won't boundaries |
| Opportunity solution trees |
The problem space is messy and you need to connect customer needs to build decisions without jumping to solutions |
| Decision log |
You've made a decision with tradeoffs that will be questioned later — log the context and expected outcome |
| Spec template |
You need a requirements document that engineers, designers, and stakeholders can all work from |
| Stakeholder communication |
You're preparing a message for execs, engineers, designers, or customers — each audience needs a different format |
| Source index |
Reviewing provenance, porting scope, and authoritative source links |
Templates
| Template |
Load when |
| Decision log template |
You need a fillable decision log entry with frontmatter |
| Spec template |
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.
- Shaping an unbounded idea into a bet (appetite, pitch, circuit breaker) — load product-shaping before prioritization frameworks apply; this skill consumes a won bet, it does not create one.
- Interaction design, task flows, state/recovery models, or usability-study planning — use product-design-and-ux after this skill has chosen scope. This skill decides what to build and why; design-and-ux defines user-facing behavior.
Working Method
- Confirm you have validated evidence (interview notes, usage data, competitive analysis). If not, route to
product-discovery. If the validated problem has no appetite or bounded solution yet, shape it via product-shaping first — do not pre-shred a pitch into tasks before its bet is placed.
- Prioritize with RICE when comparing unrelated proposals; use MoSCoW when scoping a time-boxed delivery.
- Log decisions as structured records with context, options, rationale, and expected outcomes.
- Write specs that define the problem, success metrics, scope boundaries, open questions, and edge cases.
- Communicate decisions in the format each audience needs — recommendation-first for executives, context-first for engineers, listening-first for customers.
Routing Boundary
Use product-strategy for CPO-level vision, positioning, market strategy, and portfolio direction. Route tactical prioritization, specifications, decision logs, and backlog sequencing back here once strategic direction and validated evidence are available; do not make portfolio strategy decisions in this skill.
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
This skill was ported from magnus919/hermes-profiles at commit 867a555. See references/source-index.md for the portability boundary.
1---2name: product-methodology3description: Translate validated product evidence into tactical backlog decisions, prioritization, specifications, and stakeholder communications. Do not use this skill for CPO-level vision, positioning, or market strategy; use `product-strategy` for strategic direction.4license: MIT5---67# Product Methodology89This 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.1011## Pipeline1213```14VALIDATED EVIDENCE → [PRIORITIZE] → [DECIDE] → [SPECIFY] → [COMMUNICATE]15 | | | |16 RICE + MoSCoW Decision log Spec Stakeholder17 template template briefs18```1920## Reference Guide2122Load only the reference relevant to the task:2324| Reference | Load when |25|---|---|26| [RICE scoring](references/rice-framework.md) | You need to compare unrelated feature proposals by Reach × Impact × Confidence / Effort |27| [MoSCoW prioritization](references/moscow-prioritization.md) | Scope is tight for a time-boxed release and you need crisp Must/Should/Could/Won't boundaries |28| [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 |29| [Decision log](references/decision-log.md) | You've made a decision with tradeoffs that will be questioned later — log the context and expected outcome |30| [Spec template](references/spec-template.md) | You need a requirements document that engineers, designers, and stakeholders can all work from |31| [Stakeholder communication](references/stakeholder-communication.md) | You're preparing a message for execs, engineers, designers, or customers — each audience needs a different format |32| [Source index](references/source-index.md) | Reviewing provenance, porting scope, and authoritative source links |3334## Templates3536| Template | Load when |37|---|---|38| [Decision log template](templates/DECISION_LOG.md) | You need a fillable decision log entry with frontmatter |39| [Spec template](templates/SPEC.md) | You need a fillable spec document with the sections provided by this methodology |4041## Trigger Conditions4243Load this skill when:4445- Prioritizing a backlog of feature proposals or initiatives46- Making a product decision that needs a documented rationale47- Writing a specification for a feature or integration48- Communicating a product decision to different audiences (executives, engineers, designers, customers)49- Mapping customer opportunities to potential solutions50- Scoping a time-boxed release with clear boundaries51- A stakeholder asks "why did we decide this?" and there's no record5253## When Not to Use5455- **Stakeholder discovery and interviews** — load `product-discovery` first. This skill starts from validated evidence, not raw stakeholder conversations.56- **Shaping an unbounded idea into a bet** (appetite, pitch, circuit breaker) — load [product-shaping](../product-shaping/SKILL.md) before prioritization frameworks apply; this skill consumes a won bet, it does not create one.57- **Interaction design, task flows, state/recovery models, or usability-study planning** — use [product-design-and-ux](../product-design-and-ux/SKILL.md) after this skill has chosen scope. This skill decides what to build and why; design-and-ux defines user-facing behavior.5859## Working Method60611. Confirm you have validated evidence (interview notes, usage data, competitive analysis). If not, route to `product-discovery`. If the validated problem has no appetite or bounded solution yet, shape it via `product-shaping` first — do not pre-shred a pitch into tasks before its bet is placed.622. Prioritize with RICE when comparing unrelated proposals; use MoSCoW when scoping a time-boxed delivery.633. Log decisions as structured records with context, options, rationale, and expected outcomes.644. Write specs that define the problem, success metrics, scope boundaries, open questions, and edge cases.655. Communicate decisions in the format each audience needs — recommendation-first for executives, context-first for engineers, listening-first for customers.6667## Routing Boundary6869Use `product-strategy` for CPO-level vision, positioning, market strategy, and portfolio direction. Route tactical prioritization, specifications, decision logs, and backlog sequencing back here once strategic direction and validated evidence are available; do not make portfolio strategy decisions in this skill.7071## Portability7273This 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.7475## Provenance7677| Framework | Origin | Source |78|---|---|---|79| 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/) |80| 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) |81| Opportunity Solution Trees | Teresa Torres (Product Talk) | [producttalk.org/opportunity-solution-tree](https://www.producttalk.org/opportunity-solution-tree/) |82| Decision log | Synthesized from ADR practice and product management conventions | — |83| Spec template | Synthesized from common PRD practice | — |84| Stakeholder communication | Synthesized from product management communication practice | — |8586This 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.
magnus919