hm-l2-product-validation

name: hm-l2-product-validation description: > Product-lens methodology for validating technical decisions against user impact, product vision, and business value. Use when the user asks "is this feature valuable", "what's the user impact", "RICE score", "product validation", "validate against users", "how do I measure success", "feature prioritization", "product lens", "product context", "end user value", "does this solve the right problem", "problem vs solution", "stakeholder perspective", "should we build this", "define success metrics", "quantify user benefit", "anti-solution-check", or "prioritize features by impact". NOT for initial brainstorming (use hm-brainstorm), requirements gap analysis (use hm-requirements-analysis), dependency graph design (use hm-feature-ecosystem), or long-term maintainability scoring (use hm-roadmap-maintainability). metadata: layer: "3" role: "domain-execution" pattern: P2 version: "1.0.0" allowed-tools: - Read - Write - Edit - Bash - Glob - Grep

Product Validation: Technical Decisions → User Impact

Overview

Every feature, architecture choice, and implementation decision must trace back to user value. This skill teaches the product-lens methodology: a structured way to step out of the implementation mindset and validate that what gets built actually delivers to real users. It bridges product management perspective with technical implementation across all development stages.

This skill answers five questions about every technical decision:

1. Who benefits? Which user segment experiences the improvement, and how many are they?
2. How much? What is the measurable difference in their experience — speed, accuracy, satisfaction?
3. Is this the right problem? Are we solving a real user pain, or implementing a solution looking for a problem?
4. How do we know? What falsifiable success metric will confirm delivery after deployment?
5. What's the cost of being wrong? What user harm occurs if this feature misses the mark?

Third-Party Source Synthesis

This skill synthesizes patterns from three inspected third-party sources:

Boundary Rules

At-a-glance distinction: Brainstorm finds problems. Requirements-analysis diagnoses gaps. Product-validation tests value. Feature-ecosystem maps dependencies. Roadmap-maintainability scores health. This skill's unique role: "Before we build this, will users actually benefit?"

Entry Gate

Proceed when any of these are true:

• User asks "should we build this", "is this valuable", "what's the ROI"
• A feature design is ready for product-lens review before implementation begins
• Prioritization is needed across multiple features or requirements
• Success metrics need to be defined before development starts
• User describes a solution ("build a dashboard") without articulating the problem
• A coordinator skill (hm-coordinating-loop) routes to this skill during planning phase

Do NOT proceed when:

• No requirements or feature ideas exist yet → route to hm-brainstorm
• Requirements exist but need gap diagnosis → route to hm-requirements-analysis
• Features are already prioritized and need dependency mapping → route to hm-feature-ecosystem
• The question is purely about long-term code health → route to hm-roadmap-maintainability
• The user explicitly says "just build it, I know what my users want" → accept and move to implementation with a note

Main Workflow: 4-Phase Product Lens

Follow phases in order. Complete each before proceeding to the next.

Phase 1: Problem Articulation

Objective: Establish WHAT user pain exists and WHO experiences it — before discussing any solution.

1.1 Extract the Problem From the Solution Description

When users describe solutions ("build a dashboard with 6 widgets"), apply the anti-solution-check from references/problem-vs-solution.md:

1. Rephrase the requested feature as: "The user described building [X]. What problem does [X] solve?"
2. Ask: "Who has this problem? How many of them? How severe is it today?"
3. Ask: "What do users do today to work around this problem? What's the cost of that workaround?"
4. Classify: Validated problem (evidence of real pain) vs. Unvalidated problem (assumption without evidence)

If the problem is unvalidated, recommend user research before proceeding. Do not continue to scoring.

1.2 Identify Target User Segments

For each feature or decision under review:

Record results. Each feature must have at least one identified user segment.

1.3 Pause for Confirmation

Restate the problem in user terms:

**User Problem Summary:**
- **Segment:** [who]
- **Problem:** [what pain they experience]
- **Scope:** [how many users, how often]
- **Current cost:** [workaround effort, error rate, abandonment rate]

