5 Lessons From a B2C Dashboard Launch
Before Christmas, we publicly launched the Strabo platform (https://www.strabo.app) after 6 months of work. Following the release of the private beta in the summer, we took on board feedback from 150 users which allowed us to make the necessary changes to launch the platform publicly.
Here are a few lessons we’ve learned from it, which will hopefully be relevant to anyone launching a SaaS product
- Waitlists are vanity metrics. Although they’re undoubtedly important, their purpose is more to demonstrate that there is a demand for the product, rather than counting users.
The most frictionless way of collecting signups is by using just an email box - no name, age or other details, and while this maximises numbers, it also reduces the commitment. People are often happy to put their email address in on a whim, without even thinking about it, and then instantly forget about what they’ve signed up for.
The other thing is that even passionate signups will likely have forgotten about a waitlist they’ve signed up for after a matter of weeks. So re-engagement is important, and it’s also best to write off anyone who’s signed up more than a few months ago.
- The last 10% of the work takes up 50% of the time. We’re sure anyone who’s launched software knows this already, but by the time you get to 90% done, there’s probably still 50% of the work left.
There are always more things to do in order to go live, and many of those are impossible to anticipate until you get there. By all means have an aggressive launch date, but keep it internal, or try and be a bit more conservative with what you share with users and investors.
- It is going to break. We tested it, tested it once more and then finally tested it again before launching, and it still broke. There is no substitute for having a product live, and users will behave in ways that you couldn’t possibly have expected. One particular example we found is something called rage clicks. A button might work perfectly as intended if you click it and wait for something to happen.
But what about when the button needs to call the back end and that takes more than half a second? People start smashing the button repeatedly. Your product needs to be robust in that it counters this. You need to force people down the use path that is intended and not let them deviate with silly mistakes. Of course, if people are rage clicking it also means that the button just isn’t fast enough!
- Users are forgiving! One of the biggest fears stopping people from launching is that people might hate it, or crucify them for their mistakes. What we will say is that if you reply in a timely manner and directly from the founders, put thought into your responses, take feedback earnestly and show them that you’ve poured love into the product, people will forgive all but the most sacrilegious of mistakes. Which buys you some credit to make them!
It’s pretty easy to gauge when using software that has been built with love, and while great design is difficult at MVP stage, it’s important to try and go back over the little details to include them - people will remember. So allocate some time to “bombs of pleasure” too.
- Collecting feedback is a founder task. Don’t outsource it, and do it every day! This one is super important and something we’re still working on. Talk to users as much as possible - we’re trying now not to make major changes unless they’ve been validated, at least from a desire perspective. Ie they might not ask for that feature specifically, but they’re announcing a problem that feature would solve.
There you have it! It’s definitely still a work in progress, and we’re trying to build this product in public. You can follow our daily and weekly updates directly on the website, on our community page (https://community.strabo.app) and on Twitter (https://www.twitter.com/yourstrabo). Let us know what you think!
🔥 Roast My Landing Page
Interesting to read! I was wondering how do you then navigate the unpredictability of tasks that arise during the final stages of a project, especially when planning launch dates for software or other initiatives? Would you postpone?
Thanks Aimee! It's tough, particularly as you want to count down or build hype towards a launch date that isn't guaranteed. In retrospect I think perhaps we should have finished it and built up hype for the 1-2 weeks while we tested more rigorously.
Of course, most small projects don't have the resource to do proper QA so this can be a challenge - but it's a way of ensuring a more professional launch
Very cool insights, thank you for sharing!
I have a question: How (in)formal did you adress people on your mailing-list with the updates and the launch notification?
Because I want to launch something soon and am collecting signups on my website - but since it's only mails and not more information than that, it's hard for me to decide on a writing style.
Do I play the likeable founder who adresses the first users like his buddies?
Or do I act like the professional business?
Of course this is very individual, I would love to hear on your decision with this :)
Interesting question! It can be a bit of a challenge as you want to minimise friction when collecting signups, so you definitely just want to take an email address. However, of course that means you can't address people by name when sending bulk emails.
One way round that is to use Superhuman, or a tool like hunter.io - these often give the person's name and some details from just an email address, so you can personalise comms a lot more. I'd say first name basis, reasonably casual but not too colloquial (no abbreviations etc) has worked quite well. People just like hearing that there's a real person behind the software and this can often make them much more forgiving.
Happy to discuss more about how we did it if you want any more tips - can message or jump on a call
Ben