Users, customers and the jobs they hire you for

Supports: Developer, week 2 (Know the people), first half of the 60-minute workshop. Time: about two hours.

1. Why this matters

“Who is the customer?” sounds like the easiest question in business. It is one of the hardest. In many products the person who uses the product is not the person who pays for it, and neither is the person who decides to buy. If you mix them up, you design for the wrong person, price for the wrong person and market to the wrong person. Your agents will then build a polished product that nobody signs for.

A Product Development Manager (PDM) has to be exact about people, because every later decision depends on them: which problem is worth solving, which epic comes first, which words go on the website and which feature is cut. Agents can implement a feature. They cannot tell you who it is for. If you tell them “for our users”, they will invent an average user, and the average user does not exist.

This lesson is short on method and long on thinking. By the end you will have a clear, written answer to “who are we building this for, and who are we not?”

What the PDM decides here

You decide	You may delegate to an agent	You verify	Other disciplines involved
Who the main user and customer are, what job they hire you for, and who you will not serve	Tidying a draft table; listing public facts about a market segment, with sources	Every claim about a group traces to an interview or a source you opened	Sales and marketing (who buys), support (who calls), finance (who pays), legal (who may use it)

2. Key ideas

Four kinds of person

Role	Question	TrailMug example
User	Who uses the product?	A commuter who swaps cups; a barista who scans them
Customer	Who pays?	The commuter pays a monthly fee; the café receives a fee
Partner	Who helps us deliver?	A café that accepts returned cups
Influencer	Who affects the decision without using or paying?	A workplace sustainability lead; a café’s food-safety adviser

One person can hold several roles. The commuter is both user and customer. The café owner is a partner and a customer of a different kind (she receives money from us, and may also pay for a premium listing later). A single product can have two journeys with two different people. If you find only one kind of person, ask whether you have missed another.

The B2B2C pattern

When a business pays and its consumers use the product, it is called B2B2C (business to business to consumer). A school buys a learning app for its pupils. A hotel buys a booking tool used by its guests. In B2B2C, the person who signs the contract and the person who clicks the buttons have different goals. You must understand both, or the buyer will say yes and the users will not touch it.

The job to be done

People do not buy products. They hire them to make progress in some part of their life. This idea is often called jobs to be done. A person who “buys a drill” is really hiring something to make a hole, and behind that, to hang a shelf, and behind that, to feel the room is finished. When you describe the job in the customer’s words, you stop arguing about features and start talking about progress.

A job statement has a simple form:

When [situation], I want to [motivation], so I can [outcome].

Write the job from interviews, not from your imagination. “When I am rushing to the train and want my coffee, I want a cup that is clean and does not leak, so I can get on with my day without feeling guilty.”

The most useful jobs have an emotional and a social side as well as a practical one. The commuter wants a clean cup (practical), wants to feel less wasteful (emotional) and does not want to look fussy at the counter (social).

Who you will not serve

A product that tries to serve everyone serves no one well. Write a we-will-not-serve list: groups you choose not to serve for now, and why. It is your most powerful tool for staying focused, and it protects your agents from building for edge cases. Examples: “event caterers”, “customers outside our delivery area”, “people who want one-off cups”. It is not a moral judgment. It is a choice about order.

How many personas?

Most products need two to four. Enough to cover the main user and the main customer, and not so many that nobody remembers them. NN/g explains that the scope of a persona (how broad or narrow it is) should match the decisions it supports. If the product has one clear user and one clear customer, two personas may be enough. The point of a persona is to help the team decide, not to be complete.

3. Step by step

Step 1: List everyone who touches the product

Open your product map and your interview notes. Write down every kind of person who uses, pays for, installs, supports, approves or is affected by the product. Include internal roles such as support staff, finance and the person who gets the 2am alert.

Step 2: Mark the role of each

For each kind of person, mark: user, customer, partner, influencer, internal. Ask for each, “Does this person ever change what we build?” If not, they are probably not a main person.

Step 3: Pick the main user and the main customer

Choose one of each. They may be the same person. Write one sentence why. If you cannot choose, you need more evidence, so add interviews to your plan.

Step 4: Write the job

Write the job statement for each main person, in their words, using quotes from your notes. If you do not have quotes, mark the job as a guess (G) and plan to learn it.

Step 5: Write the we-will-not-serve list

Write at least three groups you will not serve in this version, with one reason each, and the date you will review the list.

Step 6: Decide how many personas you need

Rule of thumb: one persona per main person. Write the number and the reason.

Step 7: Check the list with a person outside your head

Share it with someone who knows the customers (a sales colleague, a mentor, a partner). Ask: “Who have I missed?” Add what you learn.

4. Worked example: TrailMug

TrailMug is fictional; people and numbers are illustrative.

Everyone who touches the product:

Person	Role	Do they change what we build?
Commuter	User and customer	Yes
Café owner	Partner and customer (receives a fee)	Yes
Barista	User (scans and swaps cups)	Yes, for speed
Office sustainability lead	Influencer	Maybe: could bring a whole office
Food-safety adviser	Influencer	Yes: can block cafés
Support agent (internal)	Internal	Yes, for help pages

