As a startup founder, one of the worst things you can do is to pitch a new feature idea, hype the team to build it, and then realize: Our customers don’t use it.

I get it.

You know the industry.

You’ve worked in it for several years.

You might even know common pain points.

BUT:

Do you actually know what jobs need to get done every day?

Which things your customers need to get done, software or not?

Software, apps and tools are nice, but they need to help customers to complete their daily, weekly or monthly jobs.

Do it faster.
Do it better.
But get it done.

If your software doesn’t do that, charging money will be hard.

So, not helping customers to get their jobs done is bad.

Not even knowing what those jobs are in the first place is even worse.

Enter the Jobs To Be Done Framework

That’s where the “Jobs To Be Done”-Framework comes into play.

It’s a UX Design & Research framework, that helps teams understand what daily, weekly or monthly jobs people need to get done.

With this framework, you can finally get more clarity and confidence in the features you want to build, without wasting precious time on shipping useless things.

That’s how one of our core customers at Grauberg finally had confidence in shipping new features, and a way to always check in again if a feature makes sense or not.

So today I want to share this framework with you. Vamos!

At the end, you will even find a Miro and FigJam template for Jobs To Be Done, to get started quickly.

Jobs To Be Done – What It Is

Jobs To Be Done is a framework that comes from the UX Design and Research world. Originally coined by Clayton M. Christensen and his great book “Competing against Luck”, its goal is to bring more clarity in what tasks need to be completed daily, weekly or monthly.

The framework is especially useful when working on enterprise software or tools with many different user groups, because you can match features to Jobs To Be Done (JTBD) instead of user groups, meaning you might find some overlap in different use cases.

When to use it

• when your confidence in new features is low
• when you don’t know what to build
• when your Day 1 churn is high (customers try the tool once and then never come back)

When not to use it

• when you don’t have any customers yet (because you need to interview them)
• when you have great pull/traction on features and just need to ship them

How I Do Them

At Grauberg, we tread very carefully with this framework. It takes 1-2 weeks to finish, and depends on how easy it is to get our customer’s users to talk to us for a “user interview”.

But when I do deem it necessary, here’s my approach:

1. Get buy-in from leadership

I propose that we should interview users to better understand their jobs to be done, with the ultimate goal to know exactly what to design and ship next.

2. Schedule interviews

To understand the user’s JTBD, we NEED to interview them. Very rarely you find a full list of tasks for a specific user group online.

Ideally, we get 1-2 users per group (group could be “Account Managers, Marketing Dep., Customer Support) to schedule a 1h interview.

How to schedule interviews with users? Send this email:

Pro tip: Ideally, you want to get users in a 1:1 call, where they can talk freely. I had instances where customers scheduled a 5-head call with me, the manager and 3 users, and the users only said what they were supposed to get done, but not what they really struggle with.

Another pro tip: try to schedule calls all together, so you can do all user interviews in a day or two. That way, new insights also stay fresh in your mind.

3. Draft up a digital whiteboard

I usually use Figma or Miro and create post its for each job to be done, and then I group them into Daily, weekly and monthly tasks, and the daily group into “morning, afternoon”.

During the interview, you can either privately note down all the JTBD or share your screen to confirm with the user that this is what they meant.

4. Do the interview

I have a full blog article on how to do user interviews, but specifically for the JTBD interview, you can ask the following questions:

• Ask: “Walk me through your morning”, “What are the first things you do every day?”.
• Don’t ask: “What jobs do you need to get done?”

5. At the end of the interview

After 2/3 of the time you have for the interview, ask the user to “prioritize” the JTBD. Knowing what is most important to them will help you with knowing what to focus on.

6. Map all JTBD

After all interviews are done, map all JTBD on a whiteboard, and rank them by importance. Then, group them by user groups (account manager, customer support, etc.) and find shared JTBD, like “create a report”, which could be a feature for multiple groups.

Final step: Mark the JTBD with three different colors:

• Green – Already solve it
• Blue – Could solve it
• Red – Can’t solve it

This gives you a better understanding of things you already do for your customers, but also shows you that you cannot do everything. If one of their tasks is to make sure the coffee machine is always working, then your accounting software might not be the right tool to solve this.

Framework Done, Now Take Action

After 1-2 weeks of effort, you finally have more clarity in what to build and for whom. And especially why.

You know what things your users need to get done, and you help them do that either better or faster.

With that, you might just build the next killer feature.

​

PS.: Here are the JTBD templates for Miro & FigJam.