Remember that you are building for humans
We’ve all built something that very few people used. Here is how we could avoid doing it again.
A lot of products are built without understanding their audience. Understanding doesn’t only mean knowing who they are but also where they will find out about this product and how they will actually use it.
In the last few months, I have been involved with products that got very little traction and products that took off on day 1. I experienced both the exhilarating feeling of seeing people use something you pictured on a whiteboard and the valley of despair when it seems like no matter what you do, things aren’t working.
If you’re a Front End Developer, Designer or Backend Developer, here is a framework you can ask your team to use to figure out if what you’re about to build will actually be used.
Begin with the current situation
Yay! You’re gonna start working on a new product. The team identified an opportunity, either within your own product or outside of it. You assembled an amazing team, and you’re about to set up a kickoff meeting.
Hold on, have we looked at what’s going on with our audience today? There are two things your team should look into to figure out what’s going on:
- Research and ask your audience
- Turn to the data
At this stage the goal is to figure out if your audience is already doing, in hacky ways, the things that your product intends to solve and if yes, how they are doing it.
Research and ask your audience
Are they going on communities to ask about this problem? If they are, what solutions did they find? how many people are talking about this problem?
Whether it’s your company’s forum, Quora, Facebook Groups, closed forums…There are a lot of ways for you to answer these questions.
Once you’ve identified people with this problem, reach out! The goal now is to figure out if they did solve this problem and how they did it. Your team will also be able to understand the expectations of your audience (which is critical).
Pro tip: do not reach out to people before they faced this problem with something like: “would it help if you could do this”. People are terrible at knowing what they want.
If you’re having a really hard time finding people to talk about this problem, ask your team: are we solving the wrong problem? Is this problem something our audience is so used to dealing with, that they can’t imagine a better way (turn to the data to answer this question).
If a good enough job has been done on this, your team should know:
- the way people describe this problem, in their own words.
- how often your audience talks about this problem, and the engagement it gets.
- where they talk about it and how they solved it.
Turn to the data
As much as research can give you a sense of what your audience is doing and how painful this problem is. It lacks a big element: how many people are facing it.
To answer this question, your team can first look at your company’s internal data. How many people take actions related to the problem you’re solving, how many errors or failures they are facing…
For anything that lives outside of your own product:
Validate your assumptions
Wow, your team has made a ton of progress already! Now you have a good sense of how to describe the problem your audience is facing, in their own words. You also know that a lot of people are affected, and where they go to solve it.
Now comes the tricky part, coming up with the right solution to this problem. Once you’ve settled on what problem to solve, there will be a lot of decisions to make. The worst thing that can happen, is that your team settles on the wrong solution (if you’ve done a good enough job at looking at the current situation, you should at least be working on the right problem).
Your goal here is to figure out if the product you envision will actually be used, and where you should talk about it.
There are a few ways to go about this:
- Engage with your audience while they are facing the problem and offer the solution you are thinking of building and a form people can fill (adds enough friction to remove “sure”-type of answer). Your team can use Intercom for this.
- Set up campaigns to promote your solution (via Adwords, Facebook or the communities where people talk about this problem) and land your audience on a coming soon page:
- Create a smaller-scaled version of your solution. The focus should be on building something where people still need to do the “core” action that your team wants your audience to take.
- Look at how other companies are solving this problem and how big they are. Chances are, they went through a similar process to solve this problem, so you can accelerate your learnings by looking at what they do and make it better.
The purpose of all of these initiatives, is to get a sense of how impactful the proposed solution is gonna be. After all these experiments are ran, you will have plenty of data: both qualitative and quantitative. If they are looking good, you know that you are on to something and it will help you for the next step. If they are not, you’ve probably learned a ton and you can use them to come up with a different solution.
Define what you want to change
Now you can start building the full solution 🎉
By running experiments, your team started to have an idea of what people do once you offer this solution and how many people do it. Since your team looked at the current situation, you know how things are looking as of today (both qualitatively and quantitatively). Before you dive in and start building, you’re missing one thing:
A quick and easy way to see what’s going on once you’ve launched.
One way to do this is by using a dashboard solution (we use Mode at Shopify). The goal is that in one click, you can see how previous metrics have changed since you launched and the key metrics you are focused on for your products:
This will force your team to actually define what you want to change. It should be a pretty straightforward exercise at this point. Your team now needs to focus on one thing: making it extremely accessible.
The thing is that if you’ve worked really hard on something for weeks or months, whether as a Designer or a Dev, you probably want to know how it’s doing. It shouldn’t take more than one or two clicks, if it takes longer push the person who is leading this project.
Build so you can learn after you launched
The last piece that you are missing in the process of building something that your audience will use is a feedback loop. The common way of doing this is to send out a survey or interview users after you launched. While it’s perfectly fine, if you think about this while you’re building, you will get a ton more learnings.
After you created an easy way to look at how things are going, you will be able to know if they are going well or not. Duh.
In both cases, the ability for your team to know why things are going in a certain way or what your product is missing is key. There are a few ways you can tackle this:
- Leave space in your product to ask for feedback
Whether it’s a banner on top of a screen that asks your audience to talk about their experience, or a triggered email after a certain action is performed, accounting for these in your product experience is very important. Now that you have built the full solution, it will allow you make things like copy changes based on how your audience talks or identify broken windows.
As much as you’ve invested time in building something that people want, you can be certain that for a part of your audience, you will fail. The best way to identify it is to give an option for your audience to tell you that your product is not offering what they want.
- Implement a search bar
Search is extremely powerful in a product. It lets you see what people do on their own, not after or before you asked them. It gives you a sense of the things that are not clear in your UI or the other things that people want.
Depending on how complex you anticipate the queries to be, invest sometime in designing your empty-state. Focus on empathy (after all, you failed to return what they wanted) and how they can still find value.
This is it! Hopefully, these ideas can help you in your journey of building things people use. It’s not a bullet-proof guide, more of a collection of ideas and tips I accumulated as I faced failures on some projects.