Interacting with users

Nobody built a successful product by avoiding talking to people. You are not going to be the first one.

Over the years I’ve found some truths about interacting with users. At first I read them online, later I confirmed them myself. In general, they can be reduced to this:

The more you interact with your users, the closer you will be to their reality. You don’t see your product the same way they do.

This sounds obvious, but it’s hard to scale. You can’t talk to everyone or take every desire into account. That’s why I follow some guidelines on how and when to interact with users.

Here are some lessons I’ve learned:

  • Users are people, with emotions and desires. Talk to them that way.
  • Practice empathy. When someone faces a technical issue, they don’t want to feel like “just another customer complaining.”
  • Use multiple channels. A quick email, a support ticket, every interaction is an opportunity to learn.
  • Be honest with people.

This tips applies to any interaction you have, I’m going to go deeper now on each interaction channel I use, and when.

Interviews

I use interviews when I want to validate something specific. I always bring something to show, as it helps users visualize what I mean. Never a presentation.

Interviews take time for both sides. I usually run two or three first, look for patterns, then either commit to building something or validate at scale with a survey.

I always prepare questions beforehand. Going into an interview without a script is a recipe for wasting time.

Quick note about compensations

Sometimes I need to incentivize users with a discount or reward to get them to an interview. That’s usually fine as long as the topic is highly specific. I’ve found that offering rewards for generic interviews like “how much do you like our product” isn’t worth it, since it tends to introduce bias.

Surveys

Surveys help me validate at scale or gather qualitative data on a feature. I run them inside the product. Email surveys add too many variables I can’t control, like spam filters or missing context.

I use PostHog surveys and I’ve found the key is choosing the right trigger.

For example, showing a survey on the landing page is useless. Most people will dismiss it. Instead, I display surveys after a meaningful action.

Example, Narrax AI

Context: Narrax allow users to create AI generated videos from scientific papers by extracting assets, summarizing the content and composing a timeline with it.

Hypothesis: Users want to embed their own images in the video, but they don’t know where to place them in the timeline. Analyzing the image content and suggesting the user a position in the video would be useful for them as it reduces cognitive load.

Approach: This was really risky and expensive to build, so I displayed the survey after the user uploaded the image asking this simple question:

Would you like our AI to suggest you where to place the image in the video timeline even if it costs you credits? Options: Yes, No, Maybe

Result: We got 12 responses in a week, 75% (9) said yes, 16.67% (2) said no, 1 said maybe.

In this case the cost part was important, if I ask this question without letting them know it will cost credits, I would introduce a bias here as they could think it would be free.

Customer support

I found this interaction channel the most underrated. Especially because customer support is often perceived as a source of troubles. Instead my approach is different:

Every customer support interaction is a good opportunity to forge a better relationship with your users, impress them and finding room for improving your product.

Customer support made me learn to read between lines, users come struggling with something, and my task is to listen to them, and provide a solution. Sometimes a solution is not possible, best I can do in those cases is to provide them an alternative or an estimation of when and how it will be resolved.

I do use customer support conversations to ask for user feedback on specific features, but only when the main issue is resolved.