Roadmap Planning

8 Signs You Need a Product Development Framework

Process and frameworks can get a bad rap. Many companies are proud of having a light-weight or loose process, considering themselves “agile,” “fluid,” and “intuitive.” They may even say their work is like jazz and they don’t want to restrict their creativity. Most of all, teams fear that process will slow them down.

But, a company can also be dragged down by a lack of clarity: about decision-making, goals, and what’s causing goals to be missed. This condition can cause a downward spiral of guesses, failures, frustration, and a lack of trust that leads to more guessing and so on.

Here are eight signs that your company is on the verge of a downward spiral and tips on how a strong product development framework, such as Jobs-to-be-Done, can rescue you.

Sign 1: Missing Revenue and Profit Growth Goals
When your company is failing to hit its growth goals, be it revenue or profits, it puts strain on every team.

Revenue problems put stress on the sales team first. If only they could sell better, the company will earn more money.

All sales teams should aspire to be well-oiled, high-performance selling machines, but there is little they can do if the product does not satisfy customer needs better than the competition. See Wells Fargo’s recent fraudulent sales scandal as an example of how damaging it can be to put all of the revenue pressure on the sales team.

Sign 2: Disagreement on Customer Needs
To get growth back on track, the product team needs to ensure that their product is satisfying customer needs better than the competition. This raises an important question: What is a customer need?

Your product team may lack an agreed upon definition of a customer need, let alone agree on your customers’ needs.

If this is true, they’ll tend to use proxies to determine what to build:

  • Customer feature requests (“I want a faster horse.”)
  • Sales team feature requests (“I can close this deal if you’ll just build this feature.”)
  • Feature ideas from stakeholders, executives, etc. (“I love this idea. I know if we build it we’ll get growth. I can just feel it.”)
  • New technologies (“Augmented reality is the next big thing. Our customers need it!”)
  • New channels (“Everyone is on Snapchat. Our customers need us there too.”)

The problem with these proxy inputs is that they change frequently and often rapidly, which means the team is attempting to hit a moving target. A framework can provide a stable definition of customer needs.

Sign 3: Road maps Prioritized by Fierce Debate and Negotiation


How many times have you seen someone use their rhetorical prowess and passion to convince the room that a feature should be built?

How often do you hear someone refer to roadmapping as “horse trading?” Are your roadmap meetings exhausting and exasperating, with internal stakeholders jockeying to “win” the meeting by getting “their” features prioritized?

A colleague’s persuasive abilities have no bearing on the extent to which a feature idea will solve your customer’s problems.

Under the stress of such an environment, you may resort to answering easy questions, “Do I like how this feature looks?” or “Will I feel better if I give my colleague her way and get this meeting over with?” rather than the most important question, “Will this roadmap satisfy customer needs better than the competition?”

Sign 4: The HiPPO Rules
The HiPPO is the “Highest Paid Person’s Opinion.” It’s a fast way to decide what should be on the road map, but is it the best path to growth?

If the highest paid person happens to be very close to the problem you’re solving with your product, you might be in luck. When answering the question, “Do I like this?” she may do so from a frame of reference similar to your customer’s.

But, in larger companies, the highest paid person may be far removed from the customer’s problem or perhaps has never experienced it. Her primary activity could be managing people and nowhere in the job description did it say, “Must have experienced our customer’s problem.” If that’s the case, what she likes and doesn’t like could be wildly different from what’s useful to the customer.

Sign 5: Shiny New Object Syndrome Leads to The Disposable Road Map
With technological progress at a rapidly accelerating pace, you can expect exciting new technologies and channels to come on the scene very frequently. What do you do about it?

Do you let the shiny new objects steal your focus and cause you to throw out your road map? Or do you have a clear criteria for whether to adopt new capabilities or discard them as mere distractions?

Maintaining agility with your product road map is a virtue, but it has limits. If you find your road map is ripped up so often that you never finish a feature or you’re constantly releasing half-baked features that never get their planned iteration cycles, you’ve got a problem.

All this zigging and zagging will lead to a product full of elements that “sort of” work, none of which are truly great, and none of which bring value to the customer.

Chasing the shiny new objects and constantly changing the road map are indicators that your team disagrees on what the customer needs are. You’re likely using the proxies mentioned above (sales requests, new tech, etc) to determine what to build and as they change, your road map changes.

Sign 6: Launches Met with Crickets


You know when you put something out there, loud and proud, and all you get in response back is…crickets?

That can happen with a product release as well. Your team puts in a lot of hard work and gets very excited to show it to the world. The launch happens, you celebrate, and then you realize a week later that no one is using the new features in your product..

The obvious answer in this situation is “oh, the users haven’t found the feature yet. Let’s add help text or a flashing message somewhere to point it out to them.” If you do this and three weeks later there is no uptick in usage, you have a bigger problem. Either the new feature isn’t serving a customer need at all or the need it serves is already met.

Sign 7: Feuding Product and Marketing Teams
As a product person, have you ever looked at a marketing campaign and thought, “Why are they promoting that?”

And as a marketing person, have you ever read release notes and thought, “Why would a customer care about this? I guess I’ll just call out the new features.”

Or perhaps you’ve witnessed your product and marketing teams denigrating each other: “I just can’t understand what that team is doing. I don’t think they even know.”

If this sounds like a familiar pattern, you have a communication breakdown between your product and marketing teams that a framework can help solve.

Sign 8: Reinventing The Decision-Making Wheel
Last week you presented a deck with designs your stakeholders loved. Two weeks ago you assessed the impact of a new idea on your team’s KPIs. Three weeks ago the executives were compelled by the user problem and approved your plan.

