January 25, 2013

Four Challenges When Explaining Jobs To Be Done

Lately I’ve noticed four problems when attempting to teach or explain Jobs To Be Done to someone else. As JTBD grows in understanding, these will hopefully smooth over. Until then, I’ve prepared myself in advance.

Challenge 1: De-coupling the Reptilian Brain

We all understand the Triune Brain concept. It’s an easily explainable story, and equally practical. It applies to basically everything.

So it’s difficult to prevent an untrained JTBD thinker from scaling down to lizard thought.

Far too often, they will associate the “job to be done” with some core primal outcome. Of course it’s always about sex, food, sleep, poop, pride, fear, love, or predicability. But that doesn’t help us properly assess the job to be done and subsequently design a product or service someone would hire.

Instead, I challenge them to look at the situation. Then I urge them to describe what capabilities are needed to solve the problem. That’s the job to be done.

Challenge 2: Situation Taxonomy

Speaking of the situation, I find it difficult to properly define its scope. We’ll scale up and down, often for far too long, in search of the real and complete situation.

Let’s take the classic milkshake example. What would you say is the situation? Some options, in order of broadest to narrowest:

  • I’m hungry
  • I’m hungry and in my car
  • I’m hungry and in my car and by an on-ramp
  • I’m hungry, in my car by an on-ramp and don’t want to be hungry again in a few hours
  • I’m hungry, in my car by an on-ramp, it’s 8am and I don’t want my breakfast to be so light that I’m hungry again by lunch
  • I’m hungry, coming up to an on-ramp in my car at 8am, I want to be full until lunch, have a free hand and cup holder, $3 in cash, and don’t care about my next dental check up

And what if I’m hungry, but 10 minutes after I get on the free way? What situation beholdens to other situations?

What’s the real situation? It’s tough to draw a line. When do core parts of the situation transition to simple attributes? I see the uneasiness of being unable to answer happen all the time.

My response is that it doesn’t matter. Just pick one. Eventually you’ll circle in on a true description of the situation, but that only happens after deeper consideration. Until then, don’t let the taxonomy of the situation hold you up.

Challenge 3: Comfort with 2D Thinking

Extending the thought from Challenge 1, I see linear thinking as a problem. People will set up a progression, almost like mental dominos, and strive to follow point to point. The deeper desire here is to find the “root”. Without realizing, they think that A causes B causes C etc. So obviously the goal should be to find A, then solve for A. They think solving A is the job to be done.

But that’s not the case. It is not linear. (This is how we get mixed in with the lizard brain thinking.) Even if there is a chain of cause and effect, a major error happens along the way: we discount the importance of B, C, D, and so on. We ignore them.

Instead, I urge 2D thinking. Solving JTBD is understanding relationships and connections between ideas. A map is a better framework. Fill in areas for empathy, cost, demographics, and so forth. This way you won’t discount anything you document. Eventually you’ll understand the situation in more detail, and how to approach the solution.

Challenge 4: Where Do Attributes Belong?

The object? The situation? The person? The job? It can be confusing which attributes belong where.

I don’t have a sound explanation for this challenge yet, but so far I have taken a similar approach to Challenge 2: it doesn’t really matter as long as your documenting, contemplating, and testing.

Posted in Job To Be Done • comments
November 27, 2012

The Four Stages of a Conference Call and Jobs To Be Done

Summary: Breaking a product down into separate stages of engagement allows for clearer focus on specific jobs to be done.

Symposia has been a fun project. It’s a standard conference calling tool similar to GoToMeeting, WebEx and ÜberConference, but has the unique added value to record the call and tie all notes back to the specific moment of the conversation. Participants can review the call by navigating the one-dimensional audio stream in two-dimensional visual space. Another way to say it is Symposia adds bulleted lists, colors, boldness, and margin to a dull MP3 file. You can now skim recorded phone conversations like you would a memo or Google search results.

We designed around the job of once in a while trying to remember a specific conversation with colleagues or customers.

This novel approach has been valuable to some. It’s like Gmail: when you need to find a specific message amongst your thousands of threads, you’re really glad it’s there. But like Gmail, it turns out the review action is seldom used relatively speaking to other features. We still live in a transport world, and users will conduct 10+ calls before they review one. Not unlike composing 10+ messages or replies in Gmail before you search for that missing receipt.

This insight led us to re-examine the flows for creating and hosting conference calls. Although not our core value nor differentiator, if these flows are primarily what our users interact with every day, we need to be sure the design is optimal.

I observed a key pattern during this re-examination. There are four distinct stages to a conference call: Schedule, Join, Conduct, Post-Process.

Most people use another tool for stage one, like a calendar application, email, or unstructured communication (instant message). Scheduling is a hassle and often the source of wasted time. Key outcomes are syncing time zones, providing local international dial-in numbers, and the right call to action on how to join.

