How To Create A Minimum Viable Product

Editor’s note: This is a guest post by Emre Sokullu, founder and chief architect of GROU.PS

There’s been a lot of talk on the concept of minimum viable product lately, but not much has been written on how to actually implement one. Having gone through the process of developing one of the earliest social software mashups (GROU.PS) in PHP six years ago, and LoveBucks, a node.js Javascript app that is the Facebook “Like” Button for online content monetization (both alone), I want to describe to you a little bit what has really changed in web application development in recent years and the beauty of minimum viable product.

1. Build it on Facebook Platform

Don’t build your membership stack from scratch, let Facebook Connect handle it. Not only will that provide a better and more straightforward experience for your users, but it will also save you a ton of time and messy product decisions. You no longer have to mess with sessions, logout scenarios, collecting information about users, and probably most importantly lost passwords and spam accounts. Unless your product  is focused on the Chinese market, I don’t see any reason for not using Facebook Connect (1/3rd of the world, including China, uses it obsessively every day). Those who don’t use Facebook would probably not be your target audience anyway; after all, non-Facebook users are late adopters and conservative in their selection of new web apps. And don’t forget, Facebook Connect now lets you capture the emails of people using your service.

2. Use bootstrap.js

If your product starts life as a web app, chances are you may not be able to create a mobile experience from day one. But if you were to build it on bootstrap.js, the user experience on both mobile and desktop would be so linear and seamless that you could get along well enough by just having your users bookmark your site on their mobile devices so that they can use it like a mobile app. Hence, I call bootstrap.js a good way to show some steam on mobile without really investing in it. It also saves you a ton of work in CSS through its pattern templates.

3. Use Cloud, Scale Out

Without a doubt, cloud is easy and cheap. git + heroku + a mongo/riak host would save you a ton of time and money because you pay only for what you use. Scaling becomes much, much, much easier. I remember going through the phases of replicating our mysql stack at GROU.PS, putting a memcache layer in front of it and eventually sharding it – which was the most cumbersome part of all. It was hard. Bringing an expert on board costs a lot too.
Note that as you scale out though, the benefits of cloud decrease and it becomes an expensive solution. It’s important for you to know when to stop scaling through cloud, buy your own hardware for bare traffic and keep the cloud in place for excess traffic only (like Zynga does). To put this in perspective, think about how much you’d pay if you were an Amazon S3 client and you had to push about 1 petabyte a month. The answer is $50K (been there, done that). That’s probably a just portion of what instagram is paying right now to Amazon. It also justifies Adam D’Angelo’s explanation on their use of new funding at Quora.
At LoveBucks, we use heroku. Not only is it easy, cheap and fast to get started, it’s also acceptably reliable for a consumer web project, being a part of Salesforce and built on top of Amazon S3.

4. Beauty of jQuery

Bootstrap.js depends on jQuery. But that’s not the only reason why you’d want to use jQuery. If you’re old enough, you should remember having to choose from prototype, jquery, moo and a bunch of other libraries in the early days of web 2.0 . Well, now the competition is over and the winner is jQuery. jQuery is cross-browser, easy, beautiful, extensible and has a huge community. “DHTML” tricks are now so easy, compared to early days of web 2.0

5. Focus on core functionalities

Perhaps the biggest mistake I’ve made at GROU.PS at its initial phase was to add way too many features onto it. Sure, it made a lot of headlines in the web 2.0 community, but frankly thinking back, what I should have focused on was collaborative blogging (with ability to fetch RSS from external blogs as well as a built-in blog engine), plus email list sync’d blogging. These two were both large opportunities and GROU.PS would still be a unique value proposition with just these two. Instead, I added links (which was delicious, reddit) wiki and so on. The result? An unstable product which was trying to do too much and poor user experiences due to an overwhelming set of functionalities. (Of course this was back in the day, I can assure you now that GROU.PS is a very stable platform). It always makes sense to start simple. Don’t forget both Dropbox and Google started out as very simple products and they haven’t changed a bit in their UI (note: consistency) for a very long time.

At LoveBucks, we had the option to give people a lot of options with the amount and distributions of their donations. But we didn’t. We focused on the distribution of rewarded cash from consumers to publishers instead.
Another thing you may try for features that you believe might attract a lot of attention, is to create non-functional links, and when someone clicks them, a page with a counter is shown where it says “the feature is currently under development and check back soon”. This way, you can see how many pageviews the feature gets, hence its potential popularity. From there, you can decide on whether to invest in it or not.

6. SaaS is your best friend

Best thing with SaaS is that there is no upfront commitment and you don’t have to deal with maintenance or anything like that. It saves you valuable resources. Some of the services that you’d definitely want to use are:

• Chargify, Spreedly, Recurly, CheddarGetter for billing: Believe me, billing is not easy and you want one of these guys to handle cancellations, trials, upgrades and downgrades. Otherwise, it’s too much math for a resource-hungry new app. When the time comes, you can always migrate to authorize.net (as long as you use it as the backend) for everything, because these guys are using authorize.net‘s APIs too. The benefit; you don’t have to create payment pages, implement logics to evaluate coupons and stuff. At GROU.PS, we used our own payment pages, and frankly, maintaining them is messy, albeit the flexibility has its own advantages such as further optimization, but using hosted pages of Chargify (which we used at LoveBucks) have literally saved us weeks in development.
• LiveChat, olark, Zopim, LivePerson, SnapEngage: Again, customer support chat is not something you want to develop or maintain on your own, even if your app itself has support for chat. The reason? Because customer support chat is different by nature (one to many, operators, canned responses, logging), plus you don’t want to mix things up. Best example is GROU.PS. At GROU.PS, we provide our groups with a nice chat service, and we’re masters of ejabberd, yet we’ve decided to go with LiveChat because otherwise it’s just a big headache.
• Wufoo, Google Apps: There will be a lot of times when you’ll need to collect information from your users, have them upload files, and even sometimes have them pay you. In those cases, it makes a lot of sense to use Wufoo. At GROU.PS, when we were facing the challenge of whether creating a new form for our Valet services on our own or just outsourcing to Wufoo, we chose Wufoo, because it’s an investment where we have no idea about its return, therefore it’s much safer to do it with wufoo (for as low as 20 bucks a month). Plus, the UI that wufoo provides is so beautiful, in fact, there’s no sacrifice at all in terms of user experience; hence Wufoo might be your answer for any type of form related work.
• Kissmetrics, mixpanel: At GROU.PS, I remember investing months in enriching our analytics infrastructure, installing Thrift and Scribe for eventually consistent logging and building a Hadoop base to analyze all that data we collect. Well there’s a much easier way now. Just use kissmetrics or mixpanel and with just a line of code on HTML or your server side code, you’re able to analyze anything that’s going on your web site. Andthey enable anyone on your team (who knows how to add a code snippet) to research what they’re seeking instantly. Again, thanks to beauty of cloud.
• ZenDesk, desk.com: Customer support help is another thing you definitely need from day one no matter what your service is about (especially in day one, because your first users are the most valuable ones, you definitely want to hear their feedback) so you definitely need a platform to take care of that. My recommendation, don’t do it over email, because you want your knowledge base form from day one, your future customer support team see the style you answer questions in your early days, hence you’re better off paying a couple of bucks to ZenDesk or desk.com for this service.
• GoodData, RJ Metrics: Good product decisions require data. And investors want it too. So don’t neglect data collection and analysis. The best part of GoodData is that it’s integrated with a bunch of services I mention here as well as Google Analytics, hence it can bring you great charts like “average life time value of your subscriptions” or “customer support average response time” in a snap.

7. Use Scribd to host paperwork

This is perhaps a minor point, but for legal boilerplate that’s sent to you from your lawyer or fetched from somewhere, don’t lose time converting into a page on your web site. Just use Scribd, grab a widget with your doc embedded, and put it somewhere on your site. Again, this is a minor point but thinking along these lines gives you a good idea of what you should outsource and what you should focus your efforts on building.

8. A video is worth 1,000,000,000 words

Don’t use pages, tour sites, or heavy javascript demos to explain your product. Craft your message carefully and then create a video, that’s it. If you’re on budget, you can do it on your own but I strongly recommend you to work with a professional on this one. Some of the services are Grumo Media, Epipheo Studios, and wdysd, and the budget changes from $3,000 to $40,000. (for a full list of video production companies, see Quora)

9. Short on time and money? Drop Internet Explorer

OK this was already covered on Techcrunch, so I won’t go into too much details here. But if you feel that you’re short on cash and time, don’t waste your time with Internet Explorer, the most incompatible browser of all times. Don’t forget now Chrome has more traffic than any other browser + users of Internet Explorer are usually not early adopters, hence it’s very unlikely they’ll stick with your service anyways. You may gently warn them to switch to Chrome or Firefox to continue to your web site.

10. Spread it over time

Some features are not required from day one. Change plans? Cancel subscriptions? Add billing info? Those are things people would need as they use your service. So to get to your launch fast, don’t waste time building these, just link them to mailto:you@gmail.com and take care of those handful of outliers manually. As you see traction, you can build them.

Results:

The first version of GROU.PS took 1.5 months to develop and you can see the result in the image above (please evaluate it by the standards of the day).

As for LoveBucks, it was created in 2 weeks. Its database is already more than 1GB large, we grew to serving from 0 to more than 45,000 people daily with no hiccup. We were able to do this through cloud and the minimum viable product best practices I specified above.

A note on node.js

One thing you want to avoid; don’t always go for the hip, new technologies, especially for your infrastructure. At Lovebucks, I’ve used node.js for the backend due to its event-driven non-blocking nature (which is a must for a button product that aims to take over blogs, wikis and social networks) and the beauty of using the same language for both backend and frontend. But it turns out it’s too unstable – the multicore processor support was just added recently, API breaks frequently and worst of all libraries are even more unstable. Also consider the language that people around you (where you’ll develop your product in the next few years) know, because eventually you’ll need to hire. For GROU.PS, it was hard to scale the team for a while, because developers in Turkey (where most of our development is done) are usually only familiar with Microsoft technologies and Java, and not PHP, the language GROU.PS was developed in.