Lessons I learned from my 5 zero-to-one product launches
Product launches are never a walk in the park, and I’ve learned some lessons the hard way. Hopefully, this article will help you manage your next product launch better than I did in the past.
You’ve probably seen, many times, something similar to this phrase on the job description of a product manager position: “Experience developing products from zero to first release and beyond”. Have you ever wondered why there is such a requirement for product managers to get into a leading tech company?
Having experienced 5 zero-to-one product launches in my career, I can suggest that a product launch is a fast-track way of learning about the most important aspects of a business and product management. Product launches don’t just mean that you’ve been part of a team that created something from nothing, they also imply that you shared the responsibility and the authority to do so.
Clearly, product launches are never a walk in the park, and I’ve learned some lessons the hard way throughout the different product launches I’ve been part of. Hopefully, this article will help you manage your next product launch better than I did in the past.
1. It is a big deal
Let me start off by saying that the thrill of a new product launch does not depend on the type of product you want to ship. Throughout my career I’ve shipped internal products, SaaS products, marketplace products, and platform products, and the importance of the launch and the risk involved were always extremely high. Who can really claim that the thrill of launching a start-up is less than that of launching a new product in a scaling SaaS company?
The first lesson that I learned about new product launches was that they were always critical projects. When I mean critical, I mean life-or-death or rather, up-or-out kind of risk for the product manager in charge. I can quote one of the top-level managers in one of my product launches to emphasise this point: “You know, you have the options of a convict of the mediaeval era: if you don’t deliver on time [or successfully] we either chop your head off or we hang you.”
Too much?
Apart from the barbaric analogy, I think it’s fair! A more modern way of putting it is “with great power comes great responsibility”, and the executive of the paragraph above underlines precisely that. New product launches are high-risk, high-reward career challenges for the Product Manager in charge. I’ve been lucky enough to succeed in delivering a successful launch in 4 of the 5 launches I led, and with every success I got a promotion.
So succeed, and you will be promoted/rewarded, fail, and you will be punished/fired.
2. It is a huge bet and gambling is bad
Launching a new product is like gambling but worse. Gambling is addictive because even though you know that the house always wins, you think that you can beat the odds. It’s the dream of winning big that keeps you hanging onto the green tablecloth. When you’re launching a new product, it’s a similar feeling. You believe in an idea or a dream product so much that it’s hard to think that the odds are stacked against you.
Think of launching a new product as a gambling session in which you’re willing to sit at the table for at least a few months, and you’re willing to put not only your time (and often your money) on the table, but also your career. Yes, it is that big of a bet. If you have a failed launch, you will not only have wasted some months of your life, but you will lose on other opportunities that you decided not to take (i.e. opportunity cost). As if that wasn’t enough, you will also not be able to say anything exciting (or convincing) at your next job interview, because guess what, they will ask you how it went and why you’re looking to change.
Gamblers often lose, and the house often wins. However, there are those that make winning a reality by taking ‘lady luck’ out of the equation and reading the room perfectly to take more ‘calculated’ risks. By using skills, such as bluffing, and data, such as probability, these ‘gamblers’ load the dice and become ‘players’ instead.
This is exactly how product managers should approach new products. Since there is so much at stake, the product manager must do a lot of research (both quantitative and qualitative) and try to minimise the risk of failure. Often, this is the phase in which most startups fail. It’s easy to fall in love with an idea, a dream product, that big ‘win’. What’s difficult is to identify a gap, an opportunity, or a problem of a considerably big market, and find people who would be interested to pay for a solution. The dream product will remain a dream if it doesn’t address a problem, so stack the deck and load the dice: invest heavily in discovery.
3. Someone has to lead, and that someone is you
Generally, the product manager is neither the founder nor a high level manager. In start-ups they may end up being one of the few people in the team, but still, usually they are not the highest paid person in the team. The key point though, is that, generally, they are the only person that has to speak with every other stakeholder and team member.
Founders or high level managers are the main sponsors of any big launch. They usually have a dream and they aim to fulfil that dream at whatever cost. They can motivate anyone that they talk with, but sometimes they can’t (for organisational reasons) or they shouldn’t (for lack of technology product skills) talk with ‘the builders’. You couldn’t (or shouldn’t) have a founder or a high level manager interacting directly with developers or designers, especially when there is a product manager in the team. You couldn’t because that would undermine the authority of the product manager and reduce them to a mere product owner. You shouldn’t, because founders and generic managers usually don’t know how to communicate in the best way with tech resources like developers and designers.
Well, guess who has to lead the developers and designers in the right direction then? The product manager is the only person up to the task, because they have access to all stakeholders (including the main sponsors of the launch) and they are supposed to be the most knowledgeable person on all details required for the product launch (both business-related and customer-related details).
By showing your knowledge, supporting your remarks with data, and communicating them effectively, you as the PM should motivate and lead the way to your developer and designer teammates (and other members of the product team if there are others).
4. MVP is the only logical way to go
Launching a product is not easy at all. So why in the world would you want to complicate it even more? Throughout the different product launches I led, I found myself saying “no” more times than I wanted to. No one wants to be the party pooper, but can you actually be the party rocker while you say no?
After the successful launches all the stakeholders would congratulate me, and a few weeks after the launch they would thank me that we did not do some of the features that were requested by them. But why? Because the down side of launching something new is exactly that, it’s new! There is little to no data, and more guessing than informed decision making. The learn-build-measure cycle and the MVP approach are probably the only concepts that I favour continuously because they limit the waste and enable data driven decisions. In fact, my only failed launch was the one in which we did not follow the MVP approach. The stakeholders and sponsors pushed too hard for certain features and this led to longer development times, less learning from usage, and a more complicated backlog to manage without making profits.
If you want to have a higher chance of success, make your launch based on a Minimum Viable Product.
5. Prepare everyone for a bumpy lift-off
The last lesson I learned is specifically about the launch day/week itself. The launch is a funny moment full of emotions: you will find yourself eagerly waiting for the first sale and of course, for the first bug!
Hopefully you’ve prepared well which means that all the QA tests were passed and that you had your alerts set in place. Stakeholders that don’t know too much about the technology world may be more optimistic. You should teach them to be on high alert and prepare them for the worst. In the end, with all the QA you have, you cannot replicate the behaviour of thousands of traffic from random people to your product. There will be bugs!
I usually used different words to prepare my stakeholders like “it’s gonna be a bloodbath” or “it’s gonna be a shitshow”. Sometimes I was just so sincere and told the business stakeholders: “I hope you know that the following week is gonna be the hardest one for all of us so far”. The good thing is though, is that it lasts up to 10 days at most, which is another point to align stakeholders on. It’s gonna be really bad for a few days, but then it will all be much better than before!
So make sure that you prepare all stakeholders to expect the worst and motivate your team to be at their best. Try to go above management’s expectations with your team’s performance. In the end, success is the gap between their expectations and your performance.
Although I learned these lessons the hard way, I must admit that it was always fun to launch new products. If you’ve experienced it yourself as well, you’ll definitely relate. If instead you still haven’t, I strongly recommend it. And, in case you have a launch closing in…
Have a safe lift-off!
—
Hope that you enjoyed reading this article and that it will help you organise your next product launch better! Make sure to give me a like or a share if it was useful and please follow me for more product management content!
