Product Manager Interviews Module 2 – Product sense and product design
Users, needs and pain points
Group users by situation and need, write a job to be done, choose one segment with stated criteria and rank its pain points by frequency and severity.
What you will learn
- Group users by need and situation rather than by demographics alone
- Write a job to be done and a problem statement for one segment
- Choose a target segment with stated criteria and defend the choice
- Rank pain points by how often they happen and how much they hurt
Before you start
What you’ll learn · Before you start
What you will learn
- Group users by need and situation rather than by demographics alone
- Write a job to be done and a problem statement for one segment
- Choose a target segment with stated criteria and defend the choice
- Rank pain points by how often they happen and how much they hurt
Before you start
On this page
Asked to improve a grocery delivery app, one candidate names the users as “people aged 25 to 34”. That band holds a nurse home from a night shift at 7 in the morning, a woman who bakes cakes to order and a man who shops for his parents 300 km away, and the three want such different things that no idea can be judged against all of them at once.
Product sense starts with people and their problems. Below, you group users by situation and need, write the job one group is trying to get done, choose that group with criteria said out loud and rank its pain points. Those are the first five minutes of a strong product answer: a user and a problem that every later idea is judged against.
Situation and need predict choices better than age
Take the three people in that age band. The nurse wants groceries at the door before she sleeps, so a delivery slot at 8 in the morning matters more to her than any price. The baker wants the same heavy items every week at a price she can plan around. The man wants the right items at a door he cannot see, so he cares most about what gets substituted. Their age says almost nothing about what each will do in the app; their situation says nearly everything.
That is the idea of a user segment: A group of users who share a situation and a need, so that one product decision can serve all of them. Age, place and income come afterwards, to count how many such users there are and to find them.: a group of users who share a situation and a need, so that one product decision can serve all of them. Christensen and colleagues make the case in their article on jobs to be done: the circumstances in which people try to get something done matter more than any characteristic of the buyer. Demographics still have work to do later. Once a segment is chosen, age, city and income help you count its members and find them.
Step through the same three people, grouped first by age and then by situation:
The drawing shows the whole scene; its 6 steps are listed below.
Every step as text
- One age band. A candidate names the users of a grocery app as people aged 25 to 34. The band sounds precise, but it says nothing yet about what anyone in it needs.
- Three people in it. Three people in that band: a nurse who gets home from a night shift at 7 in the morning, a woman who bakes cakes to order in her kitchen and a man whose parents live 300 km away.
- Three needs. Each needs something different from the same app: groceries at the door by 8 before she sleeps, 10 kg of flour every week at a price she can plan, and the right items at a door he cannot see.
- One idea, three verdicts. Test one idea against the band: a cheaper price for buying in bulk. The baker gains, the nurse hardly notices, and the carer still cannot tell what his parents are missing. The band cannot judge the idea.
- Group by situation. Drop the age band and group by situation and need. Each person now stands for a segment, night-shift workers, home bakers and remote carers, and each segment has one need that ideas can be judged against.
- Age comes back later. Age, city and income still help after the choice: once you pick a segment, they tell you how many such people there are and where to reach them.
The age band put three needs in one box, so an idea such as bulk prices helped one person and left two cold. Grouped by situation, each box holds one need, and you can ask the question that matters next: which need is worth solving first?
Design practice puts the same order on paper. The Double Diamond, the Design Council’s picture of the design process (shared under CC BY 4.0), spends its whole first half discovering and defining the problem, by spending time with the people affected, before any solution is developed. A persona: A short portrait of one imagined member of a user segment, with a name, a typical day and the need that matters, which keeps a team thinking about real behaviour. It describes a segment; it does not replace one. is a different tool: a short portrait of one imagined member of a segment, with a name and a typical day, that keeps a team thinking about real behaviour. GOV.UK’s service manual uses personas to describe groups of users with similar behaviour and needs. In an interview you seldom need the portrait; you need the segment and its need.
An age band as the segment
Wrong: “I’ll focus on women aged 25 to 40.” Right: “I’ll focus on people who order groceries for parents in another city; most of them will be 30 to 55, which tells me where to reach them.” An age band holds many needs, so the ideas that follow cannot be compared; a situation holds one.
A job to be done names the progress, not a feature
Write the man’s need as a job to be done: The progress a person is trying to make in a particular situation, such as getting groceries to parents in another city. People choose a product to get the job done and drop it when it does the job badly.: the progress he is trying to make in his situation. In MySmartCoPilot’s template, “When …, I want to …, so I can …”, it reads:
When my parents run low on groceries and I’m 300 km away, I want the right items at their door the same day, so I can look after them without travelling.
The article’s summary puts it this way: people “hire” a product to get a job done and drop it when it does the job badly, and a job has social and emotional sides as well as a function. Here the function is groceries at a door. The emotional side is feeling that he looks after his parents, and the social side is that the parents do not want to feel a burden. A product that forgets the last one, for example by making the parents approve every order, does the job badly however fast it delivers.
A job leads to a problem statement, which says what stands in the way and what it costs today:
People who order groceries for parents in another city cannot tell what their parents are running out of, because the parents under-report it; today they phone before every order and still miss items.
GOV.UK’s service manual asks the same of user needs: words the user would recognise, about the user’s problem rather than a possible solution, and based on evidence from research rather than assumptions. Compare weak and strong forms:
| Names a feature, or nothing | Names the progress |
|---|---|
| “Users want a reorder button.” | “When the same items run out every week, I want them to arrive without my remembering, so I can stop making lists.” |
| “Bakers want cheaper flour.” | “When I take cake orders a week ahead, I want a flour price I can plan around, so I can quote without losing money.” |
| “Nurses need a better app.” | “When I get home from a night shift, I want my groceries already there, so I can sleep instead of shopping.” |
Each weak form names a solution or nothing at all, so it can never be wrong. Each strong form names a situation, which you can check, and a result, which you can measure.
Checkpoint
Check: Segments by situation and need · Jobs to be done and problem statements
Choose one segment, with the criteria said before the choice
Three segments are enough to choose from, and the choice is the first judgement the interviewer scores. MySmartCoPilot’s criteria are five: size (how many such users there are), pain (how much the need hurts today), frequency (how often it comes up), reach (how easily the app can find them) and fit (how well serving them suits what the company already does well). Score each segment from 1 to 5 on each criterion, then weight the criteria by the company’s goal. The program does that for the three invented segments, under two goals:
"""Score three user segments of an invented grocery app, then change the goal.
Every score runs from 1 (low) to 5 (high) and is invented for this example. A segment's
total is the sum of score x weight over the five criteria. The weights say what the
company's goal values, so the same scores can rank the segments differently.
"""
SEGMENTS = { # invented scores from 1 to 5
"night-shift workers": {"size": 4, "pain": 3, "frequency": 4, "reach": 3, "fit": 3},
"home bakers": {"size": 2, "pain": 4, "frequency": 5, "reach": 4, "fit": 2},
"remote carers": {"size": 3, "pain": 5, "frequency": 3, "reach": 2, "fit": 4},
}
GOALS = { # what each goal values: a weight for each criterion
"more orders every week": {"size": 2, "pain": 2, "frequency": 3, "reach": 2, "fit": 1},
"a loyal group that rivals serve badly": {"size": 1, "pain": 3, "frequency": 1, "reach": 1, "fit": 3},
}
def total(scores, weights):
return sum(scores[c] * weights[c] for c in weights)
for goal, weights in GOALS.items():
print(f"Goal: {goal}")
# Highest total first; a tie goes to the segment whose need hurts more today.
ranked = sorted(SEGMENTS, key=lambda s: (-total(SEGMENTS[s], weights), -SEGMENTS[s]["pain"]))
for name in ranked:
print(f" {name}: {total(SEGMENTS[name], weights)}")
print(f" Choose: {ranked[0]}")Output
Goal: more orders every week home bakers: 37 night-shift workers: 35 remote carers: 33 Choose: home bakers Goal: a loyal group that rivals serve badly remote carers: 35 home bakers: 29 night-shift workers: 29 Choose: remote carers
Recorded with Python 3.14.8 on macOS 26 arm64. To run it yourself: mise exec python@3.14.8 -- python3 segment_score.py
Runs on this device, in your browser. The first run downloads Python (about 13.5 MB), which is kept for the next runs.
Your run, in this browser
With more orders every week as the goal, frequency weighs most and the home bakers lead with 37, because they order every week. With a loyal group that rivals serve badly as the goal, pain and fit weigh most and the remote carers lead with 35, while bakers and night-shift workers tie at 29; the tie goes to the higher pain. The scores did not change; the goal did. Change a weight at the top of the program and run it again: the choice follows the weights.
Constraints can rule a segment out before any scoring. Answer the questions about the company in the table, and watch which segments still fit:
Answer the questions above: the table then marks what fits your case and says why the rest does not.
| Segment | Size | Pain today | How often | Reach | Fit |
|---|---|---|---|---|---|
| Night-shift workers Needs: groceries at home by 8 in the morning | Good 4 of 5: nurses, guards and call-centre staff are many in a big city | Mixed 3 of 5: a 24-hour shop on the way home is a workable fallback | Good 4 of 5: two or three orders a week | Mixed 3 of 5: employers and shift rotas can reach them, slowly | Mixed 3 of 5: depends on delivery slots before 8 in the morning |
| Home bakers Needs: 10 kg of flour a week, at a steady price | Poor 2 of 5: a small group | Good 4 of 5: a jump in the price of flour wipes out a week of profit | Good 5 of 5: the same heavy items every week | Good 4 of 5: easy to find through baking groups and suppliers | Poor 2 of 5: 10 kg sacks do not suit the app's household stock and vans |
| Remote carers Needs: the right items at a door 300 km away | Mixed 3 of 5: many people live far from their ageing parents | Good 5 of 5: they cannot see what is missing, and a wrong item can matter | Mixed 3 of 5: about one order a week | Poor 2 of 5: hard to find, because they live in another city from the order | Good 4 of 5: household groceries are what the app already sells |
How the answers decide
- “What does the company want most from this choice?” More orders every week: adds a caveat to Remote carers. For weekly orders frequency weighs most, and carers order about once a week, 3 of 5. In the program bakers lead with 37, night-shift workers have 35 and carers 33.
- “What does the company want most from this choice?” A loyal group that rivals serve badly: adds a caveat to Home bakers and Night-shift workers. For a loyal group pain and fit weigh most. In the program carers lead with 35, while bakers and night-shift workers tie at 29.
- “Can the app deliver before 8 in the morning?” Not yet: rules out Night-shift workers. Night-shift workers need groceries before they sleep. Without slots before 8 in the morning the app cannot meet the need.
- “Can one person pay for an order that goes to an address in another city?” Not yet: rules out Remote carers. Carers pay in one city for a door in another. Until the app allows that, the segment cannot order at all.
In short: say the goal and the criteria first, score the segments against them, and drop any segment that a constraint rules out.
Key idea
State the goal and the criteria before you choose: the same three segments rank differently under different goals, and the interviewer scores the reasoning, not the segment.
Checkpoint
Check: Choosing a segment with stated criteria
Rank pain points by how often and how badly they hurt
With the remote carers chosen, list their pain point: Something that makes a user's job slower, costlier, riskier or more upsetting than it should be. Pain points are ranked by how often they happen and how much each one hurts.: the things that make the job slower, costlier, riskier or more upsetting than it should be. The figures are invented for the example, as yours will be in an interview, and the score multiplies how often a pain happens by how bad it is:
| Pain point of remote carers | Orders it hits, of 10 | Severity, 1 to 5 | Score |
|---|---|---|---|
| Not knowing what the parents are running out of | 8 | 4 | 32 |
| A substituted or missing item the parents cannot sort out | 3 | 5 | 15 |
| Delivery while the parents are out | 2 | 3 | 6 |
| A card refused because the delivery is in another city | 1 | 2 | 2 |
Today the carers work around the first two with a phone call before every order and a neighbour who checks the bag. A workaround that costs effort every time is a sign that the pain is real.
Rank by the score: not knowing what the parents need comes first, at 32, because it hits nearly every order and its workaround costs a call each time. In an answer, name the top two or three pains and say why the first comes first; ten pains is a list, not a choice.
The score is MySmartCoPilot’s rule of thumb, and severity can overrule it. A pain that is rare but dangerous, such as the wrong medicine reaching an elderly parent, deserves a mention even at 1 order in 50, because one occurrence can do more harm than a hundred late deliveries.
In the room you have no data: say what you would check
Every number above is invented, and in an interview yours will be too. That is fine as long as you say so and say how you would check it: evidence in a product round is your reasoning, not data you pretend to have. GOV.UK’s service manual treats views that do not come from users as assumptions to be proven by research, and asks for needs based on evidence. Turn each claim of your answer into a check:
| Claim in the answer | How you would check it |
|---|---|
| Carers are a large enough group | Count orders paid for in one city and delivered to another |
| Not knowing what runs out is the top pain | Count second orders to the same door within two days |
| Substitutions hurt most for medicines | Read the support messages that mention substitutions |
| Carers would share a list with their parents | Interview a few carers and watch them plan an order |
Say it in one sentence: “I’m assuming that not knowing what runs out is the biggest pain; I’d check it by counting second orders to the same door within two days.” It shows judgement and honesty at once, and it costs ten seconds.
Survey Results Analyzer Summarise a survey of your own users: counts, Likert charts and cross-tabs by segment.Checkpoint
Check: Ranking pain points · Assumptions and how to check them
Practise: rank segments in code, then check yourself
Write the lesson’s scoring rule as a function, with ties broken by pain, and run the sample tests:
Exercise · Easy · Python
Rank user segments by a weighted score, ties by pain
An interview answer scores a few user segments on the same criteria, each from 1 to 5, and weights the criteria by the company's goal. Write score_segments(segments, weights), which ranks the segments the way the lesson does:
- A segment's total is the sum, over the criteria in
weights, of its score times that criterion's weight. - Return the names of the segments, highest total first.
- Break a tie by the higher
painscore; if the pain scores tie too, keep the order ofsegments.
segments = {
"night-shift workers": {"size": 4, "pain": 3, "frequency": 4, "reach": 3, "fit": 3},
"home bakers": {"size": 2, "pain": 4, "frequency": 5, "reach": 4, "fit": 2},
"remote carers": {"size": 3, "pain": 5, "frequency": 3, "reach": 2, "fit": 4},
}
score_segments(segments, {"size": 2, "pain": 2, "frequency": 3, "reach": 2, "fit": 1})
# ['home bakers', 'night-shift workers', 'remote carers']: totals 37, 35 and 33The sample tests also check the lesson's second goal, where two segments tie on 29, a tie on both the total and the pain score, and a criterion whose weight is 0.
Starter code · segments.py
def score_segments(segments, weights):
"""Rank user segments by their weighted score, best first.
segments: segment name -> {criterion: score from 1 to 5}
weights: criterion -> weight; a segment's total is the sum of score * weight
Ties go to the higher "pain" score, then keep the order of segments.
"""
# Your code here.
return list(segments)The sample tests · test_segments.py
from segments import score_segments
GROCERY = {
"night-shift workers": {"size": 4, "pain": 3, "frequency": 4, "reach": 3, "fit": 3},
"home bakers": {"size": 2, "pain": 4, "frequency": 5, "reach": 4, "fit": 2},
"remote carers": {"size": 3, "pain": 5, "frequency": 3, "reach": 2, "fit": 4},
}
WEEKLY_ORDERS = {"size": 2, "pain": 2, "frequency": 3, "reach": 2, "fit": 1}
LOYAL_GROUP = {"size": 1, "pain": 3, "frequency": 1, "reach": 1, "fit": 3}
def test_weekly_orders():
"""ranks the lesson's three segments for more orders every week"""
assert score_segments(GROCERY, WEEKLY_ORDERS) == ["home bakers", "night-shift workers", "remote carers"]
def test_tie_goes_to_pain():
"""breaks the 29-29 tie of the second goal by the higher pain score"""
assert score_segments(GROCERY, LOYAL_GROUP) == ["remote carers", "home bakers", "night-shift workers"]
def test_full_tie_keeps_order():
"""keeps the order of segments when the total and the pain score both tie"""
same = {"b": {"pain": 2, "size": 3}, "a": {"pain": 2, "size": 3}}
assert score_segments(same, {"pain": 1, "size": 1}) == ["b", "a"]
def test_zero_weight():
"""ignores a criterion whose weight is 0"""
two = {"x": {"pain": 1, "size": 5}, "y": {"pain": 2, "size": 1}}
assert score_segments(two, {"pain": 1, "size": 0}) == ["y", "x"]A hint
Work out one segment's total first: multiply each score by its criterion's weight and add the products. Then sort the names by a key with two parts, the total and the pain score, so that the largest of each comes first. Python's sort keeps the original order of items that tie on the whole key.
Results of the sample tests
| Test | Result | Details |
|---|
What your code printed
The sample tests run on this device, in your browser (Pyodide): nothing is sent to mysmartcopilot.com. The first run downloads Python (about 13.5 MB), which is kept for the next runs. A check in your browser is feedback for you, not proof that the code is right for every input.
The self-check below asks about each idea of the lesson in turn, beginning with the one you have answered least well:
Practice that adapts to you
Practise this lesson
14 questions about 5 ideas of this lesson. Each answer is explained at once, and what you get right is kept in this browser.
Your own segments
Pick an app you used this week. Name three segments of its users by situation, write one job in the template, and rank three pain points of one segment with numbers you label as invented.
Interview questions
The first question is answered here. Answer the other two aloud before you open their first steps:
Model answers open with any pass: ₹79 for 1 week ($2.99), one payment that never renews.
-
Fresher to mid · Warm-up
What is the difference between a user segment and a persona?
A user segment is a group of real users who share a situation and a need, such as people who order groceries for parents in another city. It is defined so that one product decision can serve the whole group, and it can be counted: how many such users there are and how often the need comes up. A persona is a short portrait of one imagined member of a segment, with a name, a typical day and a quote, written to keep a team thinking about real behaviour instead of an average user. The segment comes first and the persona describes it; a persona with no segment behind it cannot be sized or tested. In an interview, define the segment and its need in a sentence or two, and add a persona only if the interviewer asks for one.
-
Fresher to senior
A city library wants more people to use its app. Name three user segments, choose one and defend the choice in under two minutes.
-
Fresher to mid
Write the job to be done for a daily metro commuter who opens a transit app, and say which pain point you would solve first.
Flashcards · 7 cards
Recall it, then check
Say the answer to yourself before you look: recalling it is what makes it stick.
-
Why group users by situation and need rather than by an age band?
One age band can hold a nurse home from a night shift, a home baker and a man shopping for parents far away, each wanting something different, so no idea can be judged against all three. A segment shares one situation and need; age, city and income help later to count and reach it.
-
What template does the track use to write a job to be done?
'When …, I want to …, so I can …': the situation, the progress the person wants and why it matters to them. A job names that progress, never a feature.
-
Which three sides can a job to be done have?
A functional side, such as groceries reaching a parent's door; an emotional side, such as feeling that you look after your parents; and a social side, such as the parents not wanting to feel a burden. Forget one and the product does the job badly, however fast it is.
-
What does a strong problem statement say?
Who is affected, what stands in their way and what it costs them today, in words the user would recognise and based on evidence rather than on a solution. 'Users want a reorder button' fails because it names a feature, so it can never be wrong.
-
Which five criteria does the track use to choose a target segment?
Size, pain, frequency, reach and fit with what the company already does well, each scored from 1 to 5 and weighted by the company's goal. The same three segments rank differently under another goal, so state the goal and the criteria before choosing.
-
How do you rank a segment's pain points?
Multiply how often each pain happens by how badly it hurts on a scale of 1 to 5, then name the top two or three and say why the first leads. A rare but dangerous pain, such as the wrong medicine reaching an elderly parent, can overrule the score.
-
How do you handle numbers in a product round when you have no data?
Label each one as an assumption and say how you would check it, for example by counting second orders to the same address within two days. In the room the evidence is your reasoning, not data you pretend to have.
Key takeaways
- A user segment is a group that shares a situation and a need; an age band holds many needs, so ideas aimed at it cannot be compared.
- A job to be done names the progress a person wants in a situation, “When …, I want to …, so I can …”, and a problem statement says what stands in the way today.
- Say the goal and the criteria before choosing a segment: the same scores put bakers first for weekly orders and carers first for a loyal group.
- Rank pain points by how often and how badly they hurt, name two or three, and let severity overrule the score for rare but dangerous pains.
- With no data in the room, label invented numbers as assumptions and say how you would check each one.
Terms in this lesson
- job to be done
- The progress a person is trying to make in a particular situation, such as getting groceries to parents in another city. People choose a product to get the job done and drop it when it does the job badly.
- pain point
- Something that makes a user's job slower, costlier, riskier or more upsetting than it should be. Pain points are ranked by how often they happen and how much each one hurts.
- persona
- A short portrait of one imagined member of a user segment, with a name, a typical day and the need that matters, which keeps a team thinking about real behaviour. It describes a segment; it does not replace one.
- user segment
- A group of users who share a situation and a need, so that one product decision can serve all of them. Age, place and income come afterwards, to count how many such users there are and to find them.
References
- Know Your Customers’ “Jobs to Be Done” (Harvard Business Review (Christensen, Hall, Dillon and Duncan))
- Learning about users and their needs (Service Manual) (GOV.UK (Government Digital Service))
- The Double Diamond (Design Council (CC BY 4.0))
Related tools
Report a problem with this lesson
Kept only in this browser. Your Learn progress