OK, so let's just dive right in. I want you to picture this for a
second. It's it's 7.0 AM.
You're in the drive through line of a big fast food chain total.
Chaos. Exactly.
It's rush hour, everyone's stressed, maybe running late,
and you know they're grabbing what you'd expect.
Coffee, quick breakfast sandwich, orange juice.
The standard stuff. High speed, high efficiency
breakfast for people on the move.
Right. But here's where it gets weird.
One of the biggest chains years ago, they noticed this massive,
totally unexpected sales spike during that exact.
Time, and it wasn't for coffee. No, it was for their milkshake.
A milkshake at 7:00 in the morning.
A milkshake. We're not talking about like a
healthy smoothie. This is the thick, sugary, high
calorie dessert drink. It just.
It makes no sense. Why would a busy commuter hire
something that's heavy takes forever to.
Drink right. You can't.
Just down it. You can't.
Yeah, it seems completely misaligned with, you know, the
whole frantic morning commute vibe.
It is totally misaligned if you're only looking at the
product's features. And that, that exact
counterintuitive discovery, is what led to this huge shift in
thinking about product development, especially in
software. So the answer wasn't about the
taste or the price. Not all.
It came from actually watching and talking to the customers and
it was about the job. Up to be done.
Exactly. The research uncovered this,
this causal mechanism, These customers, they were mostly
alone. They had a long drive ahead.
They were hiring the milkshake to solve 2 problems at once.
Okay. What were they?
The first job was making a really tedious, boring commute.
Well, less boring. And the second was to keep them
from getting hungry before their work day actually started, which
might be hours later. So it moves us completely away
from just listing features and toward understanding, I guess,
customer progress. That's it.
And that's really the core of our mission.
For this deep dive, we're going to unpack Jobs to be Done or
JTBD. It's this theory from Clayton
Christensen and his colleagues. And the goal here is to really
get that shortcut right, to understand the deep reasons why
we choose certain products and how that changes every, I think,
for building better software. If you walk away with one thing
today, it should be this. Stop asking what features people
want. And start asking.
Start asking what progress they're trying to make in their
lives, and, crucially, under what specific circumstances.
OK, so let's breakdown the theory a little more.
JTBD argues people don't buy products they they hire them.
They hire the best solution to get a specific job done
successfully. It's all about the origins of
that decision. Why did someone at this specific
moment decide to bring this new thing into their life?
What's so interesting about that is how it just flips the whole
perspective. Yeah, as a designer, you stop
focusing on your beautiful product.
And you start focusing on the customer struggle.
Yeah. It forces you to put down the
feature list and ask, you know, three really essential
questions. So what?
Are those 3 questions? OK, first, why are customers
hiring our product and under what very specific, repeatable
circumstances? The context is everything.
Second, what's the fundamental problem in their life they want
to solve? Not the symptom, but the real
root problem. And the third.
And this is the most important one for strategy.
What kind of progress are they hoping to achieve by using this
thing? And if we bring it back to the
milkshake, that's exactly how they found the answers, right?
They couldn't get this from spreadsheets or demographics.
No way they had to get out of the office.
They went and sat in the drive through and just talk to people.
And that's where they found the circumstance that 45 minutes
solo commute. And the job was sustained
satisfaction during that quiet alone time.
They weren't hiring it as a dessert.
They were hiring it as a tool. A highly viscous, single
serving, easy to drink meal replacement.
Viscous. That's the keyword, isn't it?
It's everything. Because it was so thick, it took
them pretty much the whole 45 minute commute to finish it.
It solved the boredom and the hunger.
It fulfilled the progress they were looking for.
Wow. So once you understand that, I
mean, the strategic implications must be huge.
Oh, immense. Once a company really that's the
job their product is being hired for, they can serve those
customers so, so much better. And often it's not by changing
the product itself. It's by changing how you deliver
it. Exactly.
So for the fast food chain, once they knew the milkshake was a
commuter's meal, yeah, they could think differently.
Yeah. They weren't just brainstorming,
like, new strawberry flavors, right?
They were looking at the circumstance, right?
So a solution could be just opening the drive through
earlier, yeah, so people don't have to park and go inside,
which just adds friction. Or you could engineer the
product to do the job even better.
Make a special morning milkshake.
You know, maybe with less sugar so you don't crash later.
And make it even thicker. Make it even more viscous, yeah,
to make sure it lasts the whole commute.
The features are then optimized for the job, not just for some
abstract idea of taste. And this just totally redefines
who your competition is, doesn't it?
Completely. Normally a fast food chain
competes with another fast food chain, but in this case the
milkshakes. Real competition.
It wasn't a breakfast burrito. Nope, it was anything that
stopped boredom and hunger on that drive.
A podcast? A travel mug with granola in it.
A banana. That's the part that's so
profound, especially for someone developing software.
If you're building, say, complex accounting software, your real
competitor might not be the other big software company.
It could be a spreadsheet or a physical notebook.
Wait, so if my competition for this high end professionally
built software is a notebook, how can I possibly get
competitive data from that? How do I measure the success of
a notebook? And that's the challenge, but
it's also the beauty of it. You stop worrying about feature
for feature parity with other software.
You start focusing on the friction the customer has with
their current solution. The friction of using the
notebook, yes. Or the spreadsheet.
I mean, think about the job of connecting with colleagues.
For decades the solution was an airplane ticket.
Now a major competitor for a big airline is high definition video
conferencing software. Wow.
The software doesn't have to fly, but it solves the same core
job of connection, just with way less friction and cost.
That's the huge insight. You stop defining your product
by its features and start defining it by the progress you
enable. And this has to apply so
directly to the digital world. I mean, software is never done
right. It's always evolving.
It's a living product, yeah. So if we ignore that fundamental
job, we just end up building these systems that are just full
of unused features of what people call feature bloat and.
You hear this frustration from the people actually building
these things. Sahil Lavinja, the founder of
Gumroad, he put it so perfectly. He just articulated this gap
between obsessing over product and what customers actually
want. Oh yeah, that tweet.
It's It's a must read for anyone in this space.
It really is, he said. People don't want to use your
software. They want to lose weight, laugh,
be entertained, get smarter, spend time with loved ones, go
home on time. Sleep adequately, eat good food,
be happy. Your product is only as good as
the experiences it enables people to have I.
Mean, that's just that's it, isn't it?
The software itself is just this necessary obstacle you have to
get through. It's a tool.
It's not the goal. The goal is the progress in your
life. If the software makes me a
better parent or lets me go home on time, I've hired it
uccessfully. If it just adds more work, I
fire it. There's a perfect real world
case of this right into it and how they created QuickBooks.
A textbook example. They already had Quicken, which
was a huge deal for personal finance, but they noticed
something really interesting happening in the early 90s.
Yeah, they saw some of their users.
Small business owners were kind of improvising.
They were trying to force Quicken to do their business
accounting. Even though it wasn't built for
that job at all. Not even close.
And at the same time, all the other business accounting
companies were just trying to build the best accounting
software, which meant more and more complex features for
professional accountants. They totally overshot the job
for the actual small business owner.
They did. Because that person's job isn't
to do accounting, it's to get this stupid paperwork done so I
can get back to my real business.
Exactly. And Intuit CEO Scott Cook?
He realized their focus shouldn't be on matching
features with the Pro software. It had to be on the job of
simplicity and speed. So they built QuickBooks just
for that job, and the result was.
Phenomenal. It just took off.
It completely displaced those super specialized feature heavy
competitors. And here's the crazy part, the
financial take away, they sold it for a higher price than a lot
of competing systems that had, you know, technically more
features. It just goes to show you when
you nail the job and reduce that friction, people will absolutely
pay a premium for that progress. Value changes completely.
It does. We even saw this approach used
to sort of course correct and major tech company look at
Twitter X now back around 2021. Right, they were trying to do
too many things at once. Yeah, and the leadership
realized that the CEO at the time said they were going to
focus the platform's whole evolution not on features, but
on three strategic jobs for users.
And those were discovering what's happening.
Conversing online and and this was a big one, getting financial
compensation for their tweets. So those three jobs drove their
entire engineering road map. It was the why, not just the how
the. Why?
That's always the starting point.
So finding the job is the most critical step.
How do we? How do we actually do it?
Well, just like with the milkshakes, it takes active
effort. You have to get out there, you
have to observe customers, you have to talk to them, really
interview them in depth. And this must have a direct
impact on how tech teams write requirements.
The traditional user story, it kind of falls short, doesn't.
It it often does that old template as a user I want a
feature so that I get a benefit. It can lead you down the wrong.
Path because you end up just building the future the customer
asks for. Instead of solving the problem
they actually have. It's the classic trap.
The customer says I want a clock on the dashboard, right?
But the job they're trying to do is not be late for my next
meeting. You could build the world's best
clock, but maybe what they really needed was better
calendar integration or traffic alerts.
You have to find the job behind the feature request.
Which is why the sources push this idea of job stories.
It's a different way of writing things down.
A different template? Yeah.
It forces you to get clarity on the context and the motivation
before you even think about a solution.
And the template is it's. Smell, yeah, when situation I
like to motivation. So that benefit you have to
state the context first. That's half the battle.
OK, so let's apply that back to the milkshake.
A traditional user story might be the user wants a large
milkshake. Vague.
Not very helpful. But a job story would be when
I'm driving to work alone on a long commute, I like to drink a
milkshake so that the trip is less tedious and I don't feel
hungry when I get there. See, that story captures
everything. The circumstance, the job, the
progress. It's so much richer.
So what's a practical tip for this when a customer asks for a
feature? This is a great one.
You just ask them one simple question.
How are you solving this problem right now without this feature?
That's smart. It immediately tells you the
context, their true motivation, and who your real competition
is, even if their current solution is some messy duct
taped workaround. And it shows you all the
friction points. That's gold for improving a
product. Pure gold.
So this all leads to this this fundamental mindset shift,
moving away from how things are normally done.
It really is a different way of thinking.
Traditionally a company starts with supply.
They build a cool thing with lots of features and then they
try to like create demand for it with marketing.
It's the build it and they will come model which often doesn't
work. But GTBD says do the opposite.
Yeah, you start with a demand, the customer's real job, and
then you work backward to figure out the supply, the features you
need to build. Exactly.
And that is so valuable for modern software where the
requirements are often, well, they're emergent.
What do you mean by emergent? I mean, the customer can't
really tell you what the final solution should look like.
They've never seen it before. They just know the pain point.
They know the pain, they know the job that needs doing, so by
focusing on that job, we can build solutions iteratively that
actually deliver that progress. It's why this works so well with
things like design thinking. It keeps innovation focused on
solving real problems, not just, you know, adding more buttons.
You got it. The ultimate benefit is you
avoid building these huge, bloated systems filled with
features that deliver little progress for customers and
therefore end up not being used. We build progress, not just
software. That's the perfect way to put
it. Success doesn't come from having
the longest feature list, it comes from identifying the
specific progress a person is trying to achieve in a specific
context. And then engineering a solution
to make that happen with the least amount of friction,
whether that solution is a piece of software or a really thick
beverage. Exactly.
So as you're thinking about this deep dive, maybe reflect on your
own life or on the systems that you manage if the real
competitor for accounting software can be a simple
notebook. What seemingly unrelated low
tech tool are you hiring right now to get a tedious job done in
your daily routine? That's a great question.
I mean, think about it, are you, metaphorically speaking, using
the standard issue high calorie milkshake when what you really
need is that highly viscous low sugar formula that's built just
for your 45 minute commute? Identify the true job.
Yeah, that's the first step. It's the first and most
important step, and for anyone who wants to go deeper, we
really encourage you to check out the further reading,
especially the book Competing Against Look.
It'll really change how you see the world of products in
progress.