Most of us recognise conceptually that we can’t get it perfect right off the bat. Building something, be it a product, a feature or a blog, is a process of starting with something really meh and improving it. But while we recognize it rationally, we don’t always allow for it emotionally. We are not always ready to expose what we perceive as our faults and shortcomings to the world. We want to make it perfect before it’s out.
But that’s not how it works. Kaizen, Agile and Lean are all examples of the process of making small incremental improvements from a simple beginning. It doesn’t mean that you don’t care about the quality of your work. It doesn’t mean you don’t mind producing crappy results. It means you recognize that you always start low and build your way up. Can’t reach the sky any other way.
Every modern startup advice tells you about the MVP, the minimum viable product. How to define it, how to build it and then how to iterate on it. But it’s still hard, at the end, releasing something you know isn’t great. And the temptation to continue improving it before you make it public is strong. You will find yourself explaining why that feature is also crucial and why of course you can’t have performance issues. That’s why releasing an MVP is a huge step forward, even if it’s not a good one. That’s why places like the YCombinator push you to launch early. Because releasing an MVP is hard, you will know it’s not great, it does not represent your dream and according to Eric Rease in The Lean Startup, that’s entrepreneurs biggest fear:
Most entrepreneurs’ biggest fear is not that their vision will prove to be wrong. More terrifying is the thought that the vision might be deemed wrong without having been given a real chance to prove itself. This fear drives much of the resistance to the minimum viable product, split testing, and other techniques to test hypotheses. Ironically, this fear drives up the risk because testing doesn’t occur until the vision is fully represented. However, by that time it is often too late to pivot because funding is running out.
(I love this quote and I feel personally attacked by this relatable content)
So you’ve taken the advice, you released, the world most likely reacted as expected (you know the world isn’t holding its breath but it’s still hard to realise how much nobody cares). Now that you’ve crossed that barrier, released something meh and got meh responses to it, how would you know what to focus on now? Amongst the noise of early feedback, how will you decide what to improve next?
Last week I was in a kick off meeting for Startup School (it’s been pretty cool so far and it’s free!). Someone asked Eric, the YC partner running the call, how to know where to invest your time as a solo founder, how to decide what to focus on. Eric responded that at the end of the day it is a question of prioritization and that he presented that question to the founders of Heroku once. Their response was - work on what’s burning.
That piece of advice hit home for me and I think it’s true not just for solo founders. If you are building a product, ask yourself - what is the biggest thing preventing users from using or paying for my product? Then it becomes clear. For example, should your product be fast? Of course, but is it the thing that is preventing users from using it?
Performance is an easy example and is also something I encountered myself in the past week. When I released my app 3 months ago, the performance was horrid. Like, really horrid. Even I didn’t want to stick around while my app took many seconds to get the basic view loaded. But I didn’t fix it until last week. Why? Because it wasn’t THE reason people weren’t using my app. Don’t get me wrong, it is definitely a reason for people to not use an app, but it wasn’t the reason people didn’t use my app. At least not until last week. Before last week there were a bunch of other reasons why people didn’t use it.
You might ask - ok, but wouldn’t it have been better to fix it before people encountered bad performance? Sure. But until I prove that people want to try my product, until I see they even get to the point of having a bad experience with performance, is it really the right thing to spend the time and effort to fix it? Building “just in time” features means you are reducing waste, so while it required me to show the world my poor performance, a grave insult to an engineer, it allowed me to spend that effort after I proved my assumption that people will even want to check out my app.
Your MVP, and especially the first version of it, is probably going to be awful in a lot of different ways. The first step is to accept it and release it anyway. The second step will be to decide what to improve at each point in time. Letting the product be “not great” is not a one time decision. You have to make that decision at every step, to show to the world your unperfect product, to improve slowly over time, to be an eventual perfectionist.
And if you need some inspiration and encouragement, here are some successful products that had to try again and again before they got it right.