1.1.1 - If You Can't Name the User, You're Guessing What They Want

Outcome

Get the user right and every later decision gets easier. Scope, priorities, success criteria, what to leave out and the prompts you give AI all flow from it. If the user stays vague, every decision gets softer. AI then generates plausible options for an abstract audience instead of helping solve one real problem for one real person.

User definition

Can we name the user clearly before we decide what to build?

The call

Name the user first. Otherwise AI speeds up guesswork instead of solving a real problem.

What you are making

You are making your user definition: a short text file called user.md that you keep in your project and give to your AI as the brief. It is just three lines:

User:    [one real person]
Trigger: [what starts their need]
Outcome: [what they want to reach]

Your AI builds from these three lines, so getting them right up front is what makes the result hold up instead of breaking on the first change.

How to do it

1. Write your three lines using the template above.
2. Sharpen them with AI until two people would make the same decision from them.
3. Save the three lines as user.md and use it as your brief from here on.

Prefer to let your AI do this with you? The next section shows how, with the exact prompt for ChatGPT or Claude.

Sharpen the user definition with AI

This is a Shape idea, so the AI move is to Sharpen the user definition: run your draft through the prompt below until two people would make the same decision from it. Build and Launch ideas have their own AI moves, building and running the code.

New here? Let your AI do this with you. Paste your problem into Guide me and it builds a prompt that walks you through this in ChatGPT or Claude. You do not need to know how to prompt.

Prefer to drive the AI yourself? Give ChatGPT or Claude this page and ask it to help. For skill.txt, the Claude Code plugin and other ways in, see how to use vibe2value.

Or copy this prompt into AI chat, replace the bracketed lines with your real user definition and keep the instruction exactly as visible here. It refines your three lines until two people would make the same product decision from them.

There are six ways to work with AI across a build. This idea's AI moves are noted above. See Working with AI for all six and where each fits.

The same idea on a recipe card

Imagine a recipe that just says "cook something for hungry people." It tells the cook nothing. How many plates? How spicy? Any allergies? Now imagine it says "cook for my niece, who is vegetarian and arrives starving after a long drive and wants something warm and filling." That tells the cook exactly what to make. Two cooks reading it would both make a hearty veg stew, not a light salad.

Your user is the person you are cooking for. Name one real person (the niece), what made them hungry (a long drive) and what they want (something warm and filling). Get those three right and two people would build the same thing from them, the same way two cooks would make the same dish.

The recipe card is just a simple example, using everyday cooking ideas everyone understands, to make the concept clear. See the recipe card.

What it really means

A user definition is not a market segment. It is one real user, the trigger that starts their need and the outcome they are trying to reach. Until you can state all three in plain language, the brief is too soft. AI can generate options, but it cannot choose the right boundary without a clear user.

Make the user definition concrete

Compare the broad version with a version you can actually test.

• Too vague: This is for people who want to search the web with AI.
• Concrete enough to test: This is for a content creator who manages a website and needs to find gaps in what they have published so they can decide what to write next.

The second version lets two people make the same product decision from it.

Check the user definition

• Pass: You can say who the user is, what starts the need and what result they are trying to reach.
• Fail: The statement still sounds like a broad audience or a generic need.

Do not move into feature, scope or prototype work until this passes.

Write it down

Your user.md is a real file in your project. The AI forgets everything between sessions. It reads this file each time to pick up what you already decided, on this idea or another part of the build. Write it down once instead of explaining it again.

knowledge-base/shape-build-launch/shape/user.md is just a suggested name and place for this information. The name and the location are just how we organise this type of documentation, not something you have to follow. Call the file and put it wherever suits your project. What matters is that it is written down in a format that is easily understood by both people and the AI.

The .md ending is markdown, a plain text format often used for documents kept in a code repository like GitHub. It is just the common way people store this kind of writing alongside their code.

Writing it down is how you keep good context for your AI. See Keep the signal, not the noise for why this matters across a whole build.

