Jobs Theory Blog

In 2010, Google Ventures design partner Jake Knapp developed a process that would help product teams go from abstract idea to a testable prototype in five days flat, now known as the Google Ventures Design Sprint. Within the past five years, Knapp has led more than 100 design sprints with companies like 23andme, Slack, and Nest.

But, while some of the hottest names in the tech industry have adopted Knapp's approach, the design sprint on its own can lead to solving the wrong problem and overly subjective criteria for solutions. By pairing sprints with Jobs-to-Be-Done, product teams can define the problem from the customer's point-of-view and objectively choose solutions that satisfy customer needs. The combination of JTBD and the Google Ventures Design Sprint ensures that your work will bring value to the user and your business.

What is the Google Ventures Design Sprint?
Knapp explains the design sprint process in his book, Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days complete with step-by-step instructions on how to conduct a sprint on your own. The goal is to educate teams on how they can focus their energy on creating solutions quickly and eliminate exhausting brainstorms that go nowhere.

The sprint is broken down into five stages, each taking up one day: Understand, Diverge, Decide, Prototype, Validate. A pending deadline paired with a clear process makes the Google Ventures design sprint an easy sell for design teams. It's quick and intense.

"When we talk to startups about sprints, we encourage them to go after their most important problem," writes Knapp. Later in the book he adds, "your goal should reflect your team's principles and aspirations."

How does a team know its most "important" problem? If the sprint's focus is defined by the team's "principles and aspirations," how do you know they match users' needs?

For example, imagine a team whose product has low user engagement rates.

Improving the daily or monthly active user counts is critical to business growth and their eventual round of funding. As such, they define their most important problem as "users aren't opening our app frequently enough."

A common (although not too clever) solution is to gamify the app in hopes of increasing user activity. But users don't want to spend more time in your app, they want to solve their own problems quickly and move on with their lives.

If you define your most important problem from the perspective of your employees or business goals, you may miss solving the most important problems of the people who matter most, your customers.

Why JTBD is Critical to Your Process:
None of this is to say the design sprint is wrong. It's simply incomplete. To complete it, the team must understand what the customer need is from the beginning, without the context of their own product. To identify unmet customer needs, companies must understand what job their customers are hiring a product to do, as described in the Jobs to Be Done (JTBD) framework popularized by Clayton Christensen, Harvard Business School professor and author of The Innovator's Solution: Creating and Sustaining Successful Growth.

Here are the moments of a Google Ventures Design Sprint that are risky without a customer-focused product strategy method such as JTBD:

1. On Day One, the Design Sprint process relies on the intuition of the team to determine and map out the problem. There are no requirements to talk to customers until the problem has been solved and prototyped. The risk of choosing a business-driven problem instead of a user-driven problem is high.

2. On Day Three, everyone pins drawings of their solution ideas to a whiteboard. Each participant is given stickers and asked to place them on any solutions they find "interesting." This activity creates a pseudo-heat map of good solutions. However, asking participants "what is interesting?" is the easy question.

"When faced with a difficult question, we often answer an easier one instead, usually without noticing the substitution," said Daniel Kahneman, psychologist, Nobel Prize winner, and author of Thinking Fast and Slow.

The difficult question is: "Which solution serves your customer's need better than the existing solutions in the market?" Satisfying customer needs is your goal, not building features the team thinks are interesting.

3. After selecting a few "interesting" solutions, the design sprint presents yet another opportunity for subjective decision-making in the role of The Decider, often the CEO, PM or another executive. When voting for the best solution to the problem, the decider can override all other votes. In an environment where the highest paid opinion wins, it's hard to see where customer sits in all of this.

"Deciders generally understand the problem in depth, and they often have strong opinions and criteria to help them find the right solution," Knapp wrote in his book.

Although Knapp may have strong, intuitive skills that align with customer needs, not all teams are created equally. CEOs will veto group decisions. Product managers will rely too heavily on their own agenda. And teammates will get attached to ideas. Intuition-based decision making can be dangerous. It's unpredictable and ripe for customer neglect, but we can create procedural safeguards to protect against its bias.

Pairing the Google Ventures Design Sprint with Jobs-to-Be-Done
How can Design Sprints use JTBD to create clear, objective criteria for defining problems and making decisions?

Here's an idea:

• Before day one of the sprint, define the customer's job-to-be-done.
• Map the steps people take when executing the job.
• Through customer interviews, identify the metrics job executors use to judge whether or not the job is going well. These are your customer needs.
• Conduct quantitative research to determine which needs are unmet--those that are rated important but not satisfied in a customer survey.
• Now, define the problem for the sprint. Choose one highly unmet customer need to serve. Your goal is to "generate ideas that serve the need better than the existing solutions." This starts your sprint with an objective, customer-focused problem.
• When choosing a solution, change the criteria from "most interesting" to how well the solution serves the unmet need. Because each need is a metric based on time or probability, you can measure which solution will satisfy the need best. Voting and vetoing become irrelevant because you'll weed out any solution that doesn't meet the need more quickly or accurately than the existing solutions.
• On Friday, when you user test your prototype, you now have a strong hypothesis that your solution serves the customer need better. Look to confirm your hypothesis and test usability. Does the solution indeed make the job faster and more accurate? Does the user understand how to execute their task with this design?

Before your team jumps into a Google Ventures Design Sprint, consider employing the JTBD framework to make the process more effective. With JTBD, you can identify customer needs, eliminate opportunities for bias, and test different solutions objectively. If your team needs help in getting started, we'd be happy to show you how thrv helps product managers get their customers' jobs done.

 

There has been so much written about Product Management recently that NomNom Insights and DataStories did a study of Product Management Content on Medium. We've been doing our best to keep up and have found a bunch of helpful ideas, experience and insights. Today, we share a few pieces that align with how we think and communicate important concepts better than we could have ourselves.

• The 280 Group recently conducted a survey of over 850 Product Managers and Product Management team leaders about the biggest challenges faced in their Product Management organizations. You may be surprised to find how much room for improvement product teams think they have and how much that improvement can add to the bottom line. To download the survey report, you'll need to give the 280 Group your email address, but it's well worth it.

• Julie Zhou, Product Design VP at Facebook has some great thoughts on the battle of "Metrics vs. Experience." Like Spiderman, Julie knows that the power of data comes with great responsibility. Read it to find out why "framing things as 'metrics versus experience' is entirely the wrong way to start the conversation."

• Do you use Slack? Satya van Heummen of Fileboard has our favorite analysis of Slack so far and it shows the power of serving the emotional job: The Real Reason Slack Became a Billion Dollar Company.

• Becky Yelland wrote a great job advice piece for Mind the Product on how to be an Industry-agnostic product manager. We're especially keen on this advice because Jobs-to-be-Done, like Becky, has also seen success across multiple industries from software to consumer products to medical devices.

• NewCo (founded by our friend John Battelle) has a terrific and wide ranging interview with media theorist and cultural critic Douglas Rushkoff on their blog, Shift. R.U. Sirius' piece explores Rushkoff's thoughts on business and technology. Within is a nugget that elucidates the problem we're solving at thrv: "The bigger issue is that most digital businesses won't make money. Not until they learn to help their users create value."

If these links put you in the product management reading groove, you might enjoy our 4 day course on Jobs-to-be-Done, which you can find on the bottom right of this page.

 

Horace Dediu argues that in the mobile phone market, profit share is the key to creating shareholder value, not market share. This makes sense. You don't want to just sell more product than your competitors (market share); you want to make more money doing it (profit share). For example, Apple sells fewer smartphones and has less market share than Samsung but Apple makes 90% of the profits in the market. It's no surprise that Apple has the largest market cap in the world.

Samsung and Apple have similar products and operational models, but a huge disparity in profit. The Jobs-to-be-Done definition of product strategy highlights the differences between Apple and Samsung's smartphone businesses and provides a rubric for choosing strategies that lead to gaining higher profit share than your competitors.

Here's a traditional definition of strategy: "the set of coordinated actions that a company takes to achieve its goals." Shobhit Chugh's blog post and slideshare apply this definition to product management. This notion of strategy is closely related to Harvard Business School professor Michael Porter's definition from his 1996 article What is Strategy: strategic success is based on "choosing a unique and valuable position rooted in systems of activities that are much more difficult to match." (If you don't subscribe to Harvard Business Review, contact us and we can get you a complimentary copy of the article.)

The focus in both of these definitions is activities. However, it's very difficult to create a "unique and valuable position" based on activities, especially if they are operational in nature. (Porter even recognizes this in his article, stating "Constant improvement in operational effectiveness is necessary to achieve superior profitability. However, it is not usually sufficient. Few companies have competed successfully on the basis of operational effectiveness over an extended period, and staying ahead of rivals gets harder every day. The most obvious reason for that is the rapid diffusion of best practices.") Operational activities are often straightforward enough to copy and therefore don't lead to competitive differentiation over a long time horizon.

In fact, Samsung executes many of the same activities as Apple. Both companies manufacture hardware, sell direct to consumers, sell to retailers, conduct R&D, and market to the same customers via the same channels. Yet, Apple takes far more profit in the mobile phone market. Why?

With Jobs-to-be-Done, instead of defining strategy as a set of activities, we define it as a set of choices.

1. Which job-to-be-done to target
2. Which job executor to target
3. Which platform to use to satisfy unmet needs in the job.

Here are a few examples of strategies using this definition:

Now, let's look at Apple's strategy vs Samsung's strategy. Smartphones serve many, many jobs, but for the purpose of this example, let's zoom out and look at just three of them.

What do you notice?

The platform choice in Apple's product strategy has two major differences: a proprietary operating system (iOS) vs. an open source operating system (Android) and a proprietary app store vs a 3rd party app store.

Android has become a commodity. Any company can use Android to launch a mobile phone, which means it is very difficult to satisfy unmet needs in a job differently than the competition. In other words, it is very hard for Samsung to differentiate their Android phones from the competitors' Android phones.

On the other hand, iOS is proprietary, unique, and specifically designed to work with Apple's hardware and services. No other mobile phone company can use iOS, which makes it inherently differentiated, and there is a segment of customers willing to pay a premium for the satisfaction iOS delivers to them relative to Android.

Samsung's commodity OS forces them to attempt to differentiate mostly on hardware. By enhancing the hardware alone Samsung cannot add as much value to the needs in the job as Apple can by improving their hardware and software together. Samsung's investment in Tizen, an "operating system built from the ground up to address the needs of all stakeholders of the mobile and connected device ecosystem" is evidence that they too believe their platform choice is holding them back - not from market share, but from profit share.

By looking at Apple's Product Strategy choices through the lens of Jobs-to-be-Done, you see how they set themselves apart beyond simply choosing a different set of "activities."

The JTBD definition of product strategy can keep product teams focused on delivering results for the customer. It's clear, it's specific and it's easy to put on the wall and rally your team around it.

The Jobs-to-be-Done method helps you choose the strategy that will deliver higher profit share than your competitors. Here's what you do:

1. Define your customer's job-to-be-done
2. Identify the Customer Needs in the job-to-be-done
3. Quantify the importance and satisfaction of the Customer Needs
4. Segment the job executors based on unmet needs
5. Analyze how well the competition satisfies the customer needs
6. Make choices about product strategy using the following criteria:

Choose the job-to-be-done that has the most under-served needs for your customer.

Choose the job executor who will generate the highest value market based on their willingness to pay to get the job done and the number of job executors.

Choose the platform that can satisfy the unmet needs for your chosen job executor with the lowest amount of risk. The cost and risk of getting the job done for this job executor are critical. If it's too expensive and too risky, it'll eat into your profit.

These are the three choices that will lead you to a differentiated product strategy that can beat your competition. Of course, you'll also need superb execution, but that's another topic for another day.

Why not take a moment to ask your team what your product strategy is? Is your team using a definition based on operational activities or do you have a product strategy based on your customer's job-to-be-done? If you find they aren't aligned on what strategy to choose or even what a strategy is, get in touch with us here at thrv. We can help.

 

Executive Summary:

With Pokemon Go's explosive growth, product teams around the world are asking, "What are we going to do with Augmented Reality?" Jobs-to-be-Done provides a customer-centric framework for deciding if and how to invest resources in this new technology and ensure your efforts will create customer value.

1. Don't rush to build; be swift but purposeful. Flocking to new technology without a clear strategy can be counter-productive and increase your risk of failure.
2. Define your customer's job-to-be-done.
3. Identify the unmet needs in the job-to-be-done.
4. Answer these questions, "Can augmented reality help our customers meet these needs faster or more accurately? If so, how?"
5. Measure if the new ideas will meet customer needs faster or more accurately than the existing solutions.
6. Determine if you can integrate the ideas from Step 4 into your existing product or if you need to build something new.

---

If you've gone online in the past week, even for just a moment, you've no doubt heard about Pokemon Go, the Augmented Reality game that has men, women and children taking to the streets, parks and museums in a fevered effort to catch 'em all. The game's success has sent Nintendo's stock soaring and Product Managers across the country are being asked: What's our AR strategy?

As recently as last year, Augmented Reality was firmly ensconced in the Trough of Disillusionment on the Gartner Hype Cycle. However, Pokemon Go's success coupled with reports of it driving real in-store traffic and revenue, shows the technology is realizing its commercial potential. The distant, sci-fi promise of AR is here, now.

If you're a Product Manager, you may have colleagues running rampant with "shiny new toy syndrome," asking when you'll have an AR solution ready to launch. Someone may have even written a press release already. The temptation to build first and ask questions later is strong, but it doesn't feel right to you. Prioritizing your existing road map was agonizing and re-allocating resources to the dream of AR will take away from key projects already underway. But, you don't want to appear staid, lacking in agility and dynamism, and, above all, you're a team player. Shouting down your better angels, you say, "OK, let's do a brainstorming session."

Famous last words.

The company's best minds are assembled. The room is full of energy. BD talks about partnerships. The UX team argues the finer points of distinguishing reality from augmentation. Someone's telling a story about their neighbor's nephew's crazy antics hunting down Pokemons. Ideas flow like water from a firehose--plenty of volume, but little precision. Two hours later you've got four walls filled with sticky notes, divergent ideas, and a vague direction set by the HIPPO (Highest Paid Person's Opinion).

Back at your desk, trying to piece the ideas into a project plan, you wonder how you could've done things differently.

Here's an idea: turn your generic brainstorming session into a Jobs-to-be-Done idea generation session. It focuses your team on the most important issue: how to address the unmet needs in our customer's job-to-be-done. This approach ensures that what you do with Augmented Reality, if anything at all, will be of real value to your users and not just a transparent, rudderless attempt to ride the wave of a suddenly popular technology.

In the JTBD idea generation session you'll focus on those unmet needs and continually ask, "would an AR solution help our customers accomplish their jobs-to-be-done faster or more accurately?"

Let's walk through the process as if you're a Product Manager in the field of medical imaging.

First, define your customer's job-to-be-done through research and customer interviews. For our example, let's say the JTBD is "Diagnose skin cancer."

Next, interview your customers to determine the needs within the job and then survey them to identify which needs are unmet (important and unsatisfied). For the job of "Diagnose skin cancer" unmet needs may include:

• Reduce the time it takes to detect a change in a patient's skin condition e.g. a mole has grown in size or changed in color or texture.
• Reduce the likelihood of missing a change on the patient's skin.

NB: If you have already defined your customer's JTBD and researched the needs, you don't need to do it again just because there is new tech available. You can jump straight to idea generation, using the research you already have. Incidentally, thrv can help you execute these steps quickly.

Now, assemble the company's great minds for an idea generation session. But, don't guide the session with "How do we add Augmented Reality to our product?" Instead, ask "How can augmented reality help our customer reduce the time it takes to identify a change in a patient's skin condition?"

After collecting ideas on how augmented reality can serve this unmet need, judge the ideas based on how well they meet the need. In other words, which solution will identify skin changes fastest? Think through the process of using the new AR solution and consider if it's actually faster than the existing solutions your customers use. If the AR solution is faster, it will create value and drive growth. If it's not, don't bother investing it.

Finally, if your idea does meet the needs in the job faster or more accurately, determine if you can integrate it into your existing product or if you need to make a new one.

Explosive growth is exciting. When it happens with a new technology or platform, it's natural for someone to catch a case of GMOOT (Give Me One Of Those). It's easy to start with the ideation process, usually in the form of an unfocused brainstorming session. Instead start with asking the right questions--what's our customers' job-to-be-done and how can the technology can help them get it done better?

 

 

 

thrv works with product teams to help them satisfy their customers' needs. Critical to this effort is alignment among the teams we work with. They need to be aligned around who their customer is, their product strategy, and, at the core of it all, the words they use to communicate with each other. What is a "product strategy"? What is a "customer need"? What's a "market"? If a team doesn't agree on the definitions of these terms or the definitions frequently change, it's very hard to gain alignment and build something that matters to customers.

Since language is so important, we work hard to keep it specific and consistent. When you and your team first embark on your Jobs-to-be-Done journey, you'll hear new terms and new definitions for old terms, and everyone needs understand them all. To help you and your team speak our language, we've created the below glossary of key JTBD terms. We'll be adding to this over time and linking to it when we use the terms in our blog posts.

Hopefully, the glossary helps your own team increase consistency with their language and avoid communication breakdowns. It may also help you translate customer feedback into actionable metrics, but if you really want to learn how to do this, reach out to us. We're happy to help.

Jobs-to-be-Done: A theory introduced by Harvard Business School Professor Clay Christensen to explain why customers buy or use products--they hire them to get a job done. Importantly, jobs enable product managers to define market from the customer's rather than the product's perspective. As a result, jobs (which are independent of any product) are stable over time.

For example, consumers have used records, cassettes, CDs, iPod, and streaming apps to execute the jobs of curating and discovering music. While products change over time, the customer's job will not.

Customer: The key customer is the person who benefits from the job getting done--the job beneficiary. This is why a market exists: because a person in either a personal or a business context struggles to achieve a goal and they look for solutions to "hire" to get the job done. The beneficiary is often different from the person who executes the job. Noting this difference is important because markets evolve to remove executors. For example, consumers benefit from 'getting to a destination on time,' a job-to-be-done. When driving themselves the consumers are both the beneficiaries and the executors. However, when using Uber or Lyft, the consumer is the beneficiary and the executor is the Uber or Lyft driver. If autonomous cars become ubiquitous, drivers (the job executors) will go away.

Functional Jobs: The most important types of jobs because they are the reason that a market exists. When we write "job" we are referring to the Functional Job. A Functional Job is the core task or goal that some person is trying to accomplish in a personal, business, or medical context. When someone has a functional job to accomplish, they look for a product or service to "hire" in order to get the job done. Check out this post for a little more info on what qualifies as a functional job.

Functional jobs begin with an action verb that describes the job. Some common job verbs include: determine, ensure, create, learn, obtain, develop, identify and optimize.

Emotional Jobs: Statements about how people want to feel about themselves or how they want to be perceived by others when they are executing a Functional Job.

Since emotions can be both positive and negative, Emotional Jobs include both how someone wants to feel and how they want to avoid feeling. For example, when consumers are selling a used car, they want to avoid feeling gullible.

Consumption Jobs: Tasks that relate to consuming and using a product or service. Consumption jobs include: install, learn-to-use, repair, maintain, interface, and dispose.

For example, if consumers hire an app to help them sell a used car (a functional job), they need to learn how to use it and to interface with it.

Job Executor: The person or entity who is doing the activities to get the job done. For example, in the job of "sell a used car" the job executor could be a consumer (an individual who owns a car and wants to sell it), a car dealership, or an auction house. In the job of "Create a mood at an occasion with music" the job executor could be a consumer, a professional DJ, a radio show host, a sync department for a tv show, etc.

Job Steps: Every functional job is a process that has a beginning, a middle, and an end. Functional jobs can be broken down into different steps that fall into six main categories: define, prepare, execute, monitor, modify, and conclude.

Customer Need: An action that the customer needs to take with a variable required to get the job done successfully. Think of the variables as factors that cause the job to go well or go poorly. Because the customer wants to get the job done quickly and accurately, the action of each need must be quick and the variable must be accurate.

In order to be measurable and actionable for your product team, a customer need statement should be structured with three important elements: (i) an action, (ii) a variable, and (iii) independent of any solution.

For example, when consumers are trying to get to a destination on time and executing the step of "plan the stops," they need to determine the optimal sequence of planned stops. "Determine" is the action and "the optimal sequence" is the variable.

Importance: a measure of how important a job, job step or customer need is to the customers. Importance scores are calculated using a five point scale: not important, somewhat important, important, very important, and extremely important. An importance score is a measure of the percentage of customers who say that the need is very or extremely important.

Customer Effort Scores: The percentage of customers who say that a Job Step or Need is Very Difficult or Difficult. You can identify Customer Effort Scores with a survey.  

Unmet Need: A Customer Need in which the action is slow and the variable is inaccurate. Surveys to identify the Customer Effort Score of job steps and needs can identify what percentage of the market perceives the need as a struggle. Since the struggle causes a purchase, we prioritize needs that have high Customer Effort Scores i.e. a high percentage of customers perceive them to be difficult.

Segmentation: In Jobs-to-be-Done, customers are segmented by how satisfied they are with their ability to execute the job. To identify groups of underserved customers, thrv using the opportunity scores to group customers who all have similar needs with high importance and low satisfaction, regardless of their demographics.

Competitor: Any company that has a product or service with features that satisfy customer needs in any job step in the job and manual processes that people use to get the job done, even if they are not associated with a business. Often companies think of their competitors as those companies who offer similar products. In Jobs-to-be-Done a competitor is any company who is helping a customer get the job done, even if they only help get a few steps in the job done.

Competitor Feature: Any part of a competitor's product or service that helps a customer satisfy a need in the job-to-be-done or an activity within a manual process that a person executes in order to satisfy a need.

Competitive Analysis: An assessment of how well the customer can get the job done with the competitor's solution. The assessment is a collection of measurements of the speed and accuracy with which a customer can satisfy needs with the competition's features.

Idea Generation: The act of thinking up features that will satisfy unmet customer needs faster and more accurately than the competition.

 

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:

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:

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:

“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:

“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).

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:

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. 

Snapchat launched in September of 2011. Just 2 years later, Facebook attempted to acquire them for $3 billion. A year into their stratospheric growth, mainstream media assumed it was a sexting app. Why else would you want your photos to disappear? Now, Snapchat is worth $20 billion and major brands are spending hundreds of millions per year advertising with them.

Snapchat didn't awaken the world to a deep latent need for sexting. By looking at Snapchat through the lens of Jobs-to-be-Done, we can see how they capitalized on an unmet need in the job of "Share a moment," and we can project the next opportunities in this market.

Consider why people share photos and videos on apps such as Facebook, Instagram, Snapchat, and even Flickr. As the apps have evolved, users have been able to accomplish quite a bit:

• Acquire customers (e.g. advertisers on any of these apps, architects and photographers sharing photos of their work on Instagram)
• Sell photographic art (e.g. pro photographers on Flickr)
• Inform the public (e.g. news brands on Snapchat)
• Stay in touch with distant family (e.g. sharing baby photos on Facebook)

The list barley scratches the surface. You can hire these apps to do many jobs. But at a high level, everyone posting on them has the same goal: they are trying to share a moment. "Share a moment" is the job-to-be-done that illuminates the disruption in this market.

If all of these apps help users do the same thing, how did so many of them gain millions (or hundreds of millions) of users? Different Job Executors consider different Needs to be important. Snapchat snuck up on Facebook by finding a large population of Job Executors who thought a Need was extremely important and were deeply unhappy with how underserved it was.

A Job Executor is someone who is trying to get a job done. In the case of "Sharing a moment," you have many Job Executors: professional photographers, small business owners, parents, coaches, college kids, teenagers, journalists--a wide variety of people want to share moments.

Using conventional marketing tactics you could segment them into dozens, if not hundreds, of demographic personas. In the Jobs-to-be-Done framework, we segment by unmet needs, grouping people who believe the same needs are important and who are not satisfied with their ability to meet those needs today.

A Need is a metric used to measure the speed and accuracy of executing a job. Like Jobs, Needs are stable across time and across people. Here are a few Needs in the job, "Share a moment:"

• Recognize that this moment is shareable e.g. "You should take a video of that monkey because he looks like he's about to steal something and that will be hilarious!" If you're too slow to recognize the moment, you will miss it and not be able to share it.

• Capture the moment. You don't want to be that person trying to unlock your phone while your kid's homerun sails over the fence.
• Communicate why the moment is special e.g. the photo is out of focus or has bad lighting; the video is long and boring.
• Ensure that sharing the moment does not damage your reputation. Anthony Weiner. 'Nuff said.

Each Need has an action ("capture") and a variable (e.g. "the moment"). This means you can measure each Need and know how well a given solution serves it. For instance, you can measure how long it takes to "capture the moment" with an SLR camera slung around your neck vs the camera app on your phone in your pocket. The method that is faster meets the need better.

The magic of Customer Needs in the Job is that everyone trying to execute the job has the same needs no matter who they are or when they are trying to do the job. Monet needs to reduce the time it takes to paint water lilies. Avedon needs to reduce the time it takes to snap the photo of the elephant before it puts its foot down. New parents need to memorialize their child's first steps. Teenagers need to snag a pic of that most embarrassing but hilarious thing their friends did at a party.

The Needs in the Job are the same, but their customer effort are different for different Job Executors. Monet's hand might have gotten tired if it took a long time for him to paint the water lilies, but that moment lasts a relatively long time. Therefore, it's not very important for Monet to capture it quickly.

However, a child's first steps start and finish in the blink of an eye. For new parents, it's incredibly important to move fast to capture that moment. In the 80s, they were likely terribly dissatisfied with how long it took to bust out the VHS recording machine. Satisfaction levels have changed today. If you search Vine for "baby first steps," you'll see parents are now pretty good at capturing moments quickly.

The Need hasn't changed; the technology has. As a result, there are new solutions that serve the need better.

So, why did some people take to Snapchat like bees to honey and others couldn't have been more confused by it?

I'm 35. When Snapchat first came out, I told my younger friends, "Why do I want to look at your photos that are so bad they aren't even worth saving to look at later?" I was flummoxed.

But, if I think about the Needs in the Job, "Share a moment," and the Job Executors, it all makes sense.

Facebook didn't hit my college until 2004, just after I graduated. Camera phones were crap, and with the iPhone launch still 3 years away, we only had dumb phones. Photo sharing was not a big deal yet. I did a lot of really goofy things in college and high school which, thankfully, are lost to the sands of time.

By the time camera phones and photo sharing on Facebook exploded, I was a bit more mature (but not by much). Reducing the likelihood of damaging my reputation was only somewhat important to me and I was pretty satisfied with my ability to do it.

What if I went to college a few years later? Everyone armed with a bazillion megapixel camera. Taking photos and videos of every single moment. Posting them to this site where all my friends, family and future employers can see them, for ALL TIME.

The need to reduce the likelihood of damaging my rep would be terribly important and horribly unsatisfied. This is life for everyone who started college in say, 2007 or later. Enter Snapchat.

With their self-destructing photos, Snapchat met the need of reducing the likelihood of damaging your reputation, while keeping it easy and fun to share moments.

This was not just for the Anthony Weiners of the world. This was for any normal kid who did kid type stuff and wanted to laugh about it with their friends. Snapchat let them laugh without the risk of an employer or someone important eternally judging them. A disappearing photo has a really hard time reaching unwanted parties. And even if someone who saw it judged you, you could deny, deny, deny.

Snapchat disrupted Facebook by serving a need that was deeply important and hugely unsatisfied for an enormous population. They served the need much better than Facebook or Instagram.

Now with image filters, they are serving the need "Reduce the likelihood that the way you captured the moment fails to communicate why it's special." Watch out, Instagram!

To find the next big opportunity to disrupt the "Share a moment" market, we would:

1. Uncover all of the Needs in the Job with customer interviews
2. Execute quantitative research to determine the importance and satisfaction of each need to different Job Executors
3. Generate ideas and build features that serve the unmet needs for the highest value segments better than the competition, like Snapchat did

If you execute well against the most underserved needs, you become a threat to the incumbents. When you move on to serve the whole job (or even multiple jobs) better, you can disrupt them and be on your way to building a 100 year business.

Anyone have a good idea for reducing the time it takes to recognize that a moment is shareable?

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 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 adding new features to existing products.

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

Prioritizing Your Roadmap

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 roadmap, 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 roadmap, 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.

Aligning Your 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.

Delivering the MVP

The idea of delivering a minimum viable product (MVP) 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, more 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?", and "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.

Today, we continue our exploration of how Jobs-to-be-Done helps product managers think differently, drive innovation, and develop new products and features based on the needs of the customer. In our first two posts, we gave you a Jobs-to-be-Done Cheat Sheet and used the example of an educational publisher to look at defining your market with the customer's job-to-be-done. Let's dig deeper into this example, looking at generating ideas, pricing, and market sizing.

Generating Ideas

We've all been in those meetings where "no idea is a bad idea" and the goal is to come up with as many ideas as possible. Brainstorming is the best way to generate ideas, right? Well, often, these sessions lead to long lists of features without clear criteria for prioritizing them. Not to mention, some people are now excited enough about their creative efforts they are willing to fall on a sword to see their ideas realized.

You don't need a long list of ideas. You need to generate ideas that will lead to results for your customer and your bottom line. High-impact features are more likely to come from asking a specific question: How do we serve our customers' most important and least satisfied needs?

In the last post we discussed the need of a student to reduce the likelihood that they have a question which can't be answered in the moment. Imagine you're a Product Manager at an educational publishing incumbent like Macmillan or Pearson. It's the late-90s and the internet is just beginning to reach a mass market. To serve this need, you could add more information to printed books or to a new CD-ROM product. Or you could notice that the internet enables students to connect with other people who could answer their questions. The customer need "reduce the likelihood of having a question which can't be answered in the moment," gives us clear criteria for knowing which solution is best. It's the one that makes it most likely the student's question can be answered immediately.

Setting a Price

The difference between paying for a product or getting the job done can seem subtle. Think of it this way: A person may only be willing to pay a one time purchase fee for a book (a product), but might pay a recurring monthly subscription to learn a language (see how DuoLingo gets the job done). Pricing by the customer's willingness to pay to get the job done helps you avoid leaving money on the table and gives you a more accurate picture of your market size.

Estimating Projected Revenue

There are 2 conventional methods of estimating the size of your market and your projected revenue: top-down and bottom-up. Top-down is an estimate of the total revenue for some geography and industry (e.g. dollars spent on education in the US) multiplied by an estimated percentage of that revenue you can obtain. The bottom-up approach looks at how many people you can get to buy your product based on marketing and sales projections and multiplying that estimate by the price of your product. For instance, we project our marketing will reach 1 million people and we'll convert 10%, so we'll sell 100,000 books. Multiply 100,000 by $50 per book to get a $5 million market.

With Jobs-to-be-Done, the focus isn't on the product because products change over time. The focus is on the customer's job to be done. The market size is based on the customer's willingness-to-pay to get the job done and the number of job executors.

This approach helps you avoid market mistakes, which can be lethal. For example, Encyclopedia Britannica was a leader in education, the gold standard of information. Its business model was to sell books to consumers to help them and their children learn subjects. But just as there is no "iPod" market, there is no "encyclopedia" market. To size the market opportunity, instead of calculating the market size based on encyclopedias sold times price, education markets should be sized using the job executor (e.g. parents, students or teachers) times their willingness to pay to get a job (e.g. learn a language, learn a skill) done better.

---

 

That does it for this second installment of JTBD Product Management. Is your company still operating the old way? Could you benefit from implementing the thrv approach? If so, 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. Next week, we'll wrap it up by exploring how to approach the product roadmap, aligning your team and delivering an MVP. 

Last week we posted our Jobs-to-be-Done (JTBD) cheat sheet. It's a handy guide to help you understand how JTBD differs from traditional thinking, and how you can use the JTBD framework to create products people want to buy. This week we go into detail on five of these ideas.

