How "move fast and break things" almost killed our startup on arrival.
We started MiDrive Transfer as a result of our frustration with using other similar transfer platforms. I am an independent filmmaker and regularly send a downloadable version of my film frequently to film festivals. Some of the issues I had with other transfer platforms
- Limited file size for the free plan (most offer about 2GB file size)
- Expiry date! ( Virtually all transfer platforms set the expiration of a file download link to 1 week)
- Some require me to sign up! Really?
- Some have very crappy UX. 😩
We simply decided to create a better alternative with more latitude for the basic subscriber.
MiDrive Transfer was going to have more compelling deliverables. These were our differentiating features
- Free for all to use.
- Doesn't require you to sign-up
- No ads
- Up to 10GB file size for free (compared to 2GB for other platforms)
- 30 days expiry date (compared to 7 days for other platforms)
- Simple and responsive
- Everything that added up as a premium feature on other platforms was simply free. e.g. Password Protection.
While my other 2 partners were busy with building a world-class product, I was busy with marketing. I had initially reached out to my personal contacts about the project and many were waiting to give the platform a spin. We also had the usual regular marketing plans too. Launch on Product Hunt, Indiehacker etc.
MiDrive Transfer was ready for an open beta launch about a month later. We were very excited that we missed some very important things. Our launch on Indiehacker actually went relatively well (https://www.indiehackers.com/post/why-i-created-another-file-transfer-platform-midrive-transfer-297653168b). People tested the platform and found it cool. We only made one silly mistake. We didn't critically test the platform! We didn't test the platform with larger file sizes. I know that sounds bad but well, it's just what it is.
Shortly after we launched, I cold-emailed some tech bloggers with special focus on cloud storage publications and this was when we realized we had just loaded a gun, pointed it to our heads and shot ourselves in the head! It was bad.
The job we were supposed to have done was now being done by the people we reached out to. Here is one of the replies we got from a blogger.
First of all, we were very humbled he took the time to take the platform for a spin, however, we were very embarrassed with his response. That was when we knew we had messed up!
We immediately went to work to figure out what happened. We initially thought this was just going to be a 1-2 days fix but when we eventually found the problem, we discovered there were more than a just a couple of serious bugs! Some of the issues we initially missed were
Upload Speed
Password Protection Bug
Upload time discrepancies etc.
We eventually started tackling each one of them and this took about 4 weeks in total to fix.
People advise you to move fast! The product doesn't have to be perfect, launch now, blablabla! While they are all not bad advice in practicality, we now see that there is a thin line in-between. We wanted to move fast and break things hence missed some very critical things. My advice is to be sure your product (MVP) is at least as solid as it can be. Take your time to test and test (Especially if your product is a SAAS). Some products will do just fine if you move fast and break things but I believe some products will do much better if you take a little more time and cover all the kinks and obvious rough edges before throwing it out there. The first impression they say matters so make it count!
Now, if you enjoyed this write-up, be kind to give https://transfer.midrive.io a spin! We guarantee you won’t be disappointed.
I am one of the few people out there who don't subscribe to the 'MVP' culture. For instance, in my HR app, if we had launched and the reminder emails in the system didn't work as expected, customers would have completely lost trust in us, and left in droves, and our reputation would be in tatters. We spent a LOT of time making sure that key features our customers would want would work perfectly.
I believe the whole MVP concept is just a strategy coined up by big VC firms so that they could optimise the sausage factory process of skimming a bunch of quick to come and go startups, to pick a possibly winning racehorse to back.
Go back to the old days of software design. Microsoft Word or Lotus 1-2-3 didn't have an MVP released into the wild. Software engineers built the whole thing and launched when it was stable and fit for purpose. Same with most enterprise software. SalesForce, who are arguably the most successful SaaS of all time, never had an MVP released to the public.
I wouldn't sign-up for MVP of Elon Musk's upcoming Mars rocket...
Clearly MVPs are not suitable for some type of businesses/ideas, but that doesn't mean they are categorically broken or stupid.
Also, MVP did not originate from VC firms.
No one has truly described this problem the way you have! Very well said
This comment was deleted 3 years ago.
Reminders are actually a very very minor part of our product. The other information management is core, but a lot of entries have the ability to set a reminder as an option. However, this very minor feature absolutely, positively has to work every time, so we have over engineered it to ensure that it works even if the main app server is overloaded or goes down.
All it will take is one reminder not to fire and our customer could actually get in legal trouble for not renewing an employee's paperwork.
We spent an inordinately high amount of our development time on a tiny feature that not all our customer use. Because those that DO use it cannot have it fail because it was tacked on as an afterthought. It couldn't be minimally viable. It had to work.
We were actually told at an accelerator session to either leave reminders off so that we could launch quicker, or else have a simplistic reminder system that we could handle manually in the back end if customers needed it.
The thing that infuriates ME infinitely is that 99% of the time, knocking up a minimal product to launch equals a ton of technical debt that has to be sorted out later.
Sorting out tech debt later, once you know a direction is the right one is surely better than spending time over-architecting a solution for an uncertain space?
A buddy of mine went through a similar issue. Actually was one of the reasons I created https://uppington.io/
I also, did explain to him that saying is move fast with your core items solid.
That there is the problem. No one tells you your core features should be ROCK SOLID. Once it's functional with 1-2 tests, then they say it's time to throw it out there. That's the problem. Our initial web app worked fine with 10 users, but we weren't sure it would handle 100 concurrent users. That is the thin line. You need to be sure your product is as strong as a DIAMOND!
This isn't what it means. It means differentiating between what is essential to launch (in your case, upload and transfer large files and immediately thereafter take signups and money to access features) and what is not essential (automated password reset is a great example: you can do it by hand for quite a while, or similarly what bureaucracy and review can be replaced by something that doesn't require progress to stop and doesn't need other humans to change context to be involved).
I agree, people have this misconceptions of should I say misunderstanding of what MVP means. MVP essentially doesn't mean cutting short the functionality what it means is you only ship one important feature which actually works. Also once you are done you don't reach out to high valued customers on day 1 of launch, you do a soft launch and get the issues and fix them. Again launch early doesn't mean a month or two. It's always relative. Glad that things have worked out for you. Good luck with growing your product.
Well said. I 100% agree with your second point. Don't ever reach out to high valued customers if you aren't sure your product is very solid. Second chances are hard these days so we were lucky
Your description is more like what advice "do things that don't scale" means.
OP followed advice "launch early" and launched too early.
This comment was deleted 3 years ago.