Overview
Understanding Customers and Users is the third CSPO learning objective category, with five objectives. It asks you to describe how product discovery and validation fit into the Product Owner's regular work, illustrate a way to segment customers and users, practise a technique for handling needs that pull in different directions, identify how several aspects of discovery contribute to good product outcomes, and list ways to put Developers in direct contact with the people who use what they build.
The category separates customers, who choose or pay for a product, from users, who interact with it, and treats both as sources of evidence rather than opinion. As with the rest of the CSPO, there is no scored test on this material; your trainer covers it through discussion and exercises during the 16-hour course.
How it's tested
No exam exists for CSPO, so practice items here simply check that you can apply discovery thinking. They usually describe a team making product decisions from second-hand requests or a single loud customer, and ask which action would build better understanding of the real customers and users involved.
-
Customer or user
A person or group is described, and you decide whether they are a customer, a user or both, and what that implies.
-
Competing needs
Two segments want opposite changes, and you choose a technique to weigh them against the Product Goal.
-
Close the gap
Developers only learn about users through documents, and you pick a way to connect them directly.
A payroll product's buyers are finance directors, but daily users are clerks entering timesheets. Sales feedback asks for richer executive dashboards while support tickets show clerks struggling with data entry. A discovery-minded Product Owner segments both groups, gathers evidence on which problem most limits the Product Goal of reducing payroll errors, and invites Developers to observe clerks at work before deciding.
Learning objectives 5
Official learning objectives from the Scrum Alliance outline, in outline order.
3.1 Describe how a product owner includes product discovery and validation in their workMaking discovery a continuous habit.
- What it means
- Product discovery is the work of learning what problems are worth solving and which solutions might work, while validation checks those ideas with evidence. The objective asks how a Product Owner builds both into every Sprint rather than treating them as an upfront phase.
- What to understand
- Discovery and delivery run side by side. Refinement, Sprint Reviews and small experiments all feed learning back into the Product Backlog. Some Product Owners keep a share of each Sprint for discovery work or run discovery activities with the team between events.
- How it shows up
- Practice scenarios ask how to fit discovery into a team that only ever builds requested features.
- Common confusion
- Treating discovery as a one-time requirements phase before development starts.
3.2 Illustrate at least one approach for segmenting customers and usersGrouping customers and users meaningfully.
- What it means
- Segmentation divides customers and users into groups that share needs, behaviors or contexts. Approaches include personas, jobs to be done, behavioral segments based on usage data, and demographic or firmographic groupings.
- What to understand
- Good segments differ in what they need from the product, not just in who they are. Personas built on research help the team picture real people. Jobs to be done focuses on the progress a person is trying to make, which often cuts across demographic lines.
- How it shows up
- You may be given a description of a market and asked which segmentation gives the most useful insight.
- Common confusion
- Building personas from assumptions without any research behind them.
3.3 Practice at least one technique to address conflicting customer (or user) needsResolving needs that pull apart.
- What it means
- Different segments often want incompatible things. This objective asks you to practise a technique for weighing them, such as linking each need to the Product Goal, scoring value and cost, Kano analysis, or facilitating a shared workshop between groups.
- What to understand
- The aim is a transparent decision, not pleasing everyone. Tie each need back to outcomes and evidence, look for options that satisfy the underlying problem of several segments, and explain trade-offs openly. The Product Owner makes the final call on ordering.
- How it shows up
- A scenario shows two segments demanding opposite changes and asks how the Product Owner should decide.
- Common confusion
- Splitting the difference so each group gets half of what it asked for.
3.4 Identify how at least three aspects of product discovery contribute to successful product outcomesWhy discovery improves results.
- What it means
- This objective links discovery activities to results. Aspects include understanding the problem, generating varied solution ideas, testing riskiest assumptions early, measuring behavior and involving the whole team in learning.
- What to understand
- Discovery reduces the risk of building something nobody needs, improves the fit between solution and problem, and focuses spending on ideas with evidence. It also shapes better Product Goals and backlog items, so outcomes improve rather than just the amount of output.
- How it shows up
- Prompts ask which discovery activity most reduces a specific risk, such as building the wrong feature.
- Common confusion
- Assuming more features delivered means a more successful product.
3.5 List at least three approaches to connect developers directly to customers and usersRemoving the handoff between teams and users.
- What it means
- Developers build better solutions when they understand users first-hand. Approaches include joining user interviews, observing users at work, inviting users to Sprint Reviews, rotating through customer support, watching usability tests and reviewing analytics together.
- What to understand
- The Product Owner does not have to be the only channel between users and the team. Direct contact reduces misunderstanding and gives Developers the context to suggest better options. The Product Owner still remains accountable for value and the backlog order.
- How it shows up
- Scenarios describe Developers working only from tickets and ask how to give them real user insight.
- Common confusion
- Believing the Product Owner must filter all user contact to protect the team.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Product discovery
Learning which problems and solutions are worth pursuing.
- Remember
- Continuous, alongside delivery.
- Tested as
- Objective 3.1 and 3.4.
- Trap
- Treating it as a phase.
-
Customer vs. user
Buyer or chooser versus person who uses it.
- Remember
- They can be different people.
- Tested as
- Basis of segmentation.
- Trap
- Assuming they want the same thing.
-
Persona
Research-based profile of a user type.
- Remember
- Grounded in real evidence.
- Tested as
- Segmentation approach.
- Trap
- Inventing personas from opinion.
-
Jobs to be done
The progress someone is trying to make.
- Remember
- Focuses on the need, not the person.
- Tested as
- Alternative segmentation lens.
- Trap
- Confusing a job with a feature.
-
Kano model
Classifies features as basic, performance or delighters.
- Remember
- Helps weigh competing needs.
- Tested as
- Technique for 3.3.
- Trap
- Treating every request as a delighter.
-
Outcome focus
Judging success by change in behavior or results.
- Remember
- Discovery serves outcomes, not output.
- Tested as
- Links to 3.4 and category 5.
- Trap
- Counting features shipped.
-
Direct user contact
Developers meet or observe users themselves.
- Remember
- Shortens feedback and improves ideas.
- Tested as
- Objective 3.5.
- Trap
- Routing every question through the Product Owner.
-
Customer journey map
Steps a user goes through to reach a goal.
- Remember
- Shows pain points in context.
- Tested as
- Discovery and segmentation tool.
- Trap
- Mapping the system instead of the user.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Customers vs. users vs. stakeholders
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Customer | Chooses or pays for the product | Drives buying decisions | Assuming they use it daily |
| User | Interacts with the product | Experiences usability directly | Ignoring them when they do not pay |
| Stakeholder | Anyone with an interest in the product | Broader than customers and users | Treating every stakeholder as a user |
Segmentation approaches
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Personas | Profiles of typical users | Humanizes needs for the team | Building them without research |
| Jobs to be done | Progress people seek | Cuts across demographics | Writing jobs as features |
| Behavioral segments | Groups based on usage data | Uses real behavior | Ignoring the reasons behind behavior |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Loudest customer wins
- What candidates pick
- Prioritize the request from the biggest customer.
- Why it looks right
- It seems commercially safe.
- Why it's wrong
- Ordering should rest on evidence across segments and the Product Goal, not on volume or seniority of the request.
Clue to watch for One customer is pushing hard for a change.
-
Discovery is upfront
- What candidates pick
- Finish all research before development starts.
- Why it looks right
- It looks thorough and planned.
- Why it's wrong
- Learning continues throughout the product's life, so discovery should run alongside delivery every Sprint.
Clue to watch for The team stopped talking to users after launch.
-
Product Owner as gatekeeper
- What candidates pick
- Keep all user contact with the Product Owner.
- Why it looks right
- It protects Developers' focus.
- Why it's wrong
- Direct contact gives Developers context to build better solutions and catch misunderstandings early.
Clue to watch for Developers ask to meet users.
-
Split the difference
- What candidates pick
- Give each conflicting segment part of what it wants.
- Why it looks right
- It feels fair.
- Why it's wrong
- Half-solutions often satisfy nobody; weigh needs against outcomes and evidence and decide transparently.
Clue to watch for Two segments want opposite behavior.
-
Invented personas
- What candidates pick
- Write personas in a workshop without any user research.
- Why it looks right
- They are quick to produce.
- Why it's wrong
- Personas without evidence encode the team's assumptions and can mislead backlog decisions.
Clue to watch for Personas were created from internal opinions.
Answer framework
Use these steps whenever a scenario involves understanding or choosing between customers and users.
- Identify who is involved and separate customers, who choose or pay, from users, who work with the product every day.
- Segment them by need or job to be done, so you can see where groups genuinely differ and where they overlap.
- Check what evidence exists for each need, and plan a discovery activity where the team is relying on opinion or a single source.
- When needs conflict, weigh each against the Product Goal and expected outcome, then decide openly and explain the trade-off.
- Prefer actions that put Developers in direct contact with users, such as observation, interviews or attending usability sessions.
Practice question
Want more like this? The CSPO practice test has questions for every domain.
Checklist
0 of 10
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Before the course, list every group that touches your product and mark each as a customer, user or other stakeholder. Pick two user groups and write down what you know about their needs and how you know it. Where the answer is a guess, note one discovery activity you could run, such as five short interviews or watching someone use the product. Bring these notes to class as working material.
In class, expect segmentation and conflicting-needs exercises, often with persona or jobs-to-be-done templates. Practise explaining a decision between two segments in terms of the Product Goal, because that is the reasoning trainers look for. After the course, try one way to connect your Developers with users within a month and reflect on what changed. Four to six hours of preparation and follow-up is a reasonable plan, and the knowledge checks on this site help you test your reasoning without any effect on certification.
FAQ
How much of the CSPO does Understanding Customers and Users cover?
Scrum Alliance assigns no weights, and CSPO has no exam. Understanding Customers and Users includes 5 of the 28 learning objectives and is usually taught through hands-on discovery exercises.
What is the difference between a customer and a user?
A customer chooses or pays for the product, while a user interacts with it. In business software they are often different people with different needs.
Is product discovery a phase before development?
No. The objectives frame discovery as continuous work that runs alongside delivery, feeding new learning into the Product Backlog each Sprint.
How should a Product Owner handle conflicting user needs?
Use a technique such as linking needs to the Product Goal, value and cost scoring or Kano analysis, then make and explain a clear ordering decision.
Should Developers talk to users directly?
Yes. Objective 3.5 lists ways to connect Developers with customers and users, because first-hand contact improves understanding and the quality of solutions.
Which segmentation method does the course require?
The objective asks you to illustrate at least one approach. Personas, jobs to be done and behavioral segments are common choices, and trainers may use any of them.
Other Agile & Scrum certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 3 knowledge
You have covered discovery, segmentation, conflicting needs and connecting Developers with users. Run a short knowledge check to confirm you can choose the right customer-focused response.