I feel like sometimes people confuse Minimum Viable Product with Minimum Sellable Product. That is, MVP is not about building the smallest thing that someone will pay you money for. It's about cutting out all the pieces that might fall onto the 20 side of the Pareto principle. It's about resolving any 50-50 decisions by picking one way and going with it, instead of quibbling over which way is the best ("Don't let the perfect be the enemy of the good" sort of thing). It's about making every really difficult design decision answer the question "do we really need this feature? right now?".
If I can take you back, you might remember that the first iPhone didn't have a customizable home screen or a unified inbox. It went with "The Web is Your API" instead of native apps. It didn't even have copy-paste!
That said, if someone handed you an original iPhone, it is still very recognizable as an iPhone. It still took YEARS to iterate internally and reach that first model iPhone. From friends who've worked on the iPhone, I've heard there were something like 5 unreleased precursors to the iPad. That's right, the iPhone was actually the MVP of the iPad.
So, MVP doesn't mean you don't have to work at it. It doesn't mean that it won't take a lot of time to develop internally. At CodeConf, Wil Shipley said to think about it as Minimum Viable Awesome. MVP is about recognizing which decisions are best made by the engineers and product managers, and which are best made by the customers. Your MVP shouldn't be the first thing you can charge money for, it should be the first thing you can charge money for and feel proud about.
Your examples just show that your first sentence is wrong :) Actually, MVP IS about building the smallest thing possible that someone would use - paying for it or just using the process - and it's not about 50-50 decisions.
The idea behind MVP is simple enough: market response is more important and more accurate than anything you can ever do yourself - so the most important thing you can do is get it. The best way to get it is be out there fast, however - in order to get something that's worth something you need to give something meaningful (value) - and the result is the MVP.
MVP doesn't mean you don't have to work at it - it means you have to THINK about it a lot.. and be very connected to your market.
As we seem to be allowing a personal bias, I'll submit my MVP - http://bugmuncher.com
I've built the minimum in order to get it live in 2 weeks. I've got a HUGE list of features to add in future, including customisation, multiple highlights, automate the subscription process, API, etc.
Hey no problem with sharing your own as far as I'm concerened. Looks like a great MVP and I'll be interested to see how your own feedback leads the direction of any future features you have planned.
The front end tool is built in JavaScript with jQuery (but it's safe to use with other JS frameworks). The website and processing side was built in PHP/CodeIgniter, running on a linode VPS.
Have you checked out the interview with Jerome Breche on Mixergy? Your product sounds a lot like what he started off building (Snap-a-Bug) and then he pivoted to start snapengage.com
It's a great story, you should check out the interview.
Please hire a professional designer to redesign your website as soon as possible and ditch this ThemeForest theme. I see it everywhere now and it looks forced.
For the record, I used the exact same theme when I launched my product, but quickly ditched it.
I actually think that design looks really good - don't forget, people that read HackerNews may be more inclined to see these sorts of themes around (as they're usually used by people just launching a product to see if there's any interest). Most users might not see the same theme that often, if at all.
I think the Hacker News people are probably the target audience for BugMuncher. But in any case, the design is fine. I'm actually impressed it was only $20.
Well, I'm obviously pretty biased here because I made it, but I really enjoy using http://cueyoutube.com/
It was a "sunday night" project, and the first thing I've ever done where I thought I did just the right amount of work and no more. It hasn't, like, gone viral or anything but has a few likes and a few people using it - who knows maybe some more will use it.
But it was a great feeling - to really get something useful made, throw it out there and see what happens without investing a whole lot in it.
Another I made earlier this year was http://pickdropapp.com/ which was even less successful than cueyoutube :)
I find that whipping up things like this and just releasing them is a great way of "staying in shape". Releasing software is like a habit and the more you do it, the easier it becomes.
To deviate from my shameless self promotion, I would also like to add that I love the story of TKs http://toutapp.com/ - he's actually turned that into a real product now with thousands of users, but he got a lot of validation from his initial MVP release so that's a real success story. He's written about it quite a bit on his blog.
For cueyoutube - there's no backend! It's just a static page with some JavaScript on it (mostly jQuery but totally hacked together because I can't stand JavaScript :)
I actually copied and pasted most of it from other sources (which I've listed on the page).
The playlists are "saved" by sharing them - each playlist exists only as a URL containing a comma separated list of video IDs.
I've been sharing on Twitter using the #cueyoutube hashtag.
Unfortunately, however, my primary webserver is down due to a drive failure - I'm waiting for the VPS image to copy to a new host now. Bummer :( Should be back up in about an hour with any luck.
I really want to only work on the site in response to user demand, you know? Like I want to keep it as an MVP always. If people like it, then they will use it and make suggestions and I'll react to that.
I'm really enjoying the "throwaway" nature of the playlists themselves (ie. you don't login, you don't give them a name, you don't "save" them, you just create, share and move on with your life), but also the "throwaway" nature of the project - it's good to have something that's useful but that I'm not so heavily invested in (unlike Decal, which I'm like, totally invested in to the point of insanity).
Why code a back-end if you don't need one? You can get away with a lot more than you think you can just with a static page and the browser. With hn-books the book list exists as a static JSON file. I can put my entire site on any kind of web server -- even run it easily offline.
I said the same thing when I first had the link forwarded to me, but watch the video. The U2 spy plane serves a very important role for the airforce, but can't land or take off on its own.
This is a great example of designing something with an extreme focus on achieving its purpose while ensuring any necessary, but non-core functions are only minimally included.
I'll be absolutely shameless and plug our two services, Momentomail and Wormwall (http://www.kymalabs.com). Momentomail is a bit more mature since it's older. But when we first launched it, the entire site wasn't much more than a login page and the "Schedule an email" interface.
We made Lifehacker (after only adding a couple more things) not too long after that.
Wormwall likewise is about as basic a web authoring system as you can get. A WYSIWYG editor and a publish button. Nothing fancy.
If you discuss MVP in terms of Customer Development and the Lean Startup methodology, I think that Eric Ries puts it best by saying that whatever you, as the entrepreneur, think the MVP is, is already WAY too big. Whatever you think the minimum viable features are for your product/service, you should cut it in half - and then do that 2 more times. That's your MVP.
I think that's one of the most important things about MVP - don't bother automating processes until they are actually taking up your time.
As a consultant I see a lot of people put way too much effort into developing bespoke software to automate or "improve" workflows that don't even really exist in their business yet, only to find out that the real bottlenecks exist in places they never even knew (and that they've wasted a bunch of money building something they'll never really use).
It's like a "real life" analogue of the adage "premature optimisation is the devil".
Similarly, we started out in my cofounder's grandmother's house and ran our original site on a $20 shared host running a horribly unstable cgi-bin with perl. My cofounder took calls and fulfilled orders himself.
Since we're including our personal projects :-) I built the Birdy over a weekend. http://thebirdy.com A couple weeks have gone by and it's going strong with hundreds of users. I've added a few features, and fixed a few bugs, but otherwise, it's as I built it.
There were 4 features that are necessary for the app to do anything:
1. Create a poll
2. Pick a number
3. Process SMS msgs
4. Show results
For this first release, I didn't do anything outside of those 4 features. Soon I'll be adding the ability to open and close the poll by SMS, get results by SMS, and many more things, but for now it is "done".
I think most great examples of MVP are pretty invisible because you are typically starting off testing it with small groups of users -- just enough to get feedback to move it to the next stage. Otherwise it isn't the M in MVP -- It's not the minimum.
We are big fans of using Dave McClure's Pirate Metrics model... building activation first, then retention, and then going for acquisition, etc.
The first version of CoderBuddy was very minimally-viable compared to where we're at today. It was enough to get something done and to use in workshops. Since then we've analyzed where the biggest bottlenecks are improving activation etc., along the lines of the Pirate Metrics model.
I think my lil mac screen capture app is actually a pretty good example, originally in v1 it only uploaded to imgur and had no UI except for the menu. V2 I added advanced features like a preferences window and history.
While building this I did try hard to focus on what I could do to ship right away, and nothing more. Even for v2 I had to concentrate on limiting the features, which was quite the challenge. At this point, I cant even remember half the things that I needed to implement.
Same things we did too:
v1 just simple screen shot for mac
v2 screen edit functions
v3 version for win with edit
v4 personal profile with history
v5 easy-sharing
I consider my service, Subjot as an MVP but we're just starting to move beyond that. Since branching out on my own, its the first product I've built that I'm moving beyond the MVP.
Why? 68% of all registered users visited Subjot last week. Our total number of users are still small (private beta) but our engagement is very high.
It's in private beta but you can use this code to check it out if you are interested - http://sjot.it/nXM96E
My favorite examples are where the product satisfies its objective (fulfills the customer need) AND does it does it better than the competition (via user experience, number of features, visual design, speed, cheaper). Often people create an MVP that fulfills a customer need but is worse than the competition. Every metric will point toward the fact that the MVP failed since they are based on product market fit (PMF).
It might have started off that way. I didn't download it until recently. But nowadays it has all sorts of social networking features I think would disqualify it from being an MVP.
The purpose of an MVP is to quit screwing around with maybes and some-days and get moving.
Also, expanding is often not so good a thing as refining. It's usually better to have one or two features which are well-refined versus a great many features which aren't well-integrated and which you lack the resources to support.
86-DOS, aka Quick and Dirty Disk Operating System, which was sold to MicroSoft famously, was designed to duplicate C/PM's operating system API's. As the story goes, all the money was in the hardware as software so easy to copy. Look up the history of FCopy on the C64 to see just how prevalent it was on the much higher volume platform of the day, Commodore.
Another shameless plug: ShelfLuv.com The original version of ShelfLuv was just instant search for Amazon books - nothing else - wrapped in a pretty UI that was done at a hackathon. It would have stayed just that had people not started using it and validating the idea that there was something there and people valued a better UX for searching books.
As has been discussed, MVP can have a varying definition. If you take the minimal part very seriously, one of the products I love to reference is: http://notepad.cc
Zappos started as a website with pictures of shoes and a price. When someone would order, they would go down to Footlocker, buy the shoes, and ship them off.
This is great. I have been trying to figure out what a MVP is. Is a landing page with a description of your product and a sign up form considered a MVP?
No, that would be more like a dry test. They serve similar purposes in some ways, very different in others.
Tim Ferriss is very keen on dry testing - see 4 hour work week.
:) Above and and beyond my friend. Thanks to everyone for all your help, feel free to keep adding to the discussion I'm checking out each and everyone.
I feel like sometimes people confuse Minimum Viable Product with Minimum Sellable Product. That is, MVP is not about building the smallest thing that someone will pay you money for. It's about cutting out all the pieces that might fall onto the 20 side of the Pareto principle. It's about resolving any 50-50 decisions by picking one way and going with it, instead of quibbling over which way is the best ("Don't let the perfect be the enemy of the good" sort of thing). It's about making every really difficult design decision answer the question "do we really need this feature? right now?".
If I can take you back, you might remember that the first iPhone didn't have a customizable home screen or a unified inbox. It went with "The Web is Your API" instead of native apps. It didn't even have copy-paste!
That said, if someone handed you an original iPhone, it is still very recognizable as an iPhone. It still took YEARS to iterate internally and reach that first model iPhone. From friends who've worked on the iPhone, I've heard there were something like 5 unreleased precursors to the iPad. That's right, the iPhone was actually the MVP of the iPad.
So, MVP doesn't mean you don't have to work at it. It doesn't mean that it won't take a lot of time to develop internally. At CodeConf, Wil Shipley said to think about it as Minimum Viable Awesome. MVP is about recognizing which decisions are best made by the engineers and product managers, and which are best made by the customers. Your MVP shouldn't be the first thing you can charge money for, it should be the first thing you can charge money for and feel proud about.