Don't build features your customers ask for. Use this template instead.

Article posted on
June 26, 2020

A while ago I posted this quote on my Linkedin. It went kind of viral, reached 44k people, and got 470 likes:

This post (originally from @misterparker) summarized the methodology I just started implementing back then at Ryte. We were almost hitting our 1.000.000th user and thus wanted to optimize our research process to make sure we build the right features for all these people.

I've done hundreds of user research sessions before, but I always encountered the following problems:

Problem 1: Transparency

As a designer or user researcher, you record the interviews, write down the most important findings, and get a good feeling for the users' needs and problems. Unfortunately, this doesn't mean that the stakeholders or other team members understand all these findings. If you don't have a dedicated user researcher, it's often too time-consuming to make the interview notes digestible enough that stakeholders would read each of them regularly.

Problem 2: Backlog and epic prioritization

Everyone in SaaS knows it: Your colleagues have ideas, the users have ideas, the POs have ideas, and designers have ideas. You end up with a ginormous backlog of features where you don't even know if they solve real problems.

Problem 3: Problems are not quantified

Feature ideas aren't worth much without a problem. You know about many problems your software or user has, but you don't have a quantified pain level or occurrence count next to each problem so you know which of them you should tackle first.

The Solution

It was when I read Airbnb's Lenny Rachitskys‘ A Three-Step Framework For Solving Problems when I got the idea for this new user research approach that truly revolutionized my process and solved all of the problems mentioned above.

I tried a lot of different research approaches and got more and more excited about problems. No, not my personal problems like being scared of people who eat the brown parts of a banana. I got excited about becoming laser-focused on user problems. Problems only. Not features. Not values. Not gains. Not tasks. Not jobs. Not goals. Just problems.

"Nothing is more certain to cause a project to fail than a misunderstanding of the problem you are solving." – Lenny Rachitsky, Growth PM at Airbnb

By making the process much more focused on problems and finding a new way to document and quantify each one that came up during user interviews, I was able to build this system that I would love to share with you in this article.

You can find and copy the template here: https://airtable.com/universe/expUOZxToUDGgtOTd/user-research-process
You can find and copy the template here: https://airtable.com/universe/expUOZxToUDGgtOTd/user-research-process

The Template

The template is categorized into solutions, problems, sessions, people, and companies. I will start from the right to left and explain the process behind each one.

Companies

The tab "Companies" is really simple. It's just a list of your users' companies because you can interview multiple people from the same company.

You can segment your customer base and understand certain user behavior based on metrics like the MRR, company size, revenue, and more. Airtable gives you the possibility to integrate with Salesforce, so you can keep the data always up-to-date. And with a paid plan you directly have some really neat data visualization options.

People

You guessed it, here you find the people you interviewed or want to interview in the future. You can contact and keep track of potential interview candidates or automate this with services like usertesting.com, but It's quite expensive.

If you noticed the "Persona" Column: You can segment the personas of the people you interview and connect each feature idea with the persona type. Cool insights might appear after a lot of interviews.

Sessions

This tab consists of your past and scheduled sessions. During the interview, write down everything in the notes field of the session and focus mainly on the users' problems. After the interview, drag the session into "Extract problems".

When a session is in "Extract problems", copy all notes out of it and paste them into the problems tab. Remove all other findings and just leave the problems. Now map the session to each problem.

Problems

After some interview sessions, you will probably have dozens, maybe hundreds of problems in this tab. Many of them might be repeating, but that's a good thing.

Give each problem a pain level rating from 1-10. You will probably have an immediate feeling of the right number because of a user's reaction while talking about it. Try to find out how much time you would save by solving the problem. Now map a solution to each problem.

Solutions

Here is where the magic happens: You have a list with all your feature ideas. The big difference is, that all these ideas are now connected to every problem you ever documented. You now know exactly which user from which company needs which feature. It's all beautifully connected and the system gets richer and richer with more user interviews you conduct.

The most important ideas rise to the top

All features are now sorted by the problem intensity score. It's the summarized pain level from all problems this feature would solve.

To really make sure you are about to solve something real, fill out the "Real problem?" column. So often you have epics in your backlog, where you don't know really much about the problems it would solve.

Another nice thing is to summarize the total MRR of the companies, so you can see what features your most valuable customers need.

To separate the things you really plan to build in the near future, the solutions are grouped into "Shortlist" and "Longlist". Normally there are 100+ ideas in here, and you only want to look at the important ones frequently.

From time to time, feature ideas from the Longlist will rise to the top and get a very high Problem intensity score. Then it's probably time to have a deeper look at it and put it on the Shortlist.

See a list of problems each feature would solve

If you expand one row, you will understand why. Underneath the feature name and description, you see every problem that this feature would solve from every user interview you conducted so far. This also helps a lot during feature specification.

Everyone in the company can contribute

In Airtable you can generate a form like this. When customer success or other colleagues bookmark this, they can directly add all customer problems they observe in the database.

Find the link to this example form here: https://airtable.com/shrNJaGRQpyaup1su

I iterated and tested this template in two companies and countless interviews so far. The results were great and it saved so much time we usually wasted with documentation and presenting things and made the interview findings a lot more transparent.

I'm really curious to hear if you have a similar system in place and how you do it! Leave your feedback in the comments of my Linkedin post!

Hi! I’m Raphael, a product designer from Munich and the creator of this blog.

Latest articles

raphael@fleckenstein.infoLinkedInMediumTwitterImprintPrivacy Policy