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.