Jobs-to-be-Done has its own language, filled with analogies, phrases and terminology that you'll become familiar with over time. Soon you'll be reminding your colleagues that "no one wants a quarter-inch drill, they want a quarter-inch hole." While that might be a clever way to illustrate the difference between a product and a job-to-be-done, we know that catchy phrases are not enough. You need to see how JTBD can affect your day-to-day practices.

We'll start with the first five concepts on the cheat sheet, dealing with your market, target customer, and competition. In our next two posts, we'll cover the remaining concepts. Feel free to review the cheat sheet before reading on.

Defining Your Market

Let's explore these ideas using a jobs-to-be-done example from the education sector. Imagine you work for a company that makes textbooks, an educational publisher. It's a pretty complex environment with multiple stakeholders (students, teachers, administrators, parents) and thanks to the rapid advancement of technology, new competitors are always entering the market. At thrv, we would approach this challenge from a different perspective:

As an educational publisher, the natural assumption to make is that there is a market for your product: books. Students want to learn from the best books, and teachers, parents and administrators want to ensure that students have access to those books. The job seems simple -- produce a book with up-to-date information that's well-written, easy to understand, is well-designed and will stand up to the wear and tear of a year traveling to school, the library and back home.

But is a book what the students really want? Actually, what they really want is to learn and nowhere is it written that textbooks are the only, or even the best, delivery mechanism for imparting information. This paradigm shift -- from markets for products to markets for getting a job done -- is the single biggest 'flip' from the traditional way of seeing things to the way we view things at thrv. Once you understand what the true market is, you're now open to viewing problems and, most importantly, solutions, in a whole new light. That's where the greatest opportunity for innovation and success lies.

Doing the Research

People, as a rule, want to please. They are often uncomfortable telling you things they don't think you'll like to hear. When you show a customer your new product and ask, "Do you like this calculus book?" they are inclined to say, "Yes." After all, they don't want to disappoint you. They may even like the look and feel of it, but will it help a student learn calculus? You don't know yet. As a result, you probably haven't gotten a true read on the potential for your product.

By contrast, ask a person about some task they are trying to get done, like learning calculus, and they will give you a specific, detailed answer. They may tell you that it's frustrating when they have a specific question and there's no one around to ask. In that case, making a better book isn't necessarily the answer. By researching the job and looking for unmet needs you'll find specific problems that you need to solve and your customers will care about.

Segmenting Your Market

Demographics and Personas are the Siren Song of product development, luring you towards the rocky shores, ready to dash your product upon the rocks of apathy and dissatisfaction. Yes, there are many differences between an 11th-grade Asian-American female from Seattle and a Mexican-American 10th-grade boy who lives in Atlanta. But for your purposes, it's much more important to understand what they have in common: a need to learn calculus and a dissatisfaction with the current methods.

A far more relevant way of segmenting your market is by looking at people with the same unmet needs. The female from Seattle and the male from Atlanta may get frustrated in the same way when they have a question that can't be answered in the moment, regardless of their location, age, or gender. The unmet needs tell you more about the solution you need to create than the customer's demographic profile.

Identifying the Competition

The traditional way of understanding who you're competing with is to focus on the companies who make similar products. If you print books, so do your competitors, otherwise they wouldn't be your competitors, right? Not anymore, not if you're focused on the job-to-done. Remember, customers are not buying your product, they are hiring it to get a job done. So, when considering how they can learn something, they are not just comparing books to books. They are comparing books to in-person tutoring, online videos, interactive online courses, anything that helps them learn.

Any product, service or process -- including DIY -- that performs all or part of the job is a competitor. Threats can come from businesses using new technology to get the job done faster or those that are only serving one part of the job extremely well and soon will transition to your domain, taking market share in the process. The good news is, when you're focused on the job, it's much clearer which new technologies you should adopt to stay ahead of the competition or understand which customer needs you need to serve better. Or, if you are the competition, you can see where the incumbent is vulnerable.

Analyzing the Competition

Ever gone to a website and seen one of those comparison charts, where Product A has 23 features, Product B "only" has 18 features, and poor Product C, with their 15 features, well, how can they compete? Of course, you only need about six features, so, you're still confused on which product to buy.

The issue isn't how many features you have, it's whether or not your features are actually satisfying the needs of the customer. The best part is, that's measurable! Does a feature help the customer get the job done faster? How much faster? Does a feature help a customer get the job done more accurately? How much more accurately? By measuring factors such as these, you can devise features with demonstrable, quantifiable benefits. Or maybe you can satisfy all the needs with just one feature! Customers don't hire your product because it has a lot of features, they hire it because it has the features that get the job done.

---

Those are five ways JTBD helps you think differently. How does your organization develop its product roadmap? Do you do it the traditional way? Could you benefit from implementing the thrv approach? If so, 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.

In the next post, we'll take a look at generating ideas, pricing your product, and projecting revenue.