Who Is the User?
Separate the person using the product from the people buying and governing it. · Product Judgment · Lesson 02 · 3 min
Who Is the User? · 3 min
Situation
The buyer loves it. The team avoids it.
A company buys a Slack-style collaboration tool. The operations director values reporting, IT wants access controls, and employees want fewer interruptions.
A demo can delight the buyer while the daily experience disappoints the people expected to use it. “The customer wants this” is too broad to settle the decision.
Mental model
Map the roles around one workflow.
The user performs the task. The customer is the organization or person with the commercial relationship. The buyer approves spending. An admin configures access and settings. A stakeholder is affected by the outcome.
One person can hold several roles. In a larger organization, each role may have different authority, information, and incentives.
Example
An invitation has more than one audience.
An employee wants to invite a contractor into a project channel. The admin needs to prevent access to unrelated channels. The buyer wants collaboration without extra operational cost.
Designing only for the inviter produces a fast flow that may violate workspace policy. Designing only for the admin may make collaboration too cumbersome to use.
Failure case
Treating access as proof of value.
An enterprise contract gives 2,000 employees access. That does not mean 2,000 people receive value. Count people who use the relevant workflow, and investigate who opts out.
Interview the buyer about purchasing constraints and users about actual work. Neither perspective can substitute for the other.
PM question
Whose problem is this decision solving?
For contractor invitations, write down who initiates, who approves, who is exposed to risk, and who can reverse the action.
Could an admin set a policy once and let employees act within it? That might satisfy both speed and control. Validate the policy with admins and test the flow with actual inviters.
Remember this
Identify the role before weighing the request.
A buyer's request can be commercially important without describing a daily user need. State both explicitly so the team can make an honest trade-off.