As entrepreneurs and especially as software developers, we often build products that we wish existed. But just because we want something it doesn't mean that it is a viable business or that anyone would be willing to pay actual money for it.
Now, if instead of focusing on the solution we came up with, we revisit the circumstances where our need for the product arose, we can much better understand the potential value of our product. This approach can also help us hone in on the real problem we experienced before we came up with a solution, which can make our product more relatable and appealing to potential clients.
In my recent coaching session with Vineet, we discussed the importance of starting with the problem that inspired the product idea. Vineet’s idea was to build a search engine for Google Docs, which would allow users to easily find and access documents within their organization.
When I asked him how he came up with the idea, he told me that as a technical lead at a growing company, he often felt out of the loop on what other teams were doing. He said he wanted two things: (1) to always be on top of what was happening elsewhere at the company, and (2) to be able to quickly find the specs, decision points, and current status for each project without the need to talk to many people.
After discussing his story, we came to understand the kind of person who would need this broad cross-functional understanding the most. We identified two main types of users who would benefit from a product like this:
- A CEO or VP with a micro-managing streak who wants to understand what's going on in their organization, but doesn't like how the company hierarchy filters information on the way up (usually making it more positive than the reality).
- A founding engineer in a growing company who used to know everything that goes on and every line of code that gets committed and now feels like they're losing touch (which was Vineet’s personal experience).
We noticed that while the pain and the desire for a solution would be similar for both kinds people, the willingness and ability to purchase a product that would solve the problem will likely be higher with the CEO or VP than with the engineer.
We also realized that once there's buy-in from a manager there will be many benefits to a system that increases visibility across the organization. This can help teams work more efficiently, improve communication and collaboration, and reduce the amount of time spent looking for information.
However, we also noted that most such systems require a lot of work by individual contributors (ICs) to document and organize information, and they typically only benefit management. This can create a lot of friction and resistance from ICs, who may not see the value in spending their time on these tasks.
Our coaching session highlighted the importance of staying in the problem space when developing a new product. It turned out that a search engine for Google Docs is only one way to think about this important organizational problem that Vineet’s intuitively identified, and there may be other approaches that could be even more effective. We also realized that focusing on a specific solution limited the kinds of exploratory conversations that Vineet could have with potential customers and the kinds of marketing messages he could eventually use.
By understanding the circumstances and challenges that inspired our ideas, we can better empathize with our potential customers and create a product that resonates with their needs and concerns. Overall, starting with the problem, and staying with the problem, can provide valuable insights and help us create a more successful and impactful businesses.
If you want to try this out for yourself, answer the following three questions (in writing!):
- What were the circumstances where this “itch” of yours arose? What was your job title, what were you trying to accomplish, what else was happening around you at the time?
- How bad of a pain was this for you? Was the “itch” mostly about having any solution for the problem or was about solving it yourself? Were you losing time or money? Was it a matter of convenience or a real blocker? Were there any other people experiencing the same pain at the same time?
- Were you in a position to purchase a solution for the problem? How much would you be willing to pay? If you didn’t have purchasing power, was there a way you could convince a higher-up to purcase a solution? What kind of price range would make sense to them?
You can reach out to me at @finereli to discuss your idea or do a full session like the one I did with Vineet.
Written by