Joining is the second stage and is over looked by almost every vendor. I find this ironic because it’s also the single largest source of frustration with conference calls. Take a moment to contemplate everything that can go wrong:

  • Phone number and join link is old because the host had to recreate the meeting or accidentally created multiple meetings.
  • Participant doesn’t have a local dial-in number.
  • People generally need to download something (we’ve all used WebEx or GoToMeeting, right?), and the process is slow. Plus often the systems are problematic. IT administrators may prevent the downloading of a Java client, or lock down an IP range.
  • People are late. People arrive early.
  • Someone misses the call entirely.
  • Participants might need to remember authentication, and who likes to remember usernames/passwords?

It’s a full process unto itself and deserving of a separate stage. I find it surprising and exhausting how poorly this stage is designed, resulting in calls starting out negatively before anyone even speaks. People tend to be in a bad mood entering a conversation because of this stage.

The third stage is the actual meeting. Other products tend to focus on this stage. You got interactive white boards, call management widgets, screen sharing, social media plugins, LinkedIn profiles, liking-sharing-posting-chatting-talking … you name it. All in the name of making the call “more useful” by making it more interactive. Sometimes I feel it’s actually making a conversation more distracting. Many users resent the tools found during this stage.

The fourth stage is a never-ending ray extending out from the moment the call ends. Products tend to not associate this stage with a conference calling application, but it is a vital portion. Users create follow ups, assign tasks, share files, and log information in systems—like a CRM, ATS, or Basecamp.

I see this stage as the connector to other jobs participants need to do. The fourth stage is a launching point to other actions. However, it is important to remember Des Traynor’s point about staying true to what your product is meant to do. You don’t want to extend beyond that line. For example, it’s difficult sometimes to remember that Symposia is not a calendar scheduling tool or meant to be a framework for to-do’s, but is a conference calling application.

It has helped me to think of a conference call like a single line that has a beginning but no ending, then cutting that line into four sections.

I see the Post-Processing phase as the most fertile area for innovation. Users might come back to the call at a later point. They might need to extract context to a follow up. We have yet to fully understand the full value, but the possibilities for aiding specific jobs to be done are rich.

It has helped us to think about a conference call in four stages. Addressing each stage and targetting features and flows that focus on enabling the successful completion of the job to be done within those stages has made the product more useful overall.

Posted in Design, Job To Be Done, Uncategorized • comments
September 13, 2012

Summarizing Job To Be Done Theory

Over the past several months, I’ve found myself explaining Job To Be Done theory (JTBD) to friends, colleagues, and strangers, and each time I’ve learned more about how to summarize it. I wanted to gather all my thoughts into a concrete article so that in the future when I’m attempting to explain JTBD, I can just link them to this. I hope you find this valuable too.

Job To Be Done theory states that all consumers hire a product or service to do a job for them. Marketers and businesses should thus segment not based on demographics or psychographics, but on the situation a consumer is in where he or she attempts to complete a job. Brands who get this build a product or service around that singular job to be done. They put their entire company’s weight towards it, and become what’s known as a “purpose brand”. When you think quick furniture you can put in your compact car, who do you think of? It was probably IKEA. Its brand immediately popped into your head because it’s purpose-driven.

IKEA, as mentioned above, is a great first example. It has never been copied because it doesn’t segment based on demographics or income or whatever else. It re-segmented the furniture buying market by focusing on a singular job: quickly furnishing a room/apartment/house with well designed products. The entire company is integrated towards that end. Manufacturing, shipping, catalogs, websites, even the buying experience. And don’t forget about the brand-famous home assembly process. You can learn more about Clayton Christensen‘s insight on IKEA in this 5-minute video.

The “milkshake example” is the quintessential moment where Christensen and his colleagues flushed out the theory. It’s the most widely talked about anecdote available. This 5-minute video of Clayton giving a snazzy lecture recaps it.

This HBR article gives a good overview of how the theory is used to re-segment markets. It also includes an original explanation of the milkshake example.

Bob Moesta is one of the initial pioneers of the theory. He runs a consultancy called The Rewired Group, and has a list of resources. This Forbes article gives a quick example of one of his most famous anecdotes to explain the theory.

Bob and Chris Spiek give an excellent overview of JTBD put up against how people buy homes in this short seven-minute video.

I have purchased the two major HBR and MIT articles Clayton published introducing the theory in grand scale. I encourage you to pick up a copy.

Finally, for the more adventurous, Horace Dediu hosted Bob on his Critical Path podcast. An excellent hour-long discussion ensued that recapped many of the stories above, as well as additional insight. It’s very engaging, enlightening, and the best teaching tool for the theory. But it is an hour.

Posted in Job To Be Done, Marketing, Products, Start Ups • comments