Nobody woke up today wanting your product.
They woke up with a problem. A job they needed to get done. Something in their work or life wasn’t working the way it should. Your product might be what helps them get there, but it’s not what they’re thinking about. They’re thinking about the outcome. You’re thinking about the solution. And that gap, small as it sounds, is where most innovation quietly goes wrong.
Jim Kalbach has spent decades watching organisations fall into this trap. He’s the Chief Evangelist at Mural, author of The Jobs to Be Done Playbook, founder of JTBD Toolkit and one of the most experienced JTBD practitioners working today.
“It’s hard to escape the gravity of your own product solution and brand. And sometimes people go – yeah, okay, I get that point, and they still don’t do it.”
What are they trying to achieve?
Jim opens every workshop the same way. One ground rule: no talking about technology or solutions. Only customer problems.
Then he gives the first exercise. Without fail, the first thing people include is a solution.
This is what he calls solution gravity – the near-physical pull that your own product, your brand, your go-to-market exerts on how you see the market. It doesn’t feel like bias. It feels like expertise. You’ve been in this space long enough to know what works. You have usage data. You have a roadmap. You have stakeholders who’ve already signed off on the direction.
And somewhere in all of that certainty, the customer’s actual job quietly disappears.
Jobs to Be Done asks you to do something that sounds straightforward and turns out to be very difficult: set your solution aside entirely, and ask what the person is trying to accomplish – independent of any technology, including yours. Not “how can they get more from our product?” but “what are they trying to get done, and what’s standing in the way?”
That reframe is the whole game. Everything else in the Jobs-to-Be-Done framework builds on it.
The most important layer
When teams do attempt to think about customer needs, they tend to reach straight for the emotional and aspirational. What do people want to feel? What does success look like for them? These areimportant questions – but Jim argues they’re the wrong place to start.
For example, working with a large online retailer on women’s jeans, the initial instinct was to frame the job around looking good – the obvious emotional dimension. But when they dug into the actual unmet need, it had nothing to do with style.
It was fit.
“If the jeans don’t fit, it doesn’t matter how good they look or how confident you feel in them.”
There’s a principle inside Jobs to Be Done that you can’t achieve an emotional or social job until the functional job is done first. Jim describes it as stripping back to the centre of the earth – emotions, aspirations, and social context all matter, but they sit atop a core functional job that has to be solved before any of them can land.
Start with a functional job. Give it a clear beginning, middle, and end. Make it tangible. Then layer everything else on top. If you begin with the emotional, the inquiry diffuses fast. If you begin with the functional, you have something you can map, test, and build around with precision.
Jobs to Be Done mapping helps you to identify functional, social and emotional jobs for a specific persona in a specific situation. It is one of the core tools for surfacing the kind of insight that leads to genuinely differentiated solutions, rather than incremental improvements to what already exists.
Innovation in Action explores Jobs to Be Done in depth, featuring Jim’s work with StepStone to illustrate how organisations can use JTBD to create meaningful differentiation at scale. Order your copy now to gain practical insights and detailed guidance.
JTBD as a collaboration enabler
Most people encounter Jobs to Be Done as a research method – something you do at the start of a project to understand your customer before you start building. Jim thinks that framing misses the bigger opportunity.
“I teach Jobs to Be Done as a collaboration tool.”
Here’s what he means. In most organisations, requirements emerge from unclear sources. A senior stakeholder mentioned something. A competitor shipped a feature. Someone read an article. The list grows. Priorities shift. And nobody can trace any of it back to an actual customer need. Teams spend more time arguing about what to build than they do building.
What Jobs to Be Done provides when it’s embedded properly is a common language. A consistent, precise way of describing customer needs that everyone across product, marketing, UX, and leadership can point to.
Jim spent two and a half years helping StepStone Group, one of Europe’s largest online career platforms, make exactly this work at scale. Four hundred people in a product organisation, operating in a crowded marketplace, with a leadership team that wanted genuine differentiation, not another incremental feature release.
They started small. Two dozen people trained. A pilot to test whether JTBD was the right lens for their context. Then, a large-scale quantitative study of over 9,000 job seekers, mapping unmet needs across the entire job search journey, what Jim describes as fever curves showing precisely where pain was most acute and value creation most urgent.
The results weren’t just insights. They were a culture shift. Teams began anchoring sprint documentation and product requirements to specific unmet needs. One team built a virtual interviewer feature to address the anxiety people feel before job interviews. It launched with an NPS of 70. 60% of users said they’d keep using it.
“JTBD became coffee talk,” Jim says. “People started discussing unmet needs in hallways and sprint reviews.”
That’s the real payoff. Not a better research process, but a better way for teams to make decisions together, grounded in what the customer is actually trying to get done, rather than what the organisation has already decided it wants to build.
Practitioner Insights
The next time your team is deciding what to build, try these three questions before you open the backlog.
Can you state the customer’s job without mentioning your product? Pick any item on your current roadmap. Describe, in one plain sentence and with no reference to technology or your solution, what the customer is trying to accomplish. If you can’t, your requirement isn’t grounded in a customer job, it’s grounded in an internal assumption.
Are you starting with a functional job? Before exploring what customers feel about a problem, clarify what they’re actually trying to do. Name the job. Map the steps. Make it concrete. The emotional and social dimensions matter enormously, but they build on the functional foundation, not the other way around. Miss the functional job, and everything above it becomes guesswork.
Where could a shared language take root in your team? You don’t need a full JTBD programme to start. Pick one touch point in your existing workflow – a sprint kickoff, a brief template, a planning session, and introduce one question: what’s the customer’s job to be done here?
The organisations building in spaces their competitors haven’t found yet aren’t smarter. They’ve just stopped building from the inside out.
For those interested in learning more, there are more ways to explore this topic.
Watch my full conversation with Jim on YouTube – where we get into solution gravity, how to run a job map, and the StepStone story in Jim’s own words.
Jim is a contributor to Innovation in Action, where his StepStone case study anchors the Jobs-to-Be-Done tool in the Understanding chapter. If you want to see how JTBD fits inside a complete innovation process, the book is the place to go.
Thank you to Jim for the conversation. I learned so much about applying JTBD in practice. The reframe from research method to collaboration tool is at the forefront for me.
Q: Does your team know what job it’s actually building for?
See you next week, Vaughan.