Curious Product #19 - The launcher mindset
When you launch something you de-risk your product a lot
Image credit to lean-labs.com
I’m less active here than usual here because I’m in the middle of launching a new product. In fact, we are launching a whole company but those are not as separate as many would think - the company and the product are intertwined if your company lives in the XXI century.
In between some lines of code, meetings with suppliers and potential clients and a lot of bureaucracy - I live in Brazil - I decided to share some decisions we had to make and how this can be useful for any product manager.
Launching isn’t unique for startups or new companies. Product managers are always launching something new - a new experiment, a new feature, a new offer within an existing product. Although tactics change with context, the framework used to rationalize about the launching program is similar.
There are four pillars we have to think about when launching, let’s dig into them:
Launch fast to de-risk your product
It’s good to have technical debts
You won’t be proud of the initial product
Launch to have a learning environment
Launch fast to de-risk your product
You made the product discovery, talk to potential customers, understood your market positioning. You committed to the Lean movement. But the reality is: until you launch it and have real numbers you only have a faint idea if the offer really solves real people problems. Moreover, you have no idea how to operate the products, the real bugs in the processes and in the code until you put that in production.
Launching is key to find real value. And launching is a process, in fact you should be constantly launching. You launch your pitch, test your pitch. Test a channel, then another, even without a product. You make family and friends and employees use an incomplete version of it.
And at some point you need to really put the MVP in production into the unknown. The numbers will come and probably they will disappoint you. But that’s exactly the point, because now the problem is real and you can act upon it. You will guide the development based on how you see people using the product. You will re-do your math to check how to make the offer work for the business. That’s what is needed to mitigate business and customer value (see Marty Cagan’s four big risks if you are not familiar with these concepts).
I am talking about de-risking the product. In some situations a broken product can actually put your reputation under risk. That reduces the value of your product for the market in a non-reversible way. For example: if you are offering a cyber-sec solution but your broken solution allowed a hacker attack I am afraid you’ll get out of business. Therefore, launch when you feel comfortable with the risks involved. Don’t wait until you mitigate all risks but be comfortable with the risks taken. Going from 0 to 1 it’s a high-risk, high-reward situation.
“Being able to manage the end to end launch of broader, larger, more complex, higher risk, higher reward initiatives is critical to progressing in Product and Engineering.” - Reforge
It’s good to have technical debts
Over-engineering might get into the way to your launch. Don’t be sloppy but also recognize it’s good to have technical debts at an early stage of a product. Otherwise you can invest a lot of time paying a debt that’s not worth it. For example, if a feature is not really valuable to the customer, shutting it down will have cost you way more if you have paid the debt upfront - that was a waste.
Therefore, the key is to (i) be conscious about the risks and the reasons of the debts left behind; (ii) align well with stakeholders that the team will need time to pay some debt once you find a successful path.
Managing expectations is the hard part here. A success might drag you into technical debt bankruptcy. Therefore it’s really important to set expectations before the fact and use the inertia of initial great results to actually pay the right debts before moving on.
You won’t be proud of the initial product
For the last two parts I will cite quite often an essay from Reid Hoffman that you can find here. I will start by a famous quote he coined more than a decade ago:
“If you're not embarrassed by the first version of your product, you've launched too late.”
So forgive yourself on mistakes and bugs. Early adopters are forgivers if you are transparent about the process and willing to make it work. Early adopters are not mainstream users that wait for everything to be perfectly working. But they give you the chance to learn fast if you are open to failure and vulnerable. Perfectionism will get you in the way of learning when launching.
From Reid Hoffman:
“Sure, you might be a little embarrassed, but that's not a bad thing, as long as you're moving fast, learning fast, and improving your product.”
Launch to have a learning environment
It’s possible but unlikely that the first product or service you develop will be exactly what potential customers were already hoping for. That’s why failure is the fuel that moves new projects forward. Failure is a way of discovering one more thing that customers didn’t want, and perhaps, learning a bit about what they might want. By iterating without tears or fears, organizations are able to discover things about their future customers. - Seth Godin
A live product is the learn environment every product team needs to learn fast. To have numbers and the reality in front of their eyes. It’s comforting to be at product discovery or at planning phase, theory is often better than practice. But that’s not learning about the real world.
Launch to learn fast. To have a playground to test hypothesis in the real market. Every product team must be curious about how real customers will interact with a product. There’s no better way to find it out than having the product live.
I will end this with another quote from Reid Hoffman:
“Your assumptions about your customers, and how they'll use your product, won't be entirely correct. Eventually, you'll probably be embarrassed by how many wrong assumptions you made.
(…) If you'd launched sooner, you would have started learning sooner.
Always be curious,
Thanks for reading.