How Jobs To Be Done Can Help You Get More Users To Switch To Your Product Or Service

If the concept behind Jobs To Be Done wasn’t real, we’d all drive the exact same car.

Jobs To Be Done (JTBD) is a relatively new framework for thinking about the value of your product.  The ideas is that people hire and fire companies to do a certain job for them, and that there is always an existing solution for doing that job.  Think of it like this, the job we hire a car to do is to get us from point A to B in a reasonable amount of time.  But if that was true, why are there so many makes and models of cars?  Because that’s not the real job to be done by a car – every car can do that.  Maybe for the wealthy, the job is looking good in public (luxury cars) or for parents the job is protecting their kids (safe minivans/SUVs) or for single guys the job is attracting women (sports cars).   JTBD aims to uncover these true motivations.

Here are 3 key differences between JTBD and traditional user research.

1. Recruiting

JTBD suggests talking to people who have hired or fired your product or service within the past 90 days, when the decision is still fresh in their mind.  This narrows down the number of people who will fit the bill, and if you’re a startup with no users yet (or no product), then you’ll have to talk to users who have hired or fired your competitors.  (which is a good way to validate who you’re competing with)

2. The Process of Uncovering Why

A JTBD interview is designed to uncover the story of how the person came to decide to hire or fire a product or service, and how it’s gone since making the decision.  See this template below:

jtbd-timeline.png

The general idea is to build a timeline from when the user first thought about changing solutions, to how she decided on a solution, to how she purchased the new solution, to how it’s going since purchase.

3. The Deliverables

In addition to developing the timeline above, the other outcomes of a JTBD interview will be

  • determining what the job is to be done (ex. for luxury cars, getting around town in style and comfortably, perhaps)
  • understanding the 4 forces that drove the user to make her decision and later evaluate that decision.  Specifically:
screen-shot-2012-10-29-at-7-16-58-pm.png

The idea here is to understand what’s prompting the user to think about changing from her current solution (for example, a pain point with the existing solution or a trusted source introducing an alternate solution), what’s attracting her to the new solution (hopefully yours), what worries her about switching, and what’s preventing her from making the switch?

Using this information can be very powerful, especially when marketing a new product. Just make sure to be explicit about how your product/solution is better than the current solutions people tell you they’re switching from.

Replacing Product Visions with Customer Journey Visions

 Homer Simpson car vision:  The Homer

Homer Simpson car vision: The Homer

Where do you see the product in X years?

The product vision exists to answer this question.  It helps communicate a sense of direction to stakeholders, both internal and external.  It’s often accompanied with mockups that took a lot of time to create.

The Issue with Product Visions

But is asking what the product looks like in 3 years even important?  To me, no way.  Product visions are a self-fulfilling prophecy.  They’re created by product leads who will want to make sure they move the product closer to their vision over time so they won’t look like they (a) don’t know how to predict the future, (b) can’t execute or (c) are bad product managers.  So they iterate towards that vision, regardless of whether it’s the right direction.  At least it’s a direction that stakeholders are familiar with, they think.

An Alternative Vision

So what is a product lead to communicate if not a product vision? To me, the best way to communicate a sense of direction to stakeholders is to help them imagine what the customer’s world will be like if the product is successful.  What do I mean by that?  Let’s look at some imaginary examples:

Amazon

Product Vision
A cross-platform shopping experience that lets customers search, compare and order millions of items by voice.

Customer Journey Vision
Imagine never having to leave your house again to go to the store.  No more parking lots, no more lines at the register.  Imagine ordering items from your sofa and opening your front door an hour later to see them there.

Tesla

Product Vision
A self-driving car with free WiFi that can be charged in less than 15 minutes.

Customer Journey Vision
Imagine being able to check email and read the news while your car drives you to work each morning.  Imagine reducing your carbon footprint and saving money on gas in a luxury, high-tech automobile.

Blue Apron

Product Vision
A flexible subscription, in-home cooking service with a mobile app that uses AI to recommend meals to customers.

Customer Journey Vision
Imagine not having to think about what to make for dinner.  Imagine everything you need to make a gourmet dinner in 30 minutes shows up at your doorstep each week.

The Homer

Product Vision
“Powerful like a gorilla, yet soft and yielding like a Nerf ball.”
A bubble dome car that can hold huge beverages and plays La Cucaracha when you honk.

Customer Journey Vision
Imagine being able to honk many horns when you’re mad.  Imagine being able to shut out screaming kids on road trips with the push of a button.

How to CREATE Experiences that Spur Users to Action

help-your-users-take-action-funnel.png

 

I worked with Dr. Steve Wendel, who is our Head of Behavioral Science.  He literally wrote the book on designing software for behavior change.  In that book he outlines his CREATE frameworkthat suggests there are 5 hurdles you need to overcome to get a user or prospective user to take an action, and that at each hurdle, you’re going to lose a few people (hence the funnel shape).  Let’s take a look at the funnel in greater detail.

Cue

You’ve gotta prompt your user to take the action you want – be it an email, push notification, or ad.  This is the one I think most product development squads forget.  They focus so much on building a great user experience that they forget how and why the user would come to their product in the first place.  (if you build it, they will NOT come)