To prepare for the next defense of your road map, you’ve been meeting individually with various stakeholders, trying to determine what’s on their minds.

If the criteria for decision-making is constantly shifting and needs to be divined from tea leaves, you could really use a framework.


The Solution
A product development framework like Jobs-to-be-Done can prevent the downward spiral of guessing, missing goals, growing frustrations, negotiations, more guessing, etc.

The key idea behind Jobs-to-be-Done, a framework based on the theory of the same namepopularized Clayton Christensen, is that your customers are not actually buying your product, they are hiring it to get a job done. This is important because your customer’s struggle with the job is what causes them to look for a product and make purchase.

In Jobs-to-be-Done, customer needs are a precise articulation of that struggle. Needs are the metrics customers use to judge how well they can execute the job. Since people want to get the job done quickly and accurately, customer needs are written in terms of time and likelihood. For example, drivers who want to reach a destination on time (a job-to-be-done) need to “reduce the time it takes to determine if they should take an alternate route due to traffic conditions” and “reduce the likelihood that recent road modifications are not considered when setting the route.” Those are two customer needs in the job that are stable and the team can target with their road map.

This brings us to a key question: What does it mean to satisfy the need “better” than the competition?

Now that we’ve defined needs as metrics of speed and accuracy, “better” is easy to define and detect. The solution that meets the need faster and more accurately is “better,” i.e. it will deliver more customer satisfaction.

If the product team delivers solutions that meet the needs in the job faster and more accurately than the competition, people will use the product and put growth back on track. Marketing the product becomes easier as the features are designed with the customer benefit in mind at the start, which can be promoted at launch.

With Jobs-to-be-Done, the team gains alignment around satisfying customer needs, which leads to hitting growth goals. This customer-centric approach minimizes internal debate and negotiation because it raises the conversation away from individuals’ goals and their products to how groups work together to resolve a customer’s job faster and more efficiently. It puts the focus on your customer’s goals and assumes that if you deliver against them, everyone in the company will hit their own goals.

Your team will have common goals, common metric-driven means of evaluating proposals, and a common language with which to discuss it, decreasing the conflict and the ferocity of the debate and negotiation in the roadmapping room.

When you adopt Jobs-to-be-Done at your company, decision-making meetings can get pretty boring. The criteria is almost always “does the proposition on the table satisfy the targeted customer need in the job better than the competition?” You may have an interesting conversation about what you can do to have an even better idea, but the criteria remain the same.

If you’ve seen one or more of the above signs at your company, you’re not alone. Many teams have experienced these problems. Fortunately, there is a solution. Find a framework that works for you. And contact us at thrv.

Pitch Like a Startup to Win Budget at Your Big Company

Many people think that only entrepreneurs need to pitch investors and raise money, but the same process is happening every day in big companies. Boards, executives, and stakeholders are trying to determine how to allocate funds just like venture capital firms and angels. As a product manager or department head in an enterprise, you need budget to fund your projects and ideas. Just like an entrepreneur, you need to craft a compelling story that demonstrates your project will generate more money than is put into it.

But what makes a good pitch?

Our Product Pitch Cheat Sheet shows you.

We’ve combined top venture capital firm Sequoia Capital’s Writing a Business Plan–the outline of the story they need to hear to invest–and the Jobs-to-be-Done product development method to generate a clear and concise guide to pitching a product idea.

Sequoia’s outline tells you what to cover, and Jobs-to-be-Done helps you answer the key questions that will give you confidence in your material, such as:

  • How do you know your problem is worth solving?
  • How do you know your solution is good enough?
  • Is your market big enough?

Whether you’re trying to find budget to launch a new product or initiative, get more resources for your team, or confirm for yourself that your project is worth pursuing, Jobs-to-be-Done can quantify the justification you need to win investment.

After the cheat sheet, you’ll find Sequoia’s outline with the JTBD guidance under each point. If you’d like to learn how to do all of this yourself in detail, don’t hesitate to contact us.

 

1. State the Company Purpose
As Clay Christensen says, “your customers aren’t buying your product, they are hiring it to get a job done.” A “job” is an important goal that a person is trying to achieve in their personal or professional life, such as “reach a destination on time,” “acquire a customer,” or “overcome diabetes to achieve optimal health.”

The struggle people feel in attempting to get their job done is what causes them to look for a new solution–a product to hire. We call people who are trying to get a job done “job executors.” If your company gets the job done for the job executors, they will use your product.

A direct and simple way to state your company’s purpose is to say what job you are getting done for which job executor.

Here are a few examples:

Try to make your articulation compelling and, as Sequoia says, “declarative.” The job, the job executors and the key struggle should be very clear.

If you have chosen a job that has a lot of job executors trying to accomplish it frequently and the job is famously difficult to do well, it should be immediately clear that when your company achieves its purpose, it will create enormous value.

Finally, remember that your product is not part of your purpose. For example, if you’re trying to help small businesses acquire customers, your purpose should not be to “build the fastest, easiest-to-use CRM.” Small businesses don’t want lightweight CRMs any more than they wanted advertisements in print directories. What they want is to get a job done, so express your purpose in terms that reflect helping people overcome the stress and anxiety associated with getting a job done.

2. State the Problem
Your customer’s problem is that their job is complex and difficult to execute quickly and accurately. It could even require the use of multiple solutions.

How do you know if the pain is severe enough that people are looking for a new product to relieve it? Jobs-to-be-Done helps you quantify the pain and gives you a benchmark to know if the problem is worth solving.

