There was no user research process or function in place and few people (if any) were talking to our users on an ongoing regular consistent basis.

There were a few conversations with power users that employees at the company knew well but we didn't have a recurring cadence of a more diversified group of users to connect with.

A Jobs to be done is not necessarily a replacement for user personas, but sometimes can be accentuated by one. This document covers sourcing based on specific segments so it somewhat encompasses the user personas already (it's a step after the process).

The major way we used these forces (the graphic which is adopted from Intercom's Jobs to be Done post) basically allowed us to understand what either pulls or pushes a user away from our product.

This was important as understanding their problems gave us insight into what'll pull them towards us and their major anxieties around coding and programming in general (or new tooling in the space for that matter) that might push them away from us.

Segmenting became extremely important because we had a wide variety of use cases for which people were using Replit. Being a globally used product, there were unique behaviors and patterns that came up across different geographic cuts. For example, Indonesia focused a lot on learning on their mobile devices.

Further, segmenting allowed us to not be too "broad strokes" in our research and implementation when we learned about our user behavior for a particular use case.

The hardest part for anyone, not just PMs in my opinion, is refraining from talking and just listening (free of judgement)

Everyone has an opinion and it was always illuminating to see one or both people in the interview (we tried to do user interviews in pairs: eng-design pair, design-PM pair, eng-PM pair) jump to the defense of a feature that they had shipped or were planning on shipping.

This naturally muddies some of the learnings you're getting if you're interjecting, so watching and observing closely and understanding why users do/say certain things becomes important.

In terms of how to get better at not doing this, I find it best to usually just write thoughts down on what you would've said instead.

A good portion of our time was spent interviewing people learning or new to programming, so by and large, there were certain questions that were always asked, such as:
- What was the first thing you did to learn programming?
- What were other tools you looked at when evaluating Replit?
- How did you come across Replit?
- How familiar are you with programming?

We usually avoid too many questions. Most interviews were 30-45 mins and that really only leaves time and space for 5-6 meaningful questions, barring intros.

Tabish Gilani

I created this to teach others how we conducted user interviews at Replit using a Jobs To Be Done (JTBD) framework. It covers everything from how to source, prep, and conduct user interviews to get the most learnings.

For generating large interview campaigns where you need to source difficult to find users, use this guide.

To combat the increasing perception gap of what/who our users do/are along with why they do the things they do

The data can only tell us "what" the user is doing and a limited understanding of the "why" User Research adds context and understanding behind the data that we see at an aggregate level.

 to conduct user interviews and identify product themes which helps us understand the Ideal User Profile


What is the value that the product provides

What is the potential ideal state for the user after extracting value

What is the Job that a user hires Replit for? (JTBD framework)

 that we can utilize to build an empathy map for the user

 that we can utilize to find users to conduct interviews on

Behavioral: Product Usage, Actions taken in Replit

Demographic: Age, Gender, Education, Occupation

Psychographics: Lifestyle, Personality, Values, Interests

Take notes - capture as much as possible (recording is also an option, but ask permission)

Let them know the information we'll collect, which is available in this publicly available document 

Explicitly tell them they'll do most of the talking so they don't feel uncomfortable

Just observe and don't judge their answers (they'll be frightened to offend you)

Don't immediately offer help if they get stuck

When you must respond, leave it open-ended:

Summarize hearings back to interviewee to confirm your perception — "what I'm hearing is X"

Tangents can be useful if you keep hearing them, but otherwise you can try to redirect back to original problem

If people start talking about features they want:

"Can you walk me through when and how you would use it? How would it help you?"

"Sounds like you have X problem. Is that accurate? Can you tell me more about it?"

Any questions that led to bland answers? Can you revise?

Anything you wanted to learn but didn't get to?

What questions/topics got the most emotion?

Jobs-to-be-done Interview Script/Question Bank

Customize the bracketed language according to your needs.

Avoid leading the interviewee’s answers, e.g., don’t describe your product.

Thanks for taking the time to share your experience with [our product]. We’d love to understand how people use it, so we’ve scheduled some interviews with people like you who [have used our product / face this problem] to hear their stories.

We’re not looking for any specific answer—your honest feedback will help us improve [our product

If you can’t remember something, that’s OK. We just want to hear about your experience.

I’d like to keep our conversation to [30 minutes]Do you have a hard stop that I should know about?

Would it be OK if I record our conversation so that I don’t need to take notes? We won’t use any of the footage without your permission.

What did you run into that made you decide something needed to be done?

When do you generally [encounter problem]?

When did you start thinking about [problem]?

How did you hope to feel after [solving problem]?

What was the first thing you did to [solve problem]?

How did you start looking for solutions to [problem]?

What apps/websites do you use for [problem]?

What happened that eventually made you feel that something wasn’t working for you?

Who/what influenced your decision to use [solution]?

What almost stopped you from using [solution]?

What was happening when you decided to use [solution]?

Was anyone else involved in making the decision?

Did you ask anyone about what they thought about [solution] before using it?

Before you used it, did you think about what [solution] would be like?

Did you use anything else at the same time?

Did you have any concerns about [solution]?

In your own words, how would you describe [solution] to a friend?

Jobs to be Done User Research Guide at Replit

Jobs to be Done Interview Guide

User Interviews

Why we do interviews?

How do we do interviews?

Sign up to see more