PM User Research and Fieldwork 09 － A Complaint Is Not Yet a Job: How PMs Confirm JTBD, Switching Moments, and Pain Intensity Without Jumping to Solutions

Article type

Professional methods piece / Problem-definition guide

The one thing this piece is trying to say

After a few interviews, PMs can leave with an overly optimistic feeling:

• users voiced frustrations
• those frustrations sounded reasonable
• the team can already imagine features that respond to them
• so this must be the next problem to solve

But research does not work that neatly.

Because:

• a complaint is not necessarily a high-weight problem
• friction does not automatically mean the friction changed behaviour
• a need statement does not mean you have found the job
• an opinion does not mean you understand the context it came from
• a solution request definitely does not mean you should build exactly that

So this piece is trying to make one thing clear:

a pain point is not just a complaint, and JTBD is not a more sophisticated way of rewriting user requests.
Both require you to return to the real context and confirm:

• what progress the person was actually trying to make
• what event made the existing approach feel insufficient
• how they weighed risk, alternatives, and switching cost
• how heavy the pain really was
• whether it was strong enough to push search, switching, delay, abandonment, or workaround behaviour

First, let’s make one thing plain: JTBD is not a rewritten persona, and it is not a feature-request collection method

JTBD is easy to make mystical and just as easy to make empty.

I prefer a more grounded reading.
It is not asking “what features do users want?”
It is asking this:

when a person hires a product, service, or workaround, what progress are they actually trying to make in their life or work?

The emphasis is not the product. The emphasis is progress.

So if an interview only yields statements like:

• I want it to be more convenient
• I need more filters
• I want easier comparison
• I want clearer information

those statements may still be true, but they are usually too shallow.
They have not yet reached the job.

A job tends to sound more like this:

• reduce uncertainty to an acceptable level before making a high-risk booking
• narrow options quickly because I do not want to spend my evening comparing everything
• leave an accountable trail for a team decision so I do not have to defend the process afterwards
• prove the tool can get me into real work before I commit to paying for it

Those statements sound less like a feature wishlist and more like movement towards an intended outcome.

Why I say a complaint is not yet a pain point

Because many complaints are surface-level noise. They have not yet become heavy enough to change behaviour.

A user might complain that:

• there are too many options
• search results are not precise enough
• the homepage feels messy
• comparison is tedious
• the information before payment is incomplete

All of that deserves attention.
But the real PM question is different:

• is this merely annoying, or does it drive abandonment?
• is it a preference, or does it trigger switching?
• is it verbal irritation, or has it already produced a workaround?
• is it low-cost frustration, or high-cost friction?

For me, a pain point is better understood as a form of resistance strong enough to alter behaviour.
Not simply because it feels negative, but because it carries weight.

How do I judge whether a problem has weight? I usually look at four things

1. Frequency

Is this a one-off oddity, or a recurring problem?

A powerful story can still be misleading if it is unusual and not representative of the relevant context.

2. Severity

Does it merely slow people down, or does it genuinely block, derail, or stop progress?

3. Workaround cost

How are people already compensating for the problem?

• notes, screenshots, spreadsheets, colleague reminders
• additional time spent comparing
• switching into other tools
• extra rounds of confirmation before proceeding

If a workaround exists consistently and carries a real cost, the pain is probably not imaginary.

4. Behavioural consequence

Did it actually change what happened next?

• delay
• abandonment
• movement to a competitor
• reliance on human assistance
• reduced usage frequency
• failure to begin at all

This is often the moment when a research synthesis suddenly becomes clearer.
Not every negative feeling grows into a product problem worth prioritising.

Switching moments matter because they uncover the middle stretch between “something feels off” and actual change

I like to treat switching moments as their own object of study.

PMs often know that users eventually switched tools, changed process, or started looking elsewhere, but they do not know what happened in the stretch between dissatisfaction and movement.

If you do not reconstruct that stretch, it becomes easy to believe things like:

• users switched because one feature was missing
• users switched because a competitor looked more attractive
• searching began the moment dissatisfaction appeared

Real decisions are rarely that crisp.
They often look more like accumulation:

• a first thought that something is no longer good enough
• a period of inertia or distraction
• several small frictions building over time
• a trigger event
• the beginning of search
• comparison, delay, hesitation, and back-and-forth
• finally, a decision point

That is why switch interviews are so useful.
They stop you from only asking “why did you switch?” and force you to reconstruct the timeline.

Time, events, and sequence are often more useful than asking what people want

This is one of the easiest places to write JTBD research badly.

As soon as the interview keeps asking:

• what do you want?
• what feature matters most to you?
• what would your ideal solution look like?

you quickly collect abstract, hypothetical, solution-shaped answers.

More useful prompts usually stay closer to events:

• when did you first feel the old approach was no longer enough?
• what happened that day?
• what else was going on? Who else was involved?
• how did you start looking for alternatives?
• did you delay? Why?
• what finally pushed you into a real decision?
• continuing with the old way was still possible, so why didn’t you?

Those questions are not collecting opinions.
They are reconstructing how progress became blocked and how change became possible.

The four forces are useful, but they should not become poster slogans

JTBD discussions quickly reach push, pull, habit, and anxiety.
That framework is useful because it reminds you to ask:

• what is pushing someone away from the current situation
• what is pulling them towards a new one
• what habits are keeping them where they are
• what anxieties are making change feel risky

But the framework becomes shallow very quickly if used too early.

The more useful move is to excavate the story properly first, then use the four forces to organise it afterwards.
Otherwise you flatten a participant’s world into four boxes before the evidence has earned that simplification.

Pain intensity is not just emotional intensity; it is whether the problem changes reality

You specifically wanted pain intensity included, and I think that is worth doing.
But it should not become a loose “how much did it hurt?” scale.

Tone alone is unreliable.

Some participants sound calm while carrying very heavy workarounds.
Others complain vividly but continue to behave exactly as before.

So I do not usually ask pain intensity in the abstract.
I break it down into more concrete dimensions:

• how often it happens
• how expensive each occurrence is
• whether it affects task success
• whether it increases uncertainty or risk
• whether it has already created workarounds
• whether it has already triggered search, switching, abandonment, or delay

If none of those show up, the issue may still be irritating, but it is not necessarily a top-tier pain.

When should you stop and refuse to jump into solutions too early?

This is one of the hardest and most important disciplines for PMs.

Once you understand the user’s context, solution ideas arrive quickly:

• perhaps we need a comparison feature
• perhaps we need a template
• perhaps we need a reminder
• perhaps the paywall should move later

Those ideas are not forbidden.
But if you move into solving before the job, switch trigger, and pain weight are properly established, two things often happen:

First, you solve a symptom rather than a real progress barrier.
Second, you translate the participant’s workaround into a feature far too quickly.

So the boundary of this piece is deliberate:
we stop at whether the problem definition is solid enough.
We do not step into solution ideation yet.

What should a more reliable JTBD / pain-research output look like?

If I want this kind of work to support product judgement, I would usually expect the output to include:

• the progress the target user is trying to make
• the current approach used to make that progress imperfectly
• the events that made the old approach feel insufficient
• the shape of the switching timeline
• evidence for push, pull, habit, and anxiety
• the pain’s frequency, severity, workaround cost, and behavioural consequences
• which complaints are merely complaints and which carry decision weight
• what further research or quantitative validation is still needed

That kind of output creates a much steadier handoff into later problem-solving and design-thinking work.

Closing thought

The hardest thing for PMs in research is usually not getting users to mention problems.
It is that there are too many problems, too many complaints, and too many plausible interpretations.

Product decisions are not complaint management.
They have to return to a firmer question:

is this barrier heavy enough to stop the user making progress?

JTBD is useful not because the term is fashionable.
It is useful because it drags your attention away from feature wishlists and back towards the progress people are genuinely trying to make.
Pain intensity matters for a similar reason.
It reminds you that not every dissatisfaction deserves the same priority.

At this point, the main arc of the series is complete.
We started with data blind spots, moved through method choice, recruitment, guide design, facilitation, and analysis, and ended where good research should end: with a stronger definition of the problem.

That is exactly where your later problem-solving and design-thinking chapters can take over.
Because now, at least, the team has earned the right to move towards solutions.