The key is identifying the unmet needs. In Jobs-to-be-Done, we define customer needs as “the metrics customers use to judge how well the job is going.” The metrics we use are speed and accuracy. If the job is slow and inaccurate, the customer will want a new solution.

You can interview job executors to find out what’s frustrating and time-consuming about executing the job. Then, you can survey a statistically significant sample of job executors to determine which needs are the most important and least satisfied. These are your customers’ unmet needs.

The unmet needs are the precise articulation of the customer’s struggle to get the job done. Since a job is a key goal in a person’s personal or professional life (i.e. they need to execute the job frequently and they derive value from doing it well), the unmet needs are problems worth solving–they have great value.

It’s rare, but there are times when there are no unmet needs in a job. This means you don’t have a problem worth solving. Often this is because you came up with your idea for a solution first and it’s for a job that is over-served (the job is important but perfectly well satisfied in the market). This is a problem that’s not worth attempting to solve, as no one is looking for a new solution.

But once you’ve found a collection of unmet needs, you have the problem you need to start a business. In your pitch you can say, “[job executors] are struggling to [job-to-be-done].” Then, you can state the key unmet need(s) you uncovered in the market and intend to serve with your product.

For example, if you were pitching Waze, here’s how you could state the problem:

In this problem statement, the job executors are “drivers,” the job is “reach a destination on time,” and the unmet need is “reduce the time it takes to determine if you should take an alternate route due to traffic conditions.”

Anyone who drove a car before Waze has felt this problem, which means if you state it well, it should resonate. More importantly, if you have executed Jobs-to-be-Done, you will have data to back up your statement. You will be able to show that this unmet need is worth attempting to solve.

3. Show the Solution
When presenting the solution, Sequoia says to “demonstrate your company’s value proposition to make the customer’s life better.” In other words, how is your solution going to serve the job executors’ unmet needs in the job and how do you know it will do it well enough for customers to switch to your solution from whatever they’re doing today?

Using Jobs-to-be-Done, you can measure the value of your solution. Customer needs are all metrics of speed and accuracy. Consider how long it takes to meet your targeted needs and compare that time to the existing solutions. The closer your product gets to making the job automatic and extremely accurate, the more customer value you are adding.

Instead of talking about the features of your product, frame the discussion of your solution by how quickly and accurately it meets the needs in the job. For example, if the job is overcome diabetes to achieve optimal health and you’re targeting unmet needs around reducing the time it takes to determine costs, benefits and risks of available options for the patient, then demonstrate how quickly your product enables patients to meet these needs.

4. Why now
Sequoia recommends setting up the “historical evolution of your category” and then defining “recent trends that make your solution possible.”

Combining this with Jobs Theory, this becomes “What has changed that enables you to get your customers’ job done better?”

Consider the following examples:

In the examples above, new technologies and changing regulatory environments enabled new and better ways to get the jobs done. If you look further back in history, we see that this has always been true. Think about those people that have solved a job for a large, underserved market at the right time. Some legendary examples include:

  • Karl Benz: The potential of gasoline had just started being explored; people (and things) needed a way to get from point A to point B faster.
  • Frank McNamara (the credit card): Consumer confidence in post-WWII America was rising; people needed to reduce the likelihood that not having cash on hand prevented them from buying what they needed.
  • Jeff Bezos: In 1994, internet usage was growing by 2,300% per month and was an excellent foundation for serving the needs in the job “purchase a product” better than the existing solution of stores and mail order catalogues, which gave birth to Amazon.

During your pitch, be sure to identify recent trends that show why now is the time for your product or service. The people above tackled age-old jobs by capitalizing on technological advancements that made solving those jobs easier and faster.

5. Market size
Don Valentine, Sequoia’s founder, has always stressed the importance of the market: “We have always focused on the market–the size of the market, the dynamics of the market, the nature of the competition–because our objective always was to build big companies.”

When companies flounder, it’s because they try to define the market based on product ideas rather than market needs. Then, they invest too much in the manifestation of their assumptions: their unwanted products. This is a gamble (and almost always a mistake), as it assumes there will be a line of customers waiting to use that product simply because it exists.

Before you take your product to investors, Sequoia says to calculate market size. But how do you do it? You have to carry out research to see how many people need to complete the main or related jobs your product completes. Remember: the job-to-be-done is the market—not the product.

This is why the traditional ways of examining a market are flawed. These include the following:

  • Total Addressable Market (TAM): All units sold in a product category multiplied by the price per unit.
    Served Available Market (SAM): Units sold of a specific product type multiplied by the price per unit.
    Share of Market (SOM): Percentage of customers buying a certain company’s products.

These are product-based ways to calculate market size. Jobs Theory teaches you that the target market is the job executors and a job-to-be-done.

As an example, consider the Microsoft Zune, which was an answer to the iPod. Using traditional ways of analyzing market size, Microsoft measured the iPod market, which, at the time, was in the billions of dollars (e.g. 200 million iPods sold x $150 per unit = $30 billion market). But in 2007, the iPhone and Pandora launched, getting the job of curating music done more effectively, and the the iPod market quickly dipped to $0.

Microsoft made the mistake of defining the market based on the product. The market vanished because it was defined by a product. This left Microsoft trying to grab a market share of what was essentially nothing.

Instead, with Jobs-to-be-Done, the market size should be defined based on the customer’s willingness to pay to get the job done (regardless of the products currently in the market). To size the market into an accurate dollar amount, survey customers in the market to find out how much they are willing to pay to get the job done more accurately, efficiently, and/or conveniently. The resulting number is termed the securable market—the revenue you can generate by enabling customers to get a job done better.

6. Competition
As Sequoia says, it’s “better to identify all the competitors than have the investors discover them afterwards.” How do you capture a comprehensive list that is meaningful? Which products are worth including and how do you analyze them to show that your solution can beat them?

The competition is not just similar products. It is any existing solution–a product, service, or manual process–that the job executors use to get the job done today. This view generates a much broader list and a more comprehensive understanding of what your product needs to beat.

You can show how you will beat them by eschewing the traditional feature-to-feature comparison and instead looking at how well the competition serves the needs in the job. Your customers don’t want more features, they want to get the job done, so showing that your product has more features does not demonstrate that people will adopt it.

Let’s look at the Nest learning thermostat as an example.

A typical list of competition would include other thermostat companies such as Honeywell and Emerson. The first version of the Nest didn’t include all of the features of the Honeywell programmable thermostat and it was far more expensive, so how could you have shown that it would succeed?

First, identify the customer’s job by asking, “What job is the customer hiring this product to get done?” In this case, it’s to “achieve comfort in the home.”

Next look at the needs in the job. One need is “reduce the likelihood of the home being cold when you return to it.” How quickly and accurately does a programmable thermostat serve this need? Programming the thermostat takes minutes. The schedule is rigid, so if you get home early one day and forget to turn the thermostat up, you will be cold. The time it takes is minutes and the accuracy is low. The Nest improved upon this need by controlling the thermostat based on your location. It doesn’t require programming so it meets the need faster. It’s more accurate because it will turn on the heat automatically when you are home.

By showing how much faster and more accurately your product meets the needs in the job, you can show that you will beat the competition.

7. Product
Sequoia recommends you provide a product development roadmap covering functionality, features, architecture, intellectual property, form factor, etc.

Whether your product is far enough along to show a demo or all you have is a road map of your future, be sure to focus this section of your pitch on the unmet needs. It’ll frame your story, giving your feature set meaning and showing why customers would switch to your product.

It’s critical to demonstrate how early versions of your product will serve unmet needs better than the competition. Otherwise, your audience will question why and how you will get early adoption.

In your roadmap, you can show how even though your product only gets a few needs in the job done today, over time it’ll expand to get the whole job done (and potentially expand to adjacent jobs), creating more value for the customer and a competitive moat.

8. Business model
Sequoia’s outline recommends discussing your revenue model, product pricing, average value of a customer, sales and distribution model, and customer pipeline list. Here, you must make clear who is willing to pay (and how much).

The examples of Airbnb and Facebook show how viewing your business through the lens of Jobs Theory can help you construct a sound revenue model.

Airbnb generates revenue from the job executors of the two primary jobs the product set out to serve from day one:

1. Travelers finding lodging

2. Residents providing short-term rentals

Airbnb charges a fee on the transaction because the job executors have a willingness to pay to get these jobs done.

Facebook doesn’t make money off the primary jobs it originally helped its users complete: students getting to know their classmates and staying in touch with friends and family. Instead, the mountains of user data Facebook collects created an asset to get another job done: businesses acquiring customers. The willingness to pay for this second job done is very high.

When conceiving your revenue model, first research the willingness to pay for the primary job your product gets done. If the job executors are not willing to pay for it, consider whether or getting the primary job done creates an asset that can be deployed to getting an adjacent job done where the job executors have a high willingness to pay.

Final Advice
Jobs-to-be-Done not only provides a rigorous foundation for your pitch, but it also provides a framework for you to determine if your idea is worth pursuing or to find a new idea worth pursuing. However, just because you’ve learned the language of Jobs, Job Executors, and Unmet Needs does not mean the audience for your pitch (company stakeholders, your company’s board, potential investors) knows this language. Abstract your story from the theory to drive your points home. No one needs to know what a job or a job executor is to understand that drivers struggle to reach a destination on time. Use the theory to do your homework and then tell your story in plain English.

If you have any questions, get in touch.

7 Steps to Improve Annual Planning with Jobs-to-be-Done

Serious group of businesspeople having problems at work.

It’s the heart of Q4. Product Managers across the land are getting requests for next year’s road map as part of a company-wide “annual planning process.”

Some of you have talked your way out of an annual plan, “Why bother planning for more than a quarter? Every year I’ve been here, we’ve changed everything after 2 months.”

Whether you’re planning for the next quarter or the next year, you’re still on the hook for a plan. The pessimists among us wonder how they can reach an acceptable deliverable with minimal effort. The optimists have hope. Maybe this year we can make a plan that doesn’t get overhauled before we finish the first step.

Why do product road maps change so much?

Because the inputs typically used to make a road map–customer feature requests, sales team requests, stakeholder requests, new technologies–never stop changing.

But, your customer’s job-to-be-done (the goal or task that causes them to use your product) and the needs within the job do not change. You can use them as the basis for annual planning and vastly improve the stability and reliability of your road map.

Here are 7 steps to using the Jobs-to-be-Done product development method to create an annual plan that holds up throughout the year, delivers on the intended results, and satisfies customer needs better than the competition.

Step 1: Prioritize unmet customer needs
Customer Needs are the metrics customers use to judge how well the job gets done. A need is “unmet” if customers think it is important but not satisfied. Using a survey, you can assign importance and satisfaction scores to each customer need.

Here’s an example of a Customer Need:

When creating a mood with music (the job-to-be-done), you need to reduce the likelihood that the criteria for the playlist is too stringent e.g. the songs are too similar or no songs fit the criteria (the Customer Need).

In the job of create a mood with music, there are approximately 100 Needs.

