Why Numbers Matter in Jobs-to-be-done

I’ve done this a few times – critiqued others blogs who are just sharing what they are learning – because it’s easier to compare and contrast sometimes than it is to simply evangelize. This is one of those cases; and I believe there is some good material here to contrast what people are calling the Jobs-to-be-done “Framework” with what I believe is a far more mature and systemized outcome-based evolution of the concept of Jobs-to-be-done. For those who actually believe the pursuit of customer-centricity is a journey, I think you’ll see that a lot of folks are simply not there yet.

Targeting Problems is a Critical Capability

A recent blog post on the Rise Vision blog (@RiseVision – they help deliver content to digital signage) walked us through how they were becoming very good at delivering software; but they finally realized that they weren’t very good at focusing on the right problem.

“We were missing an innovation strategy and we lacked a framework to guide our design thinking”

So, they decided to try the Jobs-to-be-done Framework (see my post related to innovation maturity) to build a better targeting system. Many product developers I’ve watched on Twitter and in the blogosphere have likely come to the same conclusion. Where they had adopted Agile as their preferred delivery methodology; they are quick to throw away portions of it (e.g. User Stories) just because someone wrote a blog post about Job Stories. I don’t necessarily agree with that; but will leave that for a future post.

User stories – and agile – might actually be a good fit with Jobs-to-be-done. Instead of throwing out the part the actually works very well, why not focus the front end of Agile?

1. The backlog should be developed based on a robust set of fact-based information that adequately describes what the right problem is, and which needs are unmet related to that problem. This data should also clearly describe segments within the market based an a complete catalog of needs (met and unmet)
2. The backlog should be prioritized using this same evidence and done so within an understanding of which segment(s) you are addressing

User stories are basically un-articulated use cases; which are meant to describe a problem and the acceptance criteria related to it (in simple terms). It is a step in-between requirements and a design spec. These would certainly be aligned to jobs + contexts + segments + executors. So, let’s agree to just sideline this user story replacement madness for a while. And lest you think I’m the only one thinking about this, here’s a good post on dealing with the hype around JTBD vs Agile.

Customer-centricity is Customer-centric!

The term customer-centricity has been around so long, and been abused by so many, that many thought leaders refuse to use the term any longer. In fact, the smoke (experience) and mirrors (engagement) have evolved into more interesting derivative poop like employee empowerment that we have all lost focus on the customer! Folks, happy employees do not make you customer-centric; but happy customers will probably make your work environment much better.

“Before we discovered Jobs To Be Done we defined our user and their motivations through user stories. But this framework came with many problems – it was vague, and we were making too many assumptions about our users with nothing backed by evidence.”

The revolt against user stories seems to be around the accurate belief that you simply cannot create personas based on easily identifiable attributes like age, economic class, region, etc. I think we all know that this is pure rubbish (even though brilliant marketers continue to use these groupings to push their incredible products – using impressive sounding journey frameworks like LBGUPS, etc.).

So, the information I feel is important to gain a true customer-centric focus is:

1. Properly identify the Job (including proper and consistent naming convention)
   
2. Deconstruct the job into its requisite steps
   
3. Identify the metrics the job executor uses at each step to measure success (arounds speed, stability and output for example)
   
4. Identify how customers measure the success of the job (importance + satisfaction), what they use today (you vs. competing solutions), and other relevant data to categorize
   

That last item (#4) is important because it is the customer’s perspective on how well they get a job done. It could be the job they are hiring your product to help them execute. It could also be jobs related to purchasing your product, learning to use your product, configuring your product, etc. So let’s look at this:

“Jobs To Be Done tells us that Acme Inc. is being hired by their customers to gel their hair at an inexpensive price.”

That’s it? So, the job is “Gel My Hair” and my unmet need is “at an inexpensive price?” One might view this as the short division version of long division; but this is not going to get you the same answer as the long division approach. In fact, the job is completely wrong and is framed around a company’s product (hair gel). When you do this, not only are not considering the customer first, you are constraining the true view of the market. Isn’t the job really…

“Style My Hair”

And what do we do with this “inexpensive price” part. First, I would argue that it has nothing to do with “Style My Hair.” On the other hand, it is clearly one of many metrics I would expect to see in the job…

“Purchase Hair Gel”

If we were to construct a customer metric for an imaginary step like “Assess Options & Value” I might have metrics like

“minimize the cost of the hair gel” or “minimize the quantity of hair gel needed

Not everyone will answer these the same, or in the same pairings, and this differentiation is what sets your market segments. So, this price thing a) is not part of the functional job “Style My Hair”, and it’s also not a context. It’s a need, and one of many. And one other important thing to remember is that “Style My Hair” is a much larger market and if you can understand it better than your competitors, expands your opportunities. Of course, most companies just want to make and sell hair gel.

So what is the measure of customer success provided in the blog, and is it customer-centric?

“The Measure of Success is typically defined as one of our key performance indicators such as improvements in new user acquisition, retention, store sales, or cost reduction, etc.”

Notice the word phrase “our key performance indicators?” They are internally focused, or company-centric. These internally focused indicators are also lagging which means you need to wait and see; instead of determining value before you even build. If you never get a customer (see Job of Creating a Customer), do you really know why? Will you resort to more internal ideation sessions or ask customers the wrong questions? You most assuredly will. Failing fast will not save you (here’s why).

The reason this will happen is because their version of Jobs-to-be-done has provided no capability to measure customer success. If you’re trying to help a customer get a job done better, you need to measure their success, not yours. Your internal metrics are not a valid proxy for customer success.

It Looks Like Hard Work – But it’s not

Sure, the Jobs-to-be-done approach I prefer requires a lot of hard work up-front; no doubt about it. First, it actually requires you to look at multiple jobs (functional, consumption), deconstruct them into maps, capture outcome-based needs metrics and then score them

On the other hand…

For every project we consider, we ask “If we do this, how does it improve our ability to execute the job we are being hired to do?”. If the answer to the question is “It does nothing to help” or “It causes a bigger problem” then we don’t touch it because it doesn’t strengthen our ability to deliver the job.”

…is actually more work over the long haul; and ineffective work.

A more mature and systematic approach doesn’t make you go through the same process for each project, sprint, whatever. The customer metrics drive everything. Of course, over long enough spans of time, those metrics will shift, but the beauty is that the job never does. “Gel me hair inexpensively” will shift over time as new solutions to “Style My Hair” emerge.

If you want to work harder, a sure-fired way to succeed, is to misidentify the job, and then return the focus to internal metrics. If you do this, you’ve accomplished nothing by embracing Jobs-to-be-done.

The Learning Journey

“And last but not least, we have learned to simplify and focus only on the projects that will improve our ability to execute the job, because the rest will only drag us down. “

I admire groups like this who clearly have a desire to learn. The system they have described may be simple, but I see no way that it guarantees focus on the right projects or their ability to execute the job.

This is not a generational thing; because both approaches came out of my generation. It’s just sad that the younger generation is always drawn to the easy button – which never works in the real world. And I should also note that nothing is perfect; including the approach I prefer. However, I’m keeping my eyes out for anything that comes along to replace it. In the meantime, I’m trying to integrate it into my daily work so I can…

1. Get the job(s) right
2. Measure the customer, not me
3. Keep learning and sharing