Problem Framing
Turning a vague goal into an explicit problem: what is actually being asked, what must be true, what can be ignored for now, and goal against implementation.
"Build an e-commerce platform" is a bad frame; "customers browse, add to cart, pay, and admins manage products" is better; adding what must never happen, what is outside the system and what V1 leaves out is better still. The frame is the first artefact.
"I want to build something like Spotify" contains a problem, and a fixed sequence of questions extracts it: who, what they do, the one workflow that matters, the data, the boundaries, what can wait, what you do not know. The output is a first slice, not a design.
"The user can pay" is a goal. "Stripe Checkout" is an implementation. Requirements that arrive as implementations lock in decisions nobody made; the move is to separate the two so the goal can be met by the best implementation, not the first one named.
Say the problem back in your own words — to the requester, to a colleague, to the page — before solving it. The restatement is where misunderstandings surface, and it is the cheapest experiment in the domain.
For "checkout works" to be true, a set of smaller things must each be true: the cart total is right, stock exists, payment succeeded exactly once, an order was recorded. Decompose the frame into conditions, and each condition is a test and a place a design decision lives.
A frame lists everything the system will need; V1 needs a fraction of it. Deciding what to ignore — and writing down why, and what would bring it back — is how a project gets small enough to start without forgetting what it left out.