Most of the recruiting logistics existed outside of this document. In some cases, there were two people involved in the interview from the company side (not the participants), so we included the recruiting email copy here so that everyone who was involved knew what context had been shared with participants.


A good outreach message does three things:
1. Introduces who you are
2. Communicates the kind of people you want to talk to / why the recipient is a good fit from your perspective
3. Specifies what the ask is and how to participate

I would give this outreach email a B/B+. "To improve our product" is helpful if you are an existing user, but it's probably better to communicate what about "how you build and ship code" is interesting to the company.

Given that this was a pretty foundational study on how software engineers work and we reference our tool (which does a specific thing), it felt okay to keep this somewhat broad.


The redacted link here goes to a screening survey.

When you are sending out an email to a number of people, it's important to use a screening survey or some set of questions to help you prioritize out of the potential participants AND prepare for the conversations with each of them.

You want to make it clear what people are potentially agreeing to up front so that you don't waste their time.


For this project because I wasn't the only person doing the interviews, I wanted to make sure there was high level guidance as a reminder to others.

Each person who was conducting interviews had already gone through interview training and heard a much longer version of this, but I felt like keeping it here would be useful just in case.

How you start off can vary a ton based on the setting. The way you'd kick off an interview in a B2B context is different whether they are new customer or they have a longstanding relationship with the company, and it's also different with how you would probably kick off a B2C interview.

The most important thing to do here is orient your participant to the conversation at hand and focus their attention from wherever it was in the world to the here and now. It also is a time for you to start building rapport and getting a sense of how they answer questions so you know how to ask questions effectively.

There are a few reasons you want to call this out at the beginning of a conversation.

First off, it's important to make sure everyone knows why they are in the room. There's been times where I end up in interviews where someone had different expectations or understanding about the point of the call, and doing this helped us realize it would be a bad use of our time.

Second, being clear about your perspective and orientation to the call is the first step in building rapport with your participant. This isn't a quiz or a test.

Finally, language like this can help remind your participants that they are the main character here and you're excited to learn their story (or at least a specific part of it).

I always like to ask this so that there is room for the participant to share concerns, questions, or even hopes about conversation topics before we dive in so that I can plan accordingly.


Asking for consent to record is important! It's not only unethical, it can be illegal to start recording by default.


Sentences like this act as "signposts" and signal changes in the conversation. Everyone I've worked with has different phrasing for this, so feel free to use words that feel authentic to you. What you want to do is make sure that you are signaling to your participant that you're shifting the conversation to a new direction or altitude.

You'll see examples of this throughout the conversation guide. I say things like:
- shift gears
- zoom out
- switch topics

These questions are helpful ways to get a participant talking. The questions invite the participant to speak from their experience and help you get a sense of how they will respond.

While you generally want to ask about specifics in an interview, I find that opening up with broad questions like this are good ways to get the conversation flowing.

Something you want to be careful is not asking questions in a way that sound like they are a quiz — "what does company do?" can sound like a test if you're too direct.

"How is it organized?" might be better asked "What are some of the different teams?" which is right below as a nudge to the interviewer.

Since we're talking to software developers and people who write code, this could be quite a long list with many of the activities and responsibilities being interconnected.

Part of asking this question is getting a sense for the kind of work they do, the people they work with, and where building products fits into their job — i.e. Are they an individual contributor who works mostly autonomously? Are they a technical lead that spends some time mentoring? Are they a domain expert who is involved in technical decisions around languages and frameworks? These are the kinds of things I would have expected to hear (and did) when we asked these kinds of questions.

This can be a strange question to ask, but I've found that asking flavors of this can be really enlightening.

It's related to the responsibilities question because it can help you understand what this person's incentives are.

These can seem like potentially silly questions to ask, but because we were trying to understand what work looks like, it was important for us to understand work from a range of perspectives — not just writing code, but also working with others to build products.

You can see in the question below this that we expected people to talk about the process of building being something that frustrates them, but if they didn't bring it up, we wanted to ask specifically.

Here's another one of those signposts that I mentioned. I'm changing topics and want to be clear about that for the participant.


This was one of the most important questions we asked, and also one of the most exciting — we really saw participants light up when we asked this.

In these kind of situations, you really want to pay attention to voice, tone, posture, and level of detail when participants are sharing their answers because all of those will be clues about what they are excited about and what you should dig into more.

In our case, we were talking to software developers about the tools that they use to do their work, so it's something that most people had thought A LOT about.

Asking this question was very often like pushing a snowball down the hill — it was easy to get people talking and the important part was to guide the conversation so you didn't go too off course.

Between the question about the development environment and the question about software decision-making generally, you may not need to ask this question. But since it's something we care about, I made sure it was explicit in the discussion guide.


It's likely that we got good partial answers to this when people talked about their development environment, but asking this gave us a good view into all the entire workflow and often some non-technical aspects of their work.


There was a very popular tool during the time we were doing these interviews that we wanted to ask about. Because it was likely to come up and was potentially interesting to us but not critical, we saved it for almost the end of the conversation.


This is a very important question to ask.

Part of the reason that this is important is you have covered so much ground with participants that you want to let them pause and identify what this conversation has brought up for them.

Always thank them — customer time is not free.


