At most tech startups, you are plagued with the fact that you have a limited number of times and a seemingly unlimited number of features options you can build. The secondary issue is perhaps that you have a hypothesis about which features you should be building, but you won’t really know whether you should have built those features until you get them in front of your customers. So, you can have a hypothesis about how great a feature is then have your engineering spend precious time building that feature, just to find out that your initial hypothesis is wrong and that no one uses your feature. I have done this far too often to realize I needed to do something different.
What’s a better way to decide how to build a feature? Use a quiz to understand what features your customer wants before deciding which features to build.
Let’s dig into the 3 things I try to do before committing the work to an engineering resource. Also, I realize that this is a shortened scientific method. Why break something that works so well?
First, you need to ask yourself a question. I often ask the following question, “What are pain point(s) that my customer is currently experienced and what is the severity of their pain?”
You should have your hypothesis based in as much data as possible. For example, you can use your customer support emails to see what issues people are writing about. In my experience, the worst possible hypothesis are based on no facts, and one person’s opinion about what a pain the customer faces.
There are two main types of pain points I see my customer experience: 1) Pain they know about. These are the easiest features to build for because they are already expressing their pain to you. 2) Pain that is unseen. These features are often features that are meant to “delight” the customer by solving a pain that they didn’t even know they had. These are the most difficult features, but if you can solve these pains, you will know that you understand your customer better than most people.
After going through this step, I bring to the table a list of 5-10 features that you could build and the pain points that each of those features address. It’s vitally important that each feature solves a pain point.
Testing via a quiz is possibly the most important because you are either validating or invalidating the original hypothesis for each pain point. Before you build your quiz, I would recommend to read “5 Simple Ways to Improve Your Quiz Response Rate” from Interact’s blog to build a great question and help avoid bias in your quiz questions.. This article series can breakdown some of the important steps to designing a great quiz.
Specifically, when I am testing a hypothesis, each question needs to be intentional to the point that it answers the question I am asking. Let’s get into some details.
First, Ascend built a budgeting app, called Savvy, specifically to help people get out of debt. We have limited resources to be able to build new features, so it’s imperative that the right features be built.
We have three features that we are deciding upon at the moment: 1) Adding budget categories. 2) Adding ability add income/expense transactions. 3) Add features around displaying security.
Here are some potential questions to ask to understand the user’s main pain points:
Here are other questions to understand the major pain points without directly asking:
- How do you currently manage your finances?
- Approximately how often do you use cash in your transactions?
- What sort of granularity do you like in a budget?
- What percentage of your transactions are done via a check?
- When you opened Savvy for the first time, what was your initial impression?
- Was there any question in your mind about what Savvy does or does not do?
- Where you hesitant to add an account to Savvy? Why or why not?
- Which of the following produces the most stress or anxiety with your finances?
Use Interact’s analytics tool to then analyze your data to make sense of the results of your data. When you analyze data, it’s important to come to the data with a clean slate about what the data represented. You need to be aware as much as possible of your own biases.
An example of this is that you have a hypothesis that your audience’s pain point is that they are not getting enough vitamins in their diet, so you generate a quiz to see which vitamins they are currently taking and see whether there’s a demand. Let’s say your results show that your customers are already taking enough vitamins, but you are stuck on your original hypothesis that they do not, so you read the results and analyze the data in a way that will prove your original hypothesis. I have found myself with this bias as it feels “human” to continue believing an original hypothesis. To counteract the bias, I would recommend that you have someone else review the data for your hypothesis to not bias the results or go into the analysis with a completely open mind.
Solving customers’ pain points through building useful features is one of my greatest joys as a startup co-founder. It’s important to solve the right ones, and a quiz can definitely help to test your hypothesis and gain valuable information from your customers. Once you have hypothesized about which solutions may be helpful, tested through utilizing a quiz, and analyzed the data produced by your quiz, then you are now ready to implement that idea through prioritizing that feature with your engineering team.