A Brief History:

The Jobs To Be Done framework’s star is on the rise. Clayton Christensen, venerated HBS professor, seems to have coined the term as early as 2005 in his white paper, “Marketing Malpractice.” As of later, the leading proponent of the philosophy has been a product innovator named, Alan Klement. He’s published numerous thought provoking posts under his book’s blog called, “When Coffee and Kale Compete,” which codifies the theory of Jobs To Be Done.

Christensen doubled down on the concept in, “Competing Against Luck”, and over the past year, I’ve seen a small but vocal community coalesce around this approach, driving the need to rethink the way product teams get inside the hearts and minds of their customers and users. In the last quarter of 2016, three books became available as a Jobs To Be Done handbook, theory-to-practice manual, and roadmap. I daresay that in the past year, Jobs To Be Done received more attention than in the previous nine years since its inception.

A Compelling Model:

If you’ve been exposed to Jobs To Be Done from Christensen’s perspective, the milkshake case study will immediately come to mind. Briefly, morning commuters with long drives and not enough time or hunger for a proper breakfast will “hire” a milkshake to keep them sated and occupied on their boring drive to work. In contrast, afternoon milkshake consumers have a different job; they use the milkshake as a tangible gateway to conversation.

Because the milkshake has attributes like viscosity that makes it a slow commuter beverage, as well as nostalgia that makes it conversationally disarming, it is actually performing much more complex “jobs” than one would expect of a simple frozen ice cream drink.

As a model for empathy and user research, Jobs To Be Done has proven itself to be invaluable within User Experience discovery at ITX. The innovation breakthroughs for our clients have been positively received by both our internal team’s delight in finding key insights faster, and also by our clients who are surprised by the depth of insight the Jobs To Be Done philosophy provides.

A Word of Caution:

The product process is a fuzzy one. Teams coming from waterfall, or those who transitioned to agile but still hold onto the stage-gated process mindset, can fall into the trap of thinking that visioning, ideation, and design are “phases” in the software development lifecycle. We are constantly designing, testing, and improving, so the line between empathy and implementation is a difficult one to parse, but it is important.

Jobs To Be Done has started to creep over the line from ideation to implementation in such concepts as “Job Stories,” which some have proposed as replacements for the agile User Story. As an agile practitioner, it is tempting for me to protect the sanctity of Scrum, but I don’t think that’s a productive use of anyone’s time. I would recommend that anyone newly introduced to the Jobs To Be Done model embrace it and trust it as a worthwhile philosophy. However, the needs of developers as they build digital experiences are well met in the Continuous Innovation mindset.

A Few Key Takeaways:

As a Product Innovation Lead, I’ve picked up a few tactics from the thinking that’s been published over the past year. I want to share a few of them, so that you can consider for yourself if they would improve your own innovation process.

1. Don’t confuse the Marketing Persona with the Product Persona: One of the things that Jobs To Be Done is great at, is defining clear needs of the consumer, which helps build a compellingly vulnerable case around the marketing persona. When writing user stories to the backlog, we are concerned about users and their Product Persona. Many times, that user is either universal, systemic, or otherwise so obvious that it makes more sense to start with the need than the name. For example, the Agile template as a story goes: “As a <user> , I want to <use case>, so that <outcome>.” For many stories, there are too many assumptions in the three variables considered, so Jobs To Be Done might rephrase the story as: “When <motive>, I want to <use case>, so that <outcome>.” The subtle change from persona to emotional driver might help your team remove unproven assumptions about the user, and instead think from the perspective of known fears and desires.
2. Write for motivation, not implementation: As users navigate our experiences, it is tempting to build backlogs in very 1:1 superficial maps. For example, a shallow story might be: “As a user, I want a blue button, so that I can click it.” In contrast, a more motivation driven story might sound like: “When I’m looking for the next step, I want to know what the primary action is, so that I don’t get confused.” This story may in fact end up being implemented as a blue button. However, it also opens up dialogue such as: “Is this the primary action?”, “Shouldn’t the button be inactive until the form is complete?”, or “Is a tooltip available for contextual information?” These are the kinds of questions that drive high quality products with healthy backlogs.
3. Use events – not roles: The third important way that Job Story writing can help improve your User Story techniques, is in writing to the event – not the role. The way we accomplish this is by including human-readable, checklist-driven Acceptance Criteria. The AC of a story tend to be either overwrought to the point of unusability, or are underdeveloped to the point of confusion. By defining events that drive solutions to solve the intended problem, User Stories will have appropriate empathy and allow designers and developers to have workable conversations.

The JTBD theory is a great step forward in how creatives can think critically about innovation. When it comes to actually implementing that innovation in new or existing products, agile principles have proven the test of time.

Nothing is immune to disruption, but I need to see some more compelling evidence before I overhaul my Scrum process with new vernacular that might only succeed in adding confusion to the controlled chaos that agile principles manage.

How do you put yourself in the shoes of your potential customers? Share with us in the comments section below!

References:

Flaherty, Sean (2016, April 13). A Software Product’s Future: The Backlog

Flaherty, Sean (2016, January 19). Continuous Innovation

Roets, John (2016, June 24). Use Simple Checklists for Acceptance Criteria

Christensen, Clayton M.; Cook, Scott; Hall Taddy (2005, December). Marketing Malpractice: The Cause and the Cure (https://hbr.org/2005/12/marketing-malpractice-the-cause-and-the-cure)

Klement, Allen (2016). When Coffee and Kale Compete.  (https://medium.com/when-coffee-and-kale-compete)

Klement, Allen (2013, Novemeber 12). Replacing The User Story With The Job Story – Too many assumptions are dangerous (https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27)