Before we evaluate solutions — does this accurately describe the real user situation?

Wait for confirmation. If the user cannot confirm the problem description, stop and recommend user research.

Phase 2: Impact Quantification

Objective: Score the feature's potential user impact using RICE methodology (Reach × Impact × Confidence / Effort). Reference: references/user-impact-scoring.md.

2.1 Score Each Dimension

For each feature or decision:

Scoring ground rules:

• Reach: Use actual user counts when available. 10 if every user benefits, 1 if only edge cases.
• Impact: 3 = transforms daily workflow. 2 = significant improvement. 1 = noticeable. 0.5 = minor. 0.25 = barely perceptible.
• Confidence: 1.0 = backed by analytics data. 0.8 = strong qualitative evidence. 0.5 = informed estimate. 0.2 = pure guess.
• Effort: Estimate in person-weeks. Convert to score as max(0.25, 10 / effort_weeks). A 4-week feature scores 2.5; a 12-week feature scores 0.83.

Compute RICE score: RICE = (Reach × Impact × Confidence) / Effort_weeks

Alternatively, use ICE (Impact × Confidence × Ease) for rapid triage when precise effort estimates are unavailable.

2.2 Create a Value-Effort Matrix

Plot features on a 2×2 grid:

High Value ────────────
│                      │
│   INVEST             │   SHIP NOW
│   (High value,       │   (High value,
│    high effort)      │    low effort)
│                      │
│   KILL               │   LOW-HANGING
│   (Low value,        │   (Low value,
│    high effort)      │    low effort)
│                      │
└──────────────────────
     Effort →

