How Can an Agile Team Be Customer Value Focused?

Though there’s no one-size-fits-all approach to delivering customer value, here are the best ones that you can use to get started.

Published

The first principle in the Agile Manifesto tells us that “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

And while agile is intentionally lightweight and purposefully incomplete, I’ve seen that many agile teams have a hard time to determine how exactly they can deliver valuable software.

Customer value, it turns out, can be a tricky thing. Which leaves some people asking… If we approach software development scientifically, why can’t we do the same for value delivery?

How can an agile team be customer value focused?

An agile team can focus on customer value by determining what is causing the customer to use their product in the first place. This includes the pain points that the customer is experiencing, as well as the gains they expect to achieve by using the product in question.

Since the agile movement started in 2001, there’s been a heated debate that remains unresolved to this day about whether or not agile teams can quantify customer value. While there’s no one-size-fits-all approach to measuring value, a number of practices and tools exist that can help agile teams to be more specific about what they deliver for their customers.

After all, delivering customer value is a goal. And agile helps you take an empirical approach to achieving goals. Empiricism is a philosophical school of thought that started along with experimental science in the 17th century. Experimental science gave birth to modern science as we know it today, which I consider as quite a way to prove a concept.

Empiricists think that the best way to attain knowledge is through direct experience. In fact, this is how modern science works. You start with a hypothesis. You then set out to prove it right or wrong through observation and measurement of objects and phenomena that your research considers relevant. And your goal is to make the outcome repeatable and reproducible.

How can an agile team approach value delivery in an empirical and scientific way? In this post, I’m going to share with you three practices and tools that I’ve found useful:

  1. The Jobs to Be Done (JTBD) theory
  2. Seeking out feedback beyond the Sprint Review
  3. The 10 questions to ask to determine true customer value

By the end of the post, you’ll be able to take any of these practices and tools, bring them back to your team or organization, and apply them to fine-tune your definition for customer value.

If I’ve got you curious, then I invite you to keep on reading.

Jobs to Be Done (JTBD) Theory

Customers actually “hire” products to do jobs for them. Which is why knowing what “job” your product is doing for its customers is essential to delivering value.

This is called the “Jobs to Be Done” (or “JTBD”). It was created by the late Harvard Business School professor Clayton Christensen, who wrote about it in his 2016 book, Competing Against Luck: The Story of Innovation and Customer Choice.

While developing the JTBD theory, Clayton Christensen worked with McDonald’s, which had been trying—without much success—to increase the sales of their milkshakes.

The fast food company had created an ideal customer profile for the typical milkshake consumer. They had then assembled a panel of consumers who fit the profile, given them milkshake samples, and collected their feedback about product attributes like taste, texture, quantity, price, and others. The participants in the panels would give McDonald’s very clear feedback. The company would then make changes to their milkshake based on this feedback, only to see no impact on sales.

When McDonald’s invited Clayton Christensen to help out, he and his team started looking at the problem from a different perspective. They started asking themselves, “What job are consumers hiring the milkshakes to do?” So they stood in a restaurant for 18 hours one day and observed which consumers—and on what occasions—were buying milkshakes.

It turned out that nearly half of the milkshakes were sold before 8:30 am. The people who bought them were alone and this was the only thing that they bought before driving off in their cars. The next day, Christensen and his team stood outside the restaurant and started asking these customers what “job” they were “hiring” the milkshakes to do for them.

What the researcher team found was that all customers had hired the milkshakes to do the same job. Each of them had a long and boring drive to work—and they needed something to do while they drove to keep their commute engaging. These customers weren’t hungry yet, but most of them knew that they would get hungry by 9-10 am. So they wanted something filling to drink in one hand as they drove with the other.

Bananas didn’t do the trick as the customers would get hungry shortly after eating them. Donuts were caloric and would crumble all over their fingers as they drove. Bagels were dry and tasteless (and hard to eat while driving). The milkshake, on the other hand, fit in the cupholders of customers’ cars, took 15-20 minutes to drink through the straw, and gave them the feeling of being full until lunch.

