Learn and Measure Before You Build: Using JTBD to Improve The Build-Measure-Learn Feedback Loop

You can use Jobs-to-be-Done to learn from your customers and measure a new product idea before building anything.

The Build-Measure-Learn Feedback Loop is a core tenet of the lean startup methodology, popularized by Eric Ries. The main argument is spending too much time behind closed doors, chasing down a perfect product, increases the cost of failure. To decrease the cost of failure and preserve resources to iterate towards growth, Ries and other lean startup practitioners suggest the following process:

  • Develop a hypothesis
  • Get a low-cost minimum viable product out to the market
  • Measure the results
  • Learn from the results
  • Iterate i.e. return to the build phase.

The assumption is the best learning occurs when people use your product. So, you build, measure, learn, and then repeat. The primary benefit is getting customer feedback and learning if an idea will work before it “gets too far,” i.e. before significant resources have been sunk into a product that customers never wanted in the first place.

We all know that building an MVP no matter how minimum it is, will never be free. And anyone who has tried to build an MVP, especially at a big company, has likely suffered from MVP-scope creep. Suddenly, people start calling the MVP “v1” and are asking engineers to participate in its development. And while they’re at it, they get marketing to whip up some creative to drive users to the MVP. The costs balloon.

The next frontier in decreasing the cost of product development and mitigating the risk of failure in your business and your role is to measure and learn from customer feedback before building anything at all, even an MVP.

Jobs-to-be-Done enables you to measure the likely results of an idea before the first line of code is written or the first pixel of a design is placed.

Here’s how you measure the value of a product idea before building it:

  1. Determine what job customers would hire the product to do.
  2. Determine which needs in the job your product idea satisfies and if those needs are unmet.
  3. Compare how quickly and accurately your new idea satisfies the unmet needs to how quickly and accurately the existing solutions satisfy them.

What job would customers hire the new product to do?

“Your customers do not buy your product; they hire it to get a job done. The struggle with the job causes a purchase,” says Clay Christensen, author of Innovator’s Dilemma and Competing Against Luck. The first step in measuring your product idea is to identify your customer’s job, in other words, the goal your customer is trying to achieve.

Sometimes the goal is obvious. Salespeople want to acquire new customers or close new business. When it’s not so obvious, customer interviews can reveal the job-to-be-done.

For guidance on articulating a job-to-be-done, you can read our post, How to Answer The Question, “What’s the job-to-be-done?”

In the meantime, here are a couple of quick tips:

  • A job is has a clear goal, an action verb, and direct object e.g. “get to a destination on time,” “acquire new customers,” or “create a mood with music.” Your customer is the subject of the sentence, not your company.
  • No solutions. Products, solutions, and technologies change over time. To maintain a stable target for your team, keep them out of your job definition.
  • The “wake up in the morning” test. It should make intuitive sense for someone to wake up in the morning with the job-to-be-done on their mind, thinking, “I have to do this today!” For example, unless you live in a city with alternate side parking, you don’t wake up thinking, “I need to park my car today!” But, you might wake up thinking “I need to be on time today!” The job is “get to a destination on time,” not “park the car.”

Identifying the job-to-be-done is the first step in learning from your customers before building.

Does your idea target an unmet customer need?

Once you’ve identified your customer’s job-to-be-done, you need to identify their struggle i.e. their unmet needs in the job.

What is a customer need?

Does your company agree on what your customer’s needs are?

In Jobs-to-be-Done, we define customer needs as an action a customer must take using a variable required to get the job done.

One way to think about customer needs is the actions that must happen quickly and accurately for the job to be executed successfully.

For example, in the job of “get to a destination on time,” three of the many variables are travel conditions, open times, and the distance between the parking spot and the destination. Here are examples of actions that need to be taken:

  • Determine if an alternate route should be taken due to unexpected travel conditions
  • Determine the open times of any planned stops
  • Find a parking spot close to the destination

If your decision to take an alternate route does not happen fast enough to take the route or you choose the wrong route (the decision is inaccurate), you will not get to the destination on time.

You can measure the speed and accuracy of customer needs in Jobs-to-be-Done, and the measurable needs are the foundation of measuring before building.

The measurement begins by determining which needs are unmet.

After interviewing customers to validate your list of customer needs in the job, you can run a survey asking customers which needs are important and not satisfied and their willingness to pay to get the job done.  The interviews are learning from your customers. The survey is measuring.