For each feature, classify its quadrant and recommend: Ship now, Invest (worth the effort), Low-hanging (do if spare capacity), Kill (don't build).

2.3 Prioritize by RICE Score

Rank features by RICE score. Present a sorted table:

| Rank | Feature | Reach | Impact | Confidence | Effort (wks) | RICE | Quadrant |
|------|---------|-------|--------|------------|--------------|------|----------|
| 1 | [Name] | 8 | 2.0 | 0.8 | 3 | 4.3 | Ship Now |
| 2 | [Name] | 6 | 1.5 | 0.6 | 5 | 1.1 | Invest |
| 3 | [Name] | 3 | 0.5 | 0.4 | 10 | 0.06 | Kill |

Phase 3: Success Metric Definition

Objective: Define falsifiable success metrics BEFORE implementation begins. Reference: references/success-metrics.md.

3.1 Define Metrics for Each Feature

For every feature with a RICE score ≥ threshold (default: 1.0), define:

3.2 Validate Metrics Are Falsifiable

Run this test on every metric:

• Can the metric be measured with existing instrumentation?
• Is the baseline known? If not, flag: Metric requires pre-launch instrumentation.
• Is the target specific and numeric? "Better" or "faster" fail this check.
• Is there a counter-metric to detect unintended harm?
• Can the metric be measured within the defined window?
• Is the minimum detectable effect realistic given sample size?

If any metric fails falsification, flag it and define a replacement before proceeding to Phase 4.

3.3 Define Product Success Gates

Create a validation gate for post-launch:

## Product Validation Gate — [Feature Name]
- **Launch criteria:** All metrics instrumented and baselines captured.
- **1-week check:** Early signal detection. Pause and investigate if counter-metric degrades.
- **30-day check:** Full measurement window complete.
  - If target met → SUCCESS. Feature is validated.
  - If target not met but trending positively → EXTEND. Monitor for 15 more days.
  - If flat or negative → ROLLBACK or ITERATE. Feature did not deliver value.

Phase 4: Stakeholder Communication

Objective: Translate technical decisions into product/business language for stakeholders. Reference: references/stakeholder-communication.md.

4.1 Frame Technical Trade-Offs as Product Decisions

Every technical trade-off has a product consequence. Translate:

4.2 Produce a Decision Brief

For major architectural decisions, produce a structured brief:

1. Decision: What was chosen (1 sentence)
2. User impact: What users experience differently (2-3 sentences)
3. Alternatives considered: What else was evaluated and why rejected (bullet list)
4. Risk to users: What could go wrong and how it's mitigated (2-3 sentences)
5. Success measurement: How we'll know it was right (1 sentence + metric)

4.3 Cross-Stage Application Check

Apply the product lens at each development stage:

Decision Tree

Is there a validated user problem statement?
  YES → Are there multiple features/requirements to prioritize?
    YES → Apply RICE scoring (Phase 2) → Rank → Proceed
    NO → Apply anti-solution-check (Phase 1) → Define success metrics (Phase 3) → Proceed
  NO → Can we articulate the user problem in one sentence?
    YES → Write it down → Validate with user → Proceed
    NO → Route to hm-brainstorm for user needs discovery

Is a success metric defined for this decision?
  YES → Is it falsifiable (numeric target, known baseline)?
    YES → Proceed to stakeholder communication (Phase 4)
    NO → Define falsifiable metric (Phase 3) → Re-check
  NO → Define falsifiable metric (Phase 3) → Re-check

Routing Table

Gate System

Validation Checklist

Before routing to the next skill or proceeding to implementation:

• Every feature has a validated user problem statement (Phase 1)
• RICE scores are computed and features are ranked (Phase 2)
• Every feature ≥ threshold 1.0 has falsifiable success metrics (Phase 3)
• Counter-metrics are defined to detect unintended harm (Phase 3)
• "Kill" quadrant features are explicitly recommended for removal
• Major architectural decisions have a stakeholder decision brief (Phase 4)
• Launch validation gate is defined with time-boxed checkpoints (Phase 3.3)

Anti-Patterns

Self-Correction

When anti-solution-check fails (building the wrong feature well)

Detection: RICE score is high, all metrics defined, stakeholder brief produced — but the problem statement was never validated. Phase 1 was skipped or rubber-stamped. No user segment identified with real evidence. Recovery: Halt scoring and metric work. Return to Phase 1.1. Ask: "Who actually reported this problem? When did they report it? What were they trying to do?" If no evidence exists, recommend user research before proceeding. Do not score features for problems nobody has confirmed.

When RICE scores are miscalibrated

Detection: All features score within 10% of each other. Confidence is uniformly 0.8 without cited data. Effort estimates are round numbers (2, 4, 8 weeks) without breakdown. Impact scores cluster at 1.5–2.0 with no justification differentiation. Recovery: Apply the scoring ground rules explicitly. For each dimension: (1) Force Rank features instead of absolute scoring — relative ordering exposes inflation. (2) Demand evidence for any Confidence ≥ 0.8: cite analytics, user research, or team data. (3) Break effort estimates into sub-tasks — "4 weeks" becomes "API design (3d) + implementation (5d) + testing (4d) + review (2d)." If estimates still cluster, the scoring is not discriminating — redesign the evaluation criteria.

When stakeholder needs were assumed without validation

Detection: Decision brief describes "users" or "stakeholders" without naming specific segments. Product framing uses generic language ("improves the experience") instead of segment-specific impact. No stakeholder was consulted before the brief was produced. Recovery: Before producing any Phase 4 output, ask: "Have we confirmed these assumptions with [specific stakeholder role]?" If no, flag the decision brief as DRAFT — requires stakeholder validation. Do not route to implementation. Add a mandatory checkpoint: the brief must be confirmed by at least one stakeholder representative before any code is written.

When metrics measure what's easy, not what matters

Detection: Success metrics are all instrumentation-convenient (page views, click rates, API latency) while the actual user problem is qualitative (trust, comprehension, workflow friction). Counter-metrics are absent. The minimum detectable effect is set to match existing variance rather than user-meaningful improvement. Recovery: For each metric, ask: "If this metric moved by the target amount, would a user notice and care?" If the answer is "not sure" or "not really," replace the metric. Prioritize outcome metrics (task completion, error recovery, time-to-value) over output metrics (page views, button clicks). Always pair with a counter-metric that detects harm. If no meaningful metric exists, the feature may not be worth building — flag for reconsideration.

Files