Main user and customer: the commuter is the main user and customer. The café owner is the main partner. The barista is a key user whose experience decides whether cafés keep doing it.

Jobs, in their words (from interview notes):

Commuter (C3): “When I am rushing to the train and I want my coffee, I want a cup that is clean and does not leak, so I can get on with my day without feeling guilty.”
Café owner (P1): “When it is the lunch rush, I want a returned cup to take five seconds and be safe, so my queue does not grow and the health inspector is happy.”

We will not serve (for now):

Group	Reason	Review on
Event caterers	Need thousands of cups at once; different logistics	After 500 members
Customers in towns with no partner café	We cannot deliver the swap	When cafés join
People who want a one-off cup	Our model is membership	At the first price review

Personas needed: two main, Maya the commuter and Leo the café owner, plus a short note on the barista because the barista’s experience decides café satisfaction. Three, not seven.

Notice how this simplifies later work. When an agent proposes “add a loyalty scheme for event organisers”, the founder can point to the list and say no, with a reason.

5. Working with AI agents on this

Describing people is a human act of judgment. Agents are good for checking and organising, not for deciding.

Delegate:

A first draft of the roles table from your own notes, to catch roles you forgot. Ask the agent to list every kind of person mentioned in the notes, with the line where each appears.
Public research on a segment: “What public data exists on commuter numbers in my city? Give links.” You open the links.
Spotting contradictions: “Here is my job statement and my interview notes. Which parts of the statement are not supported by the notes?”
A plain-language check: “Rewrite this so a ten-year-old could understand it” is a good test of whether you wrote something clear. Compare it with your original and learn.

Do yourself:

Choose the main user and customer.
Write the job statements from your own quotes.
Write the we-will-not-serve list, because it is a strategy choice.

A brief you can adapt:

Below are my interview notes (names removed). Task: list every kind of
person that appears in the notes, whether they use, pay for, install,
support or influence the product. For each, quote the line that shows it
and give the person code. Do not invent roles that do not appear. Then
list any role the notes hint at but do not describe, so I can ask about
them. Do not recommend who to prioritise.

How to check the output. Confirm each quoted line exists and says what the agent claims. Remove any role that came from the agent’s imagination. If it suggests something useful you missed, add it as a question for a future interview, not as a fact.

Why not ask an AI “who is my customer?” Because the answer will be a fluent average. It describes how people generally talk about the topic, not the specific people you met. The Dojo rule applies here: no invented personas, quotes or journey steps.

Disclose. At the bottom of the file: “AI use: role extraction from my notes on [date]. I chose the main people and wrote the jobs and the list.”

Where this sits on the ladder. The agent skill of a manager climbs four rungs: use one agent, delegate whole tasks with a brief, orchestrate several sessions, and govern them with written policy, hooks and gates. You are on the use rung here. Ask, read, and decide for yourself. The agent orchestration track covers the two upper rungs.

6. Common mistakes

One person, one role. Look for the customer who is not the user.
“Everyone” as the target. Choose a first group you can name.
Confusing the buyer with the user in B2B2C. Interview both and map both journeys.
A job statement full of features. “I want an app with a map” is a solution, not a job.
No we-will-not-serve list. Without it, every request seems reasonable and the plan has no edge.
Too many personas. Seven personas means nobody can remember any of them.
Using demographics as the story. Age and job title say little. Situations and motivations explain behaviour.
Skipping the barista. The people who operate the product every day often decide whether it works.

7. Practice: the people file

Deliverable: people/roles-and-jobs.md in your git repo, containing:

A table of everyone who touches your product, with their role (user, customer, partner, influencer, internal) and whether they change what you build.
Your main user and main customer, with one sentence of reason each.
A job statement for each main person, in their words, with the interview code or marked G if it is a guess.
A we-will-not-serve list of at least three groups, each with a reason and a review date.
The number of personas you will write, with the reason.
An AI-use line.

Use your own product if you have one. If you are working with TrailMug, change at least three details so that the file is clearly yours.

Commit with a message such as Add roles, jobs and we-will-not-serve list.

Stretch: ask a person in a different discipline (sales, support or design) to read the file and write three questions. Save them in people/questions.md, and answer the ones you can.

8. Checklist

I listed every kind of person, including internal roles.
I marked each as user, customer, partner, influencer or internal.
I chose one main user and one main customer, and explained why.
Each job statement uses a real quote or is marked as a guess.
I wrote at least three groups I will not serve, with reasons.
I decided how many personas I need.
Someone outside my head read it and found a gap.
I wrote down my AI use.

9. Further learning

The UK service manual explains how to learn about users and write down their needs. NN/g’s introduction to personas and its short video on persona scope help you decide how many personas you need and how broad each should be. The Google UX Design Certificate video on empathy is a good warm-up for the interviews you may still need to hold. NN/g’s page on field studies explains how to learn from watching people in their real setting, which is useful when what people say and what they do may differ. In the next lesson you turn your notes into evidence-based personas.