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 to determine the alternate route before you had to make a turn. Furthermore, it was more accurate because it calculates 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.