The first step in annual planning is to prioritize the needs by the difference between importance and satisfaction scores–the bigger the difference, the higher the priority. A large difference indicates a large portion of the market is struggling to meet the need.

The result of this prioritization is a ranked list of problems to solve throughout the coming year and strong evidence that solving them will matter a great deal to your users. This list is the cornerstone of your plan.

Step 2: Analyze the competition and generate feature ideas to serve the unmet needs
Now that you have a list of problems (unmet customer needs) your team will tackle, it’s time to fill out your plan with solutions.

Look at how quickly and accurately existing solutions (i.e. the competition) meet your prioritized customer needs.

Remember our example:

When creating a mood with music, you need to reduce the likelihood that the criteria for the playlist is too stringent e.g. the songs are too similar or no songs fit the criteria.

If you’ve ever picked just one band to start a playlist on Pandora, you might find that the criteria is indeed too stringent and all the songs on the list are very similar. The accuracy with which Pandora meets this need is rather low.

This analysis provides the benchmark for your new ideas.

You’re looking to think up features that serve the unmet needs faster and more accurately than the competition. They will lead to people hiring your product to get their job done.

To generate ideas, gather a small, diverse group of colleagues from design, engineering, marketing, etc. Write a prioritized need on the board, and ask, “What can we do to serve this need?”

Compare each suggestion to the benchmark: existing features and the competition. If the idea will not meet the need faster and more accurately, toss it.

Keep a list of the ideas that do meet the need faster and more accurately. They will likely have varying degrees of difficulty, but you’ll deal with that later with cost estimates.

Think back to when Songza (now Google Music) launched playlists that were hand-curated by music experts. This idea served our example need much more accurately than Pandora. It’s an idea that would meet the criteria for “good” in a jobs-to-be-done idea generation session.

Step 3: Estimate new satisfaction scores
For each idea that met the above criteria and got on the list, estimate what the new satisfaction score would be if you surveyed your customers again, after they have been using this new feature. It’s a judgement of how much faster and more accurate the new feature will be.

If the existing solutions take days and your new feature only takes minutes and improves accuracy, you can imagine that satisfaction will increase quite a bit. If your new feature is only 1 second faster and the same level of accuracy, you should estimate a rather small increase in satisfaction.

Step 4: Estimate the cost of each feature
Your goal is to satisfy customer needs profitably so before you can prioritize which solutions to build first, you need a cost estimate. This is the one step that is likely not very different from what you do today. Talk with your builders–designers, engineers, etc.–and estimate the resources and time required to build the feature.

Step 5: Prioritize feature ideas by value
Feature value is a function of two factors:

  1. How many more customers will be satisfied with their ability to meet the need with the new feature
  2. How much the new feature contributes to improving the customer’s struggle to get the whole job done.

The first factor can be estimated using the new satisfaction score assigned in Step 3.

The second factor matters because your customers are not just trying to meet one need, they are trying to get the whole job done. If you’ve done the full research and collected all of the customer needs in the job (usually there are around 100), you’ll be able to see what portion of the job you are improving by meeting one or multiple needs with a given feature.

You can use these two factors to calculate the value of each feature idea. It gets a little complex, so get in touch if you want to know exactly how to do it.

After calculating the value of each feature, stack rank your list of feature ideas, putting those with the highest value and lowest cost at the top.

Step 6: Present to stakeholders
Road map presentations to stakeholders are often the most feared meetings of the year.

Product Managers have spent time with each stakeholder, understanding their goals, and collecting feature ideas from them. They’ve discussed feature requests from customers and salespeople as well as new tech that has come on the scene.

Based on estimated impact upon KPIs and cost estimates, this long list of ideas is prioritized and presented.

The stakeholders look for their ideas and fight for them. Fierce debate ensues. Passionate speeches are given. Horse trades are made.

Hours later, the team emerges from the room, exhausted and demoralized, but the road map is finalized! Everyone is getting something and no one is getting everything.

Those who think they got the raw end of the deal are onto their next mission–destroy that road map on which none of “their” features got prioritized.

Who wants to go through that every year or quarter?

A Jobs-to-be-Done roadmap presentation is very different. Here’s an agenda:

  • Remind the stakeholders of the job your customers are trying to get done.
  • Show the unmet needs, backed by qualitative and quantitative research.
  • Unveil the plan–a set of solutions to your customer’s most important and least satisfied needs.
  • Demonstrate your calculation for how getting more of the job done generates customer value, drives the willingness to pay and usage of the product i.e. meets business goals.
  • When someone offers a new idea that isn’t on the road map, evaluate it–does it meet a high priority need? Does it do it faster and more accurately than our existing ideas? Is the cost lower?

Because you’ve gone through the Jobs-to-be-Done planning process, you have objective criteria for judging ideas, reducing the need for debate and mitigating the risk of building the wrong product. Since the criteria is driven by your customers instead of your colleagues, it’s very difficult to argue against. Is there someone on your team who does not want to satisfy customer needs?

Step 7: Assess new ideas against prioritized needs
Plans fall apart when new information arises that undercuts the premise on which the plan was built. If the premise relies on ever-changing customer feature requests, sales requests, new technology, and stakeholder ideas, it’s easy to see why the plan would also constantly need to change.

When plans are built on stable customer needs, the constant flow of new data does not alter the premise and so the plan does not need to continuously change.

Instead you have a simple way to evaluate each request, each new technology, each new idea:

“Does this meet the prioritized needs better than our existing ideas and for similar or less cost?”

If no, you don’t change the plan at all. If yes, you don’t need to “pivot” or rip up the whole plan. You simply refine your existing plan–solve this list of customer problems–by swapping in a new solution for an old one.


