When it comes to the Jobs To Be Done (JTBD) framework there are two categories: promoters and detractors. While widely adopted, JTBD has its own share of adoption issues.
You need to be strategic, at times abstract, and look at things from different perspectives. It’s not easy, but it’s very well worth it. It’s a powerful thinking toolkit for product strategy, market research, and understanding customers. So what makes it tick for Intercom, Basecamp, Mural, and many others?
The core idea of JTBD is to cultivate innovation by changing perspective from personas to jobs. The framework allows you to get a better understanding of motivations, pains, challenges of your customers.
A job to be done is a shorthand for what a customer needs to go through to accomplish a particular change in his or her environment.
What is so special about it? JTBD allows you to look at what you’re doing from a more timeless and technology agnostic way. To last and be around in 5-10-15 years you need to look at the problem you’re solving from a wider angle. There will always be trends and new technology. It is the companies and products that can look beyond that survive and win. Now, let’s review some valid examples of jobs to be done.
JTBD real-life cases
At Railsware we approached product building as a box of issues for a long time. We also used different product discovery techniques throughout the years. All new products at Railsware start with the Inception. It’s a two-day process to define customers, their motivations, goals, pains, risks, and other important dimensions. So when we first saw Jobs To Be Done, it immediately felt natural and took its place in our work. The method itself consists of five phases:
- Market identification
- Jobs identification
- Jobs categorization
- Create jobs statements
- Opportunities prioritization
As a growing product studio, we built tons of prototypes and have few of our own validated products as well. Two of our successful products, Mailtrap and Smart Checklist for Jira, were not created using JTBD. We started to do both based on our own pains and needs. Using Jobs To Be Done for them helped us refine our understanding of the problem space and expand the market.
By the way, we are hiring. Check out our job openings.
Market identification
Both Mailtrap and Smart Checklist started as issues we’ve had ourselves. At that moment we were interested in solving those pains and building solutions for them. That’s why we didn’t go through a more extensive marketing identification process. There were clear pain points, and they needed a product to cover each of them.
Over time we’ve learned to look at any potential product or idea in a more sophisticated way. That includes understanding the market well and looking for how to position in the niche (if any).
Although not a Railsware brainchild, but rather a consultancy product we did for a client, Knowa is a good example of starting from the market. It kicked off as an idea to make a communication platform for the pension industry. It took over 8 months of customer development, prototyping and testing to come up with a potential solution.
That time helped to deepen market understanding for the founders and form a solution. Knowa became a governance platform for not only the pension sector but also for M&A deals.
Job identification
To do job identification, you can use techniques like interviews, customer feedback, focus groups, and others. In both cases, ideas for products came out of our own needs. We’ve stumbled on issues many times before there was a decision to productize them. It is much harder when you don’t “eat your own dog food”. Then the only way is to keep going over the learn-build-measure loop. That’s how you can build solid expertise, and it takes time.
For Mailtrap, we sent a bunch of staging emails to production users. That wasn’t great. So we thought about how we can test everything in an isolated environment before production. Check out the video explanation for Mailtrap for more details.
For Smart Checklist, it also was simple. We used JIRA a lot, and it was a surprise to see zero good checklist plugins on Atlassian Marketplace. For example, the available solutions did not allow you to manage long checklists through the interface. We decided to get this job done.
For Knowa, it took time to get this right. In the beginning, everything was revolving around communication for pension funds in the UK. In time it became possible to get to a higher level and abstract the main JTBD. But it was built out of small problems like a need for structure around discussions and people. So don’t worry if you can’t identify the correct jobs right away. Build up from smaller ones based on what you know. Test the rest until you’re comfortable enough to abstract it. We will show an example of this in the sections below.
Shift your work experience with us – join Railsware.
Jobs categorization
During this phase, you need define main and related jobs. Also don’t forget the functional, emotional, social jobs to be done aspects. It’s important to say that our jobs were mostly problem-oriented and functional rather than emotional.
Functional aspect
Mailtrap: test email notifications without spamming real users
Smart Checklist: manage checklists in JIRA
Knowa: simplify governance of pension-related projects
Emotional aspect
There are many emotional jobs to be done examples when it paid huge dividends to use them.
The guys from PagerDuty replaced standard tedious ringtones in their mobile app with awesome new ones. They are fun as hell. Users can set humorous notification alerts singing “You Made the Server Cry” or “Gone Are the Hard Drives” when something goes wrong with a server, network, and so on. It added a ton to the product and differentiated them among the competition.
MadebyTrue (former TRUE Jerky) combined emotional and practical aspects by adding a toothpick in each pack of their beef jerky.
Since both Mailtrap and Smart Checklist were internal products at first, we didn’t think about emotional aspects at the start. But it was time to think about them when we were about to release the products to the public.
Mailtrap: early on, there was an idea to have a flower eating emails, and we were thinking about how to animate it. It was fun and special way to make Mailtrap stand out from the competition and have people remember it. This evil flower (actually, not that evil anymore) is still on the Mailtrap’s home page:
Another solution was about naming subscription plans. Until recently, they were titled Midge-trap, Fly-trap, and Bee-trap. But, we had to sacrifice this naming to gain more clarity about which plan covers which audience.
Knowa: it was important to emphasize a few points:
- security (there is a lot of sensitive data and you need to feel in control)
- privacy (every user should feel that his or her data shows up in proper places only)
- simplicity of the platform
For simplicity, Knowa opted for a simpler approach to the interface. It’s nice but not too present-day. When showing any feature, we think of how to make users feel as secure as possible. Security is not only the part of the backend but also a metric of how users feel inside the app.
Create jobs statements
You need a job statement to describe your JTBD. The framework has the ‘verb + object + context’ template to do this. Now let’s look at job statements for each product. Remember that we need to convey the idea of what the product is to be hired for.
Mailtrap:
Test (action verb) any notification (object of action) before it’s sent to the end customer (context)
At the moment we only use emails for notifications. It’s easy to see how this can expand to any type of notification and expand the market for Mailtrap.
Smart Checklist for Jira:
Manage (action verb) small-to-big checklists (object of action) in Jira (context)
Though the Markdown editor is the epic feature of Smart Checklist, we do not need to insert it in the job statement. Why? Because the main JTBD is still to manage checklists. This way we also can avoid thinking too much about a specific technical solution.
Knowa:
Make (action verb) modern governance (object of action) easy (context)
is one of the most precise and clear jobs to be done statement examples.
Opportunities prioritization
At this phase, you prioritize JTBD using different criteria. This can be customer satisfaction with the existing solution, how easy it is to develop new solutions or improve existing ones. As a result, jobs will be divided into the following categories:
- under-served JTBD – you can improve existing solution on the market through innovation
- over-served JTBD – you can update solution to make it more affordable compared to the existing solution on the market
- served right JTBD – your chances to wedge in are rather low because the particular job has enough proper solutions to get it done. In this case, it’s better to change focus to other related jobs
All Jobs To Be Done examples were under-served. Smart Checklist had a few alternatives, but none of them had this approach to managing checklists. Mailtrap was a breath of fresh air on the market, and this job to be done resonated well. Knowa is a new take for its industry and has little direct competition.
The job to be done product examples above provide you with a general idea of how the JTBD methodology works in real life. As you can see, one of the main JTBD benefits is to cultivate innovation and come up with better solutions. You also can use Jobs To Be Done for:
- Competitor analysis
- Design offers and product placement
- Customer experiences creation
- Aligning processes and other useful things you can learn here
JTBD often struggles to find its place in comparison to personas or user stories. Let’s try to figure out why.
How Jobs To Be Done differs from other user-centered approaches
Personas
Persona is an imaginary representation of a target customer. For this, you need to consider the user’s behavior, motivation, preferences, requirements, and other aspects. This method has several benefits:
- personas push you to empathise and think about users
- you can use personas for decision-making
- personas help to generalise and prioritise your efforts
The Jobs To Be Done framework, which sets the focus on jobs instead of people, is often shown as the antithesis to personas.
Some say that JTBD is better and there is no need for personas at all. That usually comes out of the standard (and often wrong) demographic approach to personas. Historically personas had tons of demographic information in them (age, location, gender, etc.). Over the years this became a de-facto dogma. What is often forgotten is that personas are there to build empathy. This is their core purpose.
Empathy is not what JTBD is good at. There are emotional and functional aspects, sure, but it never gives as comprehensive look as personas do. We recommend that you carefully study both approaches and use them together. This way you get the best of both worlds and a much richer picture. After all you need to understand your users and what jobs they need to be done.
User stories
A regular user story template looks as follows:
As a (role), I want (objective), so that (benefit)
It’s easy to talk to pretty much anyone in user stories. They are simple and down to earth. They allow you to understand what users want and what can be built.
Yet, the major drawback is to have users as a primary source of requirements. This can lead to many conflicts between requirements, missing some of them, focus on ambiguous requirements, and so on. Job Stories are there to cover these flaws. Both approaches are similar and very different at the same time.
| User Story | Job Story |
|---|---|
| As a___, I want _____, so that _____ | When _____ , I want to _____ , so that_____ |
| As an administrator, I want to be notified on any new sign up, so that I can start communication with new customers. | When a new customer signs up, I want to get a notification, so that I can start communication with him or her. |
As you can see, Job Stories address an action (job) instead of personas which makes them more independent from solutions.
User-Centered Design
The Jobs To Be Done method puts the problem first to understand which challenges and needs a user faces. It is required to find out a solution in this regard. User-Centered Design (UCD), which occupies the niche of software development, is quite similar to this concept. Meanwhile, the UCD rests on three principles:
- The solution should be based on the user’s goals, tasks, and motives
- The solution should follow the way the user processes data and makes decisions
- The user should control the state of the solution
UCD and JTBD are similar in their mindset of involving the direct observation of users. In view of this, they are often considered as complementary to each other.
Though some techniques overlap with jobs to be done, it’s hard to say it can replace each of them. The best decision would be to benefit from shared use of JTBD and other methods. However, if you need JTBD, go ahead since it has much to offer.
Who should try the framework and why?
Product owners, product managers and startup founders looking to gain new perspectives
JTBD allows you to think strategically and build a product that will last beyond current trendy or technical solutions. The framework is a great tool for market discovery and evaluation.
If you are looking for a versatile tool that would help you not only come up with an offbeat product idea but also investigate the context, detect all risks and opportunities, and create an actionable roadmap for your product development in one session, then BRIDGeS is exactly what you need! BRIDGeS is a flexible framework that took all the best from JTBD and many other tools to help you make decisions and create solutions easier. Find out more about BRIDGeS and what advantages it can bring to your team here.
Developers and UI/UX designers aimed at building a great product
The goal of the team is to make a kick ass product. From that perspective, Jobs To Be Done can bring more innovative solutions as it goes to interface and product vision itself.
Marketing team willing to understand customer purchase decision
Are you a marketing team member, and you need to figure out what drives customers to make purchases? In this context, the purchase process is a customer’s job to be done, and you can study it with the JTBD framework. When there is a clear understanding of how purchases are made, it’s much easier to find a root cause and make an improvement. Then it’s only up to your creativity to come up with better solutions.
Let’s face it – Jobs To Be Done is not easy. It takes time to understand and to glue it together with everything else you’re already doing. In this article, we introduced how the Jobs To Be Done framework examples look, and limelighted the benefits of this technique. From our experience, JTBD is a great concept to try and dig into. Try it out to see if it works.