Lessons from a failed startup
"Do research" is not a corporate strategy
In failing to build a company, I have learned many things. Core to all of them is that a company is not a product. Ideas change, products change, people change. We “pivot”, rapidly, relentlessly, sometimes ruthlessly.
Managed well, change is a catalyst. Managed badly, it can be catastrophic.
In this series, I try to explain the various ways in which I failed to understand this, and how I would endeavour to do better next time. You may notice that the style of these posts is more instructive than usual. Remember that these are mostly addressed to my future self, and as such, I am telling myself what to do; you, my dear content consumer, can do whatever you want.
We founded Prodo with two goals: to research novel, ML-powered methods of detecting bugs in code, and to build products upon that research to help the average application developer find bugs.
In hindsight, I think this was quite foolish (though my fellow founders might disagree).
“Research” implies that the work is quite difficult, will take a long time, and most importantly, has a substantial chance of failure. In contrast with product development, where “failure” often means “we didn’t know how to do it with our skills, on time and within budget”, a failure in research could mean that your task is impossible with current technology, or requires breakthroughs in the fundamentals of mathematics.
If you want to do research, do it in academia, or a company that can afford gigantic, multi-year failures. A nascent startup seems like the wrong place to make huge, expensive, time-consuming bets; a sequence of tiny ones is much more likely to pan out.
More in the series
- Focus on the problem, not the solution
- If the company goals change, the company should probably change too
- "Do research" is not a corporate strategy
- Your corporate values transcend your product vision
- Trust your gut, understand your heart, and open your mind
- Go to therapy with your co-founders
- Explore the terrain first
- Unless someone cares, don't waste your time
- Code is a liability; ship without coding, if possible
- Do less, and do it better
- Agile methods are tools to try more ideas in less time
- Until you have traction, money is a trap
- If you don’t know how to do it, that’s your biggest problem
- Roles can be fluid, but they must be defined
- Camaraderie is helpful, but no substitute for working together
If you enjoyed this post, you can subscribe to this blog using RSS. I personally use Feedly; you can subscribe here.
Maybe you have something to say. You can comment below, email me, or toot at me. I love feedback. I also love gigantic compliments, so please send those too.