The end of the year can be painful and frustrating if you don’t have a clear planning process that aligns your company and leads to a stable, reliable road map. I hope you find these tips for using Jobs-to-be-Done to be helpful with your annual planning.

Don’t hesitate to reach out with questions so we can help you go into the holiday season with confidence and have a prosperous new year!

A Step-By-Step Guide to Using Clay Christensen’s Competing Against Luck and Jobs Theory to Launch Great Products, Part 2: Answering The Right Question

unmet-needs-whiteboard

This is Part 2 of two-part series explaining thrv’s process for executing Jobs Theory. Part 1 is about customer research you can do to define the right question that will drive your product development. This part is about answering that question.

If you’ve read Part 1 of this series, you know about the first 5 steps to executing Jobs Theory:

  1. Define your customer’s jobs: functional, emotional, and consumption
  2. Identify all of the unmet needs in your customer’s jobs
  3. Find the unmet needs
  4. Segment your customers
  5. Identify competitor weaknesses

This work leads to defining your question:

What can you do to serve your customer’s unmet needs in the job better than the existing solutions?

The next step is to generate great product ideas that answer this question.

Step 6: Generate Ideas
You might have noticed something: in all the steps so far we haven’t had any ideas. The traditional innovation process usually starts with product or solution ideas. An ideas-first process is fundamentally flawed because the goal of innovation is not to generate more ideas, it is to satisfy customer needs better than the existing solutions. Jobs Theory enables you to build a needs-first innovation process.

When I was a product manager at Microsoft in the 1990s, we had a “brainstorming” room where our team would go to spitball new ideas. Anything went. As you probably know, the only rule in brainstorming is “there are no bad ideas.” This was (and is) absurd. There is a nearly infinite supply of bad ideas.

When executing Jobs Theory, you don’t need to “brainstorm” because you have clear criteria to judge product ideas: the unmet customer needs in the job.

When you get your team together to generate ideas, start by writing an unmet need on the whiteboard. Then, ask the room: “What can we do to serve this need?”

It’s still helpful for your team to think out of the box–perhaps your product is a website but a chatbot would serve the need much faster–but now, because you are answering a specific, measurable question, you know whether to keep the idea or move on.

If surgeons were your customers and you wanted to help them “restore artery blood flow,” you’d ask about the unmet need, “Does the idea help surgeons reduce the likelihood of restenosis?”

If drivers were your customer and you wanted to help them “get to a destination on time,” you’d ask “Does the idea help drivers reduce the time it takes to determine if an alternative route should be taken?”

If the ideas don’t satisfy the needs, quickly move onto the next idea. If they do meet the needs, keep them on the list.

Push the team to build on the ideas and achieve step function improvements over the existing solutions. Don’t let them be boxed in by the limitations of your existing product. The sky is the limit. Later, you can plan your roadmap to get there, step-by-step.

Now that you have a list of ideas that serve the unmet customer need, measure how well they do it–how much they improve the probability of achieving the goal as stated in the need.

Stack rank the ideas based on how much more reliably or faster they meet the needs than the existing solutions. If you see an idea that produces a step function improvement–reduces the time from days to hours, minutes to seconds, etc.–you may be sitting on a gold mine.

Jobs theory enables more efficient, precise, and relevant idea generation. Not only can you ensure all the ideas are relevant, but you can see if they are good enough.

Step 7: Price your product.
Pricing typically uses a combination of inputs, including the cost to make the product (or deliver the service), perceived value, and the price of substitute products in the market. Using this last input can be a fatal mistake for both pricing and market sizing.

To know why, you need to understand a pitfall of traditional market sizing: products and technologies come and go.

Traditional market sizing is based on variations of the following equation: the market = product price * the number of units sold. For example, in 2007 the iPod market was huge ($150 * 200 million iPods sold = $30 billion). Microsoft thought this was a big market and launched the Zune, an iPod competitor.

This is what the iPod market looked like at the end of 2011.

screenshot-2016-10-11-14-24-23

The “market” (defined by a product) went away, which means that Microsoft was looking to take a share of virtually nothing. But, of course, the true market, the customer’s job-to-be-done, didn’t go away. The iPod may have gone away, but people didn’t stop executing the job.

Jobs Theory’s definition of a market explains what happened.

There is no such thing as the “iPod” market. Customers don’t want iPods anymore than they want records, cassettes, or CDs. What they want is to get a job done, i.e. create a mood with music.

“Price * units sold” is a flawed definition of a market because it can disappear from right under your feet. Defining the market based on the customer’s job-to-be-done is much more helpful because the job will exist forever and therefore, the market will too.

To execute market sizing with Jobs Theory, you can look at the willingness to pay to get the job done. Willingness to pay can be measured by asking job executors (and if necessary purchase decision makers) how much it is worth to them to get the job done perfectly. The resulting data can be plotted (from high to low) on a line against the number of job executors. We call this a “need curve.”

The area under the curve is the total market size. It will also identify the prices that will place your product at the high end of the market, the low end, or somewhere in between.

In Competing Against Luck, Clay Christensen says, “The reason why we are willing to pay premium prices for a product that nails the job is because the full cost of a product that fails to do the job — wasted time, frustration, spending money on poor situations, and so on — is significant to us.”

By looking at the willingness to pay to get the job done, you can price your product to target the part of the market that will be the most profitable, and you can measure how lucrative that market will be over time, without the risk of it going away.

Step 8: Create messaging and positioning.
Positioning a product in a market and creating messaging that will resonate with customers is quicker and easier using the job-to-be-done and its customer needs.

