5 Reasons to NOT Launch a Shipped Feature
In the world of Agile, teams have a concept of a sprint. A sprint is between one and four weeks in length. The team defines what work will be done in that sprint. They then further break the work down into tickets that developers can own. While the sprint might be two weeks in duration, developers often ship more frequently than that, even daily. But this doesn’t constitute a launch, nor should it.
First, some definitions:
Shipping means deploying code to the production environment.
Launching refers to actually informing your users of this new feature. This could be through in-app alerts, a marketing newsletter, or even a press release.
Productive product development teams ship frequently. This enables you to learn faster. It encourages your team to break down their work into the smallest units of shippable value. And it minimizes the risk of outages or severe bugs when you ship. It’s much easier to roll back one day of development than six months.
But just because your team is shipping features frequently doesn’t mean your marketing team needs to launch them.
Five reasons to ship, but not launch:
It’s early. While you should always strive to ship units of value, sometimes you recognize you are very early on your journey to delivering full value. In this case, it can be helpful to hide the feature behind a feature flag and only release it to a small cohort of users. This can help you rapidly learn and iterate while minimizing downside risk.
You want to maximize the launch impact. If you are following your product strategy, you are likely investing consistently in a specific area. One launch strategy is to trickle out feature announcements one by one. A more impactful launch strategy is to hold off, and then announce several exciting new features aligned with a single theme in one big bang.
You are measuring and documenting feature impact. Data-backed claims touting the impact of your new feature, as well as user case studies, are powerful assets to share as part of a launch. Waiting until you have these assets in place can amplify the impact of your launch.
You are testing discoverability. If you promote something, you drive engagement that might not have happened otherwise. If you want to truly test how discoverable a new feature is, then don’t tell the user.
Some features don’t need a launch. New onboarding flow? Fixed a minor bug? You don’t always need to shout this out to your users. Especially onboarding features. Your current users are already onboarded. This update is irrelevant to them.
Everything that ships does not have to be launched. Your go-to-market strategy should be as well thought out as your product strategy. Sometimes choosing not to launch can have a greater impact than launching.
