Define · Add-on
Build for both buyers and users
In business software the person who buys is often not the person who uses it. Meet both needs.
About 1-3 daysEvergreenLast reviewed 5 November 2026
Who this applies to
- Skills it builds
- Discovery and researchCommercial and business sense
- PM types
- All
- Product types
- Business software (B2B / SaaS)
- Starting points
- All
- Ways of working
- All
- Experience
- All
- Size of organisation
- All
Steps, by experience
Beginner (under 1 year)
- List the buyer, the users and any administrators.
- Write what each one needs to succeed.
- Spot conflicts, such as control versus ease of use.
- Decide how to meet both.
- Measure success for each group.
Intermediate (1 to 4 years)
- Define needs for buyers, users and admins.
- Resolve conflicts.
- Set measures for each.
Experienced (5+ years)
- Design for adoption so buyers see value.
- Give buyers reporting that shows return on investment.
- Align packaging with buyer needs.
Who can do this
Owner: Product manager
Can be delegated to
- UX Designer: Design for different roles
- Data Analyst: Define usage and value reports
Reviewed by: UX Designer
Tool examples
- Google Docs
- Write a needs table by role.
- Figma
- Design role-specific views.
Definition of done
- Roles and needs defined
- Conflicts resolved
- Measures set for each role
Common pitfalls
- Designing only for the buyer
- Forgetting administrators
- No proof of value for buyers
If you lead the team
What good looks like: Products meet the needs of both the people who buy them and the people who use them.
Ask your PM
- What does the buyer need to see, and what does the user need to do?
- Where do those needs conflict?
Warning signs
- Features win deals but users avoid them.
- Only one of the two groups was researched.