This is a story that saved me months of development time and it's all thanks to interviewing potential customers. After interviewing them I realized that the problem has already been solved, just not in the way I originally would have thought.
This blog article describes my process for discovering that the product idea wasn't worth my time or energy. I hope by the end of this article others will see the value in interviewing customers before writing a single line of code.
What was the problem? #
After building my previous app, I wanted to approach my next product a little differently. Instead of coming up with an idea and spending months building something based on a hunch, I wanted to spend some time upfront to figure out if the problem resonated with people.
I spent some time coming up with new problems that I could solve. The idea I kept coming back to was this one:
Figuring out where I put notes, docs, information in various apps requires active knowledge about where I stored it.
I thought this problem was interesting and one I could potentially solve with software. I don't like memorizing where I stored information, I just want to perform an automated search to find where my information is stored. I thought this was an interesting idea to explore. It met all of my personal product idea criteria:
- It solves a real problem I have
- I could build a prototype in a month or so of my time
- I could potentially charge users to purchase the product immediately
Normally when I come up with a product idea, my first inclination is to start building. The thought is "I'll validate the product once people can try it." Instead, I decided to find people who really enjoy organizing their notes and ideas into various productivity apps and see if they have the same problem I have.
Finding people to interview #
My first step was to find online communities that like using productivity apps and enjoy organizing their ideas. I found a couple of subreddits that met that criteria. Then I messaged a few people that were active in those communities that would be interested in having a conversation with me about their workflows.
I tried to make the conversations friendly and direct with a probing question about their workflows. I found this to be effective because I was pleasantly surprised by how many people wanted to chat about this problem.
I asked a few questions to get the topic closer to the problem I was trying to understand:
- Do you ever struggle to remember where you put a note, doc, or some other piece of information in the various apps you use?
- Do you use an app to solve this problem? If so, what is it?
- What if there was a tool to help search for your information, would you find something like that useful?
- What if your employer adopted this tool, allowing you to search for any notes, docs the company created, would you find this tool useful?
Results of the interviews #
After messaging a few people asking them if they struggled to find information they had written in various apps, here were the results:
- 4 people did not have this problem
- 4 people did have this problem
As I started to dig deeper into how each of them addressed the problem of retrieving information they stored somewhere, I uncovered that the ones who solved the problem had an organizational system for cataloging data. The ones that struggled with this problem also tried to solve it with organizational solutions.
Most people during this interview mentioned either Evernote or Notion. Ah!
As I started to investigate, it sounded like most people chose to store all
their information in one central location and make it a priority to keep it
organized. They have workflows that involve cataloging their data into one app.
If they use other apps, then they end up making references to that data inside
something like Evernote.
The people that never have this problem make it a point to only use a couple apps that can handle most of their organization or note writing needs.
So the problem is real, but people are solving it in a relatively easy way. I also noticed that the way I asked the questions led them to agreeing with my premise, which is a problem.
What did I learn? #
I learned that people solve this problem already using very popular apps. I learned that the problem I thought was important, was very small compared to the other note taking problems these apps are solving. After my investigation, I felt like the problem has effectively been solved by other apps on the market and my solution wasn't as profound as I thought.
Nothing In Life Is As Important As You Think It Is, While You Are Thinking About It -- Daniel Kahneman
After discussing my customer interviews with a colleague, another important lesson I learned was that my line of questioning was leading the witness. I presented the problem too plainly and forced the customer to focus on the problem and buy into the solution I envisioned. Some people were "interested" in the imaginary tool I was thinking about building, but that doesn't mean they would actually use it when it was built.
What questions should I have asked? #
I wanted to get them to talk about the problem I was trying to solve instead of asking them what problems they have with staying organized and writing notes in multiple apps. I think these conversations are a dance.
I want them to confess the problem I'm investigating without directly asking them if it's a problem.
So I think reframing the questions could have gotten me better answers and possibly led me to uncovering other problems:
- How do you stay organized using multiple productivity apps?
- What are some problems you have staying organized?
- Could you stack rank your problems in terms of significance?
- How do you stay organized at work when the company uses different tools to organize notes, docs, and information?
- Do you pay for any existing note taking service?
In the end, this was another valuable learning experience. Ultimately I got to the answer I wanted: this product wasn't worth building. But, because my line of questioning was nudging the interviewee to agree with me, I could have easily made the decision to pursue building this product.
Conclusion #
I went into these interviews with a set of questions that led the customer where I wanted them to go. Like with any good survey, the way the questions are structured are critically important. I'm learning a lot because of the mistakes I'm making, and it's energizing me to continue down this path of talking to people.
This exercise of performing customer interviews was eye opening: creating a product in a vacuum is a major reason why my products have not been successful. I'm figuring this out by saving hundreds of hours in product development. I learn through experience, so it seems obvious now why product managers interview customers constantly, but it wasn't obvious to me until recently.
These customer interviews killed my product idea and I couldn't be happier about it.