Agile Zone is brought to you in partnership with:

Mitch Pronschinske is the Lead Research Analyst at DZone. Researching and compiling content for DZone's research guides is his primary job. He likes to make his own ringtones, watches cartoons/anime, enjoys card and board games, and plays the accordion. Mitch is a DZone Zone Leader and has posted 2578 posts at DZone. You can read more from them at their website. View Full User Profile

Lean Startup: Should You Really Get the Product Out as Quickly as Possible?

  • submit to reddit

Steve Blank was one of the first people to form the Lean Startup approach in his book, "The Four Steps to the Epiphany."  He recently had a discussion that was recorded with .  The details can be found in an article on Inspirationfeed. 

What I wanted to examine was the Lean Startup principle of launching the Minimum Viable Product (MVP). 

Rather than putting products through year-long testing phases, Blank suggests that startups develop a minimum viable product (MVP) and get it to market as soon as possible. This approach will accelerate the testing phases because startups can continually make changes to the MVP as they produce it. This also allows startups to make the necessary changes to the MVP before it becomes too costly.
--David Schmidt , Inspirationfeed

Just the other day I saw a developer comment complaining about the "go fast and break things" culture in many engineering departments these days.  Technology choices have a tendency to stick around longer than anyone expects, so the short-term decisions end up becoming the foundation of a project.  If the choice isn't the optimal one for a long term foundation, it's nearly impossible to go back and rebuild the core of your work.  That's why some engineers fiercely in favor of "over-engineering" and the year-long testing phases that Steve Blank criticizes.  

Of course, the assumption and hope is that your startup will be lean and agile enough to quickly rebuild things from scratch if needed, even if that thing is now bringing in revenue with customers relying on it.

What are your thoughts?  How do you balance the MVP approach with over-engineering?


Ian Mitchell replied on Mon, 2013/07/29 - 9:40am

> How do you balance the MVP approach with over-engineering?

I'd say that you can't balance them, given that the MVP is determined by business stakeholders, while the "over-engineering" you describe is driven by concerns for technical excellence and due-diligence.

However, perhaps we can change the question slightly, and allow a better comparison to be made. To do this let's remember that the MVP is a subset of business functionality, and not just a business model with some implementation and architectural considerations thrown on.

If the "Minimum Viable Product" defines the most basic level of acceptability, it implies that there are additional features which would truly delight the customer. Yet if we pursue them, we will have gone beyond that MVP, and we will have started to "over-engineer" the feature set.

So here's the question I would ask:

How do you balance the MVP approach with "customer delight"?

Steve Denning has made the case for "customer delight", and it has been posited that organizations falling short of this lofty goal are unlikely to survive. Yet if that is true, what does it mean for the Lean Startup model, and for the launching of MVP? Are such initiatives doomed to fail, while others "delight" the customers with a full-on feature set?

Part of the problem is that we are struggling with mixed messages. CEO's are sometimes too slick for their own good. They'll talk about the latest craze they've heard about in the business class cocktail lounge. They'll talk about "thinking like a Lean Startup" and "delighting customers" in the same breath. "Which is it?" is the question Agile teams ask as they stare at their Product Backlog, and the lack of a cogent answer will leave them floundering.

Robert Brown replied on Wed, 2013/07/31 - 10:47am

IMHO, MVP and Engineering do not have to be at cross purposes as long as you make sure everyone understands the following sentence:  Viable is just as key as Minimum.  Defining what is Viable is the tough part.  What winds up happening is that the business unit usually doesn't have the same MVP in mind.  For example:  If you are implementing a system that will need to have high security, the Viable portion of MVP should say that high security is part of the initial product.  An MVP release that has no or very poor security is not a Viable product.  Yet many developers and business owners would use Blank's reasoning to say that security can be skipped or not developed well because we need to go fast.  I run into it all the time, is a product viable if it will take a rewrite to implement a feature that will be needed in the near future?  

What I usually find is that MVP to a business unit means a UI that is complete but doesn't necessarily work well.  While Minimum to an Engineer means a single feature set that works from UI to DB but may not have other features.  When Blank says an MVP I'm sure he means the second one, but many people seem to take it to mean the first.  


Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.