Guide: Talking to Users for Small Teams

This post will step you through all you need to set up a lightweight learning cadence with users. It assumes you’re a small-to-medium team and don’t have structured one-on-one feedback loops with the people who use your product. This one’s not about testing, concept research, or a lean/applied mindset, it’s about table stakes for making informed decisions at an early stage.

• Why?

When you speak with your users, you’ll learn. You’ll validate or invalidate assumptions (some you didn’t know you had), figure out what people actually care about, mitigate product risk much faster than building and testing, and learn about the larger context you’re playing in.

NPS won’t cut it: it’s a lagging indicator — useful for benchmarking, maybe — that won’t give you a rich picture of what people need and why they need it. You need to be actually speaking to people, and you can do it easily in a short and loosely structured interview. With a few hours of effort, your team will start building a rich picture of who’s using your product, what they need, and why it’s important to them.

Start with 5 users as a target and try it. This is a lightweight research approach that you can set into a cadence for continuous learning. After a few rounds, you’ll see patterns solidify, and if you feel your learning slow down, reflect and adjust.

• What?

In short, you’ll do this:

  1. select users for an interview
  2. reach out to them with convenient time slots
  3. hold (5) 20–30 minute video chats, taking good notes
  4. run a short debrief meeting with your team to consolidate findings
  5. repeat

• How?

We’ll operationalize it step-by-step:

1 → Select Users for an Interview

First, you need to figure out who you’ll speak with. If you’re just starting, look for people who have recently signed up for your product and converted past your major activation milestone. Get a list of ~60 people you’d like to speak with (depending on incentives & your relationship with customers, expect 10–25% response rate).

2 → Reach Out with Convenient Timeslots

Next you need to reach out: do it personally (use your name), indicate why you’re contacting your user, offer them a simple next step to participate (we’ll use Calendly), and be clear about any incentives or tricky logistics. There’s a template below.

The simplest way I’ve found to schedule interviews is with Attach it to your work calendar, set up the timeframes you’d like to use for the call, create a 30-minute event type, and make sure you add a question to collect video chat ID / phone number. You’ll get a link that looks like this: “<yourname>/30min.”

With link-in-hand, you can write your recruiting email. Try something like this, and if you’re offering an incentive add in the optional [(if incentive:) content] pieces.

Title: <company> research interview [(if incentive:)–$X]
Hi <name>,
I’m <Full Name>, <position> at <company>. I’m emailing you because you’re a current customer who recently signed up, and our team would love to learn more about how you think about <research focus>. Can you help out by joining us for a short phone/video chat? [(if incentive:) We know your time is important, if you can participate, we’ll offer a $X Amazon gift card to thank you for your time.]
The research interview is really simple: I’ll ask you a questions about how you think about <research focus> right now, and the activities that you do for it. It should take about 25 minutes, and we’re flexible on timing. At the end we can also discuss any questions you might have about <company>.
If you’re interested, you can sign up for an interview right here: <Calendly url>. It will set up our meeting automatically, and I’ll follow up with you to confirm the time slot. Please let me know if you have any questions!
Thank you,
<Full Name>
<optional phone #>

That’s it. Send in batches of ~20 and see what you get back. Adjust your incentive upwards if the response rate’s not working. We don’t need large samples here, so get comfortable running small, fast, and lightweight. I recommend running the first round manually so you can adjust your template to address open questions / concerns that come back. For subsequent runs, learn about’s Mail Merge and you can send a templated email to a .csv of customers in one click (video here).

3 → Hold (5) 20–30 minute video chats

Here’s the fun part. I recommend starting with Justin Wilcox’s Customer Development Interview. The framework and his technique incorporate a lot of the basic best practices for user interviewing, and it’s easy to understand and run with. Watch this short video here (7 mins) and pay attention to what is being asked, and how to ask it. You can also refer to the original post for more context on the questions you’ll be asking. In short, you’ll ask:

  1. What’s the hardest part about [problem context] ?
  2. Can you tell me about the last time that happened?
  3. Why was that hard?
  4. What, if anything, have you done to solve that problem?
  5. What don’t you love about the solutions you’ve tried?

and you’ll do it without pitching your product, or asking about any hypotheticals or preferences. Each of these questions may sound a bit weird or awkward to ask as-phrased, but they work—ask with confidence and then be silent, your participant will tell you if they don’t understand, can’t answer, or need more direction.

