I’ve spent most of the last 15 years either conducting or commissioning UX and digital product research so it’s time I share my experience of JTBD research in an enterprise business to business (B2B) world.
Research is split broadly into two types. Qualitative and quantitive. The most complete kind of research has both a qual and a quant element.
Qual: Contextual interviews
The classic JTBD interview is great but suffers from self-reporting bias. That is people are telling you what happened and human memory means that often we embellish and offer incorrectly post-rationalize why we do something when recounting what happened.
Contextual interviews work well because you are in the context where the person is working. For B2B research this is normally the person’s desk.
Spend an hour with your user. Ask them to show you how they complete a task, you can ask questions as you go. But try not to dictate the flow of what the user is trying to do. Just watch and ask.
Look for the higher level functional jobs they are trying to complete.
Look for gaps in the experience, where people move between systems, write things down for later, ask a colleague a question, refer to an external information source, search Google, etc.
These asides can often give you further sub, functional jobs as well as emotional and social jobs.
I suggest recording the jobs as job stories:
You may only need to do between 5 – 10 interviews. We can then use quant techniques to validate the jobs we’ve found.
Now you have identified jobs you can use a survey to understand how many other users undertake those jobs.
You can use a basic Likert scale
Do you find yourself going to Google to look for the HR policy?
Very often, often, sometimes, never
(I prefer a 4 point scale with no middle, neutral option)
Look for 20 – 100+ users to validate.
Now you have identified the jobs the end users hire your product to do and validated them a scale. Great job 👍. We are done right?
The dirty secret in B2B
The problem with B2B software products, especially in enterprise is that the person choosing the product and the person using the product are different.
They have different jobs. A person on the procurement team my have the social job of:
When I am reviewing the new HR tool online on my own at my desk
Help me to feel like I’m choosing a product that looks modern and will last many years
So I can look good in-front of my boss
Choosing a product that looks like it will last many years is not something a day-to-day user would hire the product for.
Collect the jobs of procurement users either from the sales team or by talking to existing customers, it’s a delicate art but well worth spending the time and effort as what sells enterprise software is sadly often not 100% based on the jobs of day to day users.
Garbage in, garbage out
Good research means you can sure you have identified the correct jobs. Put the time, effort and money into the right, quality research, then you can be sure you are developing your product based on the jobs your users have. Poor research may mean you are making important product decisions on weak foundations.
I regularly run JTBD training workshops for product teams.