Joe Stump on Why a Minimum Viable Product Design Strategy Works

In Chapter 16 of 17 in his 2011 Capture Your Flag interview, Internet entrepreneur and SimpleGeo CTO Joe Stump shares why less is more when designing and building consumer Internet products. He takes a minimum viable product - or MVP - approach to release products with core features and build on them after initial feedback. He contrasts this with taking an approach that layers on non-essential features that dilute user experience and core feature functionality. He notes Apple and its initial iPhone release with roughly six apps. Stump is the co-founder and CTO at SimpleGeo (www.simplegeo.com), a San Francisco-based mobile location infrastructure services company. Previously Stump was Lead Architect at Digg. He programs in PHP, Python, Django and enjoys scaling websites. He earned a BBA in Computer Information Systems from Eastern Michigan University.

Transcript:

Erik Michielsen:  What have your experiences taught you about what makes a product great?

Joe Stump: Every interaction that I have with a product, I look for two things.  I look for the way in which you use the product needs to be blatantly evident, right? I feel that a product has failed if you have to read the instructions.  If you have to read the manual, other than assembly, obviously, you have to use the manual to use a product for its core feature, it’s failed as a product.  

And the other thing I look for in a product and product interactions are when a product does something in a way that is frustrating or requires more effort than it should, particularly when there is better technology.  A good example are doors, right? As a computer geek, it drives me insane that I still have to have a key and actually turn the key and open the door handle.  We’ve had automatic doors and RFID for a decade now.  Why can’t I just walk up to the door and it opens?  Like, I want my Star Trek doors!

So, I think those are my day-to-day interactions and what shapes product for me are one, because of those things, one… I try to pair a product down – when you first start and you have an idea for something, you’re like, “Oh man, it would be cool if I had something that did X.”  But by the time you actually launch that product, it does X, Y, Z, 1, 2, 3.  And the iteration of the product should only launch with just X. It should do X and do it very, very well, and then you layer on features from there.  

Apple is amazing at doing this.  You know, the first iPhone launched and I think it had one home screen and six apps, right? The world has changed.  But they paired it down to it’s most minimal, core feature set, people still loved it, people still used it, yeah there were issues and we’ve come a long way. When I launch and work on products, launch it with one great feature.  The founder of Instagram has a great quote that all great products started out as a feature. T

he other thing that I do with product and is something that if you go back to the key analogy, I won’t put a feature in a product unless it’s perfect.  So, a lot of people will treat features as a checkbox.  Like, “Oh, yeah I can upload user photos.”  But if uploading user photos is a draconian, terrible experience, I’m not going to add it.  I’m going to keep working on it, and keep working on the UI [user interface], and keep working on the technology till it gets to a point where it can pass “the mom” test, and then it’s a feature ready to be added to the product.

I think where people get things wrong too often is they treat the feature like a checkbox and feel like the product is better because the feature exists, even if the feature is poorly implemented.  And I think the reverse is true.  I think the product is actually worse because people are now being trained to use a crappy feature in a crappy way and if you even tried to fix the feature, they’re going to get angry that you changed the feature.  So, my approach in that situation would to just not have the feature until it’s fully baked.