1.1.1 - If You Can’t Name the User, You’re Guessing

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.

Why it matters

If the user stays vague, every decision gets softer. Scope expands, priorities drift and AI generates plausible options for an abstract audience instead of helping solve one real problem for one real person.

Explainer

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.

How to use AI for the user definition

• AI chat: Rewrite the user definition until you can state all three parts clearly.
• vibeCoding: Build the thinnest flow that tests this user definition in practice before broader build work.
• AI-assisted coding: Carry the same user definition into implementation and review so the live system keeps the same decision.

Sharpen the user definition

Copy this prompt into AI chat, replace the bracketed lines with your real user definition and keep the instruction exactly as visible here.

You are checking whether this user definition is clear enough before you move forward.

Constraint:
The user definition must be specific enough that two people would make the same product decision from it.

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

Task:
Decide whether this user definition is specific enough to guide the next decision. If it is vague, rewrite it so two people would make the same decision from this user definition.

Check:
- Would two people interpret this the same way?
- Does it stay concrete enough to guide the next step?
- Does it meet this bar: You can say who the user is, what starts the need and what result they are trying to reach.

Return:
- A corrected user definition
- A short explanation of what was vague

Evaluation

Before accepting the result, check whether two people would make the same next decision from it.

Example

To help you work through this, here is a real example. StartWithYourContext is an AI search tool built as part of the vibe2value project. Here is how its user definition was written using the three parts:

• User: A content creator who manages a website and publishes regularly.
• Trigger: They need to find gaps in what they have already published so they can decide what to write next.
• Outcome: A shortlist of new page ideas grounded in what already exists on the site, not generic content advice.

This definition is specific enough that two people would make the same product decision from it. It names who the user is, what starts the need and what the result looks like.

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.

Multi-sided worked example

For example, StartWithYourContext looks like one product, but the user definition splits into two:

• Content creator: Needs relevant search results shaped by what they have already published.
• Developer: Needs a clean integration across the application stack.

Both are real users with different triggers and different outcomes. If only one is named, the other side gets designed by accident.

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.

Work through this in a workshop

If your user definition is still unclear, bring it to a free weekly workshop. Bring the messy part of your AI-assisted build and leave with a clearer next step. In some sessions, we walk through practical examples on the Cloudflare Workers stack to show how a rough idea turns into something that actually runs.

Where is the user still vague?

What part of your current brief still describes a generic audience rather than one real user with one trigger and one outcome?