Lessons from a failed startup
Code is a liability; ship without coding, if possible
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 braniac, can do whatever you want.
So you’ve found your customer. You know what they
want need. And now you’re going to write a custom piece of software for them.
Except… don’t do that. You haven’t really understood them yet.
First, solve their problem. Then, do it better, with code.
We were working on improving code review with an automated, intelligent bot. And in this instance, I think we did the right thing: we started reviewing a lot of code for our customers, manually. We identified common patterns across a few unrelated organisations, and then we started to automate it.
Our second product was totally wrong. A beautiful UI, very sophisticated tech… and not a single customer.
Code is horrendously expensive to write (in both money and time), a burden to maintain, and a huge sunk cost that encourages you to sink more into it.
Write as little as you can. Do it on paper for a while, with a pen. Use a spreadsheet—they’re ridiculously powerful, and while I’d argue that making a spreadsheet is coding, it’s definitely less coding than writing a UI from scratch.
If you can’t do that, use Pipedream (I love it), or Zapier, or whatever you like to connect the dots. Make a bookmarklet to augment a web page that does 80% of what you need already. Make a browser extension. Write a Twitter bot.
There’s a hundred different ways to outsource part of your application somewhere else entirely. You don’t have to keep it that way forever, but you may want to think hard about where you start.
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.