It’s time! We are finally launching the first public version of Slidebean tomorrow. Slidebean is a new presentation tool that we’ve been developing that we consider to be the next evolution in presentation-making, by offering an extremely simple and straightforward approach to making slides.
Slidebean was selected to be a part of Startup Chile (Round 8), and there’s so much more behind this launch that meets the eye, so I wanted to share a little bit of the story behind this product.
We discovered the need for a tool like Slidebean (called Prezqb in early conception stages) when we were working on Pota-Toss as part of the DreamIt Ventures program in New York, for two particular reasons:
- Making Power Points (or Keynotes) was taking too much of my time.
- Our slides seemed to catch everyone’s attention.
So we had the first thing, a problem to solve.
It was only months later, after we decided not to move on with Pota-Toss that the idea for Slidebean started taking shape again. It seemed everyone we knew had dealt with the issue of Power Point taking too long, and the fact that most presentations we get to see throughout the day were hideous or worse. But that was still too small of a sample.
We’ve been asked a lot why did we decide to take on this project specifically, and the best answer we have is that everyone in the team could relate to the problem, and we believed that there was a promising market for the now-called Slidebean.
1- Validation, validation, validation
The initial money for our previous project came from Kickstarter funds. We were extremely lucky to have been picked up by Techcrunch (see the article here), which was key to funding our campaign, but the biggest lesson we learned was that we didn’t need a developed product to be able to sell it.
When we launched Kickstarter not a single line of code had been written, and we decided to go down the same road with Slidebean. I developed a motion graphics/startup video with a narration recorded with my iPhone inside my closet (to get rid of the echo) that showed the vision and basic functionality that Slidebean would have; and we put it on Facebook, Twitter and Reddit (this was somewhere around June 2013).
We also setup a simple yet stylish landing page on Squarespace (check it out here) with a huge Sign Up button that actually pointed to a standard contact form. The response was astonishing!
Over 1,000 people had visited our website the first month, and around 25% had signed up for the tool. There were no ‘Coming Soon’ signs on the page, it just said “Sign Up” so we knew that most of our ‘users’ were genuinely signing up to use the tool. It was only after we had captured their data that we told them that the tool was under development (which actually wasn’t, yet).
This excellent conversion rate and an apparently convincing video got us a ticket to Startup Chile and convinced us that it was worth making an investment in developing this tool.
I’m particularly proud of this cheap, fast and effective validation that has already worked twice for me. With this approach, we also managed to grow to a user base of almost 1,000 users even before the tool launched, a huge user base that plenty of startups would consider a luxury. This of course costed us $0.
2- Show me the money
¿How to develop a product with no money? Sadly, money is the reason most ideas end up being only ideas. The core Saborstudio team consisted of myself, Vinicio Chanto (Industrial Designer), José Enrique Bolaños (CTO) and Alejandra Paniagua (Web Developer). Our burn rate around that time was somewhere around $7,500/mo including salaries and office expenses.
This meant even a very short development period of 2-3 months would cost us around $20K. Allow me to remind you that we are in Costa Rica, and finding Angel investors willing to chip -twenty thousand dollars- for an idea are extremely hard to find.
Saborstudio had been doing some client work for some time, so we decided to focus on specific customers that were willing to pay a good price to hire our team, and we worked hard to secure some consulting work for the next few months. This of course meant working on Slidebean part time, but it was better than nothing.
I’ve always said that developing a great product requires 110% commitment. This was not the case for us, but the whole team was understanding of the situation and we were able to find a ‘virtual’ 110% commitment that meant doing our consulting work at late nights and focusing our day-office time on Slidebean.
This works, and may work for your startup as well, but it does require a very committed team and client work that doesn’t take too much of your time and mental power. We were lucky enough to have both. With that, we are proud to say that got to an amazing milestone without raising a cent.
3- Start with a tiny market
You may someday develop a product that everyone uses, but you can’t expect everyone to use it at first. We decided to focus on a market of users that are not designers, and that -might- not require all the features that Power Point or Keynote offers.
Slidebean is designed for people that need to make presentations on a weekly or even daily basis.
This means a LOT of presentations and little time to focus on the details. We don’t expect Slidebean to be used for Demo Days or defending your graduate dissertation, we expect it to be used on day-to-day office or college presentations (for now).
It’s still a huge market to cover, but it’s people with a very specific set of needs and one that we are also particularly familiar with and with easy access to. On the marketing and growth stages we’ll probably be even more specific as to who are we approaching, but for the development purposes we expect this tool will fulfil their needs.
As a strong recommendation, do NOT be distracted by what people outside of that market has to say. In our case, for example, other colleague designers have raised their concern as to the flexibility of the tool. It's simple, take the feedback, write it down, nod, then go back to your desk and work on the market you are focusing in.
4- Strip down to basics: a true MVP.
MVP stands for minimum viable product, and it truly needs to be the minimum product that you can launch to validate your assumptions. A great startup quote to keep in mind is:
This is probably the hardest part of all, especially as the team gets larger. I’m anything but an authoritarian CEO (actually all of the oposite) and I am lucky to have an amazing team; but this has been the only case where I’ve had to truly raise the "project manager flag" and forcefully (not really), determine to leave features out of a release.
For people new to the ‘Lean Startup’ approach, determining truly -necessary- features can be extremely hard. We’ve been working with the Lean Validation Board by LeanStartupMachine, which has resulted in an excellent tool to keep the team focused on the task at hand. For this beta version we worked with the following Core Assumptions (a Core Assumption is defined as one that if invalidated would break the business).
- People is willing to change the tool they currently use.
- People is willing to pay for a new tool.
- People can handle a Cloud-Based only platform.
- People is willing to lose certain control in exchange for an efficient and good-looking alternative.
After careful discussion, we confirmed that this last assumption is the core thing that we need to validate at this point, since it’s also the main differentiator of Slidebean versus other, traditional tools.
With this in mind, we can then focus on developing a tool with a set of features that works towards validating THAT specific assumption and nothing else. This meant leaving out -plenty- of stuff we had in mind, and cutting corners to solve interface conflicts in an effective although not-ideal way.
It’s also important to avoid getting caught up in discussions as to how to solve a particular feature. In our particular case, all members of the core Slidebean team have a very strong background in design, which sometimes resulted in longer-than-necessary discussions over the look of a button. Avoid this as much as you can, and remember this is probably going to be irrelevant towards the core assumption you are trying to validate.
It’s also very helpful (I dare say necessary) to work with an unmovable deadline. Get used to setting deadlines and not missing them. It not only gives the team a great sense of accomplishment, but it puts a pressure on everyone’s back that eventually results in people working harder and focusing more on MVP-material. Not having a deadline brings a sense of ‘peace’ that a startup cannot afford to have; or even worse, it allows you to add features that you don't need yet.
A first MVP should not take over 3 months to develop, and you should look at 1 or 2-week tops developing sprints. It’s useless to cook a feature for +1 month unless you are absolutely sure it’s going to have a big impact on your product.
"Fuck it ship it" is a good modo to remember from time to time. No matter how careful you are, you are going to encounter bugs, crashes and stuff you didn’t account for. The best way to find out is with real users and not with on in-house tests.
Now go, finish your product and launch it!