Product Strategy Review
Use this skill before product-requirements when the main risk is building the wrong thing rather than implementing it incorrectly. Preserve the user's ownership of product decisions; challenge assumptions without turning the review into a pitch or silently changing the idea.
Choose the Review Depth
- Discovery: the idea is early, the target user or problem is uncertain, or demand has not been tested.
- Challenge: a proposal exists and needs an adversarial premise, scope, and alternative review.
- Focused: the user named one decision; investigate only the evidence needed for that decision.
Do not force a long interview when repository context or supplied research already answers a question. Ask only questions whose answers can change the recommendation.
Investigate
- Identify the named user, their job to be done, the triggering situation, and the cost of the current problem.
- Establish the status quo: workaround, incumbent product, manual process, or choosing not to act.
- Separate evidence from inference. Label important claims as
observed, user-stated, inferred, or unknown.
- Test demand quality: frequency, urgency, existing spend or effort, access to users, and evidence stronger than compliments.
- Find the narrowest wedge that produces a complete outcome for a specific user without requiring the full vision.
- If the current market, competitors, pricing, or platform behavior affects the decision, verify it from current primary sources.
Challenge the Premises
Create a short premise ledger for assumptions that could invalidate the proposal:
| Premise |
Current evidence |
What would falsify it |
How to test cheaply |
Include product, distribution, workflow, technical, trust, and operational premises only when material. Do not manufacture objections for completeness.
Generate at least two materially different paths when alternatives are useful. Consider a smaller wedge, integration, service/manual approach, buying or extending an existing tool, and doing nothing. Cosmetic variations of the same implementation are not alternatives.
Decision Brief
Return:
- problem, target user, and triggering context;
- demand evidence and the strongest uncertainty;
- status quo and why it is or is not sufficient;
- critical premises and cheapest validation experiments;
- alternatives with trade-offs;
- recommended wedge, explicit non-goals, and success signal;
- open decisions that require the user rather than the agent.
If the recommendation is to proceed, hand the accepted direction to product-requirements. Do not implement, file issues, contact users, spend money, or make external changes unless separately requested and authorized.
1---2name: product-strategy-review3description: Challenge an unvalidated product idea using demand evidence, target users, assumptions, alternatives, and the smallest valuable wedge. Do not use after scope is accepted.4---56# Product Strategy Review78Use this skill before `product-requirements` when the main risk is building the wrong thing rather than implementing it incorrectly. Preserve the user's ownership of product decisions; challenge assumptions without turning the review into a pitch or silently changing the idea.910## Choose the Review Depth1112- **Discovery:** the idea is early, the target user or problem is uncertain, or demand has not been tested.13- **Challenge:** a proposal exists and needs an adversarial premise, scope, and alternative review.14- **Focused:** the user named one decision; investigate only the evidence needed for that decision.1516Do not force a long interview when repository context or supplied research already answers a question. Ask only questions whose answers can change the recommendation.1718## Investigate19201. Identify the named user, their job to be done, the triggering situation, and the cost of the current problem.212. Establish the status quo: workaround, incumbent product, manual process, or choosing not to act.223. Separate evidence from inference. Label important claims as `observed`, `user-stated`, `inferred`, or `unknown`.234. Test demand quality: frequency, urgency, existing spend or effort, access to users, and evidence stronger than compliments.245. Find the narrowest wedge that produces a complete outcome for a specific user without requiring the full vision.256. If the current market, competitors, pricing, or platform behavior affects the decision, verify it from current primary sources.2627## Challenge the Premises2829Create a short premise ledger for assumptions that could invalidate the proposal:3031| Premise | Current evidence | What would falsify it | How to test cheaply |32|---|---|---|---|3334Include product, distribution, workflow, technical, trust, and operational premises only when material. Do not manufacture objections for completeness.3536Generate at least two materially different paths when alternatives are useful. Consider a smaller wedge, integration, service/manual approach, buying or extending an existing tool, and doing nothing. Cosmetic variations of the same implementation are not alternatives.3738## Decision Brief3940Return:4142- problem, target user, and triggering context;43- demand evidence and the strongest uncertainty;44- status quo and why it is or is not sufficient;45- critical premises and cheapest validation experiments;46- alternatives with trade-offs;47- recommended wedge, explicit non-goals, and success signal;48- open decisions that require the user rather than the agent.4950If the recommendation is to proceed, hand the accepted direction to `product-requirements`. Do not implement, file issues, contact users, spend money, or make external changes unless separately requested and authorized.
egeetas