Behzod Sirjani

I created this discussion guide and email copy for an early stage company who wanted to better understand developer workflows to inform a tool they were building.

Developer Research - Email Copy + Discussion Guide

You can use a version of this message to book interviews.

My name is NAME, and I work on the [X team] at [REDACTED]. 

I’m talking with a few [users / developers / people like yourself] to understand how you build and ship code in order to improve our product. I know that you may not be a current [REDACTED] user, and that’s totally fine. This is more about you and your workflow than our tool.

If you’re open to chatting, please answer a few questions here [REDACTED LINK] so that we can best prepare for the conversation.

Each conversation will last approximately 45 mins, and we’ll send you a $75 Amazon gift card within 5 business days as a token of our appreciation.

Important things to remember for every interview:

✓ Prior to the interview, briefly review the participants’ responses in this spreadsheet [LINK REDACTED] and LinkedIn profile (or equivalent) to get a feel for their work history. You’ll be asking them about this in the call.

✓ Staff each interview with 2 people (one is talking; one is taking notes)

Make a copy of the discussion guide (below) and use that to take notes

Try and capture *verbatim dialog* if you’re not using some sort of transcription tool. Write down the actual words someone is saying; we care a lot about the specific ways that people describe things.

and add to your notes document in Google. Make sure you are recording the meeting. Watch this Loom [LINK REDACTED] to get set up with Grain.

Important! Spend 5-10 minutes highlighting in yellow the particularly interesting things people said. What stood out? What further questions did it bring up for you? Make note of it in the doc. Add Google comments with your thoughts and key takeaways so others can easily scan through. You can also use Grain to create highlights.

Save the interview notes here [LINK REDACTED].

5 mins - Develop rapport with the participant

Some kind of greeting – How is your morning/afternoon/day going so far?

Hey [PARTICIPANT NAME], my name is [NAME] and I am a [ROLE] at [REDACTED]. I really appreciate you taking time to chat with me today about your work as a [ROLE] at [COMPANY].

If there are two of you on the call, introduce your partner as well.

Our team is trying to better understand the core responsibilities and workflows of people like you, so I may ask you some questions that feel really basic, but I promise that they come from a place of genuine interest. We know that there are lots of different ways to write software and build products, and I’m excited to talk to you about how you do it.

There are no right or wrong answers to any of these questions, I’m truly just interested in your experience and perspective.

Do you have any questions before we get started?

Is it okay if I record this call so that I can review it later? We will not be sharing this outside of our company. 

 I’d love for us to start off by hearing about [COMPANY] from your perspective.

Now I’d love to hear a bit about your work at [COMPANY].

At a high level, what are your core responsibilities at [COMPANY]?

For each of the key responsibilities, dig into the following. You likely won’t need to ask all of these, since much of it will flow naturally. Try to keep this to 5 minutes.

Who do you collaborate with to get this done?

10 mins - Understanding the person and their context at work

Understanding someone’s OKRs / goals is a good way to understand what is most important to them at work.

What do you enjoy most about your work at [COMPANY]? Dig into why.

What are some of your biggest frustrations about your work at [COMPANY]? What keeps you up at night with regard to work?

What are some of the biggest challenges or friction you have when it comes to building products?

How much control/autonomy do they have over solving it?

Now I want to shift gears and dive into how you and [COMPANY] build and ship software/products.

Can you walk me through what your development environment looks like?

For each of their tools, if it isn’t painfully obvious, dig into:

Whether or not they pay for it as a company?

Who made the decision to bring that tool to the company?

What does and doesn’t work well about it?

I’d love to hear a bit about how your current development environment looks different today from past companies you’ve worked at.

How does it compare to [PREVIOUS COMPANY]? 

Whose job is it to decide the development workflow and stack at [COMPANY]?

Who else needs to weigh in on or approve that decision? Walk me through the step-by-step process of approvals.

Dig in: Who on IT? What’s their title? What is their review process? Then what happens next?” The goal is to understand how new tools and processes get adopted.

How much control do you have over the tools that you use at work?

 (Try to focus on the things that matter when it comes to writing software/building products).

Which tools feel like they get in your way?

Say you were curious about a new tool. What are some of the things you look for to evaluate whether or not it’s a good fit for you?

When you start a new project, what are the first few steps involved?

It’s helpful to understand if they start in code or elsewhere.

What’s the hardest part about this process for you? Why? Where do you get stuck?

[[If they’re an existing [REDACTED] user]]: I know you’ve used [REDACTED] in the past. Have you used [REDACTED] for work-related projects or side projects?

Dig into those projects to learn why they chose [REDACTED], what worked well, etc.

Can you tell me about where [REDACTED] creates friction in your workflow?

As we’re wrapping up, I wanted to go back to something you said. Can you tell me more about [TOPIC]? 

I really appreciate your time and this conversation. Is there anything else you’d like to share before we end?

Often, if the interviewee is familiar with your product, they’ll end with some feature requests or ask for customer support. It’s helpful to think about what your response might be when this comes up.

Developer Research Discussion Guide + Email Copy at Stealth Startup

Developer Research - Email Copy + Discussion Guide

Recruiting Email Copy

Booking interviews: Email or DM copy

Sign up to see more