When messaging misses the mark, it is usually because the message is focused on the product and its features. For example, Magellan messaged to potential customers that its RoadMate product has a “Wide-Angle Lens” and a “G-shock Sensor,” both sophisticated technologies.

But how does a Wide-Angle Lens or a G-shock Sensor help a driver get to a destination on time? What need is it satisfying? If messaging describes the product features or technology, the customer has to figure out on their own how (and if) the features help them get the job done better.

Messaging based on satisfying the job-to-be-done is easier for customers to understand. And because the needs in the job-to-be-done are prioritized based on importance and satisfaction, you can create messages based on the most underserved customer needs in your market.

Step 9: Plan your roadmap.

“Jobs Theory enables innovators to make the myriad, detailed tradeoffs in terms of which benefits are essential and which are extraneous to a new offering.”

–Clay Christensen, Competing Against Luck

The unmet needs in the job-to-be-done are your basis for making smart tradeoffs. Each job typically has about 100 customer needs. You can prioritize the needs by calculating the difference between the importance and satisfaction scores. The needs with higher importance and lower satisfaction are top priority. When you’re choosing which product features to build now and which to postpone–making tradeoffs–you choose the features that meet the top priority needs.

The same mindset can be used to plan your road map. A great road map will balance cost, today’s impact, and tomorrow’s promise. During your idea generation, you may have come up with some brilliant ideas that will take a long time to build or be very expensive to execute. This doesn’t mean you should ditch them. You just need to figure out how to increment your way to the brilliant idea while meeting customer needs better and better along the way.

This is step 1 of your road map planning: Determine the incremental improvements that will take you from where you are today to where you want to be tomorrow, getting the whole job done faster and more reliably than the existing solutions. Step 2 is to determine which of those incremental improvements to tackle first. The criteria for this prioritization is the extent to which the improvements serve unmet needs. You prioritize the work that tackles the most important and least satisfied needs.

Without good customer metrics, such as needs in the job-to-be-done, companies often prioritize their roadmap based on a flimsy projection of business impact, the charisma of people lobbying for the features they like, and the “HiPPO” (the Highest Paid Person’s Opinion). All of these methods are subjective and/or based on unreliable premises.

Your product roadmap (and your tradeoffs) should not be prioritized by your team. They should be prioritized by your customer’s unmet needs in the job.

Step 10: Mitigate your risk.
Understanding what causes a customer to purchase (“hire”) a product can help you mitigate product development risk.

Competing Against Luck points out, “In 2015… one thousand publicly held companies spent $680 billion on research and development alone.” And yet, “Most people would agree that the vast majority of innovations fall far short of ambitions, a fact that has remained unchanged for decades.”

Once a product enters development, companies spend an enormous amount of capital, time, and resources on building, marketing, and selling the product. Jobs theory can help you avoid product failure and ensure the roadmap will generate the revenue and profit growth needed to justify the investment.

Failure occurs when a product does not create customer value in a market. What is “customer value?”

Customer value is a measure of the difference of customer satisfaction with getting the job done between your solution and the existing solutions. Since the goal is to satisfy customer needs and needs are metrics related to speed and accuracy, you can compare the speed and accuracy of getting the job done with your solution vs. a competitive solution. That difference is the customer value you’ve created.

satisfaction-chart-001

Market opportunities exist because a person is struggling to get the functional job done. Improving the speed and accuracy of getting the job done reduces struggle and anxiety, which increases customer satisfaction and the likelihood they will hire your product.

This means you can measure the value of an idea even before you build it. Consider how much faster and more accurately your idea will meet the needs in the job if your idea is executed perfectly. Compare that to the baseline–the current satisfaction levels with each need in the job. You now know if the idea adds value to the market, so you’ve mitigated the risk of your idea. You still have execution risk, but your situation is a lot better than the risk of executing perfectly on an idea that does not add value in your market.

Step 11: Accelerate your growth.
Steps 1 through 10 are all the preparation steps to launching your product and accelerating your revenue growth. Jobs theory gives you a different lens through which to view your market, your customer, and your competition. It gives you powerful, metric-driven, customer-centric techniques to identify unmet needs and competitor weaknesses. And it gives you the tools to generate great product ideas that customers will pay for and to create messages that will resonate with customers.

Jobs theory is not easy to practice, but it is extremely effective if you make the organizational changes required to execute it well. As Clay writes, “Organizations typically structure themselves around function or business unit or geography — but successful growth companies optimized around the job. Competitive advantage is conferred through an organization’s unique processes: the ways it integrates across functions to perform the customer’s job.”

If you are interested in learning more about jobs-to-be-done techniques that you can use at your company, feel free to contact me directly.

Jobs-to-be-Done and Agile, Better Together

I’ve spoken to quite a few product managers whose teams and companies have recently adopted the Agile Software Development framework. When we discuss Jobs-to-be-Done and thrv, they are often intrigued, but then say, “We just went Agile. Does Jobs-to-be-Done work with Agile?” The answer is yes, Jobs-to-be-Done not only can work with Agile, but they are better together. Agile helps you develop a product faster and JTBD helps you develop the right product. Together, you get the right product faster.

Agile has spread so quickly, it has taken many forms. Here’s a quick reminder of the core values from the Agile Manifesto:

Screenshot 2016-07-06 10.58.22

Jobs-to-be-Done is based on the idea that your customers are not buying your product, they are hiring it to get a job done. This is the foundation of its customer-centric product development method that helps you identify unmet customer needs and generate solutions to serve them.

Agile and JTBD address two different but equally important issues–how to build and what to build. Yet, they aim to achieve the same goal: satisfy customers.

