To me, succeeding in the long-term as a user-focused company is all about building out your own framework for talking to users, learning from your experiences as you go, and ensuring that you have buy-in from your team and leaders to do so.
In this post we’ll cover:
Why it’s important to talk to users
The two primary phases of user interviews and user research
If you’re somewhat familiar with the startup world, you’ve probably heard the phrase “Do Things That Don’t Scale”. It’s the title of a popular essay by Paul Graham, founder of the most popular startup accelerator, YCombinator.
The main point that Paul makes in his essay is that everyone should just go out and talk to users. But he also explains why very few do so:
“They'd rather sit at home writing code than go out and talk to a bunch of strangers and probably be rejected by most of them.”
Whether you’re starting a new business or pursuing to grow an existing one, this is true. Talking to users is a lot “harder” than simply looking at usage data or asking a friend, family member, or colleague for advice.
I know this very well, and here’s why…
The Failed Startup I Co-Founded
Quite a few years back, I started a small project with a few friends. The idea was that people could buy a share of their neighbors’ dinner. While I was studying, I found very little joy in cooking (still do). So if there was a way for me to get a nutritious, fresh meal close to my home, made by people living close to me, that would have been awesome.
One of the first things we did when we started the project was to design the interface of the app we were going to build. We set up a landing page and posted launch posts, etc. on social media to drive initial traffic to it.
What we didn’t do was talk with those who signed up. We just thought we’d keep them on a launch list and blast-send emails to that list as soon as we had a product ready.
Close friends and family of ours gave great hints as to why the product/market fit just wasn’t there yet. But we kept going and told ourselves that they just weren’t the target audience.
That, or that they just needed a little more convincing (red light signal).
I eventually left the project as the rest of the team and I had some difficulties working together. The remaining team actually went on and raised some seed money and got national TV coverage.
But the project never took off and I attribute one single thing to why it didn’t make it further than that; not talking enough to users.
We should have validated the problem with a lot more users and used those as our initial pool of people to get feedback.
My guess is that our proposed value proposition was a bit off and that users might have liked an approach slightly different and maybe more in line with traditional takeaway.
Our mistake was that we were insanely focused on building a solution that wasn’t solving a big or clear enough problem. Let alone one that people would pay us money to solve.
Enough with the lookbacks. Let’s dive into the two main phases of user interviews and research.
Understanding The Different Phases Of User Interviews
You can divide user research into two primary categories:
Talking to users for product/market fit and feature development
Talking to users to test user experience and interface
The double-diamond model has often been referenced as a great way to grasp how experts think about talking to users.
The first diamond is about finding the right customers and making sure you’re solving their problems. The next is about testing whether your solution actually matches their wants and needs. Discovery. Delivery.
When starting a new job, I suggest building a frictionless process for talking to users at least once a week. Whether it's answering support tickets or doing interface testing.
Finding Product/Market-Fit And Building Features
While many would claim, especially those claiming to be data-driven, that their churn cohort data would tell you if they’ve found product/market fit, actually talking to users is so much better.
In the early days, before building anything, one of the frameworks you could follow is the one Mitch, Partner at Y Combinator, talks about in his Youtube video. He suggests you start off by asking your potential customers:
What is the hardest part about doing the thing that you're trying to solve?
How do you currently attempt to solve that problem?
Tell me about the last time that you encountered this problem.
Why was this hard?
What, if anything, have you done to try to solve this problem?
What don't you love about the solutions that you've already tried?
Figuring out the potential of the idea:
What are you currently spending to solve this problem?
How often do you experience the problem?
What is your current budget to solve this problem?
Asking the right questions
Now imagine this 3D drawing of a mountain-like figure. The basic idea is that asking too closed questions will likely only get you, at best, to a local maximum. Asking more open-ended questions could get you to a global maximum. But it could also get you to the very bottom.
User Experience & User Interface Tests
Once you’ve figured out what users want, it’s time to start digging into the second half of the double-diamond model. This is where we test the solution(s) we’ve come up with, with our users. The goal is to see if they understand how to use it.
Remember, doing this only makes sense if you’ve made sure that your solution actually solves a problem for the user. Otherwise, you’re both testing if you’re helping the user with a problem and if your solution makes sense for them to use.
Giving test participants the right tasks to perform
When you’re ready to have users test what you’ve built, make sure that you’re doing it right away. One way not to do it is to ask the user:
Try using this part of our solution. Does that make sense to you?
For one, users don’t know what you know. They might not even be familiar with that “part” and little do they know what it might be capable of doing.
They might even feel forced to compliment your solution because they know it would make you happy (like asking your mom if she thinks your startup idea is good).
Instead, provide users with small tasks to perform that will (hopefully) encourage them to interact with what you’ve built. That way they won’t be aware that you’re observing how they interact with that part of your solution and their mind will be focused on the task you gave them.
Examples are always easier to understand, so let’s say you’re working on a new feature for Instagram. This feature should make it easier for people to post image carrousels on Instagram.
You’ve recruited a couple of test users that you know have used this feature before. Instead of asking them to try out the new feature, you give them the task:
Create a new post with 3 images that you know will get a lot of engagement
Because you added the last part, your test participant will likely focus less on the new feature and instead focus on creating a great post.
As she does, observe how she uses the new feature and if there are any major issues along the way. Note these down for questions after.
If the participant stops, ask them to speak out loud about any frustrations, considerations, or thoughts in general.
Doing this with a small handful of people will likely tell you more about the usability of your feature than watching heatmaps or screen recordings. And it’s because of a single thing: context.
Building your own user interview framework
Doing interviews and tests as mentioned above is hard work. But it’s also incredibly rewarding. And so, would it make sense to figure out how to set up these tests on a more regular basis?
Brian Armstrong, the founder of Coinbase, describes his initial steps when talking to users:
Launched the website and got a few signups
Sent an email to 5 of the signups that weren’t using the site anymore
Asked them why they stopped using it
Found out that people liked the app but they wanted to purchase Bitcoin in the app
Added a simple “buy” button and found out just how many wanted to buy Bitcoin in the app
If you’re continuously iterating on a specific feature, doing this yourself would make sense. If you want to do more explorative work (also known as “product discovery” work), you should just make it really easy for users to sign up for a short interview.
I’ll continue to add thoughts, tips, and ideas to this post as I explore the area more and more throughout my career.