It’s OK to solve your own problem first, to be the first customer. This at a minimum gets the idea out of your head and reduced to practice where it can be tested. The trick is to use this basic product to spark further discussions about the problem you solved, no your solution.
Q: I am just starting the planning for my first product. The inspiration came from a problem I have faced personally. I have talked to about 20 people and three can relate to the pain, but with small variations in preferences and priorities. I am now considering treating myself as the first customer and then addressing feature variations in a next iteration. My worry is that I may be biased. Did you face any problem of this sort? How would you recommend I handle this?
It’s OK To Be Your Own First Customer
Use The Product To Have Conversations About The Problem
Now go back and write down what you have learned about the problem, and the problems that were uncovered once you started to manage the more basic aspects. Now you can have some more conversations about the problem:
- Start by eliciting symptoms not offering a solution or a prescription
- Focus on what else a prospect has done to address the symptoms
- Try and put some numbers on both the level of pain, the frequency it occurs, and the total impact on the task, job or business
- Talk to a number of different people who can offer a variety of perspectives: don’t try and average the responses but write them down individually, it may take a while for the true pattern to emerge from a collection of data points and observations.
Don’t talk about your solution or show it until you can describe the problem to a prospect and they agree you understand it.
Managing Your Biases
This last part of the question is one that I wrestle with as well. I don’t have a lot of good suggestions for how to manage your own (unconscious) biases but here are a few that I have found that help:
- A bias often takes the form of ignoring or rejecting observations or data as an outlier or not relevant. Keep track of things you learned or heard or observed that you rejected as extraneous. Most of the time your instincts are likely to be correct but it won’t hurt to run the list by a few other people.
- Pay attention to a quick emotional reaction on your part to feedback, positive or negative.
- Try to write down the rules of thumb, construction principles, and problem solving recipes you followed. They are often based on past success but may occasionally lead you astray. Consider the environment(s) you have applied them in previously and how well those situations match the current one.
- Consider what might be true that would break or invalidate one or more of your assumptions about the problem or your solution. Use these to determine the limits of applicability for your solution or approach. If you cannot think of any limits, think harder or talk to more people.
- Keep track of prior biases that have caused you problems or led you to ignore real problems or reject viable approaches. Chances are you will make the same mistakes again, especially where your approach has been successful more often than not.
My Biases
This is not an exhaustive list by any means but I thought I would try and take my own advice to give you an example.
- I strongly prefer a conversation to Adwords, surveys, landing pages or other automated quantitative approaches.
Risk: my methods don’t scale well. - I don’t worry about statistical significance as long as I can find a few examples of people in real pain after talking to 30 or 40. I pay a lot of attention to how I sourced them to make sure there is not some correlation among all of them that is ruling out finding people in pain–they don’t all have attributes in common except for those that define as potential prospects.
Risk: sometimes the market is too small–or I am too early. - I look for a community that’s already talking about aspects of the problem. I would rather join one or more existing communities than try and start one.
Risk: sometime this forfeits a market leadership position or an opportunity to increase my “luck surface area” by talking about the problem.
Counter-example: starting the Bootstrapper Breakfasts in 2006 - I spend a lot of time horizon scanning and looking at emerging problems and technologies. I try and make connections between two or three distant areas for innovation brokerage.
Risk: this lack of focus can waste time and energy. Also some of the more interesting and useful aspects of a technology only emerge after it is widely deployed and “boring.” - I strongly prefer approaches that rely on bootstrapping and leveraging revenue for organic growth.
Risk: some opportunities benefit from early investment.
If You Build It–And Use It–At Least You Are Moving
If you build your first product version for yourself it at least gets you moving and testing your problem and solution hypotheses on real situations. It also gives you something you can use to invite further comment and feedback from others. The more niche the offering, the more it relies on rare expertise or experience that you have, the more this approach offers a reasonable way to jumpstart the first iteration of your MVP. The trick when you are showing it to others is that you use it as a vehicle to explore their perspective on the problem or the need and their constraints on what is an acceptable solution.
Related Blog Posts
- First Seven Questions Any Product Plan Should Answer
- Tom Van Vleck’s “3 Questions” Complement Root Cause Analysis
- 21 Great Questions for Developing New Products
- Thinking About Your Business Goals
Six questions to answer on a single sheet of paper, or carry with you on a 3×5 card - Thinking About Your Business Goals, Part 2
Ask yourself two key questions. What do you want? How will you know when you get it?