If you’re one of the more than 500 million users of the file sharing service Dropbox, you know how convenient it is for managing files across all your devices and with other people.
For Dropbox founder Drew Houston, who started the service in 2007, it was anything but obvious that it would be a success. He didn’t know whether people would value the service, didn’t know which features they would want, and had trouble convincing investors of its value.
He could have conducted extensive market research, but that would have been time-consuming and expensive. So, instead of dragging their feet, Houston and his team created a simple four-minute video to demonstrate Dropbox in action. Houston himself narrated it, and it simply showed the core feature of Dropbox: He changed a file on his PC and it was instantly visible on his Mac (and vice versa).
Although this was such a simple concept (and one we take for granted now), it was a novel idea at the time. The video was an instant hit, with thousands of people joining the Dropbox waiting list literally overnight.
This simple, almost amateurish, video gave the Dropbox team the confidence to build the product, and launched the company that is now worth billions.
Start before you’re ready.
If 2020 has taught us anything, it’s that our best-laid plans can easily get derailed!
When building something new – whether it’s a product, a service, or responsibility in your team members – it’s tempting to wait until it’s perfect before you launch it. But that’s a never-ending task, and – after a certain point – has diminishing returns.
Start before you’re ready. Don’t wait for the perfect time, because the perfect time never comes.
This doesn’t give you a licence to create terrible products! You still need quality, you just don’t need perfection.
In the software development world, products are released in stages before they are “perfect”:
- Alpha: At this early stage, the product is not really fit for use, but the team releases it to a carefully-selected group of users for assessment, testing, and review.
- Beta: This is the first public release, but users know the product still has some problems, so their expectations are set early.
- Live: The bright, shiny product is released with the major known problems fixed.
If this was a car, an alpha release would have safety issues that make it unsafe to drive on public roads, a beta release would be safe but perhaps with some minor faults, and the live release would be the new car you buy from the dealership.
The key to getting things done now, in our fast-changing world, is to launch when at “beta”. If it’s only good enough for “alpha”, it needs more work, but don’t wait forever. When you judge it’s good enough for beta, take action.
You might be reluctant to start before you’re ready, but it gives you real feedback you can’t get in any other way. For example, Gmail was in beta for five years before Google officially ended its beta status in 2009. By that time, it already had hundreds of millions of active users, who had the benefit of using Gmail for all that time, but also provided invaluable feedback to Google.
Apply this principle to all areas of your organisation, large or small, and in diverse areas. For example:
- Try an online collaboration tool for people working at home.
- Launch a social media campaign before you know exactly how it will work.
- Promote somebody to a new role before they’re 100% ready to take on that responsibility.
- Dip your toes into a new market to test the waters.
Don’t be reckless and start too soon (that would be acting at the alpha stage, which is premature). Do enough to ensure you won’t create a disaster. But when you reach that point, don’t wait.
- What projects do you have right now in beta, which you could you release?
- What projects are in alpha that you could quickly get to beta?
- What essential criteria apply (safety, reliability, and so on) to future projects to judge when you’ll be ready to act?