# 1 · Who: the person it's for You can't judge a product without knowing whose life it's meant to change, and requests rarely say. "An app for tracking expenses" could be for a freelancer getting ready for tax, a couple splitting rent, or a finance team approving claims. Those are three different products. When nobody says, you build for "users", and the product fits no one well. This part is about the people. The problem comes in `2-problem.md`. --- ### W1 · One person, one situation **Rule:** Describe who it's for as one specific person in one specific situation: what they do, where they are, what device they're on, how often they'll use it, and what they're in the middle of. "A freelance designer, on her laptop at the end of the month, sending four or five invoices", not "freelancers", and never "everyone". If there are several kinds of user, pick the one whose success matters most in this version and say who comes second. Then say who it's **not** for. **Why:** Every product decision depends on who is looking: what goes first, how much to explain, what to leave out. A product for everyone makes each of those decisions by compromise, and nobody finds it made for them. **Agent trap:** writing "users", "small businesses" or "anyone who wants to…" in the brief, or listing five audiences so no one is left out. With "everyone" as the user, every feature seems worth building, because somebody in "everyone" might want it. **Check:** would two people reading your description picture the same person? Can you name one kind of person this version is not for? ### W2 · Find the job they're hiring it for **Rule:** Write what the person is trying to get done, in their situation, in this form: "When , I want to , so I can ." Add what they want to feel or avoid when it matters ("without the client thinking I'm disorganised"). The job is about their life, not your product: no feature names in it. **Why:** People don't want an invoicing app; they want to get paid without chasing. The job stays the same when tools change, so it tells you what matters and what's decoration. It also tells you when they'll judge the product: at the moment the job is done, or isn't. **Agent trap:** writing the job as the feature ("I want to create invoices"). That only restates the request and can't tell you what to leave out. Or skipping the feeling when it's the real job: a parent booking a babysitter is buying trust more than a time slot. **Check:** does your job statement contain no feature names? Could something other than your product do the job (a phone call, a spreadsheet)? If so, it's a real job, and those other ways are what you're up against (W3). ### W3 · Know what they use today **Rule:** Find out how the person does the job now: an app, a spreadsheet, a WhatsApp group, a paper notebook, a colleague they ask, or nothing at all. That's the real competitor. Note what it does well, what annoys them about it, and what they'd lose by switching: their existing data, their habits, and other people who'd have to switch too. **Why:** People switch only when the new way is clearly better at the part that hurts, by enough to be worth the effort of moving. Something a little nicer than the spreadsheet loses to the spreadsheet, because the spreadsheet is already there and everyone knows how it works. **Agent trap:** assuming nothing exists today, so the product fills an empty space. Or comparing only with well-known products you've read about, when the person actually uses a shared sheet and their memory. A common result: they have 200 clients in a spreadsheet, and the product starts empty with no way to bring them in. **Check:** can you name the current way, one thing it does well that your version must also do, and what it takes to move their existing things over? ### W4 · Ask or mark it; never invent the user **Rule:** Everything you write about the users must come from the person, their files, or a source you can name. If you don't know, ask (within the question budget in `START.md`), or write it as a marked assumption: "Assumed: mostly on phones." Never write personas with invented names and ages, made-up interview quotes, survey results, percentages, market sizes, or "research shows" claims. **Why:** Invented research looks like evidence. The person, their team or their investor will make decisions on it, and the product gets shaped for someone who was never asked. A clearly marked guess can be corrected in one reply. A persona with a name and a backstory gets believed. **Agent trap:** filling the shape product documents usually have: "Meet Sarah, 34, marketing manager, frustrated by…", "73% of freelancers struggle with invoicing." Both sound plausible and both are fiction. The same goes for testimonials, user counts and logos on landing pages (working with your human, Q3; UI design, A7). **Check:** for every claim about users, can you point to where it came from? Is every claim without a source labelled "assumed"? Is there any number you can't source? Remove it. ### W5 · The person who asked is not always the user **Rule:** Work out who's who: the person you're working for, the person who pays or decides, and the person who uses it every day. They may be one person (a founder building a tool for themselves) or three (an agency, its client, and the client's customers). When they differ, build for the daily user's job and the decider's reason to choose it, and say where the two pull in different directions. **Why:** Products fail when they please the person in the meeting and not the person at the screen: a booking system the owner loves and the receptionist works around. The person who asked knows a great deal, but often describes what they want to see, not what the user needs to do. **Agent trap:** treating every preference of the person who asked as a user need: "show everything on the dashboard" because the manager wants to see everything, while the staff who use it all day need one list. Or the opposite: forgetting the admin who sets it up, who is also a user, of different screens. **Check:** can you name who uses it daily, who decides to choose or keep it, and who asked? Where their wants conflict, did you say so? --- ## Check - [ ] The person is one specific person in one situation, and you named who it's not for. - [ ] The job is written as "When…, I want to…, so I can…", with no feature names. - [ ] You know what they use today, what it does well, and what switching would cost them. - [ ] Every fact about users has a source; every guess is marked "assumed"; no invented personas, quotes or numbers. - [ ] You know who uses it, who decides, and who asked, and flagged where they differ.