The story of a failed launch (or, why we’re going back to closed data)

Published in

Actiondesk

5 min readApr 10, 2021

6 weeks ago, we launched the public beta of our product Actiondesk on Product Hunt and got great traction there (here’s the story of our Product Hunt launch).

A public beta meant that anyone could come on our website, create an account and start using our software.

Last week, after getting tons of leads and observing our conversion had become much lower, we decided to stop this and move back to a closed beta. A non-user now has to be referred or selected by our team internally before being able to start using Actiondesk.

When we started thinking about this, it felt like a step back but we are convinced it will let us build a better product, create more value for our users, and drive more growth.

Here’s our thought process.

1/ Alpha, closed beta, open beta, what the hell does this mean?

We’re a small team of 4 people, and none of us has ever built a product from scratch and shipped it to the world. Our two software engineers were previously working for great but bigger startups: Deezer and S4M. My co-founder & CTO has worked in various startups and bigger companies as a Software Engineer & Lead Engineer. As for myself, I was previously managing an e-commerce company.

So the question of how and when to release our product to the world had always been a tough one.

We initially started with a period of about 7–8 months that we could call an alpha. We had a very rough product, were talking to a lot of potential users and were onboarding a few.

Thanks to this, we were getting great and precious feedback, the product was getting better and better.

During this period, we always had in mind the wise words of Reid Hoffman:

If you’re not Embarrassed by the first version of your product, you’ve launched too late

So we decided to launch openly to the world in February. This launch was a success by a lot of metrics (I talk about that here).

But as the weeks went by post-launch, there was a serious problem:

Our conversion was much lower than it was during our “Alpha”. So what was happening?

2/ With the current state of the product, our users need to have an onboarding call before using Actiondesk

During our alpha, we were having multiple calls with our soon-to-be users: to explain to them how we can help, to hear about their use cases, to train them, to build automations with them.

When we launched publicly, users basically had to figure out those steps by themselves. Needless to say: most of them didn’t and some got frustrated, leaving Actiondesk and not intending to come back.

Realizing that, we quickly moved to do two things:

Build an onboarding wizard to help new users build a first automation (that you can see here)
Qualify leads based on the answers to the form they filled in before accessing the app, and try to get on a call with the ones we thought were the best fit for Actiondesk.

The wizard helped but was not enough. Actiondesk is very versatile, and we’ll ultimately need different kinds of wizards depending on who you are, the company you work at, the tools you use and the type of automations you want to build.

At this point, most potential users didn’t want to jump on a call. Their time is precious, they had already spent time trying out Actiondesk, they got frustrated and didn’t want to give it more time, not even a 30-min call.

Another problem is that we got close to 1,000 new users in just a few weeks, and our customer support team (= myself) got swamped with requests coming from some users that didn’t fit our persona and were very unlikely to convert no matter how good the product is. This became a distraction.

The conclusion was very clear. At the current stage of the product, users are not able to get the aha moment, to see the value of Actiondesk by themselves. We need at least one call with them to show them how to get there.

We also need to focus our efforts on the users who can get the most value from Actiondesk and avoid spreading ourselves too thin.

3/ Our new onboarding workflow

Before I get into what we’re doing now, I definitely need to give a shoutout to Rahul Vohra, Superhuman’s CEO and Brian Balfour. We got a lot of inspiration from Superhuman onboarding’s process and the two following articles helped us a lot thinking through this.

This is our current onboarding workflow:

A user goes on the website
Clicks on “Request access”
Is redirected to a form asking a few questions
When the form is done, they’re encouraged to get recommended by someone who’s already using Actiondesk.
Depending on the answers to the form and whether the user was recommended, we will make a decision on whether to give them access or not.
If we don’t give them access right now, we send an email explaining why.
If we do, we ask them to schedule a call during which we will give them access and train them.

4/ Why this new workflow lets us create more value for our customers

So let’s break this process down and understand the thought process behind each step:

a/ The form

The form is there to gather information on the user. This will help us assess whether Actiondesk can actually bring value to that user. If it can’t, the user and us are better off not wasting time trying to make it work.

We already had a form before, but since the user knew they would get access right after no matter what, they weren’t incentivized to properly fill in the form. This meant we had bad data and were not able to really know which users we should focus our efforts on.

b/ The recommendation

The first time I encountered a private beta working with recommendations, I hated it. It was frustrating and seemed elitist. So it was a tough call to do it ourselves.

We did it because if a current user recommends someone they know, it’s very likely that this person fits our persona and will benefit from Actiondesk. On top of the answers to the form, it’s another signal telling us whether it’s someone we are able to help and should focus efforts on.

c/ The email with the decision for users who don’t get in

It never feels nice to be “rejected”. The first time I was not accepted into a beta, I was angry and felt they thought I was not good enough for their tool. Explaining we are not accepting users because we don’t think we can serve them well is important.

d/ The call

We already went over this. The call is here to train the new user, show them the tool and make sure they immediately get value from it.

This is just the beginning, I’ll share the first results of this move in one or two months. Stay tuned :)

As I said at the beginning, we’re newbies so keen to hear your thoughts on the topic! Anything you’d do differently?