The job to be done of your job

  
0:00
-0:53

Recently, I was listening to the Invest like the best podcast with Instagram co founders Kevin Systrom and Mike Kreiger.(clip above)

They spent some time talking about jobs to be done, which was really nice to hear since I have spent so much time doing jobs to be done interviews.

What I like about the jobs to be done framework is that it makes you focus on two things fundamentally.

  1. The specific situation that someone is in

  2. The set of struggling moments that they encounter in said situation.

Although, this is is the first time that I actually thought of my skills as serving a job to be done for my “customers” inside the org which I work.

This made me think of a few interesting questions as it relates to the team work of product development.

  1. What is the JTBD for different people inside of a tech organization?

  2. What are the struggles that different teams face when building product?

  3. Are there patterns of situations that people inside an org find themselves in that cause these struggles?

The Job(s) To Be Done of Product and User Research

When I think about product research (something I do quite often), product development, design and strategy, I have a feeling this way of thinking can be really useful.

Based on past conversations, I think the core jobs of product research is as follows:

The core job:

Make it possible for teams to focus on their craft and the quality of their solutions, not the validity of problems.

sub jobs: still important but in service of the main job

  • Enable product developers and designers to identify and solve the highest priority problems for users/customers quickly.

  • Take away confusion or ambiguity about what specific user groups are trying to achieve in their lives and with your product(s).

  • Help everyone make decisions that are rooted in customers reality, not opinion.

    What did I miss? What do you think?

    Leave a comment

How to solve for the JTBD of user research

Then the question becomes how do you service this internal JTBD?

How do you “Make it possible for teams to focus on their craft and the quality of their solutions, not the validity of problems.”

Currently, my thinking is that in order to solve for that internal JTBD you have to prioritize a few important trade offs.

You have to make it

  • More about TLDR, less about reports

  • More about the product in the users context, less about the user in the products context.

  • More about personal stories, less about small sample size empirical evidence.

  • More about prioritizing user pain and struggle, less about generic feedback

  • More about making it easy to think about users as someone you know well, less about guessing, assuming and projecting out own biases.

What am I missing?

Leave a comment

Loading more posts…