product-thinking

name	product-thinking
description	Product-need reasoning lens for "make something people want" — loaded by questioner, design-author, and structure-planner to validate user demand while framing, designing, and slicing scope
user-invocable	false

Product Thinking

A reasoning lens, not a gate. It produces no artifact of its own and blocks nothing. It shapes how the pre-implementation agents frame, design, and slice scope so that the work is something real people actually want.

Core Lenses

Four lenses sharpen every framing, design, and slicing decision:

• Demand evidence over assertion: Ask what signal says a real person wants this — not whether it is technically possible or interesting to build. A clever capability nobody asked for is still waste.
• Smallest thing people want: Prefer the thinnest version that delivers real value, and resist speculative scope and gold-plating. Extra surface area is cost you pay before you have learned whether anyone wants it.
• Build for someone specific, not nobody: Name the actual user a change serves. A feature with no identifiable user is a red flag to surface, not a detail to gloss over.
• Talk-to-users mindset: Treat the user's stated intent as a proxy for real demand, and explicitly surface where an assumption is standing in for validation rather than silently accepting it as fact.

When Framing the Task

Questions to sharpen the inferred goal and acceptance signals you write into task.md:

• Who specifically is this for? Identify, if knowable, who the work serves — an actual person or role, not "users" in the abstract.
• What signal would tell us they want it? Identify the observable demand signal that the acceptance criteria can stand on.
• What is the smallest version that delivers that? Frame the goal around the thinnest outcome that would satisfy the named person.

These lens questions shape only how the questioner frames the inferred goal and acceptance signals — never what gets researched or what goes into questions.md. (The goal stays out of questions.md by design.)

When Designing

Questions to apply while choosing an approach and writing ## Decisions made and ## Out of scope:

• Does this decision serve a real user need or a hypothetical one? Tie each decision back to the named user, or surface it as an open question.
• Where is an assumption standing in for demand? Call out the places where "users will want this" is unvalidated, rather than burying it.
• What is the thinnest design that delivers the wanted outcome? Prefer the simplest approach that satisfies real demand over the most complete one.

When Slicing

Questions to apply while ordering slices:

• Does slice 1 ship something a real person would want, or only infrastructure? The first slice should deliver value, not scaffolding.
• Is any slice building for nobody? A slice with no identifiable user is a signal to cut or re-order.
• Can we cut scope to the smallest wanted thing? Trim slices toward the thinnest version that delivers real value.

Lens, Not Dogma

This lens informs judgment; it never blocks the pipeline. Do not manufacture user-research ceremony where the user's stated intent already answers "who wants this." On an empty or trivial task, the right move is to apply judgment and ask nothing extra. The point is to keep "do real people want this?" in view — not to add ritual.