Shape a feature or problem before implementation. Use this when the request is still fuzzy, when several solutions are possible, or when execution risks outrunning product clarity.
Installs into .claude/skills of the current project.
Are you the author of Product Think?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/stella-product-think)
---
name: product-think
description: "Shape a feature or problem before implementation. Use this when the request is still fuzzy, when several solutions are possible, or when execution risks outrunning product clarity."
argument-hint: "[feature idea or problem statement]"
---
# Product Think
Shape a feature or problem before implementation. Use this when the
request is still fuzzy, when several solutions are possible, or when
execution risks outrunning product clarity.
## Arguments
$ARGUMENTS: feature idea, problem statement, or change request.
## Interaction Mode
Default to one coherent pass after confirming the problem statement. Do not stop
after every step for ceremonial approval. Pause only when the user's answer would
materially change who the product serves, the product boundary, or the
recommended direction. Do not make the user answer questions the repository or
evidence can resolve. Lead with discoveries, not step narration.
## Instructions
1. **Clarify the problem first**:
- who is affected?
- what pain or friction exists today?
- why does it matter now?
2. **Separate problem from solution**:
- write down the user need
- write down the proposed solution
- check whether the solution actually addresses the need
3. **Define outcome, not just output**:
- what should be better if this works?
- what user or business behavior should change?
4. **State constraints**:
- technical constraints
- organizational constraints
- compliance or trust constraints
- timeline constraints
5. **Explore options**:
- simplest viable option
- stronger but more expensive option
- what not to build yet
6. **Make tradeoffs explicit**:
- speed vs correctness
- breadth vs depth
- automation vs control
- flexibility vs clarity
7. **Define scope**:
- in scope
- out of scope
- follow-up ideas that should not block the first version
8. **Define success**:
- what would we measure?
- what would we observe qualitatively?
- what would count as failure?
9. **Produce a short product brief** in prose or markdown, with:
- problem
- user
- goal
- options considered
- recommendation
- risks
- success signal
10. **Only move to implementation planning after this is coherent**.