When you conduct the interviews, have a teammate on-hand to take notes throughout the interview. (This is a great way to involve your engineers & other team members who may not be comfortable conducting the interviews.) Make sure you capture relevant quotes, motivations, questions for future interviews, ideas that spring up (don’t pitch them!), and adjustments for next time. These sets of notes are the primary source you’ll work from when you’re making sense of your round of 5 or 6 interviews.

Consider recording your interviews. It’s not necessary, but extremely helpful collect verbatim quotes or language, fill out fuzzy spots in your notes, or double-check your understanding as you start to find patterns. If you record, ask permission up front, and be clear about how you’ll use and store the recording.

4 → Run a Short Debrief Meeting with Your Team

Get everyone who conducted & observed your interviews in a/the room. Plan for hour, expect 40–90 minutes of time. Your goal in a debrief session is to build a shared understanding of what you saw, surface ideas/insights/patterns, and decide on specific next steps for the above.

I recommend affinity mapping as a lightweight way to get through a debrief. Designers love it because it looks so darn creative, and underneath the shiny cover it’s a simple and powerful approach to making connections across your interviews. You’re going to build out a set of themes and findings from the ground up, letting interesting categories emerge from the ground up. Here’s the procedure:

  1. Assign each team member a set of notes, ideally from an interview they conducted or observed. This is when you can use the recordings to refresh your memory, sharpen notes, or get somebody acquainted with an interview they were not a part of. Should be done before debrief session.
  2. Crawl through the notes and pull out anything interesting onto a sticky note: direct quotes, questions, observations, ideas. Don’t worry about connections yet, start with the raw facts you’ve gathered. You’ll move and adjust and relate them to each other in physical space (wall/whiteboard) to start surfacing patterns and connections.
  3. Go around and start by adding a sticky to the wall/whiteboard, and read out loud what it says. Have anyone with a potentially-related sticky read it out loud and put it next to that one. Continue going around and adding new areas or adding stickies to existing groups, reading aloud as you go so everyone’s aware of the whole board.
  4. If things get messy, stop and regroup. Re-arrange and break out big theme areas into smaller areas. If you’re on a whiteboard, write in next to that group a word or two that captures the major theme. (Or title it with a different color sticky.)
  5. Keep going around until all stickies are on the board: they may be grouped, alone, or in a “misc/uncertain” bucket. Do a final pass to regroup as necessary.
  6. Now, one by one, write a sentence that describes the main idea/insight/question of each group. As you do, decide on next steps: is this something to address? something to investigate further? evidence of a known issue to assign? You don’t have to do something for each category that surfaces, but you should decide clearly if and how you’re going to address it or follow up.

And that’s it, one complete round of customer learning. At the end of the session, make sure you have a record of the patterns, problems, and ideas that emerge from each round. Even if it’s just a few sentences and a couple bullet points each time, you’ll start to build a cumulative body of customer knowledge that you can draw on in the future.

5 → Repeat

Now you’re ready to adjust and go again. Tweak your format if necessary. Think about new, specific sets of users you may want to target. There’s always room to get better at interviewing, and drawing out insight from what you’ve heard. Focus on these pieces once the core mechanics of “interview customers every [cadence period]” are set in place.

• Final Thoughts

Design and research disciplines have a wide set of tools for understanding people and behavior, and framing those findings to be useful in product, design, and strategy. To get started, you really don’t need any of the formal stuff—the most crucial step is to start talking to people, and learning about their actions, needs, and perspectives. Later on you can use this same loop to start working on targeted and strategic research questions that will come up.

Once that loop is in place, there’s a tool worth investigating off the bat: Jobs to be Done.

The essential idea of JtbD is this: don’t think about the features you’re offering your customer, consider “what job is our customer hiring the product to do?” This line of thought comes from Clayton Christenson (author of Innovator’s Dilemma, Competing Against Luck [it’s about Jobs to be Done], and others) and his Harvard collaborators. Like a good persona, it shifts our focus away from the thing we are building to what people need. It’s a subtle shift in mindset. Consider your team’s chance of success with the narcissistic feature-focus (“look at all these features we shipped!”) vs. a focus on addressing real peoples’ real goals and needs (“look how we’re helping people do <very specific job>”).

When you’re larger and begin to specialize in product and design, those teams can do the heavy lifting of generating real personas, charting out service scenarios, and building a clear picture of your product context-of-use. It’s useful and interesting work, but you may find it to be low-leverage without specialists familiar and practiced with the tools (read: early stage / no designer).