The problem with a Lean Startup: the Minimum Viable Product.

On November 21, 2012, in Startup, by Paul Kortman

I’ve been struggling lately. I’ve discovered that others are struggling with the same problem too, so I needed to write about it, for me, and for those whom I’ve discussed this with.

I’ve been reading, discussing, and learning the Lean Startup Methodology for the last 3 years now. When most people hear the concept of Lean Startup, they think bootstrap startup, ya know lean on funding. While this isn’t always true it’s suprisingly still prevelant thinking. Perhaps Eric Ries should have done an MVP of the movement’s name and received some user feedback on it before writing the book.

The basics of the lean startup philosophy are to get user feedback, do user testing, and discover if people are willing to use (and pay for) the product you are creating both before and throughout the creation process. It’s called lean not due to lack of funding but due to efficiencies inherent in the process. It’ll cost well over $60,000 to build anything of value (app or physical product). Most often ideators (co-founders) will donate their time to the development which brings down the hard costs, but does not effect the cost of those hours given. Lean Startup philosophy asks: What if you found out that people didn’t want this product after only spending $500 versus spending $60,000 (in time and money). That’s where the lean (efficient) comes in. Lean Startup: Minimum Viable Product

So the theory of Minimum Viable Product (MVP) is born. We all understand what Product means, and Minimum makes sense: what is the bare essentials that you can get away with?

But Viable. That is the issue.

Eric Writes:

“The idea of minimum viable product is useful because you can basically say: our vision is to build a product that solves this core problem for customers and we think that for those who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go. So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.” source

How much do you need to solve of the core problem to be “viable”? For example to solve a dating issue by creating the next

  • Do you need profiles?
  • Do you need a matching algorithm?
  • Do you need a date idea generator?
  • Do you need user feedback/ratings/reviews?

At what point does this become Viable? When do you have the Core built to say yes our early adopters will forgive us and we can hold up a tent with these poles we have. Who is the judge of this?

The key with MVP is that you iterate and test. You need to get a feature out in the wild and find out: Do people want this? Does it solve an issue? Will they use this? Find out the answer and either fix/improve the feature or add on another feature that continues to solve the problem. Do this cycle a few times and perhaps then you have a viable product? How many cycles till it’s viable, and haven’t you already been launching MVPs, yet they’re not “Viable.”

When is an MVP Viable?

That is the question I have been struggling with on ThingShare all summer. We built an MVP to test if people would want to use it, if they’d like it. Yes we invested more than $500 in both time and hard costs, so perhaps we went to market with more than a minimum viable product, but I’d argue that we went to market with smoke and mirrors.

I’ve been waiting to write this post until we had two more features implimented (just last week) because as Joe (my co-founder) and I often discussed there’s a cliff in the process inside ThingShare and we’re pushing our users off this cliff. “Oh you didn’t have your own parachute?… Sorry.”

That’s what MVP means to me, smoke and mirrors.

Can you sell a product to people before building the product? Can you convince people to use a car with no brakes or no steering wheel?

Yup, we’ve done that.

Success! We’re a Lean Startup.

And somehow I’m not okay with this. Strangers who use ThingShare to rent video games are now my friends and I have had to appologize to them for our lack of product completeness. Then it gets even richer: The users suggest features which already are on our roadmap but were cut due to the word minimum.

Rubber meets road in Lean Startup:

An Example Minimum Viable Product Process

ThingShare is a peer to peer video game renting platform. At least that’s the vision for it. I could argue that it still doesn’t “work.” But I’ll let you push it around and find the dark alleys of where the site breaks down.

The first MVP we launched with was a signup form, could we get 10 people to signup.


Next iteration was being able to list your video games and gear, could we get 10 people to list their video games and gear.

Check But how strange, we now have over 30 users and yet you could do nothing more than list video games and gear you owned… some rental site this was! It could be argued that our initial users signed up because they felt safe showing their Games & Gear to their friends. Check and fail. You couldn’t even rent a game yet. So how was this site viable? I argue that it was indeed not viable. It was an iteration, a test in the Lean Startup style, but viable it was not. Yet users were still signing up and listing their stuff.

So we added the ability to rent something (and a bonus wish list, public profiles, and all kinds of other goodies) We asked the question again: Will people actually use this?

Check! they sure enough did, about 20% of our user-base tried renting something. Can I emphasize that they tried, but we pushed them off a cliff. You see we were testing if they would try to rent a game, We weren’t testing a user to user messaging system, or an item checkin-checkout process, just “will users actually try and rent a game?”

Thus if in those days you tried renting a game you’d receive an email saying “Congrats! your rental of Assassin’s Creed 3 has been approved! Connect with the lender via Facebook to work out the details.” User? Meet cliff, here let me help… *shove*

Turns out Facebook has a spam filter and if you try to send a message to someone whom you’re not friends with it ends up in their “other” box and they never see it :(

So our earliest adopters, the people who trusted us, we pushed off a cliff in the name of Lean Startup. What am I supposed to tell them… “Sorry it was an MVP?”

Last week we added a messaging system, and a check-in/checkout process. The next iteration. Our users have already thanked us, and have suggested the next couple of features (which we had already listed on our internal road-map).

At what point does our product become viable?

  • When we reach critical mass?
  • When we have no other features to build? (ha that’ll never happen, I’m a visionary don’t you know)
  • When we bring in revenue?
  • When we make profit?

Definition of Viable: “capable of living” source. Uh, well I don’t exactly want Frankenstein’s Monster. So at what point can a platform sustain life? And did we “launch” too early?

No answers, just questions. Questions to test and iterate on.

Tagged with: