This isn’t going to be your standard startup retrospective. For one thing, my startup is alive and kicking, having adopted and adapted these lessons, and is now accelerating towards product/market fit. Secondly, the standard startup retrospective has been done over and over and over and over and over again.1 There are even collections of them and analyses of the failure of the postmortems themselves. And, I’m not the kind of guy who likes repeating what others have done.
I’ve read the retrospectives, the lessons, the bad decisions, the failures, the successes. I’ve heard both sides of every story. You know what? They are all right – both sides. And it is all worthless advice. Here’s why.
You cannot truly learn a lesson without going through the experience yourself.
Several weeks ago, a friend of mine asked me for the biggest lesson I learned from starting my own company. As is normally the case when put on the spot to answer questions that involve picking a single thing out of a huge list of possibilities (along with “what is your favorite X?” and sadly for the sake of interviews “tell me about a time when you…”) I hesitated, hemmed, and hawed, and looked towards my wife, sitting next to me, to see if she had any insights into a lesson I had learned in the last two years of building a company from scratch. Now, several weeks later, I’m ready to answer the question, and it gets meta. But first, let me give some “minor” lessons from the experience.
Example #1: Product/Market Fit
My co-founder and I got really excited about the product we decided to build. We were sure that if we built it, we would be able to find people who wanted to use it, and if we could find people who wanted to use it, we could find people who wanted to pay for it. We didn’t jump blindly to building – we aren’t that naïve. But we did set out to build a two-sided marketplace, and we only spent concerted effort on customer development for one side of that marketplace. We used those customers to help us design the product, and we built up good relationships with them. But, when it came time to find the other side of the market, we fell flat.
Lesson from this: don’t jump into building product without first validating there is a market (and in this case, two markets) for it. Build an exceptionally minimum product to validate what customers might buy and only after knowing what they want or need should you invest more time and money into building a real product.
Example #2: Fundraising
We raised money straight out of the gate, with no product and no customers. We were fortunate enough to find a very good lead investor who was willing to take a chance on us as entrepreneurs, but that in some ways also validated our poor decisions at the beginning to build a product prior to finding a market. We were a solution in search of a problem, and with a decent chunk of money in the bank, we had the luxury of continuing to build beyond when we should have reevaluated the problem we were trying to solve.
The single piece of advice I received from a colleague who had been a VC in a prior job was to not raise money until after product/market fit. Whoops! Ignored that one.
Example #3: Second System Effect
When I chose the technology and architecture for the company, I wanted to correct for the pains I experienced at Opower, adapting a technology stack as the business grew over 7 years. I thought I could make a few simple decisions early on that wouldn’t complicate and slow development too much at the beginning but that would pay dividends later on.
Even if I made the right decisions, I most definitely fell into the trap of the second system effect. I should have looked to optimize for the exact stage we were at instead of considering anything beyond a few months out.2
The Big Lesson
I knew all of this stuff before I started. Along with going through the experience of building a software company from the very beginning a few times (though never as a founder), I have read countless books, articles, and blog posts on the subject. They all mention the same lessons that everyone has learned before. Let me reiterate – everyone has made the same mistakes and learned the same lessons. Over and over again. The bigger lesson in all of this is that I could not truly learn the lessons without making the mistakes myself, too. And that can apply across all of life and all of business.
Everyone must make their own mistakes in order to learn their own lessons.
How To Apply This Lesson
I believe in the “advice process” to help with distributing decision making across an organization. That process requires that a person making a decision solicit input and advice from people who are affected by the decision. It does not require that the person accept the advice, and finding myself in the position of giving advice to my colleagues, that can be frustrating. I very often find myself thinking, “I’m not sure how much more clear I can be in my advice. Doing X will result in Y, and Y is bad.” But the person making the decision must experience “Y” for herself in order to understand how “X” caused it and to make the connection for next time. That is a hard lesson to swallow. The best that can come from this situation is that next time a similar decision must be made, the person will remember “Ah, last time Jeff pointed out that X would cause Y and it did, and this is a lot like X, so I’ll choose differently this time.”3
The Big Picture
As a kid, I remember my parents (and friends’ parents and parents of kids on TV shows) saying things like “you’ll understand when you are older” or “you’ll thank me for this someday” about lessons in life or decisions they made on my behalf for my benefit. I cannot fathom the amount of frustration kids must cause parents when they make poor decisions that parents know will turn out poorly. The best a parent can do is to minimize the damage (or at least the permanent damage) that the kids do to themselves. It must take an amazing amount of discipline to let your child make mistakes and not just always try to protect her. But the best parents are the ones who can do that, and then can help the children understand what the lessons are to be learned from the mistakes.
I hope I can use this lesson to be a better parent when the time comes.
Some recent advice I heard was to write code that will last as long as your company has been alive. So, if your company is only a month old, write code that you would be happy to refactor away in a month. ↩
Just recently I noticed an chunk of code that was going to cause an issue for a colleague, but I resisted telling her what the problem was. I wanted her to run into the issue herself and attempt to solve it on her own. In the end, I helped her figure out the problem and solution, and I think she learned something in the process. ↩