Innovation

[video] thrv CEO on Building High-Growth Products with Jobs-to-be-Done at Product Tank SF

Jay Haynes, thrv’s CEO, gave a talk on Building High-Growth Products with Jobs-to-be-Done at Product Tank SF, the San Francisco Meetup for Mind The Product. Below is the video of the talk.

Watch for the moment when Jay asks, “How many people work on teams where everybody agrees on what a customer need is?” Nobody raises a hand. So, if you’ve ever felt this way, you are not alone. But, as Jay explains in the video, there is a solution for clearly defining customer needs using the job-to-be-done.

6 Steps for Product Managers to Handle the Pokemon Go Augmented Reality Craze

screen_shot_2015-09-10_at_11.59.05_am

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?

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

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

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

Screenshot 2016-07-06 10.58.22

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

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

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

Screenshot 2016-07-06 11.14.09

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

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

Fallacy 1

There is no need for product discovery.

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

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

Fallacy 2

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

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

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

The Critical Problem

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

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

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


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

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

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

Screenshot 2016-07-06 20.36.58

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

Objection 2: Research will prevent us from being nimble.

Here’s another Agile Principle:

Screenshot 2016-07-06 20.38.34

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

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

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

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

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

1ffcc2e

This is gross.

Darts_in_a_dartboard

This is nice.

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

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

Screenshot 2016-07-06 20.47.58

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

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


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

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

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

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

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

Why thrv, or How I Set Out to Improve Product Launches and Product Teams’ Lives

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 and Jobs-To-Be-Done

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.