Stop Asking What Customers Want. Ask What They’re Trying to Get Done.
One of the biggest changes in how I approach product discovery came when I started looking beyond what customers were asking for.
Earlier in my product career, I would often ask customers questions like:
“What feature would you like us to build?”
The answers were usually predictable.
A better dashboard.
More integrations.
Bulk actions.
A new reporting option.
Those requests were useful, but they didn’t always tell me what I really needed to know.
Then I started using the Jobs to Be Done (JTBD) mindset.
Instead of asking what customers wanted, I started asking:
“What are you actually trying to accomplish?”
That question changed the quality of my discovery conversations.
Customers Hire Products to Get Jobs Done
The basic idea behind Jobs to Be Done is simple.
Customers don’t really buy products because of the products themselves.
They “hire” them to make progress in a particular situation.
Think about a customer using a project management tool.
Their job isn’t necessarily “manage projects.”
Their actual job might be:
“Make sure everyone knows what they need to complete before the deadline.”
That’s a much more useful discovery insight.
It tells us what outcome matters, rather than simply describing the software they currently use.
Feature Requests Can Hide Bigger Problems
One thing I’ve learned from customer conversations is that the requested solution isn’t always the underlying problem.
A customer might ask:
“Can you add bulk editing?”
If we stop there, we might build exactly that.
But if we dig deeper, we might discover that they’re spending three hours every week updating records manually.
Now the problem is much clearer.
The customer isn’t really asking for bulk editing.
They’re trying to reduce repetitive manual work.
Maybe bulk editing is the right solution.
Maybe automation is better.
Maybe the workflow itself needs to change.
JTBD gives Product Managers permission to explore the problem before committing to the solution.
Context Matters
A job doesn’t happen in isolation.
There’s usually a situation that triggers it.
For example, someone might use an assessment platform differently when they are:
- Hiring 10 people quickly
- Running a large graduate recruitment program
- Evaluating existing employees
- Managing a recurring assessment process
The same customer can have completely different jobs depending on the situation.
That’s why I find JTBD particularly useful during discovery.
It pushes us to understand the context behind the behavior.
Ask About the Moment, Not Just the Product
When conducting discovery interviews, I try to avoid questions that lead customers toward a solution.
Instead of:
“Would you use an automated reporting feature?”
I’d rather ask:
“Tell me about the last time you had to create this report.”
Then I explore what happened.
What were they trying to accomplish?
What made it difficult?
What did they do instead?
How much time did it take?
What happened if they couldn’t complete it?
These conversations often reveal far more than asking whether someone likes an idea.
JTBD Helps You Find Better Opportunities
One of the biggest benefits I’ve seen is that JTBD can reveal opportunities beyond the obvious feature request.
Suppose customers say they need better reporting.
After talking to them, you discover their real job is making faster decisions during a weekly meeting.
Suddenly, the opportunity isn’t necessarily “build more reports.”
It could be:
A better summary.
Automated insights.
Alerts.
A simpler dashboard.
Or even a completely different workflow.
The job gives you a much larger solution space.
Jobs Should Influence Prioritization
JTBD isn’t only useful during interviews.
I also find it useful when prioritizing the roadmap.
If two features are being considered, I ask:
Which customer job does each feature help accomplish?
Then I look at the importance of that job.
How frequently does it occur?
How painful is it today?
What happens if customers can’t complete it?
How well are existing solutions solving it?
This creates a much stronger basis for prioritization than simply counting feature requests.
Don’t Turn JTBD Into Another Template
One mistake I’ve seen teams make is turning JTBD into a rigid research exercise.
They create elaborate job statements and spend hours debating wording.
That’s not the point.
The framework is valuable because it changes how you think.
It reminds us that customers are trying to make progress.
Our job is to understand that progress before deciding what to build.
Final Thought
The biggest lesson JTBD has taught me is that customers don’t always know the best solution to their problems.
And honestly, they shouldn’t have to.
That’s our job.
Customers can tell us where they’re struggling, what they’re trying to accomplish, and what makes the current experience difficult.
Product Managers need to connect those dots.
So the next time a customer asks for a feature, don’t immediately add it to the backlog.
Pause for a moment.
Ask what they’re really trying to get done.
You might discover that the feature they requested is only one small part of the problem they’re actually trying to solve.
Leave a Reply