Developing the Minimum Viable Product

Developing a product is a perpetual trade-off. There is always competition between the desire for greater functionality and the push to launch quickly. A critical part of the product management process is deciding what features get prioritized for launch and which get pushed to the back burner for a later date.

4ormat minimum viable productA recent article on Techcrunch caused a stir: Bootstrapped Startup Saves over $100K by Dropping IE. The founders of decided they didn’t want to code their app for Internet Explorer, so IE users who try to sign up are pointed to download pages for Firefox, Chrome, and Safari.

I bring this up not to call attention to my own recent comments about IE, but rather to highlight the thinking that went into this decision for the business owners. This was very clearly a product decision in that it was defining the scope of their product’s features and the work required to build the application. But it was primarily a business decision. What was the cost (in time, money, and resources) to make everything IE compatible, and how did that measure up against other priorities?

All product decisions are business decisions.

Making the UX better is a business decision; it’s an investment in the customer’s experience. Excluding browser support is a business decision; you’re sacrificing audience size for faster time-to-market. You can’t define and build a product without taking into consideration how it fits into the overall business strategy.

With that in mind, how do you figure out what is necessary to launch? What is your minimum viable product?

Focus on the Core Value

What is the true value of your product to the consumer? Focus on developing the core feature that makes your web site attractive and leave the bells and whistles for later.

For example, take Sparrow, a mail app for Macs. Sparrow recently launched an iPhone app. For those who use and like the desktop client, the iPhone app is a great brand extension. However, it doesn’t yet support Push notifications. You have to actually open the app to see if you have mail. The lack of push notifications may have kept some customers at bay, but the real value of the Sparrow app is it’s UI. There are plenty of people who want the app and don’t care strongly about the missing feature. (As of now, the app has over 2,600 review in the App Store.)

A side benefit of putting off non-core features until later is that you will have a reason to make more big announcements in the future when you launch them.

Make the User Experience Good, not Perfect

It’s important that the user interface be intuitive, responsive, and clear. But you could easily spend days, weeks, or months tweaking details in an attempt to get it “just right.” Stop it. There will be time after launch for more testing and refinement. In the short term, worry about making it really good, but not perfect.

Keep Your Business Goals in Mind

It’s incredibly easy to get distracted, but¬†everything you’re doing should work towards the goals of your business.

Let’s imagine you’re starting a B2B enterprise app, and you someone sends you an article about the value of social media integration and building for viral marketing. You may look at your product and think it doesn’t have enough tweet and like buttons, but before you make your designers and developers add them to each page, think of how your business is going to operate. Your marketing strategy will probably involve lead generation and a dedicated sales force. Social media is a great tool, but is it worth taking a few extra days to change your product? Maybe not.

The bottom line is that you can have the best idea in the world, but if you’re late getting it to market, you lose. Focus on building the product that best delivers your core value in a strong way. You can always add more bells and whistles later, and it’ll be much easier to do so after you have customers and money coming in.


  1. Sara Root says:

    Great points about balancing speed to market with feature overload. But I think the bigger issue in these situations is the lack of clarity around ‘definition of done’ and overall project scope. If there is alignment from the outset, these questions around what’s in and what’s out should be determined long before a delivery date is given. Scope changes are fine, but it’s how you communicate the tradeoffs ( as you outlined, time, money, resources). Too often, we haven’t communicated the resource constraints that went into setting a launch date to begin with.

    • That’s a great point Sara. Planning before anything else is vital, and I think that the planning stage is really the best time to consider all of these factors. Much easier to work it out at the start rather than keep course-correcting during development. That saves time and money. Of course, there will always be inevitable issues that come up, but good preparation makes it much easier to deal with them when they arise.

What do you think?

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>