Quick-fire reasons why I love Jobs To Be Done for Platform Design
The research framework transformed how I conduct discovery and make decisions.
You can scroll past this intro to jump straight to why I feel Jobs To Be Done is great for Platform Design.
I work as a designer at intelligent energy platform Kaluza. We are building a platform for multiple markets, users and use cases. All to save consumers money and reduce the carbon impact of energy.
There is a lot of ambiguity. We are figuring some things out for the first time. We work closely with highly technical energy specialists, analysts and engineers. As designers we apply design-thinking to find the golden opportunities.
Bringing Jobs To Be Done into our platform
Three common challenges I encounter in the platform space are:
- defining a complex and dynamic range of users with limited time
- maximising value in my designs with limited resources
- remaining agnostic to cater for future customers
Researcher Faisal Chaudhuri introduced Jobs To Be Done (JTBD) to be trialed in our Kaluza Platform Design team. And it has been empowering me to be drastically more effective.
JTBD provides a framework to identify what is happening in the field of your product/service. You can quickly categorise what you, your users, your partners and any third-parties are doing. Everything is recorded as a job, basically an action. And it all fits together like a jigsaw.
The approach gives you a script to quickly capture a shallow understanding of the big picture. But areas of opportunity are easy to flag for deep dives. Here’s an example of how the job hierarchy works.
The point of using this approach is that it’s easy to equip yourself with just enough targeted knowledge to make a well-informed next step. But without further ado, here are my reasons to love Jobs To Be Done for Platform Design.
Reasons Jobs To Be Done is powerful for Platform Design
It is easy to share insights
The output of JTBD research isn’t stranded on a whiteboard. A beefy workshop or interview can be transferred quickly to a simple table. This is easy to share on an email, ebook or Confluence page.
Non-designers can pick it up quickly
Not only did I find it easy to get started with JTBD, so did non-designer colleagues. This technique provided a friendly way to induct Product Managers into conducting their own discovery, as it is so simple and structured.
I just provide weekly guidance, which drastically increases my research bandwidth.
I can lean on the framework during a user interview
I’ve had user interviews crop up at short notice. I’ve had group interviews on technical areas I know little about. I’ve had interviews after being up all night with my toddler. JTBD can structure how you frame a conversation if you follow the simple jobs canvas grid. So that you don’t have to think (as much).
My mind: I feel so tired, I can’t remember what 13 third-party tools they use. I’m not even sure I know the exact name of their department.
My questions: Hi! What is your main purpose? How would you split that into categories of smaller tasks? Great! And what little steps would you split those into? Thanks, I‘ll be in touch again to dive into detail on some specific areas.
That (slightly abbreviated) question script could be more or less applied to every user introduction interview I carry out.
I can lean on the framework when going through my findings
You can use rough job canvases when capturing insights from interviews/recordings. These are almost ready to be transferred to your insights like-for-like. After light editing, you’re ready to document!
This greatly reduces how intimidating it is to discover a new user type, encouraging higher volumes of interviews and workshops.
I can quickly analyse products in bulk
As you collect jobs at varying levels, you can gather broad insights. One insight is the tools used for a specific job.
It is easy to spot overlaps where different tools complete the same job. And I can methodologically go through every single job with the interviewee to capture pain points.
I can quickly understand how other tools are used with ours
What is the user doing before they open our product? Where do they go after? This isn’t something I can gather in as much depth as with service mapping. But I do get the opportunity to explore the product landscape from a distance.
Such as what CRM an agent uses to trigger a new piece of work. Or how they share reports with their colleagues. This kind of insight has been crucial to empathise better with our users.
I can quickly grasp relationships between user groups
Job canvases let me discover how different user groups take responsibility for different jobs and where the overlaps are. Fantastic for a deep understanding of the user sphere.
Alternating product/user means-tests our knowledge
The structure of JTBD lets me flitter between a user or product lens. I have been able to understand the varied preferences across different user groups for different tools that perform same job.
JTBD is supporting user stories and mission/vision
Jobs To Be Done has supported us tactically by replacing user stories with ‘job stories’. These have been invaluable to structure co-design workshops. Unmet user needs or jobs can act as the improvement. They feed into the larger jobs that ensure we are accountable to the purpose of our product.
I found that sometimes, the so called ‘need’ was actually an additional job. In other cases, it was just an enhancement (need). The job that kicks off the story isn’t the same as the final job that is enabled by the improvement. One will generally be at a higher altitude than the other.
The same is true at the strategic level. Big and Main Jobs feed product value up to our approach in defining team mission and vision.
Job insights are compatible with other techniques
Actors, systems, paint points… JTBD offers fantastic groundwork for deeper service design.
I have also attached jobs to sitemaps. This has helped us to evaluate an information architecture by surveying how jobs are split across a user interface.
Final thoughts
I hope these use cases come in useful or inspire new ideas. I think my main takeaway is that Jobs To Be Done has made research more accessible.
I can gather high quality insights with limited time and resources. This helps make better design decisions and ultimately reduce UX debt.
Suggested reading
Applied Job To Be Done: Jobs to Be Done by Jim Kalbach
Tips on interviewing people: The MOM Test by Rob Fitzpatrick
