Framework for building a product
While building a product we are often confused where to start ? or at least I am. Conventional product wisdom says you got to start from the problem. Identifying the problem is a good start.
The way we solve a problem determines whether we can build a product out of it.
According to me the solution could be of 3 different types:
-
Manually solution or human labor intensive
-
Offering a service or like consultancy
-
Building a product/app/machine or the nirvana
The solution which solves problems at scale and consistent quality ideally becomes a product (maybe good or bad).
Surveymonkey evolution :
If we have to build a product like surveymonkey the problem/vision statement would be
Collect survey data at scale.
- Manually solving it:
Old Fashioned Surveys
We could provide an excel sheet with questions and space for answers. Have one excel sheet per person. Send it across to people through email. Beyond 10 excel sheets it would be an obvious nightmare. But does the job. This whole “process” is conceptually a product it is just sitting in our minds.
2. Offering a service:
Ask someone for help!
If we have to do surveys almost weekly and we do 10–15 surveys per week. Then this manual process won’t work out. Imagine if a “person” could do it for us. He could be an employee or an outsider. This person would collect the questions from us. Prepare excel sheets, collect the answers and assemble it. This person becomes the consultant. It is us!. The service we provide will be in a way the product.
We would walk around advertising ourselves as the survey consultants. We would be 2–3 times faster than normal beings. Knowing the gotchas of this domain. We would offer professional services for a fee. The problem lies in scale again. We could do maybe 100–1000. Beyond that we would need another human.
3. The Product:
The product could be a tool (an app, website whatever) which solves this problem at scale. Our learnings from manually doing it to getting feedback from a “consultant” should have taught us the commonly used scenarios.
Now we can build this system. We know commonly used features/use cases. Based on the domain the common use cases may serve everyone or one particular industry or domain. The more generic the use cases larger the opportunity. If we have some edge cases which are specific to an industry then it might not be so fun because of a million customizations.
The machine/system we have built will work day or night at whatever scale based on the amount of time and energy we invest in it.
If we apply the analogy to washing clothes. Long long ago people washed their clothes themselves, then someone discovered he could do it for others and started hand wash laundry service may be. Then we could build a machine/product that every one could use to solve this problem at scale.
If you follow these steps it might do a reality check on why are things the way they are.
The beauty of many products around us is, we didn’t realize they were problems we were facing until the solutions came out.
Manual usage → Consultant/Services → Product