Turn an Idea Into a Concrete Problem

Why this matters

"I want an app for my bakery" fails for the same reason in every tool: it describes nobody doing nothing in particular. The tool fills the vacuum with generic choices, you get a generic page, and the project dies in the gap between what you imagined and what appeared. The fix happens before the tool, on paper: name the person, name their struggle, name the smallest version that removes it. That sentence is the seed every later brief grows from, and writing it is the highest-leverage ten minutes in this program.

Concepts

Use the everyday analogy of a food order, but do not stretch it past its limit: like a kitchen, a tool builds what the ticket says. Unlike a kitchen, it cannot ask the customer what they meant. Your ticket must therefore carry three lines:

1. One user. Not "customers" or "people". One concrete person with a

name and a situation: "Aylin, who runs a neighborhood bakery and takes phone orders." If two different users need two different things, you have two projects; pick one for version one.

1. One job. The single task that hurts today: "taking Saturday orders

without writing them on paper scraps that get lost." A job is observable: you can watch someone do it badly today, which means you can check whether your app does it better tomorrow.

1. One first version. The smallest thing that does the job end to end:

"a page showing products, hours and the phone number, with a form that collects name, items and pickup time." Everything else (payment, accounts, delivery tracking) goes on a named later list, not into version one.

Write the problem in one sentence with this shape: "[User] struggles with [job] because [current workaround]; version one will [smallest fix]." Example: "Aylin struggles with Saturday phone orders because paper notes get lost; version one will collect name, items and pickup time in a form she can read on her phone." Read that sentence and notice what disappeared: the vague "app", the payment system, the customer accounts. What remains can be built this week.

Worked example

Real input: "I want a task app for students." Narrow it three times. First, the user: "Mert, a second-year student who forgets weekly assignments." Second, the job: "seeing this week's assignments in one glance on Sunday evening." Third, the version: "a page where he types assignments with dates and sees them sorted by date." The later list holds the rest honestly: repeating tasks, reminders, sharing with friends. Nothing is deleted; it is scheduled. An AI tool given the final sentence builds the right small thing. Given the original sentence it builds a generic todo clone nobody asked for.

Expected result: any idea you care about rewritten as one user, one job, one first version, plus a later list with at least three parked extras.

The common wrong move

Smuggling the whole vision into version one with words like "simple" or "basic": "a simple shop with just products, cart, payment, accounts and tracking." Adjectives do not narrow scope; lists do. If version one has more than three capabilities, it is version three wearing a disguise. Split it.

Lab and next step

Lab A04 takes a vague restaurant request and turns it into a structured brief plus a copyable prompt. Next, lesson 6 names the seven parts every good brief carries, so your one sentence grows into a complete specification.