Users, customers and stakeholders
The person who uses a product, the person who pays for it and the person who decides whether it happens are often three different people. This lesson shows you how to tell them apart, how to listen to internal users who can't switch, how to map stakeholders before they surprise you, and how to write personas a team will actually use.
By the end you can
- Separate users, customers, deciders, blockers and affected people for any product
- Explain why internal users who can't switch hide their problems, and where to look instead
- Build a stakeholder map with wants, fears and an engagement plan for each person
- Spot the hidden stakeholder whose incentives change if your product works
- Write a behaviour-based persona and label which parts are still assumptions
The everyday picture
Think about a school lunch. The child eats it. The parent buys the food and packs it. The school sets rules, such as no nuts and no fizzy drinks. A grandparent insists that children need a hot meal, and the parent listens. Each of them can make the lunch fail in a different way.
Pack something the parent likes but the child hates, and it comes home uneaten. Pack the child's favourite sweets, and the parent stops buying them or the school sends them back. Ignore the grandparent, and you hear about it at dinner. A lunch that works has to work for the eater, the payer and the rule-maker at once. Products are the same, and the PM's job is to know who plays which part.
Users, customers, deciders and the rest
These are roles, not people. One person can hold several, and one role can be spread across many people.
- User: uses the product to get a job done.
- Customer or payer: pays for it, from their own pocket or their budget.
- Decider: chooses it, approves it or approves changes to it.
- Influencer: shapes the decision without making it, such as a trusted colleague, a consultant or a sales rep.
- Blocker: can stop it, often late. Security, legal, finance and IT are the usual ones.
- Affected: doesn't use the product but lives with its results, such as the finance team that relies on stock data the Store app creates.
In many consumer products one person holds most roles: you choose a music app, pay for it and use it. Even there, roles split more than you'd expect. A family shares one grocery account, and the person who orders isn't always the one who cooks. A parent pays for a child's learning app. In B2B the split is normal. Slack is usually chosen by a team, paid for by a company and governed by IT. Square is chosen and paid for by a shop owner, used by the staff at the counter and seen by every shopper who taps a card.
| Product | Uses it | Pays | Decides | Can block | Affected |
|---|---|---|---|---|---|
| Mangrove app (consumer) | The person ordering, often for a household | Same person | Same person | Payment providers, app store rules | Store pickers, riders |
| Partner app (B2B) | The shop owner or a helper | The owner | The owner | Mangrove's credit team (credit limits) | DC pickers, sales reps |
| Store app (internal) | Receiving staff, stock counters | Store operations budget | Head of store operations | IT (devices, security), finance (GRN rules) | Finance, suppliers, shoppers who find empty shelves |
| Order API (platform) | Developers on the app, Partner and POS teams | Engineering budget | Head of engineering | Security | Every customer and shop that places an order |
Why it matters: each role has a different idea of success. The shop owner wants low prices and reliable deliveries. The helper who places the order wants it done in two minutes. The credit team wants unpaid invoices kept down. If you design only for the payer, users struggle and quietly stop using it. If you design only for users, the payer sees no value and the blocker says no at the last moment.
Quick check
A parent pays for a reading app that their 8-year-old uses after school. The child's teacher recommended it. Which is right?
The child uses it, the parent pays and decides, and the teacher shapes the decision without making it. Mixing these up leads to the classic mistake of designing for the person in the meeting instead of the person using the product.