Purpose
Take a rough feature idea and run it through a disciplined validation pass — surfacing whether the user problem is real, whether evidence supports demand, what could make it hard to build, and the cheapest way to test the riskiest assumption — so PMs commit engineering time only to features that survive scrutiny.
When to Use
Invoke this skill when the user asks to:
- Validate or pressure-test a feature idea before building it
- Decide whether a feature request is worth adding to the roadmap
- Evaluate a stakeholder or sales-requested feature for real user value
- Triage a backlog of feature ideas and figure out which deserve discovery
- Prepare a feature for a prioritization or roadmap review meeting
- Identify the riskiest assumption behind a feature and how to test it cheaply
Inputs Required
Before starting, collect:
- The feature idea: 1–3 sentences describing what the feature does
- Target user: Which segment or persona this is for
- Problem it claims to solve: The user pain or job-to-be-done behind it
- Evidence so far: Any requests, support tickets, usage data, or interviews that prompted it
- Origin: Where the idea came from (customer ask, sales, exec, data, internal hunch)
- Strategic context: Current company/product priority this would support
- Constraints: Known tech, timeline, or resource limits
If evidence or strategic context is missing, flag the gap explicitly as a validation weakness rather than assuming it away.
Instructions
Step 1: Problem Clarity Assessment
Determine whether the feature is anchored to a real, specific user problem.
- Restate the problem as a job-to-be-done: "When [situation], the user wants to [motivation], so they can [outcome]."
- Score problem clarity: Strong (specific user, specific pain, evidence of frequency) / Moderate (plausible but unverified) / Weak (solution looking for a problem)
- Flag the solution-first trap: if the idea is described entirely as functionality with no underlying pain, name it.
- Identify who experiences this problem and how often — a rare problem for a niche segment is a different bet than a frequent one for the core base.
Step 2: Market & Demand Evidence
Grade the evidence supporting demand, not just the anecdote that sparked the idea.
- Classify each piece of evidence by strength:
- Strong: quantitative usage signals, multiple unprompted customer requests, willingness-to-pay signals, churn tied to its absence
- Medium: a handful of support tickets, qualitative interview mentions, competitor parity pressure
- Weak: single loud customer, exec opinion, "I think users would want this"
- Note the requester bias: features from sales/execs skew toward winning one deal, not serving many users — call this out if present.
- Identify whether competitors offer this and whether that's table stakes, a differentiator opportunity, or a feature-parity treadmill.
- State the demand verdict: is there evidence enough customers feel this pain to justify discovery?
Step 3: Feasibility Flags
Surface what could make this hard, risky, or expensive to build — before engineering does.
- Technical complexity: net-new system vs. extension of existing capability; dependencies on data, infra, or third parties
- Scope creep risk: does the simple description hide a much larger build? Name the hidden surface area.
- Maintenance cost: ongoing support, edge cases, and complexity this adds to the product permanently
- UX/cognitive load: does this add a setting/screen/concept users must learn? Features that complicate the core flow carry hidden cost.
- Reversibility: easy to remove later (low risk) vs. hard to walk back once shipped (high risk) Rate each flag Green / Yellow / Red with one line of reasoning.
Step 4: Strategic Fit
Check alignment beyond "would users like it."
- Does it advance the current top priority, or is it orthogonal?
- Does it serve the segment the company is trying to grow, or a segment being de-emphasized?
- Opportunity cost: what does building this displace? Name the most likely tradeoff.
- Fit verdict: On-strategy / Adjacent / Off-strategy.
Step 5: Identify the Riskiest Assumption
Name the single assumption that, if wrong, makes the whole feature a waste.
- Categorize it: Desirability (do users want it?), Viability (does it help the business?), or Feasibility (can we build it sustainably?).
- This becomes the target of the experiment in Step 6.
Step 6: Recommended Experiment
Propose the cheapest test that de-risks the riskiest assumption.
- Match the test to the assumption type:
- Desirability: fake-door test, painted-door CTA, prototype + 5 user interviews, smoke-test landing page
- Viability: pricing/willingness-to-pay interview, concierge MVP for a few accounts
- Feasibility: technical spike, time-boxed prototype
- Specify: what's being tested, the method, the success signal (a concrete threshold, not "people like it"), and the rough effort (hours/days, not a full sprint).
Step 7: Verdict
Deliver a clear recommendation:
- Build — strong problem, evidence, and strategic fit; proceed
- Test — promising but the riskiest assumption is unvalidated; run the experiment first
- Park — viable but not aligned with current priorities; revisit later
- Kill — weak problem or evidence; stop here and say why Be decisive. State the verdict in one line, then one paragraph of rationale.
Output Format
- Structure: Seven labeled sections in sequence, each with its scores/flags and a one-line takeaway; verdict stated upfront in a single bolded line
- Length: 700–1,000 words
- Format: Structured document — headed sections with scored sub-items and short reasoning; feasibility flags as a Green/Yellow/Red list
- Sections: Problem Clarity → Market & Demand Evidence → Feasibility Flags → Strategic Fit → Riskiest Assumption → Recommended Experiment → Verdict
- Tone: Senior PM reviewing a peer's idea — direct, evidence-demanding, constructively skeptical; not a cheerleader
Quality Checklist
Before delivering output, verify:
- [ ] The problem is restated as a job-to-be-done, not just a feature description
- [ ] Every piece of evidence is graded Strong / Medium / Weak — not lumped together
- [ ] Each feasibility flag has a Green/Yellow/Red rating with a reason
- [ ] Exactly one riskiest assumption is named and categorized (desirability/viability/feasibility)
- [ ] The experiment includes a concrete success threshold and a rough effort estimate
- [ ] A single clear verdict (Build/Test/Park/Kill) is delivered without hedging
Notes
- The most common failure mode is a feature with a vague problem and strong internal advocacy — be hardest on problem clarity when the evidence is just "an exec wants it."
- A "Test" verdict is not a soft no; it's the correct answer for most genuinely promising ideas, since the point is to validate before committing a sprint.
- When evidence is entirely qualitative, say so plainly — one loud customer is a signal to investigate, not a mandate to build.
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills