How ‘Jobs to be Done’ Saved Us From a Costly Mistake

The product team was sure they were building what customers wanted.. until we talked to them

Andrea F Hill
Frameplay

--

In April 2016, ReadyTalk established a dedicated innovation team (DART) to work alongside the existing product teams. I ran this team, which focused on better understanding our existing and prospective customers so we could make strategic recommendations back to the business.

One of our first projects was supporting an existing line of business. The team had been steadily improving the product over several years, and one of the key stakeholders had a wonderful idea to make the product better.

We wanted to test the concept with customers before doing the heavy technical investment, which is where my team stepped in. We decided a quick way to test our proposed concept was to run a Google Ventures Design Sprint. [More on that here].

GV Design Sprints are a great approach for a team that already has a concept in mind and wants to answer “should we do this” — as opposed to starting with generative research to answer “what should we do”? I heartily recommend starting with the “what” first.

1. Set the project scope

There are three levers to adjust when designing a new offering. The more you adjust, the riskier the project.

In this case, we were supporting an existing line of business with an established customer base and channel. We were considering adjusting the “product” lever. There would be obvious technical risk, but first we wanted to address the market risk: would this help our existing customers get their Job Done better/easier? Would changing the product in this way create or capture new value?

2. Identify the customer

As a sustaining innovation initiative, we were focused on creating more value for our existing customers, and those who were similar to them.

Our target customer was ‘someone who used Webinars for marketing purposes’. We limited the scope of our research to those who were already aware of and currently using Webinars, to test the perceived value of the new enhancement we were considering.

We recruited participants with a variety of job titles, and a mix of both existing ReadyTalk and non-ReadyTalk customers. One screening requirement was that the participant had to be responsible for creating content and running Webinars for their company.

3. Understand her Job to be Done

This is where things got fun!

It’s easy to look at what a customer is doing, and list out those tasks. But lists don’t help with prioritization. It’s much more powerful to dive deeper into understanding the deeper WHY. Why is she performing this task, and what is she trying to achieve?

We met with several of our target customers (each individually) and asked them to walk us through their process. We created a map / flow diagram of what they did to achieve their goal. The point of this was to understand their activities, and what was important to them along the way.[1]

Separating the WHAT from the WHY is where real innovation can take place. When people perform the same task time and again, there may be ways to improve it, but it may not be meaningful enough to cause them to change their behavior.

Rather, an innovator must focus on what will be most impactful. This may mean helping the customer move past a struggle; if she is unable to do something as easily as she would like. We listened to how she described the various steps. Were they tedious? Difficult? Time-consuming? Each of these could indicate an opportunity to improve her experience.

What IS a Job to be Done? This question is a doozy.. I have an entire series dedicated to how different authors have described the concept. For the purpose of this article, let’s go with ‘Jobs to be Done are what users are trying to accomplish. They hire products and services to help them ‘get the Job done’.’

We knew: the core functional Job to be Done of our customer

We didn’t know: her corresponding emotional or social Jobs
We didn’t know: how she measured the success of the Job (her Desired Outcomes)
We didn’t know: what other tools she currently needed to hire to get the entire Job Done
We didn’t know: what parts of the Job she enjoyed, she hated, she struggled with, she loved…

Product Managers out there, any of this sound familiar?

And the more ambitious your product goals, the less you know. Intercom has a great story they’ve shared where they thought they were creating a Map for their customers, and their customers were ‘hiring’ the feature for something completely different.

This is why talking with customers — not just observing what they’re doing — is essential. You need the WHY, not just the WHAT.

4. … Do Work…

Pay no attention to the man behind the curtain

Because we followed the GV Design Sprint plan and already had a specific concept in mind, we didn’t do as much work digging into our unknowns upfront as we should have. Instead, we jumped right to ‘ideating’ and prototyping.

BUT! It worked out fine, because our second round of customer interviews gave us the chance to dig past the functional needs our customers had, to uncover what was really important to them…

