A Feature Isn’t a Feature. It’s a Job to Be Done.

For a long time, I saw features defined as collections of user stories.

The team had a certain amount of capacity. We knew roughly what we wanted to build. So we grouped the stories, estimated the work, fit what we could into the available capacity, and called the collection a feature.

It was practical.

It also created a problem.

We were shaping the customer experience around our capacity instead of shaping the work around the job the customer needed to accomplish.

And sometimes, important parts of that job simply disappeared.

Start with the job, not the stories

Today, I prefer a much simpler definition:

A feature should enable a customer to complete a Job to Be Done.

I should be able to describe clearly what someone will be able to accomplish when we're finished.

That sounds like a small change in language. It isn't.

A collection of user stories tells me about the work we're planning to build.

A job tells me about the value we're trying to create.

That immediately gives the team a different way to think about scope.

Instead of asking, “Which stories fit?”

We can ask:

“Can the customer successfully complete this job?”

Jobs make outcomes easier to see

One reason I like framing features around jobs is that jobs lend themselves naturally to measurement.

Did the customer successfully complete the job?

How long did it take?

Where did they struggle?

Did they abandon it?

Did we make it easier, faster, clearer, or more reliable?

Suddenly, success isn't defined by whether all the user stories moved to Done.

It's defined by what changed for the customer.

That also makes it much easier to establish a baseline before we start building. If we understand how customers perform the job today, we have something meaningful to compare against after we release.

The feature isn't the measurement.

The customer's ability to accomplish the job is.

Customers don't think in features

There is another benefit I've come to appreciate: Jobs to Be Done gives us a much better way to talk with customers.

Customers don't necessarily care about “Feature X.”

They care about being successful in their role.

So instead of asking customers what they think about a feature we've already imagined, we can have a much richer conversation.

What are you responsible for?

What are you trying to accomplish?

What makes that difficult today?

Where do you lose time?

What information do you need?

What does success look like?

Those conversations keep us anchored in the customer's reality rather than asking customers to react to our internal product vocabulary.

One initiative can contain multiple jobs

This becomes particularly important when a product serves multiple personas.

Imagine a workflow where one person initiates something and another person receives, manages, or completes it.

From the company's perspective, that might look like one feature.

From the customer's perspective, there may be two very different jobs.

Those should be understood separately.

Each persona has different responsibilities, context, information needs, constraints, and definitions of success.

Separating the jobs lets product, design, and engineering focus on each experience. It can also make the work easier to divide across engineering teams.

More importantly, it helps prevent a common problem: designing the workflow primarily around one persona.

When we treat the entire interaction as one big feature, it's surprisingly easy to create an excellent experience for the person on one side and an awkward one for the person on the other—or to overlook an important reality affecting one of them entirely.

Breaking the work into distinct jobs forces us to understand the value we're creating for each person.

That doesn't mean pretending the jobs aren't connected.

Dependencies should be explicit. Two jobs may need to release together for the overall experience to work.

Separate the jobs. Understand the value independently. Design the experience holistically.

Smaller isn't the goal

This distinction matters because I don't think the answer is simply “make features smaller.”

Small work isn't automatically valuable work.

I've seen features become complicated collections of stories because we were trying to squeeze too much into a single definition of value. The result was longer release cycles and fewer opportunities to continuously deliver something meaningful to customers.

Breaking a large initiative into customer jobs gives us a more useful boundary.

We're not slicing work simply because we want smaller tickets.

We're looking for the smallest meaningful customer outcome.

That is a very different thing.

Follow the customer flow

Thinking this way also changes how I approach the customer journey.

The question isn't simply whether we've represented every screen, requirement, or user story.

It's whether we've followed the customer through the entire job.

What happens before they start?

What information do they need?

What decisions do they make?

Where can they get stuck?

What happens when something goes wrong?

What tells them they've been successful?

And what happens next?

When we start with capacity and stories, those moments can become edge cases.

When we start with the job, they're part of the experience.

“Done” needs a higher bar

This is probably the biggest change in my thinking.

Shipping isn't done.

Engineering completing the stories isn't done.

Releasing the feature isn't done.

Those are important milestones, but they're not the outcome.

Done is when we can measure that the customer has achieved meaningful value.

That means our work doesn't end at release.

We need to know where the customer started. We need to understand the outcome we're trying to change. We need to measure what happens after release. And we need to be willing to learn and adjust when reality doesn't match what we expected.

That's harder than moving a collection of stories to Done.

But it's also much closer to why we're building products in the first place.

A feature isn't valuable because we shipped it.

It's valuable because someone can now do something meaningful that they couldn't do—or couldn't do nearly as well—before.