It’s often tempting to hard launch new products and features.
In SaaS, it’s almost always the wrong decision.
As the founder of product adoption software, Userpilot, I’ve launched a lot of new functionality over the years.
And in my experience, Soft Launches are more effective, more cost- and resource-efficient, and they lead to better experiences for SaaS users.
Pretty much every time.
Why Soft Launches Beat Hard Launches for SaaS
Best Practices for Soft Launches
When You Should Hard Launch After All
Why Soft Launches Beat Hard Launches for SaaS
Let’s quickly clear up the jargon.
Hard Launches are what companies like Apple excel at.
They generate a buzz and excitement about new products, building up maximum publicity and expectation to peak at the moment that the finished article is unleashed on the world.
The result? Explosive growth and revenue from day one.
Every founder dreams of one of those Steve Jobs moments when the world is waiting with bated breath for your new innovation to drop.
But for 99% of companies, Hard Launches don’t work out like this:
Marketing and engineering have not aligned so that the story and the experience are at odds.
Media isn’t interested.
Worst of all, the product doesn’t work as it’s supposed to on launch day, turning the publicity generated negative.
Remember this?
The armored glass demonstration at the launch of Tesla’s Cybertruck is a perfect illustration of the perils of a Hard Launch.
At the ill-important moment, the product didn’t live up to the promise.
No matter how much research you’ve done, no matter how well-engineered your software is - something unexpected can always happen to derail the event.
A Soft Launch is a product or feature release without fanfare.
The innovation is put out there quietly, with only limited and targeted efforts to draw attention to it - often with the explicit understanding that the new feature is still a work in progress.
If you Soft Launch your product or feature, you have the chance to fix issues with it before pushing for mass adoption or building marketing messages around it.
Those issues fall into three categories:
Stability
Usability
Value
Stability
If you’ve ever been involved in software development, you know that bugs and glitches are unavoidable. No matter how much internal testing you carry out before launch, live user testing always reveals new problems.
With a Soft Launch, you can improve your software iteratively rather than offering up a “once and for all” finished product.
When we release a new feature at Userpilot, we proactively collate bug reports and help requests to identify and roll out fixes as quickly as possible.
Obviously, this is one of the great advantages SaaS has over installed software - we can be reversioning all the time. Remember when you had to wait on a new disk in the post for software patches?
By keeping expectations under control, a Soft Launch will usually make users more tolerant of bugs and stability problems. They get that you’re offering up an MVP and welcome the value-added - their feedback is part of a dialogue rather than a complaint.
Usability
It’s the same thing with usability.
At Userpilot, we use Fullstory to record and watch back entire user sessions. This gives us a real insight into where and why users are hitting dead ends or running into difficulties in realizing value from our tools.
We can then A/B test alternative UX to see what leads to better customer success rates and fewer obstacles.
Just because it follows all the principles of good UX design and just because
it makes sense to you - it doesn’t mean that your real-life users will find your new releases usable.
With a Soft Launch, you can collect live user data, test improvements, and keep releasing ever-better versions of your products.
Value
Finally, a Soft Launch allows you to validate the value proposition that your new features offer.
Once again, a feature or change that seems like an obvious improvement to you may not provide anything your users care about.
A Soft Launch lets users discover their own value in the new features at their own pace.
It can also let you pull a feature that’s clearly not working in a way that is much easier than when you’ve made a big noise about it as part of a Hard Launch.
Let me give you an example that kind of combines all these factors.
At Userpilot, we wanted to allow users to autofill attribute identifiers when they were building Experiences. We thought it was irritating and unnecessarily time-consuming for users to type these out.
So we fixed it.
But it didn’t work in the way we had planned.
The new terms crashed the database unexpectedly.
So we withdrew the new functionality and restored the old version.
Luckily, we’d only released it to a subset of our users (around 20%), and we had simply put the new feature in place for those users without any warning or explanation. Very quickly, the problems became apparent, and we were able to pull it back and regroup.
If we’d Hard Launched that feature to our entire user base with a lot of internal marketing? We would have done ourselves more harm than good. We’d have lost users and damaged our reputation.
Best Practices for Soft Launches
This example brings me neatly on to one of the key questions about Soft Launches.
Who do you launch new features to?
I think the right answer to that lies in what drives product and feature adoption. This can be distilled to three elements:
Awareness
Recognition of potential value (the Aha! moment)
Motivation to try it out - to act to get from Aha! Potential to achieving Activation
As a general rule, when we release a new feature we release it to all users at once - the attribute identifier autofill release was an unusual exception to this rule!
We then use contextual in-app cues to draw users who would see value from the new features towards it.
Indeed, you don’t have to reserve Soft Launch techniques for new releases.
In fact, you should constantly be Soft Launching your existing features as part of your evergreen secondary onboarding flow.
That is, when users’ in-app behavior shows that they could benefit from a feature they aren’t regularly using, you should deploy exactly the same kinds of contextual prompts to draw their attention to these additional sources of value that they haven’t discovered yet.
Soft Launch to All Users
When we launched the functionality to deploy native tooltips in your app, we didn’t directly tell any of our users that this had been added.
Instead, we made it possible for them to discover it for themselves - with relevant messaging at those times in their user journeys that told us that they would see value in them and would be motivated to take action (for example, when users were building an Experience).
Here’s another example, of how we drew attention subtly to new functionality with a hotspot when we added NPS surveys to Userpilot:
There are tools out there which allow you to launch new releases to certain groups of users (Optimizely does this, for example).
But for us - and I think for most SaaS businesses - that’s usually not the best approach.
Unless there’s a risk that your new feature will actually detract from the rest of your product (perhaps by disrupting overall UX, steepening the learning curve or crashing the database…) then it’s better to launch to all users and allow the right people to discover it for themselves.
When to Segment
There are a couple of other exceptions to this rule:
Sometimes it makes sense to launch new features to power users (Pros and Advocates in our user journey diagram below). This is ideal at the early stages of development, when your release is more a beta test than a launch as such. You can get feedback from your most invested users, who won’t be put off by bugs and UX issues and who - in fact - will often have their sense of engagement with you deepened by you seeking out their feedback.
When you want to assess how new features affect your overall value proposition and thereby what marketing messages are likely to work in future, it’s often advisable to restrict launches to new users (those heading towards Aha!) and keep existing users on the current UX. This way, all aspects of your offering are given equal weighting and find their own relative values - new users have no preconceptions, unlike existing users who already have their own established patterns of use. Depending on the scale of your changes, you may need a migration plan for switching existing users over to the new version.
Soft Launches and Roadmapping
At this point, I feel that I should mention how complementary this process of continuous Soft Launching and adapting is to the kind of dynamic product roadmapping that Airfocus makes possible.
By using the unique Prioritization features Airfocus has (I’ve never seen them anywhere else), you can plan, schedule and timetable new releases in a way that optimizes value to users against resource requirements.
Can you imagine the extra complexity it would add if all these projects - and the marketing - had to complete at the same time for a Hard Launch date?
Or how wasteful it would be to sit on finished features which could be adding value to users until Hard Launch time?
There’s a reason we don’t develop software like this anymore. And Soft Launches are infinitely more suitable to today’s agile working practices than the Hard Launches of the past.
When You Should Hard Launch After All
This is not to say that there’s no place for Hard Launches anymore. A Hard Launch might be right:
If you’re in a race with a competitor to get a killer feature onto the market first
If your top priority is maximizing revenue or market share in the short run
If you’re 100% certain that it’s going to be a success
The first two cases are all about timing.
But the third is about preparation, and that’s what one or more Soft Launches allows you to do - to iron out all the problems, to perfect the UX, to develop marketing messages that resonate with real users’ use cases and needs through an iterative process.
Once you have all that in place, weigh up the costs of the launch against the benefits of the added publicity.
You may find that there’s no need for a Hard Launch after all.
If all your users are discovering the new features in-app at the most effective moment through clever contextual onboarding and plenty of new users are attracted by your value proposition - why bother?
Yazan Sehwail
Read also
Create effective product strategy
Experience the new way of doing product management