Like most engineers, I tend to have a bias towards action. Getting started and building things is what I really enjoy, so naturally, I start a lot of side projects. Over time, I've tried to limit those to specific problems I've had myself, building on Paul Graham's famous essay
The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself.
One downside of this process is, that I've too often neglected that a) choosing problems to work on this way leads to a very specific customer profile (which is mostly myself) b) skips the research work of digging through truly unmet needs, exploring customer segments that could be served, and analyzing existing and upcoming competition in the space.
This lack of proper due diligence before building is what takes time, what might not be as fun and rewarding as starting to build, especially with the dogma of "build it and they will come". The cold hard truth, sometimes, is "If you build it, they will do absolutely nothing.".
The Action Bias
As I mentioned before, a popular belief is that you should start building yesterday. Unfortunately, without a distribution strategy and the first customers in mind, this will get you nowhere. What's the use of a finished product if absolutely no one uses it?
Even worse, what if you started building and there's already a competitor serving a silver bullet to your problem?
I think the drive to build is extremely valuable. But unleashed too early, it's a dangerous rabbit hole, of shooting first, then aiming.
If you have worked through the necessary steps upfront, you know that there's a customer with this problem, and you can work towards something.
The Lean Startup
Most teams work primarily around iteration. A feature is put out in an initial version and improved based on customer feedback. This is a continuous process, and I wrote about it quite a few times already. This methodology is in large covered by the Lean Startup, but I think we've gotten too focused on the Build-Measure-Learn cycle, which comes after defining the vision and problem.
4 weeks vs. 4 months
Diving into the MVP and thinking we know what we're building is great, but if this takes a considerable amount of time before the first customer is onboarded and feedback shared, every hour of work past what would have been absolutely necessary might be a dangerous investment. Especially if you started building without spending time on discovery and exploration.
If you're not completely sure what the problem you're fixing it is, which customer segments will be served, and if there is existing competition in the space, you should really spend the work upfront. Even if this takes weeks, you can start with confidence that you're solving an actual problem, and you have people that eagerly await your progress.
What comes before building, then?
First, it's time to find a problem that people really have. Maybe something you ran into yourself, but you have to find people that have the same issue, otherwise, where will your revenue come from? When you interview people to find out their problems, or if they share yours, make sure to target people who are not too close to you. Otherwise, it might be easier for them to answer what you'd like to hear.
Once you have identified one or more unmet needs, check out if they are truly unmet. If there are competitors, create a grid to compare features across the board, and be honest about the fact that you're probably not the first product in the industry.
Once you're assured you're not blindly running into competition with an identical value proposition, continue the process by coming up with as many potential solutions as you can think of, then pick the best. Never get emotionally attached to a solution, stick to solving the problem in the best way.
In the last months, I built and helped build multiple side projects that all ran into the same dead-end of stagnation caused by a lack of users and customers. Even though the technical side was better than ever, in the end it didn't help. After seeing a pattern emerge, I wanted to know why this happened, and what was needed to overcome that problem: I completely ignored problem and customer discovery, competitor analysis, and distribution planning.
Then I read Why Startups Fail by Tom Eisenmann, which does a great job at outlining the issues with false starts, i.e. building, then finding the problem and customer to serve.
The next time I come across a problem, I'll identify potential customers first, then check out the market and find competitors, and if all of those indicate that there's room for a solution, I'll think about distribution and finally, I'll start to build.
Of course, your situation may be entirely different. I didn't have an existing base of followers or customers to build on, so this is a pitfall that most first-time founders will run into. As Justin Kan said, "First time founders are obsessed with product. Second time founders are obsessed with distribution.".
To put it into a list of steps: Identify Problem / Unmet Need → Identify and Interview Customer (Segment) → Come up with Solutions → Choose best Solution → Plan Distribution → Start building and iterating on product