Many startup founders (or corporate innovators) have an issue with the concept of an MVP. The definition of a Minimum Viable Product varies greatly – but in the purest sense, it should be “the least you can do”

For example, I co-founded a startup in 2009 with two ex-Yahoo colleagues. We’d started as a consulting shop focusing on delivering targeted IP for companies. Unfortunately, at the time, right after the great recession, very few companies were looking to expand their patent portfolio. We had a lot of trouble getting gigs.

At the time, Twitter had just launched, and it was super-hot. After looking at our dwindling funds, we looked at Twitter to see if we could do something to latch onto their rocket. They had just launched their open developer eco-system, and people were developing apps for Twitter like crazy. So we put our heads together and looked at a way to pivot to some service that would leverage this. We would also use the Lean Startup MVP concept to get a prototype out the door rapidly, then iterate and pivot to what our customers were looking for.

One of our team was really active on Twitter, and his biggest issue with it was that he would miss important stuff, as the Tweet streams went by so fast. If you weren’t online and watching at the time, you might miss something which you were deeply interested in. Twitter’s search was less than optimal at the time, so we decided to come up with a tool that could gather all of the tweets on a topic and present them in a way that the most important tweets would be highlighted.

Of the three of us, I was the only one with more recent coding experience, so I started relearning how to code in the hottest tools of the day, which was Ruby on Rails. It took me a few weeks to get back into the swing of things (before this, I’d only done functional programming, so there was a bit of a learning curve for me to grok object-oriented programming, but eventually, after reading tons of books and doing tutorials, the light dawned, and I figured it out.)

Around the same time, tools like Heroku and AWS were making it super easy for a startup to crank up a website in short order. Everything seemed to line up to get this product out the door and fast.

About 6 weeks later, we had a working prototype that did the barest of tasks: you would enter a search term and wait. Twenty-four hours later, you would be able to log into the service, which we called “tweebus,” and see a list of all the most important tweets, with the tweet and the payload (if any – links to external sites).

And I thought that is where we should have stopped and launched (I’ll call this Point A). But we didn’t.

We had some disagreements on the features and functionality. I wanted to get it out the door, but my colleagues disagreed. We had to add a feature to extract and preview links. We had to add a feature to allow customers to run ads. We had to add a feature to allow brands to “buy” their keywords – instead of looking through a stream of words, the word “beer” might be replaced with a Heineken icon (like a rebus – hence “tweebus”). We had to add a feature to allow websites to embed a “tweebus” stream into their sites. We had to add more finesse to the algorithm, which decided what was important (the original algo was on retweet numbers, factored by the number of followers that the retweeters had, plus some other secret sauce). This went on for a while until one of us ran out of cash, and he dropped out.

The two of us who remained kept going, finally launching it into the world (Let’s call this Point B). It stayed up for exactly a week, and my remaining co-founder said to take it down since it wasn’t getting any traction. We continued adding features, then my co-founder went off on a tangent, and we both walked away, needing to get real jobs again.

So you might think – maybe you should have stopped at Point A and launched and promoted it.

Or maybe we should have left it up longer than a week at Point B.

Both are wrong. We went about it the totally wrong way. If I knew what I knew now, I’d have done it completely differently.

Another way to describe an MVP is the “smallest possible step”. Here is an example of a better MVP:

Aardvark was a Q&A service like Quora that Google bought for $50M, then discontinued a few months later. Per Wikipedia:

Aardvark was a social search service that connected users live with friends or friends-of-friends who were able to answer their questions, also known as a knowledge market. Users submitted questions via the Aardvark website, email or instant messenger and Aardvark identified and facilitated a live chat or email conversation with one or more topic experts in the ‘askers’ extended social network. Aardvark was used for asking subjective questions for which human judgment or recommendation was desired. It was also used extensively for technical support questions. Users could also review question and answer history and other settings on the Aardvark website. Google acquired Aardvark for $50 million on February 11, 2010.

Here is the story behind the story: their MVP was no code at all. They threw up a site that captured questions; then, the team answered the background questions. They didn’t have to write a sophisticated routing engine, an IM client, or anything. They created an MVP which “emulated” the site that they wanted to build. If you want to be less kind about it – they faked it.

But the fake led to proof that the model worked – that people would ask the questions. People would USE the service. Once they proved that, they built the engine to create the full service. Cut to a few months later, and bam – a nice exit to Google for all founders. Sure, maybe not a unicorn, but enough to get to the next one.

This was our mistake with tweebus. We should have built a front-end that captured the query, then hand-searched the users’ answers and presented them. This would have proved demand for the service before we needed to write any code for it. If we’d put that up and promoted it, maybe we would have seen that there was little to no demand for it, and we wouldn’t have spent all that time and effort on it.

Actually, I did learn to code in RoR, so it wasn’t a total waste of time. But I digress.

The lesson here: think about the very least you can do to prove your idea before you write (or pay someone to write) even a single line of code. Prove that it has demand before you invest too heavily in the concept, launch it, and realize that, in the end, no one really wanted it after all.

Who knows how many of those failed startup founders out there could have been saved if they had just done the least they could do to prove the concept.