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.