5. Talk to customers some more

We returned to our target customer base a few days later, prototype in hand. But to the surprise of some of the members of the team, we weren’t running a Usability test or Task analysis. Rather, the prototype was an artifact to help support the retelling of the story of their Job.

Based on the map we’d created on Monday, the team had come up with ways to automate part of the customer’s Job. We had heard this was a time-consuming part of the Job, and we had designed a way to make it easier for them.

They hated it.

It turned out, although this part of the Job was time-consuming, it was what they took the most pride in. They didn’t resent the time it took, and rather, they wished they had more time to spend on it.

This is why spending the time to understand the customers’ overall Job to be Done is such an improvement over simply observing their behavior and trying to optimize it. Eliminating a time-consuming activity seems like solving a problem.. until you talk to the customer and find out what success looks like for her.

Actual (non-ReadyTalk) customer quote :-)

Lucky for us, the customers were overjoyed at another part of the concept. It was something that we had included almost as an after-thought, as it helped with the overall user flow. Similar to the Intercom map, they immediately saw a better application for the proposed feature. It would save them time and lower their risk of error by off-loading what was currently a very manual process (that they didn’t enjoy doing).

The best part? Not a single participant had identified that particular activity in the first round of interviews. But when presented with an artifact, they were transported into the situation and they had a strong emotional response to what we were showing them.

6. Interpret the findings

…Things happened….

Three big results came out of this research:

  1. We did NOT move forward with the concept our stakeholder had been so bullish on. He thanked us for saving the company a lot of money and time.
  2. We decided to further explore the concept that had emerged through the second round of qualitative interviews.
  3. The entire product organization realized how little we knew about our customers’ Jobs to be Done and what truly motivated them.

Number three was a huge win for my team, as it helped our internal customers understand how we could be beneficial to them. As in many product organizations, they were very often focused on optimizing how best to build things, and through a better understanding of the customers’ Jobs to be Done, we were able to provide the context and direction to help them understand what best to build.

Considering the overall customers’ Job to be Done made a huge difference in this project. We took a step back from the feature we thought we wanted to build, to understand the overall picture of what our customer wanted to achieve. That led us to understand that improving this one step wasn’t actually valuable to her.. and uncover what in her overall JTBD she was actually craving help with.

Lastly, it helped the entire team realize the significance of emotional and social Jobs —the rich story that we’d never get from surveys or web analytics, but that helps us ensure we’re building valuable products and features.

7. Iterate and Improve

This was a great opportunity for the team to rapidly get some customer insights to report back to the product team. Was it enough? For the purpose of this initiative, yes. We had a hypothesis about a specific feature, and we were able to quickly get feedback on its value.

However, there was a general sense that we had stumbled onto a concept our customers valued. As great as it made the team look this time, no one wanted to leave it for chance in future projects.

We decided to spend more time focusing on understanding the Jobs of our customers, so we could focus on only solving problems that they wanted to have solved, and saw value in.

Often when we look at product successes, we look at launches. In this case, we reveled in what we had saved the company in opportunity cost. The feature that we had planned would have been extremely expensive, and by talking to our customers and better understanding what was important to them, we were able to better invest our time and resources elsewhere.

Learned something? Click the 👏 to say “thanks!” and help others find this article.

Andrea Hill is the principal consultant at Frameplay. Frameplay is an innovation consultancy that helps companies become more customer-focused and thrive in a rapidly changing world. Learn more at frameplay.co

[1] Although we didn’t use it at this time, it’d be helpful to use something like the Universal Job Map, as developed by Strategyn, to call out the eight steps of a Job. This would have helped us ensure we weren’t missing anything critical in their process, and uncover what outcomes were important to them along the way.

--

--

Andrea F Hill
Frameplay

Director with the BC Public Service Digital Investment Office, former web dev & product person. 🔎 Lifelong learner. Unapologetic introvert