Product delivery is not the endgame – value is!
In design and technology, we can get drawn to ideas like a moth to a flame.
Someone says, “Chatbot”, then machine learning gets brought up, and before you know it a team is working on something your gut tells you is a waste of time.
In a world where innovation is the holy grail, we’re misled to accept that winning depends on ideas – better ideas, more of them, executed quicker. I’ve certainly been guilty of this.
Sure, research can help fight the good fight – minimizing bad ideas and de-risking others. But it’s tempting to shortcut a state of discovery so that we can speed up our entry into a state of delivery. Delivery is where the rubber hits the road, the ‘exciting’ part. And there’s no shortcut between discovery and delivery like an idea with cachet.
The problem with ideas (besides the fact that we have a natural tendency to cling on to them too tightly) is that they live in the solution-space. Whether it’s a new product, a new service, or a new feature, when we adopt the solution as our obsession and our unit of analysis, we’re missing the point entirely.
This is because humans don’t care about products – we care about progress. We don’t want to buy better cameras – we want to become better photographers. And while we focus on designing the “thing”, the customer’s focus (implicitly, almost unspeakably) is somewhere else entirely: on the outcome they’re seeking.
Product delivery is not the endgame – value is. And as part of multi-disciplinary, cross-functional teams tasked with creating value, we should all have the means to evaluate our work by asking simply: “are we improving our customer’s ability to get to their desired state?”
How exactly? Well, one helpful vehicle is Jobs-to-be-Done.
Jobs-to-be-Done (JTBD) can be described as both a mindset orientation and also an innovation framework.
While it’s been gaining traction in the design industry in recent years, it’s not entirely new. Clayton Christensen, Anthony Ulwick, Bob Moesta and co are considered the founding fathers of JTBD, each contributing to Jobs Theory decades ago in response to ideas-first product development, hoping to turn the art of innovation into a science.
Before them it was economist Theodore Levitt who opined in the 1960s that “People don’t want to buy a quarter-inch drill, they want a quarter-inch hole.” A simple statement with a profound implication – stop studying the product (or the customer) and instead study the job.
True design-led (as opposed to technology-led) innovation comes from finding better ways for people to complete their ‘jobs’ – cheaper, faster, easier, safer, or whatever other measures of success they attach.
In contexts where research can get cloudy and true insights are hard to spot, or where some stakeholders bolt off with ideas that have put the cart before the horse, I’ve used Jobs-to-be-Done as a way of galvanizing the team, nailing down where to focus, creating a shared language and optimizing ideation.
It’s worth mentioning, though, that JTBD is no silver bullet. In fact, there are corners of the industry that don’t even see eye-to-eye on what it really means. I’ll do my best to highlight these tensions while demonstrating how I use it – more as a lens than a robust end-to-end method. I’m no expert, just a budding practitioner.
JTBD relies on a few core principles, and the first is that people don’t buy products and services – they hire them to get a job done.
This job can represent overcoming some problem, achieving a personal goal, avoiding a situation or carrying out some activity, for example. When a better solution comes along, so says Jobs Theory, customers and users will fire yours and make the switch. Ideologically, this isn’t anything new. Alan Cooper and co, years ago, put forth their model of Goal-directed Design, pressing on us to put customers’ desired end-states (where they want to get to) front and centre. There’s a portion of the industry that argues JTBD is simply the same approach under a new moniker, and perhaps it is.
From my perspective, however, JTBD has value as an orientation. With design’s dissemination as a problem-solving, value-creation vehicle across industries and organizations, it’s rigour has at times been diluted – personas have been warped into demographic-based marketing tools, and journey maps regularly zoom in on what users are doing while ignoring the why.
Anything that gets me and my team to stop and say “hold on, what is our user really trying to accomplish here, in the grand scheme of things, how can we help them?” is worthwhile.
The ‘trick’ with JTBD is defining the job – what exactly your product, service or feature is being hired for.
Again, it seems there are a couple schools of thought here (and if you keep up with JTBD thinking in the Twittersphere, you’re probably already familiar with the turf wars that have ensued). One JTBD perspective asks us to define the job as the progress users are seeking to make, and to innovate by resolving the struggles they face in pursuing that progress.
The other perspective invites us to identify the job our users are undertaking as a higher-order process (where our product is likely just one of several they rely on), and to innovate by meeting unmet needs at various points along that process.
An example here might prove helpful. Instead of piggybacking on the classic ‘milkshake marketing’ story in Jobs Theory, let’s consider premium cars from the perspective of a car manufacturer – call them Nexus.
As Nexus sells cars through its flagship venues, dealers and maybe even online, some of its teams may focus their efforts on helping customers buy cars – improving the dealership experience, optimizing web platforms, simplifying financing, or better communicating new in-car features and benefits. But, if you think about it, the customer’s underlying job is not to buy a car – it’s not necessarily to even own a car or drive a car. So, what is their job-to-be-done?
One JTBD camp asks us to uncover the underlying progress some customers might be seeking, framed as ‘Help me’ statements. Through interviewing ‘switchers’ (those who have recently adopted or abandoned the product) about their purchasing decision history, we can uncover their true job and the struggles they face in completing them.
Some car customers might be saying (implicitly), “Help me enjoy superior mobility comfort”; others might be saying “Help me unleash my alter ego” or “Help me keep up with the Joneses.” Zeroing in on the first job around mobility comfort might reveal that customers face anxieties around having to choose a car that provides enough comfort in enough different contexts (city errands, weekends away, etc), or anxieties about ongoing running costs.
The second JTBD camp might ask us to contextualise the act of buying a car in a higher-level job – “Get from A to B conveniently and reliably,” for example. In a job framed as a process in this way, there are steps around accessing a vehicle and being transported in a vehicle, but nothing around necessarily buying or owning that vehicle. Evaluating unmet needs in this job might reveal that customers want to better match the type of car to the type of trip, or reduce the time and money they spend looking after a vehicle.
We can imagine that each approach could help Nexus land at a similar innovation: an on-demand car service that replaces ownership with access. Customers no longer buy a Nexus, but they rent one as they need it, with the freedom to select the right Nexus for their trip and the avoidance of nuisances such as storing the car, insurance and maintenance.
A similar end, however, is not evidence of a similar means, and each JTBD approach does appear to have its nuanced differences. Still, at its core, Jobs-to-be-Done (regardless of approach) demands us to double down on the customers’ underlying purpose – not car buying, not car ownership, but mobility. Consider whether or not you’ve framed your JTBD at the right altitude by asking:
Another common principle across Jobs Theory is that jobs are not purely functional in nature, but also have emotional and social components.
It’s important to recognise these, as they can be important drivers of behaviour in certain contexts. It’s arguably the reason why different levels of Uber’s service exists. From a purely functional perspective, they shouldn’t – but we know that getting from A to B is too simplistic a framing of what’s really going on. If you’ve got all the time in the world, cost-savings may drive you to select Uber Pool; at other times you might select Uber Black, to impress a date for example. Paying due notice to all three dimensions of a job can lead to improvements in the product and experience.
Borrowed from Jobs Theory, I like to frame all the functional, emotional and social dimensions in the following way:
Consider our Nexus example. In the job of Get from A to B, we might be able to map functional dimensions customers attach such as “help me minimise time spent looking for parking;” emotional dimensions such as “help me feel good about the impact I’m making on the environment;” and social dimensions such as “help me be perceived as a trendy urbanite.” If these dimensions outweigh others, I may very well end up buying a Vespa or hiring a bicycle instead of using Nexus’ on-demand car service.
Understanding the various dimensions to a job, and the unmet needs that bubble up for different users in different circumstances, can surface real opportunities to deliver value that resonates at both a functional and personal level.
There’s easily more that could be said about Jobs-to-be-Done. Deeper within the theory, the concept of jobs and ‘job executors’ is used to size markets, to define competitors and to drive product messaging. One JTBD camp relies on switch interviews to uncover the four forces of progress; another camp maps out steps in a job and quantifies the importance and satisfaction of needs at each step along the way.
Without diving into these details, I still believe JTBD has value as an approach, if not a robust methodology. As researchers and designers tasked with improving experiences or creating something new, it helps teams align on language and keep customer outcomes – as opposed to company outputs – front of mind.
It helps us appreciate the greater context of our users’ behaviours, so that we can innovate by being human-first, as opposed to technology-first. And it unlocks the creation of value when we help users make the progress they’re seeking – getting jobs done better, more cheaply, more quickly, more predictably, more conveniently.
(For a more rigorous application of mapping and prioritising desired outcomes against steps involved a job, take a look at Anthony Ulwick’s Outcome-Driven Innovation and his book – Jobs to be Done: Theory to Practice.)