When McDonald’s understood the job its customers were hiring milkshakes to do, it gave them insight into exactly what changes to make to boost sales.

McDonald’s moved the milkshakes from behind the counter to the front. They gave their customers a prepaid swipe card to help them not get caught up in a line and be late for work. Finally, they made the milkshakes thicker, so that it took customers longer to drink them through the straw.

By applying the JTBD theory, McDonald’s increased milkshake sales sevenfold.

This is a good example for what the lean startup movement calls achieving product/market fit. It happens when a product satisfies a strong market demand driven by an unmet customer need (or one that was not met well enough before the introduction of your product to market).

Much has been said and written about the JTBD framework. In my experience, I’ve found that you can boil down the framework’s use to one simple job to be done template:

When (trigger or situation), I want to (job to be done), so that I can (desired outcome).

Job to be done template

Here’s one example:

When someone sends me a message on LinkedIn, I want to be notified on my iPhone, so that I can choose whether or not to respond instantly.

Job to be done example

The job to be done is very similar to a user story template (especially in teams that practice Behavior-Driven Development and write their stories’ acceptance criteria in the Given-When-Then format).

One way to adopt this template is to create a backlog of jobs to be done for your product, then map out the specific epics, features, and/or user stories that enable each job to them. Another is to not adopt the template at all, but to create all new backlog items with the customer’s job to be done in mind.

If you want to do a deep dive into the Jobs to Be Done theory and get into the nuts and bolts of the JTBD framework, I recommend reading Anthony W. Ulwick’s 2016 book, Jobs to Be Done: Theory to Practice.

It’s by far the best source of information I’ve come across on the topic.

Seek Out Feedback Beyond the Sprint Review

Feedback is not enough. Gain insight through measurement.

Agile is about working in short cycles and shipping in small chunks, so that you can seek out feedback early and often. This allows you to learn lessons quickly and make small course corrections or major changes (a.k.a. “pivots”) to your plans along the way.

For one reason or another, many individuals and teams misinterpret the meaning of “feedback.” Feedback means the signals that you can get directly or indirectly from your customers and their use of the product (or sometimes their lack of use of the product).

Feedback can be qualitative and quantitative. It can come from conversations with your customers before, during, or after the Sprint Review. It can also come from data that you’re collecting from your product that gives you certain insight.

Simply said, feedback isn’t and shouldn’t be limited to the interaction you have with a couple of stakeholders on your Sprint Review meeting. Identify the “jobs” that your customers are “hiring” your product to do—and start tracking the right metrics.

The 10 Questions to Identify Customer Value

Now that you know the JTDB theory and agree on the need to collect feedback early and often through all useful means, let me propose a set of 10 customer value questions:

  1. Which customer segments is our product serving?
  2. Which customer segments is our product NOT serving?
  3. What jobs are these customers hiring our product to do for them?
  4. What other products or services are helping them get the jobs done?
  5. How can we tell if the product is helping them get these jobs done or not?
  6. Is our roadmap, product backlog, and sprint backlog focusing on the highest-value items first?
  7. What is the customer’s aspiration? In what situation do they want to end up after they use our product?
  8. What’s causing our customer to lose sleep at night? What are the situations that they want to avoid like the plague?
  9. What is causing our customer to take action? What are the biggest fears, frustrations, and obstacles they are experiencing?
  10. How is our product eliminating these problems or reducing these pain points to an absolute minimum?

Any agile organization, team, and individual can ask to inspect & adapt its ability to deliver customer value.

The Bottom Line

There’s more than one way in which an agile team can identify what is creating customer value and measure how well they are delivering it. Some of them I covered in this article, others not.

While there’s ups and downs to each, I think that the only “wrong” way to approach customer value is to choose to not approach it at all.

Let me and the rest of this post’s readers know how you’re solving this challenge in your team and organization in the comments below.

By Dim Nikolov

Jack of all trades and master of none. Dim is a Certified Scrum Product Owner (CSPO) and Certified Scrum Master (CSM). He has a decade of experience as a stakeholder, member, leader, and coach for agile teams.