From a Vague Goal to an Explicit Problem
"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 situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
A goal has arrived as an ambition — "something like X" — rather than as a problem. What sequence of questions turns it into a problem you could start on, and what does the output look like?
A friend wants to build "something like Spotify, but for podcasts by small creators". You can picture the app. You cannot picture the first thing to build, and every attempt to start turns into a list of everything Spotify does.
Enumerate the reference product. Spotify has playlists, recommendations, offline mode, social sharing, artist pages; a feature list is concrete, and it turns an ambition into tasks. Copying the reference feels like the safe way to know what "done" looks like.
The list is Spotify's problem, not your friend's. Recommendations exist there because of a catalogue of millions; the creators here have a few dozen episodes each. Most of the list solves problems this product does not have.
- The list is Spotify's problem, not your friend's. Recommendations exist there because of a catalogue of millions; the creators here have a few dozen episodes each. Most of the list solves problems this product does not have.
- A feature list has no order. Everything on it is a noun and nothing says which one, if it worked, would mean the product works — so the first thing built is the easiest, and the thing the product is for is untested for months.
- The data and the boundaries are hidden inside features. "Offline mode" is a storage and licensing question; "creator pages" is a data-model question; neither is visible as a question when written as a feature.
- The unknowns arrive as blockers. Audio hosting, transcoding, and how a podcast feed even works are discovered when a task reaches them, and each one stops the task instead of starting a small experiment.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Run a fixed sequence of questions against the ambition, in order, and write down every answer as a plain sentence. What is it, in one paragraph? Who uses it? What does each of them do? Which one workflow, if it works end to end, means the thing works? What data exists, and what must persist? What is outside the system? What can be ignored in V1? What do you not know? The order matters: each answer is the input to the next.
- Translate the reference product's features into the questions they were answers to, then ask whether this product has the same questions. "Recommendations" answers "how does a listener find something in millions of tracks?"; here the question is "how does a listener find a creator they have heard of?", and the answer is a search box.
- End with two things only: the smallest slice that touches every layer of the core workflow, and the unknowns as questions with experiments. Not an architecture, not a feature list. The slice is what Monday is for; the questions are what the week is for (What to Build First).
- Treat everything else — the design, the stack, the second feature — as not yet decidable, and say so. The explicit problem is what makes those decisions possible; it is not the decisions.
The sequence, and why the order matters
Each question depends on the one before it, which is why the sequence is fixed. The failsBy column is what happens when a question is skipped — usually the next answer is guessed, and the guess is invisible until it is expensive.
- 1What is it?
One paragraph, in the friend's words, with no feature names.
fails by Taken as obvious; every later answer inherits a different picture per person.
- 2Who uses it?
The actors — usually two or three, never twelve.
fails by Guessed; the workflow is then built for the wrong person.
- 3What does each of them do?
Verbs per actor: upload, find, play, resume.
fails by Written as nouns from the reference product.
- 4Which workflow means it works?
One chain of verbs across actors (MVP Thinking).
fails by Chosen for ease instead of meaning.
- 5What data exists, what persists?
Entities named from the verbs (Entities From Requirements).
fails by A schema designed before the verbs are known.
- 6What is outside?
External systems, each a research item and a failure source.
fails by Discovered when the code reaches them.
- 7What can wait?
Not-V1 with reasons.
fails by Nothing waits; everything is V1; nothing ships.
- 8What do I not know?
Questions with experiments, riskiest first.
fails by Worries with no verbs, met as blockers.
The output is the last two rows plus a slice. Everything else on the page exists to make those two rows right.
The first slice, and what it does not prove
The slice is deliberately tiny and deliberately end to end. The interesting field is the last one: a slice that claims to prove the product would be a demo, and this one is honest that it leaves search, resume, accounts and scale untouched.
- Upload formAccepts a title and an audio file from the creator.
- APIReceives the file, stores it, records an Episode row with the storage location.
- StorageHolds the audio file; returns a playable URL.
- DatabaseCreator and Episode, with title and file reference.
- Player pageLists episodes by title; plays one with the browser's audio element.
The unknowns the sequence surfaced
None of these were visible in "something like Spotify". They appeared when the sequence reached "what is outside" and "what persists", and each is small enough to answer this week. The first one is answered by the slice itself.
- ✓Actors: creator, listener. Core workflow: upload → find → play.
- ✓Persist: Creator, Episode, audio file, PlaybackPosition.
- ✓External: audio storage, transcoding if needed, identity.
- ~Creators are few and known to the builder in V1; no sign-up flow is needed yet. To revisit before opening it up.
? Audio.
becomes Can the browser play the format creators actually upload, or does every file need converting first — and if so, before or after publishing?
experiment Upload the three formats the first creators use; try to play each in two browsers.
? Files are big.
becomes How large is a typical episode, and can a single request upload it, or does the upload need to be chunked or go directly to storage?
experiment Upload the largest real episode through the slice and observe what fails.
? Resume.
becomes Where is playback position stored so that a listener resumes on another device, and how often must it be written?
experiment Deferred to the second slice; write a one-line design and see whether it needs an account.
The first two unknowns are answered by building the slice with real files. That is the best kind of unknown: one the next step answers for free.
How to do it
Most important first.
- Write the ambition at the top. Answer the sequence in writing, one sentence per answer, refusing to skip: skipping "who uses it" is how the wrong workflow gets picked.
- Name the core workflow as a chain of verbs. For the podcast app: creator uploads an episode → listener finds the creator → listener plays the episode. If that chain works, the product exists.
- List the data the chain touches and mark what must survive a restart. Episodes and creators must; playback position probably should; a listener's search history need not, yet (What Must Persist).
- List what is outside the system and treat each as a research item: audio storage, transcoding, payments to creators, the identity provider (Where Does My System End?).
- Write "not V1" as an explicit list with a reason each, and write the unknowns as questions with experiments. Then name the first slice and stop (The Next Question).
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The podcast app, through the sequence. What: listeners play episodes published by small creators, and creators can see that they were heard. Who: listener, creator. Actions: creator uploads an episode with a title; listener searches a creator by name, plays an episode, resumes where they left off. Core workflow: upload → find → play. Data: Creator, Episode, the audio file, PlaybackPosition. Must persist: all four. Outside: audio storage and transcoding, identity. Not V1: recommendations, playlists, offline, comments, payments. Unknowns: how large is an episode and where does it live; does the browser play the uploaded format or must it be converted; how does resume work across devices.
- The first slice: one creator, one episode uploaded through a form, stored somewhere, listed by name, played in a browser. It touches upload, storage, the database, an API and a player, and it answers the format question by trying it. It does not touch search, resume or accounts, and it is a week, not a quarter.
- The store, as a check that the sequence generalises. "I want to build an online store" → customer and admin → browse, cart, checkout, pay; create products → core workflow browse → cart → pay → confirmation → Product, Cart, Order, Payment → payment provider outside → coupons and reviews not V1 → "who says an order is paid?" as the first unknown → product page as the first slice. Same questions, same shape of output, a different problem.
How you know it worked
What now exists that did not before, and what question you can now ask.
- The ambition has become a paragraph, two actors, a chain of verbs, a data list, a boundary list, a not-V1 list and a question list — and all of it fits on a page.
- The first slice is named, is small enough to build this week, and touches every layer of the core workflow.
- Every reference-product feature has been either translated into a question this product has, or dropped with a reason.
- The unknowns are questions with experiments, and the riskiest one is scheduled before the slice depends on it.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?Which chain of verbs, if it works end to end, means this thing exists?
- ?Which of the reference product's features answer questions this product actually has?
- ?What is the smallest slice that touches every layer of that chain, and what does it not prove?
- ?Which unknown would change the slice if answered — and is it scheduled first?
What can go wrong
- The sequence is run and the answers are invented. "Who uses it?" answered from imagination produces a listener who does not exist; the sequence needs the friend in the room.
- The output grows into a design. The data list becomes a schema, the boundary list becomes an architecture diagram, and the first slice waits for both. The sequence ends at a slice and a question list, deliberately.
- The reference product is dropped entirely. It carried real information — that listeners expect resume, that creators want to know they were heard — and the move is to translate its features into questions, not to ignore it.
- The core workflow is chosen for ease. "Creator uploads an episode" is a fine first slice and a poor core workflow, because a product where nobody can listen is not the product.
- A page of plain answers is less exciting to show a friend than a feature list that looks like Spotify, and the friend may hear "not V1" as a downgrade of their ambition.
- The sequence takes an afternoon and produces one slice; a feature list takes an hour and produces a backlog. The backlog looks like more.
- Translating reference features into questions requires understanding why the reference has them, which is research the copy-the-product approach skips.
- "The sequence is a form to fill in." It is a set of dependencies: the workflow cannot be chosen before the actors are known, the data cannot be listed before the workflow. Filling the boxes out of order produces a page that looks complete and is not.
- "The output should be a design." The output is the thing that makes a design possible. Designing before the explicit problem exists is how the podcast app gets a recommendation engine.
- "Reference products are a trap." They are a source of questions. Spotify's features are answers to real problems, and asking which of those problems this product shares is faster than discovering them from scratch.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe sequence of questions is the same for any ambition — an app, a service, an internal tool; what differs is how much of the reference product survives translation.
- TEAM-SPECIFICA solo builder can run the sequence in an afternoon and should resist making it longer; a team with a product owner should run it with them present, because the "who" and "core workflow" answers are theirs to give and the engineer's to question.
- ILLUSTRATIVEThe podcast app, the friend and the episode counts are invented; the sequence is the point, not the product.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The lab at /thinking/start runs exactly this sequence: enter "I want to build X", answer the nine questions, and receive a roadmap — with a warning if a technology was named before the problem.