When there is more than one user

Not every product has a single user. When a system serves more than one side, each side needs its own user definition or the one you write will quietly exclude the other. More on this in Multi-Sided Systems Blur Faster.

Risk and mitigation

• Risk: The user keeps being described as a generic audience, so AI-generated options feel productive while pushing the product toward ambiguity.
• Mitigation: Require one named user, one concrete trigger and one measurable outcome before approving new scope. If a feature cannot be explained through that lens, it does not move forward.

Key takeaway

Do not move forward until you can say who the user is, what starts the need and what result they are trying to reach.

How to document your user definition

Once your three lines are sharp, write the user definition up in full so your AI has the whole picture: the answer, why you believe it, what you are optimising for, where you might be wrong and the standing instruction it should follow. Keep it in a file with your project like this.

# User definition

## Answer
User: [name one real user]
Trigger: [what starts the need]
Outcome: [what they are trying to reach]

## Evidence
Why you believe this. Conversations, examples, tickets, your own experience.

## Decision
What you are optimising for and what you are saying no to.

## Risk
Where you might be wrong and what would tell you.

## AI instruction
The standing note your AI reads on this project.

Here is one filled in so you can see what good looks like, grounded in the recipe card idea from earlier.

## Answer
User: My niece
Trigger: She arrives starving after a long drive
Outcome: Something warm and filling to eat

## Evidence
The last three visits she turned up late, tired and hungry and went straight for the fridge. She never wants to wait or cook.

## Decision
Optimising for warm and filling. Saying no to light, healthy, quick or fancy. One hearty bowl beats three clever small plates.

## Risk
She might have eaten on the road and want something light. If she says she is not that hungry when she arrives, switch to a smaller dish.

## AI instruction
Cooking for my niece, who arrives starving after a long drive and wants something warm and filling. Keep every choice warm and filling, not light or fancy. If that changes, check with me first.

Common questions

1. This feels over my head. Is it even for me?
   You do not need to be technical for this step. Naming your user is a plain decision about a real person, not code. If you can describe who you are trying to help, you are already doing it. More in Over my head and I don't know where to start.
2. I just want to start building. Do I need to do this first?
   Yes. Skip it and the AI builds for an average nobody, then breaks the moment you change something. Ten minutes now saves the rebuild, which is the warning in AI did the easy part.
3. I am building this for myself. Am I the user?
   You can be. Write yourself down as one real user, then check later whether the people you want to reach share the same need.
4. Can't the AI just work out the user for me?
   It will guess one from patterns. It cannot know who you are trying to help, so you name the user and let the AI sharpen it. The AI amplifies your direction, it does not set it, as in If AI Is Your Guardrail, You've Already Lost.
5. Is this just a persona with a new name?
   No. A persona is a made-up average. This is one real person, sharp enough that two people would build the same thing.
6. What is the difference between the user and the customer?
   The customer pays. The user feels the need. Build for whoever hits the trigger, even when they are not the same person.
7. Do I have to interview real people first?
   No. Start with your best guess named as one person. Interview later to check it.
8. My users are businesses, not people. Who is the user?
   A business does not feel anything. Name the person inside it who hits the trigger, like the office manager, not the company.
9. What if I am building a site rather than an app? Who is the user then?
   The person who will read a post and open an email, not "my audience". Name the one who has the problem your writing answers, because that is who decides what to write about and what to leave out. That is the first move in Your Ghost site.
10. My user and my paying customer are different people. Which one do I name?
    Name the one who feels the need, then note who pays. In a product the two often split: the person using it every day is not the one signing off the invoice. Build for the trigger, sell to the signature. Build your product starts from that same shaped idea.

What now?

Apply it. Guide me turns what you are building into a prompt that walks you through this idea.

Get all 27. The guide is a free coffee-length read with the whole method. Join free and it is yours to download.

Get a hand. Work with me and we will work out together what is worth doing. The first conversation is free.