How I used JTBD framework to draw insights from user interviews
Written by Eugene Nikiforov, PM at The Product Gene
While interviewing junior-level Product Managers, I’ve struggled to establish a framework to analyze insights from the interviews and more importantly — to draw conclusions from them. I was overwhelmed by the depth of problems and motivation that drives PMs at their job. The data I was collecting seemed inconclusive and not interdependent. The more interviews I’ve conducted, the more different people’s stories I’ve heard, bust structuring this stories and understanding what to do based on them was the real challenge.
My initial approach was to count frequency of specific problems, traits, situations (anything that could be relevant) across respondents. I ended up listing this data along with a percentage of how many respondents mentioned that situation. That wasn’t very useful but it was a good start. The main thing my list was missing was a context — It didn’t address the Job Story behind a specific problem.
Later on
advised me to apply Jobs-To-Be-Done approach to my task and recommended checking out Intercom’s book on JTBD. The framework turned out to be eye-opening on the way to perceive your customers and competition. The main idea behind JTBD is that customers hire products to do jobs that help them progress within a specific context. For example you might hire a plane to get from point A to point B. But the competition the plane faces heavily depends on your motivation of getting to point B. If you want to go on vacation, the plane competes with local vacation opportunities. If you go for a business meeting, the plane competes with videoconferencing and shared workspace software. You get the idea. The reason (story) you hire a specific product to solve your problem, defines the product’s competition. I felt like the JTBD approach could help me with analyzing interviews and applied it to the respondents’ problems.During interviews, I’ve often encountered PMs taking coding classes and I wasn’t sure what to do about it, before I’ve applied the JTBD framework. A product manager might hire CodeAcademy to learn coding. How do you compete with CC for PM’s time and money? One might think that you should produce better or cheaper courses, do more appealing UI, get better instructors or use other ways to amplify the current model. But that approach does not appreciate the underlying reason, why a product manager hires coding class in the first place. PM doesn’t hire coding course to learn coding. Her main Job Story here is “I want to speak the same language as engineers in order to gain their trust and respect and not to feel anxious about communicating with them since I don’t understand the technical side as good as they do and they know it”. Learning coding is just the obvious solution to addressing that job story, but not the only one. This is why we are doing a case study block (pure practice) to work on communications with engineers. We are addressing the same job story in a different way, but with the same outcome — reducing anxiety about working with developers.
Applying JTBD to every problem on the list helped me to structure the PM’s problems and brought the common patterns on the surface. I’ve attached two markers to every problem:
- The frequency among the respondents in the sample
- The frequency of facing a problem or its implication ranked on a scale from 1 to 10 times the pain of facing the problem ranked on the scale from 1 to 10.
I used these two figures to prioritize the jobs that PMs have in order to understand which one we should solve first.
When getting to the deep motivation of the respondent, I found it useful to bombard the person with the “Why is it hard/important?” question once I found a pain point. The question is extremely uncomfortable to repeat over and over again, but it’s extremely useful. The idea befind that is that nobody shares personal emotional motivations right away — you have to dig deeper in order to get to the bottom of it. The typical exchange has looked like this:
— I want to get better at creating roadmaps.
— Why is it important for you?
— Because I feel like it’s one of my weak spots.
— And why is it important to focus on it now?
— Because I’ve been hearing some negative feedback on my roadmaps from my stakeholder.
— And what are the implications of you bringing a poorly-done roadmap to the stakeholder?
— I have to do several iterations before it’s approved.
— And what are the implications of that?
— The manager may think I am incapable.
— And what are the implications of that?
— It’d harder for me to get promoted or grow.
— And what are the implications of that?
— It sucks.
This way of structuring questions means basically drilling down till you get an emotion from the respondent. That means thay you’ve uncovered an underlying motivation. Now you understand the story of the job that this PM may hire someone for.
Another way I’ve applied JTBD framework is communications strategy. The idea is that communication we use on the landing page should not be built around the product we are building. Communication should be about the job story PM has and us solving this job in the most cheapest /efficient way. As I’ve learned on UX research calls later, it’s of paramount importance to draw a logically consistent line of reasoning between the customer’s job story and the solution you are offering. The user should be able to follow your explanation on how your solution executes his job better than any competitive, since in the end that explanation is what you have to sell to your customers.
Join our Slack community to stay up-to-date with our product and business results and help us deliver the best product to the market.
