What is a product launch?
When people hear about product or feature launches, they might think a product team spends weeks and months working on a feature, and then comes the big reveal of a killer feature at a big tech conference. Maybe something similar to the Windows 95 launch?
In reality, product launches are rarely linear or the end of the product development process. A product launch is more often just the beginning. It’s the first time when you can truly validate the feature you built is useful. Then with a combination of quantitive data and user feedback, your team can continue to improve on your product.
How to launch a new product or feature?
Once your feature or product has been built. There are many ways that you can test or roll out your feature to your users. How you launch your feature depends on many factors — the maturity of your product, your existing user base, the type of product/feature you are launching, the goal/the metric you want to achieve with this feature, etc. There is no recipe for launches and often you will have to rely on your experience and product sense. I’m laying out below three common types of rollouts that I’ve seen or used, but it’s by no means comprehensive.
Limited rollout gives the product team the benefit of controlling the size and types of users. Before running a limited rollout, you should set a quantitative goal that you want to reach as the criteria for a wider launch. I’ve listed some common variations of limited rollouts/tests:
Employee only — This is also referred to as dogfooding. Originated at Microsoft, it is often used by large tech companies as it’s a low risk way to test new features with their employees and get feedback.
Restricted rollout — This allows the product team to control the user types that can access the feature. For example, releasing the feature to specific user types (paid users only), specific geographical locations (only users in Southeast Asia), demography (teen only), platform (iOS users only), etc.
Invite-only rollout — The product team can invite users to try out a new feature, very often, only the most interested users will sign up. This is a great way to gauge in the interest of a new feature from your most engaged users.
A/B test — This is often used to test product improvements with the goal of optimizing a specific metric. You would test the version of your feature with a specific change against the control (the existing feature) and compare how the change affects your metric.
Since you may not always be in a particular rollout group, a great resource to monitor different rollouts or tests that companies run is @wongmjane’s Twitter account.
2. Gradual rollout
After you’ve validated a new feature and is ready to roll out to a big number of your users, you can roll out to 5%, 20%, 80%, 99% of users gradually over time to reduce risks, etc. server crashes due to a large number of requests caused by increased usage of the new feature.
3. Full rollout
Sometimes a full rollout is required in order to launch a new feature. This could be due to a major product launch/promotion campaign; or if a product or feature requires consistent experience for all users in order to bring customer value, for example, any social features or features that require network effect.
*note on holdback group — even for a fully rolled out feature, many times you may want to leave 1–5% of users on the original experience, this allows you to monitor long-term impact of a feature and aid in troubleshooting in case the root cause is caused by a feature.
Launch day checklist
Prior to launch day, create checklist along with deadline and owners. I’ve included an example, but your actual list may vary by product, context, and company.
End to end QA test for all use cases
Legal sign off
Anticipate the number of requests from the new feature and stress test the backend server
Inform customer service department
Log data and check it’s logged correctly
Ensure your app has been approved by the App Store or Google Play Store
Work with product marketing manager to create a go-to market plan
On launch day, you may need to create an hour by hour list of what needs to be done in order to ensure the successful launch of your product, many product teams set up a war room, a room with all the stakeholders, and run through the launch day checklist together. I’ve included an example below:
Smoke test — a less extensive QA test that covers only the major use cases
Send PR, blog announcement
Launch marketing campaign
Launch the feature/product (turn on the A/B test if the feature is behind an A/B test, deploy your website, publish your app after it’s been approved by the App Store or Google Play Store.)
Whichever way you choose to launch a new feature or product, putting your product in front of your users is often the best way to validate and improve your product.
“If you’re not embarrassed by the first version of your product, you’ve launched too late”
- Reid Hoffman
This is a repost from my Medium article.