Reaction

As you may have read in books like Blink, our minds use shortcuts to make instantaneous judgements in response to a cue.  You should be aware of how your audience might react to your cue.  For example, if you’re telling them you have the greatest budgeting app in the world, be aware of what people think about the word “budget” (mostly negative reactions, as it implies work or an unpleasant realization that they’re spending too much).

Evaluation

If you can get past the knee-jerk emotional response, then you have to get past a more rational cost-benefit evaluation.  If you’re asking them to switch to your product, this is the point in time in the Jobs to be Done framework where they might decide whether your product is superior to what they’re using today, and whether the switching costs will be worth it.

Ability

Your audience has to have the ability to take the action you’re asking them to take.  For example, if you send an email asking them to log in to your app and check on some changes but they’re in a cellular dead zone on the subway, they’re not logging in then (and chances are, they’re not going to remember to log in later, unless they open that email again).

Timing

Which brings us to the last step – even if the person can take the action, you have to convince them why NOW is the time to do so.  For example, in my line of work, getting younger employees to save for retirement is hard – there are more immediate financial goals like buying a house or paying off student loans that feel more urgent that something that’s 30 years away.

Here are a couple behavioral techniques that can help create urgency:

  • Scarcity: you might have seen Amazon do this with a message like “only 3 left in stock” under a product’s description.  Or with a limited number of beta invites for an upcoming app launch.
  • Deadlines: you may have seen this on TicketMaster – a clock that counts down saying that the price for those Bieber tickets you’re thinking about buying will only stay locked in for 3 more minutes.  Same idea with limited time offers.

Execution

This one is not on the visual, but the last step is actually taking the action.  This is where you give your user a virtual high five for taking an action that you both wanted her to.

Why Agile and Roadmaps Don't Mix

I’ve worked in Agile for 6 years now, having worked in waterfall at Accenture for 5 years prior to that. I’ve presented dozens of roadmaps. But now I’m on a mission to kill the phrase “roadmap”, at least internally, at work. Why? Because roadmaps and Agile don’t mix. Allow me to explain.

The Visualization

Ever presented a roadmap that looks like this?

roadmap.png


Of course you have. And when you do, your stakeholders see a Gantt chart/project plan. If you’re using agile, you probably used some rough estimation to come up with the timeline. Yet the visualization makes it hard to convey the uncertainty around the timeline. No matter how many asterisks you put on the slide, they will see this as a project plan.

The Expectations

So your stakeholders see this “project plan.” What do they expect? For you to deliver on it! They judge you, your squad, your parents, your value to the company on your ability to “stick to the plan”. But is delivering features “on schedule” really success? No way. High fives for delivering software features on time/on budget should be left in 2002 with waterfall.

What happens when you’re delayed? When great business opportunities present themselves? When you realize you want to iterate more on something based on feedback? You have to update your “project plan”. Bummer. Everyone was really excited about that thing at the end of your roadmap. Clients were expecting it. Senior execs built revenue projections off it. Someone from customer service Tweeted that it’s coming. Now they’re all scrambling to save face. And they hate you, product manager, for not doing your job! 

And you thought it’d be OK to update the roadmap because that’s the point of Agile right?

better Alternatives

There are a few alternatives I prefer to the Gantt chart roadmap:

1. Gantt Chart with Buffer

This is a minor tweak to the "project plan" view but at least have some buffer depicted on the roadmap.  Perhaps some empty months with a dotted box outline and a "?" suggesting that the teams need to reserve time for things like responding to customer feedback, production bugs, and new opportunities.

2. Kanban Style

Kanban boards are used to show the status of different work items (in the roadmap context, those would be research/validation work, design, or development).  You don't have to lose the timeline context on these boards - you can still indicate an ETA for each item so people have a general sense of when it'll be available (I'd use quarters instead of a specific month to provide flexibility).  Here's an example Trello board for Chuckwagon, an imaginary app that saves you time in picking recipes to make at home, grocery shopping and cooking:

Screen Shot 2018-04-12 at 12.21.58 PM.png

A couple things to note:

  • Ideas are being validated before they go into the design/build queue.  In this case, the Group Meal Plan ideas was scrapped because users didn't think their friends and family would want to make the same recipes as them.
  • Once released, there's analysis being done to identify whether a change is improving the KPI it was intended to improve.  In this case, the Waitlist Landing Page improved the acquisition KPI because it's collecting email addresses of potential users but the social sharing feature didn't, because few people ended up sharing the landing page link via Facebook, Twitter or LinkedIn.  By doing this analysis we're able to constantly learn and make sure the focus of the product development squads is on outcomes, not just output.

Microsoft also uses this concept for their public Office365 roadmap, although they don't use the same visual layout:

Screen Shot 2018-04-12 at 12.29.46 PM.png

3. Time Horizons

Here's an example from Slack's platform team that shows items bucketed by near term, mid term and long term, with no specific mention of what those "terms" mean.

Screen Shot 2018-04-12 at 12.32.28 PM.png

 

I like the Kanban style roadmap myself, because it provides a quick view of what's happening in product development but doesn't lose sight of outcomes and learnings.