‘Build->learn’ instead of ‘learn->build’ to discover a real pain/problem

A recent discovery of Lookscope’s power users helped me organize my thoughts on how to validate the existence of a real pain/problem/love for B2C app products that were created based on a founder’s personal desire/experience/inspiration.
Interviewing potential/current customers is a required task for building any successful product, but one challenge I’ve found when interviewing potential users of Lookscope is that the interviewees often couldn’t articulate their problem/needs in a way that directly helps confirm a real pain or problem. I guess this may not be a big concern for experienced founders who have conducted lots of these interviews and know how to frame questions to tease out the information needed properly, but as a first-time founder, my view is that to do that effectively is not easy and mastering the skill takes a lot of time and practice.
As a result of this challenge, I’d like to share another method to discover a real pain/problem when developing B2C apps, a method that seems to be working for Lookscope so far. The method is to quickly build and launch an MVP with event tracking capabilities built in, acquire first users, and then look for any aggressive use pattern.
For example, if I summarize the key stages of what I did with Lookscope, the result would look as follows:
- Build an MVP with analytics and a way to collect user’s contact info for follow-up,
- Launch the MVP,
- Acquire initial users to a size just enough to make the collected analytics data statistically meaningful (e.g., a few hundred downloads),
- Monitor general use patterns of those users as well as properties that would directly indicate the degree of time/energy investment made by the users (e.g., closet size for Lookscope),
- Look for signs of aggressive use of the app,
- Follow up with the corresponding users (i.e., power users) and learn who they are and why/how they use the app,
- Update your user acquisition strategy and improve product design based on what the power users do or need,
- Acquire more power users,
- Repeat Steps 6–8
Since this method allows the developer to start by building a product (just an MVP, not an elaborated version), I think the approach can feel more intuitive than starting with talking to potential users and even fun for founders who enjoy and are good at building products and generating product ideas based on their own inspiration/experience.
I plan to continue testing this method and share updates in the future.