In fact, that’s the first principle of The Agile Manifesto:

Screenshot 2016-07-06 11.14.09

Agile enables teams to adapt to an environment where requirements and technology are rapidly changing. Jobs-to-be-Done gives teams a stable focus for their agile efforts–customer needs in the job-to-be-done, which never change. Putting the two together allows you to build rapidly developing products and services that matter to the customer. Every team needs to determine what should go into the next sprint and I think using JTBD to do it produces the best results.

What can happen if Agile is used without a solid product strategy framework and process such as JTBD? The team can succumb to two common fallacies that lead to a critical problem.

Fallacy 1

There is no need for product discovery.

Some Agile teams start with writing code, cranking out an MVP without asking “Why are we building this? How do I know it will satisfy customers?” Often, this happens because senior management defined the backlog in a separate meeting.

JTBD starts with discovery by talking directly to customers. You can confirm which features will satisfy users because you can connect them directly to stated customer needs. And if you use thrv as a developer, you can see the connection between your Task, the Feature Idea and the Customer Need it intends to serve so you always know why you’re building what you’re building.

Fallacy 2

If our sprints are tight enough and we release often enough, we don’t need feedback from customers.

It doesn’t matter how often you deploy if the features are irrelevant to customers and you don’t know if you are satisfying them. JTBD gives you a criteria with which to measure potential customer satisfaction–does the feature serve an unmet need and does it do it better than the competition?

It also provides a framework for checking in with customers once the product is built. Instead of asking, “Do you like this?” You ask “Does this reduce the time it takes to get the job done?” And instead of only tracking product usage, you can also track the value it produces for the customer–how much more accurately and faster are they getting the job done?

The Critical Problem

A poorly articulated product backlog that has a variable criteria for prioritization and is full of features that do not matter to the customer.

Without clear criteria for prioritization, opinion will win. Though an agile team decreases the cost of each release, if you’re placing bets on opinion, it may take many releases to stumble upon the right features. That cost adds up quickly. And it’s multiplied by technical debt. Every time a feature goes unused, it needs to be removed. If it’s not, it can cause side effects that get in the way of new development, making every new build take longer. The cost of building the wrong thing compounds with each deployment.

JTBD provides a clear, customer-focused criteria for prioritization. Though researching customer needs requires time up front, it helps teams avoid delays and costs down the road. Investigating the customer’s job leads to finding the right features in far fewer releases.


Even though Agile and JTBD offer a powerful partnership, there is a natural hesitancy to try to incorporate the two methodologies. Perhaps adopting agile was disruptive and the idea of adding something new is exhausting. Here are a few of the objections that come up and ways to counter them:

Objection 1: Research is slow. Building right away is fast.

You may have a colleague remind you of the following Agile principle:

Screenshot 2016-07-06 20.36.58

“There’s no time for lengthy and costly customer research,” they’ll say. JTBD does require some upfront research, but it can be done rather quickly, especially with thrv’s help. Regardless, the cost of building the wrong thing for multiple sprints is far more expensive than implementing JTBD.

Objection 2: Research will prevent us from being nimble.

Here’s another Agile Principle:

Screenshot 2016-07-06 20.38.34

“Conducting all sorts of research will lock us into a certain approach, and we need to be able to shift quickly,” goes the argument.

Indeed while product feature requirements may change, the job does not. Forty years ago people wanted to curate music. They still do today, but in the intervening 40 years the products have ranged from LPs to 8-tracks to tapes to CDs to MP3 players to streaming music on phones. Customers don’t want Spotify any more than they want a 50-CD changer. They want to reduce the time it takes to find the right song for the mood. The job and the needs are stable.

Customer research doesn’t set your road map in stone because you’re always looking for a better way to serve the needs, adopting new technologies as they are ready.

Research doesn’t prohibit you from learning from releases; it gives you more specific parameters about what you’re trying to learn.

And research doesn’t prevent you from being creative: instead of throwing spaghetti at the wall, you’re throwing darts at a target, the customer need. Without understanding the job-to-be-done and customer needs, you might as well wear a blindfold when throwing the darts (or the spaghetti).

1ffcc2e

This is gross.

Darts_in_a_dartboard

This is nice.

Objection 3: We just figured out agile; it’ll be too hard to add something to that mix.

Ok, here’s your chance to take an Agile Principle and turn it back on your colleagues:

Screenshot 2016-07-06 20.47.58

If you’ve just recently finished a sprint and are reviewing your efforts, this is a perfect time to bring up Jobs-to-be-Done. It’s not about scrapping what you’re currently doing to try something new; it’s an improvement to your existing methods.

There’s nothing about Jobs-to-be-Done that precludes Agile, sprints, or scrums.


So, how can you get started without too much disruption to your release cycles?

Have your product and UX team work on the JTBD research while the engineers work on the current sprint. (I do recommend that engineering participate in the research but they can spend less time on it. If you want engineers to join the research, try decreasing the number of tasks in the sprint.) Once the research is done, you can can use quantified customer needs to prioritize the backlog for the next sprint planning session.

From now on, you’ll have features on the backlog associated with customer needs. This means that when your designers are creating wireframes or your engineers are building features, they can see the customer needs they are serving. They’ll know why their work matters and better understand how to deliver customer value. This will lead to better decisions from everyone and more productive sprints.

It’s easy to assume one ideology can handle everything and introducing another will create conflict. With Agile and JTBD, the opposite is true.

If your team is using Agile and you want to know more about adding Jobs-to-be-Done, drop me a line. I’m happy to help.

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.

Prioritization

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.