Needs that have high importance and low satisfaction are unmet. The survey gives you quantitative evidence of what percentage of customers find the need to be unmet and whether or not they are willing to pay to have their needs in the job satisfied.

The Jobs-to-be-Done survey measures whether or not a problem is worth solving.

For example, before Waze launched we conducted a survey for the job “get to a destination on time.” The highest scoring unmet need in the results was “determine if alternate route should be taken due to unexpected travel conditions.” Waze satisfied this need and enjoyed accelerating growth.

Once you identify the unmet needs in the job-to-be-done, you need to determine if your product idea is targeting one of them. This is a major learning moment–you learn if your idea is solving a worthwhile problem or if it is a solution in search of a problem. And you have learned this before building.

Compare your idea to the speed and accuracy of the existing solutions

Assuming you learned in step two that your idea is attempting to satisfy an unmet need, it’s time to measure if it does so better than the existing solutions. Customers switch to a new solution only when it gets the job done better.

What does “better” mean?

Above, we noted that customers want to get the job done quickly and accurately. To pressure test this, consider the following: Are there any goals you have that you like to achieve slowly? Can you achieve them at all if every step you take in the process is inaccurate? Can you think of any successful products that helped customers achieve goals slowly and less accurately than the previous solutions?

“Better” is satisfying the unmet need faster and more accurately than the existing solutions.

To determine if our solution is good enough to invest in, we first identify competitive solutions, measure how quickly and accurately they satisfy the targeted unmet need, and then compare those metrics to the speed and accuracy of our new idea.

The competing solutions aren’t bound to similar products. It’s any product, service or manual solution that customers use to get the job done.

Before Waze launched, customers used Google Maps, traffic reports on the radio, and calling a friend to determine if an alternate route should be taken to unexpected traffic conditions.

If we were to measure the speed and accuracy of Google Maps in this scenario, we would use the product and write out the steps. Remember this is before the app had a feature that would automatically suggest a new route. To determine an alternate route, users had to:

  1. Drag the route line on the map to a different road
  2. View the new calculated time to destination
  3. Compare it to the original route
  4. Repeat for all variations until the fastest route is found

This took a few seconds to many minutes depending on how many variations the user was willing to try. The real killer here was the accuracy. It was so hard to identify alternate routes that people would stop this well before testing them all. Therefore, the decision to take an alternate route or not was often inaccurate.

Now, we have speed and accuracy benchmarks: seconds to minutes and inaccurate.

Waze’s auto-suggest feature was automatic and instantaneous, enabling you determine the alternate route before you had to make a turn. Furthermore, it was more accurate because it calculate the variations for the user.

The trick is that we can measure this idea before building it by determining how fast and accurate it would be if executed perfectly. If we determine it would be less fast and accurate than the leading existing solution, we have learned that the idea is not good enough and not worth investing in, even at an MVP level.

Learning and Measuring Before Building the MVP

At this point in our process, we have:

  • Learned the customer needs from our customers
  • Measured the unmet needs–problems worth solving
  • Learned if our product idea is targeting an unmet need
  • Measured the willingness to pay of the customers: is there a market worth targeting?
  • Measured the performance of the competitive solutions
  • Learned if our solution is better than the existing solutions and can cause people to switch to it if executed well in the build phase.

In short, we have measured and learned before building.

Either you will learn that your idea requires more refinement before its worth building anything, even a prototype, or you will have validated the idea and know which features are critical to include in the MVP.

In both cases, you have not only decreased the cost of a failed idea but you have also decreased the the cost of success.

Now that it’s time to build your MVP, check out this post on how you can integrate jobs-to-be-done and agile workflows.

Reach out to us to get more detail about how to do any of the above at your company.

Posted by Jared Ranere in Competitive Analysis, Customer Needs, Idea Generation, Innovation, Jobs Theory Blog, Roadmap Planning, 0 comments

JTBD Product Management: An Education Market Example, Part 3. Road Mapping, Aligning the Team, & Scoping an MVP

This week features the third and final installment of our JTBD Product Management: An Education Market Example series. If you haven’t read them already, check out Part 1, Part 2, and our Cheat Sheet. With this series, we’re presenting you with an overview of how the Jobs-to-be-Done framework can help you view product management and product development through a different lens – one which focuses on the customer, the job they are trying to get done, and their unmet needs.

