How Intercom designs valuable features with Job Stories

When you've got a good grasp of a customer's Job to be Done (JTBD), what are the next steps to craft a solution?

There's a lot of advice on how to conduct your own JTBD-style interviews, cluster the data, and synthesize the findings. It's common to reach a point where you've done all the research and wonder, "so, what?" What are you going to do with it?

Currently, there isn't much information on how to leverage the research output to make better design decisions that create good outcomes and business impact. It's most likely because the design process isn't always smooth or straightforward, making it tough to document or even discuss.

However, I was lucky enough to come across a video that demonstrated how a company like Intercom does it.

By the end of this article, you'll have a landscape of how they use it to build valuable features.

But first a quick refresher on what a Job Story is.

The output of JTBD style research is a distillation of the core customer jobs to be done into the form of Job Stories.

At Intercom, every design problem is framed in this Job Story format where the focus is on a triggering event or situation, the motivation and goal, and the intended outcome from the customer's perspective:

When _____ , I want to _____ , so I can _____ .

For example:

• When a new customer signs up,
• I want to be notified,
• so I can start a conversation with them.

It's an excellent place to start a design project since it captures motivation and context (the why) while not caring about what the solution should look like. This allows for more creative and unique solutions to real-world problems in the design process.

However, understanding the job story is only one element of a larger picture. It's a terrific starting point, but what comes next?

In Sian Townsend's keynote address "Jobs to be Done: from Doubter to Believer," I stumbled across a section on how Intercom uses Job Stories in their design process.

Intercom collects feature requests from all their customers on a rolling basis which they proactively act on.

In their Shared Team Inbox feature (shown below), the number #1 feature request they got was for something called "Inbox Stats".

Sian notes that they didn't know "what the feature should do" because of the abstract nature of the request, so they reached out to use the JTBD approach to help them design this feature.

So, when they began talking to their customers, they began to see patterns, which they turned into Job Stories to answer key questions that their customers had:

1. How big is our Support workload?

2. When are we busiest?

3. How good/bad are we at responding to customers?

4. Who on my team is busiest?

The overarching themes that emerge from these Job Stories revolve around helping support managers in making better decisions (the high level job to be done).

The team launches a project through a pitch called "Intermission," in which they present a clear problem statement that serves as the project's main focus after conducting research and distilling it into Job Stories.

Sian goes on to say that the transition from research to actual feature isn't smooth, but it's always interesting.

Based on the Job Stories they start by sketching out how they might address the core customer needs.

She then mentions that they skipped ahead to mock things up and make them look good.

But, she goes on to say that mapping the key questions from the Job Stories to the mockups was a critical step in the process. This was done to see if mockups would answer the customers' questions and allow them to make progress.

Once they felt confident that the mockups would answer the questions, they moved on to check how it looks against customers that vary in size. Data visualizations behave differently for customers of different sizes.

This step is called "Kicking the Tyres" and they use Google Sheets to visualise it!

She mentions that throughout this entire process, they're reviewing the design decisions being made against the key question from the Job Stories.

After this point, they get to the final feature where it answers the customers top priority question without any superfluous data. A valuable feature.

While I was writing about this I noticed a couple of things.

• To diverge on many ideas in a team setting, the key question from a Job Story could be structured as a "How Might We". You can read my post on how to convert a JTBD story to a HMW note here.
• The key question from a Job Story can also be converted into a "Can We" question to consistently achieve alignment amongst the team on whether the design mockups addresses the top priority question customers have.

It's fascinating to explore a company like Intercom and examine their design process. It's usually a black box but this was an eye-opener. Case studies like this show that there is a method to de-risk building the wrong thing by interviewing customers, synthesising the output into Job Stories, sketching solutions with pen and paper, mocking things up and testing with real data using something like spreadsheets (depending on your situation).

So, for you to get started designing with Job Stories here's what you need to do:

1. Start with the high-level job that customers are trying to get done.
2. Identify the smaller job or jobs which resolve the higher-level job.
3. Observe how people are choosing to progress right now. What solution are they using?
4. Interview people to understand what their motivation is for choosing the current solution. You can understand what they like about the current way that they're choosing to make progress so that you can incorporate any insights into your solution.
5. Synthesize the findings into Job Stories (highlight motivations, causality and anxieties.)
6. Based on the Job Story, formulate what the key question is from the customer's perspective. Frame it by starting the sentence with "Can we" forcing you to answer with a direct yes or no.
7. Sketch out solutions that answer the key question whilst also using the Job Story to constrain your output towards single direction.
8. Convert the solutions into prototypes (both low and high fidelity depending on your context) to test and learn. Ideally, validate the solution with the least amount of effort before moving on to work that takes more time but doesn't improve your learnings.

Hopefully, this helps you create something awesome in the future! If you liked this post you will probably enjoy my thoughts on How to build a bare minimum feature

References

1. Alan Klement - Replacing the user story with a job story
2. Sian Townsend - Jobs to be done: From doubter to believer. This also has a great introduction to JTBD theory.