Strabo is Live! 5 Lessons learned from a Public Software Launch

Before Christmas, we publicly launched the Strabo platform 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.

These have been well documented. They mainly consist of design and usability changes and a fundamental change to the customisability of the dashboard. Users don’t want to see an empty state when they log in - people aren’t interested in taking the time to configure an unproven platform themselves and so we needed a reduced time to value.

We achieved this by building a default dashboard state with three main pages: Overview, Investments and Accounts. The customisability is then accessible by adding new pages which can be configured to the user’s specific needs. In this way, they get to check out the standard features of the platform before configuring any new ones. We launched this standard state after some tweaking and a load of internal testing, and discovered a few things that you can only learn in practice!

Here are a few lessons we’ve learned from it, which will hopefully be relevant to anyone launching a SaaS product

‍

1. 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. That being said, it feels great to have people waiting to use your platform! Things like referrals with stated bonuses can also help with this.
   
   
2. 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.
   
   
3. 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!
   
   
4. 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.
   
   
5. 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 site here, on our community page and on Twitter. Let us know what you think!