We’ve been using the educational publishing industry in order to bring this thinking to life, but the ideas presented here can be applied to any industry where you’re tasked with creating new products, or new features to existing products.

In today’s post we’ll talk about how to prioritize your road map, align your team and develop your minimum viable product.


When you spend all day, every day thinking about your product, it’s only natural that your success metrics will be product-centric. For example, if you’re building an education app road map, you might optimize for an increase in “time spent in app” or “frequency of sessions.” Any feature that would make these metrics go up would be high priority.

However, if you’ve read the previous entries in this series you know that the customer’s satisfaction with getting the job done is your ultimate target. When developing a road map, Product Managers using Jobs-to-be-Done prioritize features that serve the most important and least satisfied customer needs.

If we’re working on the job “learn a subject,” we might find that “minimizing the likelihood of having a question that can’t be answered in the moment” is very important and not satisfied. Interestingly, a feature serving this need might cause users to spend less time in our educational app because more of their questions are answered right away and they are learning the subject faster. The app is increasing value for the customer even though a commonly used KPI is decreasing.

Prioritizing by customer needs leads to releases that deliver value to users and avoids those that could be great for the business but irrelevant to the users.

Align Team

Designing, developing and bringing a new product to market requires a team of skilled individuals who are committed and focused on a common goal. You’re going to be challenged with a host of difficult decisions from feature prioritization to scope to where to invest resources. Even the best teams can be challenged by these situations, especially when the time for discussion ends and choices need to be made.

All too often, this is when the course is determined not by data, but by The Boss, who makes a suggestion that’s really more of a directive. Since she’s in charge, the HIPPO (HIghest Paid Person’s Opinion) rules. As a result, your team is left in a state of frustration. Everyone is left to argue for their ideas on what to prioritize and the result is time and money wasted, a dysfunctional team, and customers who are potentially confused by or unsatisfied with your product.

So, how do you get team alignment? By removing the personal and focusing on the measurable. When you measure things like speed and accuracy, you eliminate opinion or hunches. If the research shows that students learning algebra have an unmet need to “reduce the time it takes to learn how to factor quadratic equations” and it currently takes days, everyone can get behind an idea that reduces that time to hours or even less. When you align the team around customer needs, opinions matter a lot less.

Scope MVP

The idea of delivering a minimum viable product to market as fast as possible is so widely accepted, it’s nearly conventional wisdom. But, how do you know which features belong in the MVP? What makes your product viable?

You and your team may bring years of training and experience to the task so you could rely on intuition. Or you could attempt to estimate the impact on your business and include the features that will generate pageviews or time spent in your app or repeat visits–whatever your KPIs are. Or you could show the MVP to your customers and say, “Do you like this?” If they say, “yes,” are you ready to go?

When scoping your MVP, Jobs-to-be-Done thinking prompts the question, “What features will have the most impact on my customer’s needs?” For example, Britannica may have shown new editions of its encyclopedia with “even more volumes” to its customers. They may have said, “Great! We love information. Bring on more volumes!”

But do the extra volumes help reduce the likelihood that a student’s question can be answered in the moment? Does it reduce the time it takes to find the definition of an unfamiliar word?

“Liking” a product is not the same as having it serve your needs much better than previous solutions.

Jobs-to-be-Done assumes if you create value for your customer, value for your business will follow. The features that belong in your MVP are those that serve at least one important and unsatisfied customer need. It’s best if your MVP meets the most underserved need i.e. the one with the highest opportunity score. If your MVP doesn’t serve an unmet need, you’re not ready to ship. If your MVP includes features aligned with over-served needs, you may have to re-think your roadmap.

That wraps up our JTBD Product Management introductory series. We hope you’ve found it informative and that it has sparked questions, such as “Is our company defining our market as a product or a job?” “Is someone out there getting our job done better with a different product?” “Do we agree on what a customer need is and does our MVP meet at least one?”

If you feel you could benefit from implementing the thrv approach, get in touch with us. We’d love to talk with you about how our products and services can help you launch high growth products. Be sure to check the thrv blog regularly for more ideas, stories and insights on how to implement the Jobs-to-be-Done framework.

Posted by Jay Haynes in Jobs Theory Blog, Roadmap Planning, 0 comments