Jobs Theory Blog

 

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 in order to bring this thinking to life, but the ideas presented here can be applied to any industry where you're tasked with creating new products, or new features to existing products.

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

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

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

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

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

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.

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.

Today, we continue our exploration of how Jobs-to-be-Done helps product managers think different, 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.

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.

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.

There are two 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 (eg. 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 times 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. 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 will 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 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.

Let's explore these ideas using an 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 advance of technology, new competitors are 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 & 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, and that's where the greatest opportunity for innovation and success lies.

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.

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.

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.

Ever gone to a website and seen one of those comparison charts, where Product A has 23 features, and 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 different. How does your organization develop its product road map? 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. 

This is the introduction to a series about how Jobs-to-be-Done can change your product development mindset. Part 1 explains the first five rows of the chart using the example of an educational publisher. Part 2 discusses Idea Generation, Pricing, and Market Sizing. Part 3 covers Road Mapping, Aligning the Team, and Scoping an MVP.

Jobs-to-be-Done is often presented from a theoretical point-of-view. To help you apply it to your everyday life in product development, we've created a Jobs-to-be-Done Cheat Sheet.

The Cheat Sheet illustrates the practical difference between a traditional approach to product management, and the JTBD approach from thrv. If you've ever found the theory to be a little overwhelming, this breakdown may help.

To ground the concepts, we imagine how Microsoft could have used JTBD to think differently when competing with the iPod. If you were a PM at Microsoft then and focused on the customer's unmet needs in the job of curating music, would you have proposed the Zune?

Think of the Cheat Sheet as a first step towards setting yourself apart from all other product managers and companies who don't know about Jobs-to-be-Done. Save the image and refer to it when you're about to do something the same way you always have.

To dig deeper into the Zune vs iPod, sign up for our free email course: How Microsoft Could Have Beaten the iPod Using Jobs-to-be-Done.

To apply JTBD to your market, check out our training, software, and services or contact us.

 

 

It's one of the toughest moments for any company. You've spent time and money, pushed a great team to their limits, and now you are ready to launch a product into the world. You should be proud, elated even, but your stomach is in knots. Why?

Because, despite all your efforts, you're not sure if it's going to be a success. You've seen this movie before. A big investment in all the best ideas from all the most talented people results in a lackluster response from your customers. The stakes are high so you tightened up your sprints and got more ruthless with your prioritization. Maybe this time will be different?

I've been there and know the feeling well. Excitement, fear, hope and trepidation all swirling around inside your heart, head and stomach. I've optimized design and engineering processes until my team is a well-oiled machine, but it had no effect growth. It's an experience I kept coming back to when thinking about the next challenge to take on in my career. The more thought I gave to it, the more it became clear: I was passionate about the product launch, or more specifically, helping organizations launch products with more confidence, less risk, and in ways that not only brought business success but also led to happy and focused teams.

The turning point for me occurred when I learned and adopted the Jobs-to-be-Done framework. JTBD clarified my thinking and reoriented my perspective on product management. After years with a product-centric point of view, JTBD asked me to take a customer-centric view. It made all the difference in the world. I realized that the tightest sprints in the world won't fix a broken product strategy that doesn't focus on customer needs. I'll admit, it was challenging at first. I had to break the way I had been thinking and speaking about products for years.

Eventually, I understood Jobs-to-be-Done was more than a buzzword and more than a mindset. It's also a process that brings science to the art of product management and increases the product launch hit rate and efficiency for those willing to put in the effort. When it came time for me to venture out on my own, I knew that helping others reap the benefits from this approach was not only what I wanted to do, but was also something that the product community needed.

thrv helps companies and product teams understand that successful launches aren't about innovative features (though that can help) or user tests saying your product is "cool" but rather about satisfying unmet customer needs. People buy products, people switch from other products, not just because something new comes along, but because it helps them do something they are already trying to do faster or with greater accuracy. With thrv, we are building the only platform for product managers based on understanding and quantifying the unmet needs of the customer's job-to-be-done.

Nothing gets me more excited than working with an organization and being there for the "lightbulb moment" when the customer-centric approach kicks in. thrv helps people understand and leverage the Jobs-to-be-Done process in a way that makes adoption faster and keeps the entire team focused on the customer throughout product development. While the theory of JTBD has a growing influence within the product management field, little has been done to help teams implement the practice. And as product managers, we all know a great idea doesn't launch a successful product--it's all about implementation and execution. thrv's tools and services are here to support you every step of the way.

 

Welcome to thrv! We're excited you're here and we can't wait to tell you more about our company, our people and our software. Why are we so excited? Because we believe the discipline of Product Management is ready for a new approach, one that will have you seeing your customers, your career and your product road map in a whole new light. We thought the best way to introduce ourselves to you would be by letting you hear directly from our Founder & CEO, Jay Haynes.

Jay has 25 years of experience running companies and shipping products, including time at Microsoft as a Product Manager. He is the holder of three U.S. patents, and received an MBA with Distinction from the Harvard Business School. Jay's taken that experience and expertise and focused it on one mission: To help product teams launch successful products. That's ultimately why he started thrv, the first and only software application for Jobs-to-be-Done product management.

So, if you're involved in product management and you're struggling with questions about features, customer needs, pricing, or customer acquisition, grab a cup of your favorite caffeinated beverage and start your journey with this introductory interview that will help you understand what Jobs-to-be-Done is all about, how thrv leverages this innovative approach, and most importantly, how it can help product managers excel at their jobs.

I've heard of Jobs-to-be-Done. It has something to do with a milkshake, right?

Jobs-to-be-done was made famous by Clayton Christensen of the Harvard Business School, who wrote about analyzing milkshake sales for a major fast food company (watch this great video for a description of the milkshake example). 40% of shakes were sold first thing in the morning. Did this company's milkshake have a flavor that early birds craved? No, they had a "Job-to-be-Done"--keep hunger at bay until noon and reduce the boredom of their morning commute. Christensen stumbled upon a real insight: People weren't buying a product, they were hiring a product to help them get a job done.

The milkshake served the job because it kept you full until lunch, you couldn't drink it quickly, and it only took one hand to consume--perfect for driving. It's interesting to note that recently Taco Bell created a line of breakfast items and focused on the fact you could eat it with one hand, leaving you free to go about your business. Now, that's a relatively simple consumer example, but Jobs-to-be-Done is a very potent approach in much more complex markets like medical devices, business information and complex consumer markets where the job itself is actually much more complicated.

Ok, but what is thrv?

thrv is the first and only software to use the Jobs-to-be-Done methodology for product teams and product managers. And what that means is thrv puts your customer's job front and center, so everything you do as a product manager and a product team, from analyzing competitors to prioritizing your product road map, to figuring out your messaging and positioning is done in thrv. That's very different than other product management tools and software which start with ideas about what your product should do. Because thrv focuses on your customer's job rather than your product, it helps you to generate ideas that will help your customers with their most critical issues.

With thrv, how do I use it with things like Buyer Personas or developing a cool new feature set?

Buyer Personas are interesting. They tend to be based on things like demographics, where you have an urban woman in her 60s and a rural man in his 20s and each is a different buyer persona. But the power of Jobs-to-be-Done is that it focuses on what those personas, those customers, are actually trying to accomplish. In the traditional view of things, a buyer persona might lead you astray from potential customers. For example, could an urban 60-year old woman and a rural 20-year old man both be trying to reach a destination on time? And the answer, of course, is yes. And they could both struggle with executing that job the same way, but because personas use demographic information to define your customers, rather than the job itself, that can lead you to make extraneous or even inaccurate assumptions. Jobs-to-be-Done can be very useful because it gives you insights into why customers are struggling to execute the job, not just who they are demographically. And once you understand why they are frustrated with executing the job, then you have the key to developing a new feature that they are likely to connect with and use, because now youve helped them get the job done quicker or more accurately.

Will using thrv and the JTBD methodology help me to get more people to buy and use my product?

That is the entire goal! To make you a product management hero. The goal with JTBD and within thrv is to coordinate your entire product team on what your customer is trying to do. In other words, to help you figure out, before you invest in building and marketing and selling a product, what is it that people are likely to buy and use? And what they're likely to buy is something that helps them get a job done. This of course was the famous milkshake marketing example. Clayton Christensen, when he was writing about it, realized that if you thought about improving the milkshake, if you realized that 40% of the people drinking milkshakes were drinking them in the morning on their commute, then you could study and analyze what's happening on their morning commute and gain insights into the job they are trying to execute. Rather than just studying how you make a milkshake better, you would study the job. And this is where you come up with breakthrough innovations that people will more likely buy and use.

Wait, so JTBD sounds different than what I thought. I don't have the time to learn new stuff, and we've already got a system at work. Why should I try this new approach?

There are three main reasons you might want to try the JTBD approach: One is, you want to convert more customers, and JTBD can be very powerful because it can quickly help you improve your positioning and your messaging just by thinking about what your customer is trying to accomplish. The second is that it can help de-risk your product road map. Your company is likely planning to invest potentially millions of dollars in new product features that are theoretically going to help you beat your competition. But that investment can be very risky because frequently companies launch new products or product features and they don't generate the revenue growth that they need. With thrv and JTBD framework you can assess the risk in your product roadmap. The third reason is that its a much better way to identify your competitors' weaknesses. If you have competitors that you are worried about, that are launching new products and/or are taking market share from your company, you can use thrv and JTBD to figure out where their weaknesses are by analyzing not just your product vs. their product, but how well your competitors product gets the job done, and how well your products get the job done.

I'm just a product manager, doesn't this need to get approved by the C-Suite?

It's good to have executive buy-in into any new approach or new tool, but as a product manager you can train your team, and get the training you need yourself to help improve in your job as a product manager independent of your C-Suite. Because as a product manager you're always looking for new insights into what your customers want and what your competitor's weaknesses are. JTBD and thrv can help you as a product manager which can help you help your team, which is the ultimate goal of thrv, to create highly effective product teams.

I get what you're talking about, but this will totally baffle my colleagues.

JTBD is a very logical process. When you explain your customer's job and what theyre trying to accomplish in a logical, coherent story, which is what JTBD enables you to do, your colleagues are more likely to agree on what your goal as a product team should be. In traditional methods, where there isn't an agreed upon method to understand customer needs or what your customer is trying to accomplish, problems such as conflict, dissatisfaction, and emotional arguments among colleagues can arise. One of the real advantages about thrv and JTBD is, you can translate a customer story into a series of metrics that can be measured, so then you and your colleagues can agree on what your customers are trying to accomplish which makes it easier to agree on what you should put in your product road map and how you should message and position your product.

Ok, this all sounds pretty good, but the Head of Product wants to push new features out by the end of the quarter, will thrv help us do that?

What you want to ask yourself (and your team) is, why do you want these new features for your customers? This is the power of JTBD thinking, understanding that customers don't necessarily want new features. In fact, what they want is to get a job done. If you can get the job done with fewer features, in many markets, thats actually a better solution. Ultimately what your Head of Product wants is satisfied customers and more revenue by selling more of your product. Jobs-to-be-Done enables you to focus and measure where your customers struggle so you can identify if you truly need more features, or you may in fact need fewer features to help your customers get the job done quicker and more accurately.

This requires a paradigm shift in thinking for the Head of Product and his/her team. Rather than measure their success by the number of features launched, they should be looking at customer satisfaction as a key metric of success, and customer satisfaction is measured, in the mind of the customer, by how well they can get their job done. That was my job at Microsoft as a product manager - we measured ourselves against the competition by who had the most features. Most of the time that didn't work because people weren't buying software based on the feature count, they were buying based on how effectively they felt the product would help them with the job they needed to get done. That traditional sort of thinking does often tend to lead companies down a path, and they do tend to chase their competitors. Real breakthroughs can comes when companies eliminate features and make it easier for customers to get the job done. This is not easy to do without JTBD, which is why we created thrv.

 

* * *

Thanks for reading, we hope you found Jay's thoughts and insights worth thinking about. If you have any questions or comments, we'd love to hear them. You can leave a comment below, or engage us on Twitter @thrvapp. If you'd like to speak to us directly about thrv and our training program, you can get in touch with us here.