I was at a breakfast meeting yesterday and we got to talking about minimum viable product (MVP). I’ve written about this before, basically saying how speed of development and MVP are not synonymous. But the question arose: how do we know when we have a minimum viable product?

Before I answer that question, though, I want to make sure we all understand this incredibly important concept. A minimum viable product is the least development you can do to give your potential customers the idea of what you are trying to accomplish, what benefits this service/product might bring to them, and give you a feel for the revenues and costs associated with delivering the service/product. The point of MVP is to get those of us who are inclined to sit around the office and develop apps out of the office talking to customers.

Dropbox famously built their MVP as a video. I’ve seen paper reproductions and I’ve seen code. Sometimes wireframes work or a nicely mocked up PowerPoint presentation. Every one of these can get the idea across and get a conversation started. In fact I could easily argue that the less code you write the better off you are. [1]

It’s important to understand that most people can’t imagine what you are imagining. They need to see it or touch it to truly get it. And that’s why words on a page or a concept in speech is simply not enough. Physical is better. The decision about how to get that across to a customer, though, is up to you.

When we started working on an MVP for Equals we decided we needed to write code. The concept — writing a note that can tell the difference between text and numbers, performing any mathematics automatically — was hard to imagine. We felt it was important to show that ability so we started with an MVP that did just that and over the course of months refined its capabilities.

We also realized that there were a number of other things we wanted to test as well with customers. Would sharing be of interest? Would being able to send things to third-parties like Evernote, Twitter and Facebook be important? What about collaboration? History? Integrated data?

Some of these things were natural offshoots so we didn’t need to develop them. Once people understood sharing the idea of collaboration was a natural extension, very easy to discuss. Some we could put screenshots in place that simulated the look-and-feel but didn’t actually function. I didn’t have to build Evernote, Twitter and Facebook integration. Showing a table with those options was enough. When we developed the first Equals MVP we included no text formatting. We talked to potential customers about the idea but found that it didn’t stimulate a conversation. So we added functioning code. [2]

Once again, back to the original question: how do we know when we have a minimum viable product? We know when we have a hint of all the features we want to get a reaction to from the customer. Those features need not be complete and in many cases they don’t even need to be functioning. But they do need to spark a conversation.

After all, the whole point of the MVP is to get a sense from customers as to whether we are on the right track or not.

—

[1] This goes especially for non-developers. Stop asking people if they’ll write an app for you based on an idea. Mock the thing up in PowerPoint or Keynote using a tool like Keynotopia and go get customer feedback. That’s a heck of a lot cheaper than writing code.

[2] We also needed to prove we could do it in a cross-platform way.