Lately I have been considering if there is a better approach to launching products. My time is limited because of my freelance consulting, other projects, etc. I have committed to launch new experiments during the next months though. I have many ideas I want to test. Problems I want to address. Potential solutions that could help people tackle those problems. Being my time & energy limited, optimising what and how launch those is paramount. But more importantly, launching means moving things forward. Not so easy.
A kindly reminder on the importance of launching was this article, Why Developers Are Building So Many Side Projects. From Future, the a16z newsletter. I had another one yesterday, with my friend launching Magic Board AutoPaste Keyboard. He has a toddler. Has organized two weddings in different countries in the last month and went on his honeymoon… and still delivering like that!
Launching a product is always scary. There are ways to understand why it is scary and why it should be a priority. Rationalise the need of fast shipping. Minimise risks and take advantage of ways of launching faster. I have never regretted launching too soon, but I have had the feeling of launching too late.
The blockers to launch fast would be, in this particular order:
- Insecurity, fears
- Viability
- Launch execution
Fears
The problem with launching is 90% of the times, self confidence. I have a very few examples of product launches where the quality of the product was the issue. On the other hand, I have tons of examples were a fast launch would have solved myriads of problems and wasted resources.
My way to approach it now is a) think in terms of potential outcomes and b) minimise risks.
Mapping potential outcomes. What are they potential outcomes of a launch? Lack of interest is number one. The one thing you really want to know as soon as possible. Face that is the case and deal with that possible outcome mentally. Finding out soon is not a bad outcome, finding out down the road is. Customers dealing with a buggy solution? if they have interest, they will stick around. Take a look at how many terrible products people use for years.
Minimising risks is even easier. Does your product put lives or business at risk? If so, you should not be using a quick launch methodology, sorry to break the news to you. Otherwise, what would be a catastrophic result of things going wrong with your product? Plan for that outcome
Just launch. Put your product in people’s hands and listen. That’s your lifeline.
Viability
I probably spend too much time validating something can be done. I am a perfectionist, so I like to be 100% sure something is possible before launching. The problem with that approach is that sometimes you discover there are more important variables that should have been resolved before tackling the technical aspects. From having an unaffordable CAC to being a type of market I am not really interested in being part of. Launching would have helped solve those questions beforehand.
My new approach to this the last months has been to have a side track to experiment with technical validation of ideas. Think in terms of “For me to solve problem X, I should be able to use Y technology in Z way”. Go and test that is possible in a barebones, pure technical environment. Tinkering with the technology. If I am not able to validate the technical side of a side project by playing with it a few days, it is probably not something I should be attacking.
Execution
A key aspect. Tightly tied with the fears point. In the past I have worked with teams where this was the main issue. “We want to launch, but when the product is ready. If the product is not really there, how would we know people really want it?”. That is a catch 22. Another friend sent me this meme not too long ago, to remind us about it.
There is a lot I could write about this mentality or issue. How that is a red flag that signals a poor product direction or a display of lack of experience launching products. It all can be summarised: launching fast and imperfect triumphs a too-slow-too-late perfect launch.
There are exceptions of course, but be sure that the odds of you being in the former are massively higher than you being an exception.
I am not pleading for bad execution. Neither a proponent of throwing best practices through the window (this article, A development process startup founders should use to ship features weirdly fast is a good example, although it makes a couple good points). I am a firm believer of execution being exponential. I believe in making smart choices as a competitive advantage. Embracing constrains and trimming unnecessary weight is the best possible way to fast execution.
Ship like there is no tomorrow. Focus on what is important, the rest will take care by itself.
