If MVP fell out of the sky and wiggled on your face, would you know it?

Minimum viable product. It's something that most of us working on a product or project know we should do, but hard to actually do in practice.

For me as an engineer, it was particularly hard because you have the ability to build, and you like doing it. Therefore you're use to building something first, and then showing it to people. That's because just telling people that you have something without having actually built it just seems like...lying.

Half the problem of an MVP is picking the right scope for your problem. But beyond that, there are other reasons that might derail you from building an MVP.

Often times, we don't know what actual MVP might look like. Other times, we have fear that gets in the way of letting us release MVP. I'll tackle the first, and then the latter in a future post.

When you're thinking about the solution to your problem, think of the simplest thing that could still work. Then cut and have it do less. Does it still solve the problem? If it doesn't, see if you can shrink the scope of the problem. If does, see if you can shrink the solution. Keep going until you only have one basic unit of good/help that you're giving to the world.

This basic unit of good is your core value proposition, and it's also what you're testing to see if it's something people will want and find useful, because at this point, you don't really know. You might know whether you'd find it useful, but you may not know if others will.

 If the core proposition of your product is compelling, your users will forgive all sorts of un-polish. Don't fall into the trap of thinking that the next feature you add will be what brings the boys to the yard. There will not be just one feature that rockets you into the stratosphere. You'll just end up building fluff and throw pillows on top of a cornucopia of crap features. I think it's what they call polishing a turd (or putting lipstick on pigs). 

Think about software for an airport control tower. What's its main core value proposition? To land planes. If it doesn't do that, it doesn't matter that it can land big planes, small planes, on any number of different frequencies, or how many it can do at once. No one will care because it doesn't land planes.

Another good example is Mixpanel's reporting. They report all their times in UTC, probably because they just didn't want to mess around with timezones. You'd think that in building the MVP for web analytics, you'd need to show the stats in the user's timezone. Apparently not. Mixpanel's core proposition is real-time tracking of events generated by your visitors.

Delicious's bookmarking (and by same reasoning, Flickr) is another good example. It's core value proposition is for me to save web pages and organize it easily for recall later. It's useful to me even if there's no other users around. However, the public nature of the bookmarks and tags has the added side-effect of having aggregations. It has to be first useful to a single user, even without other users around. Many new startups ignore this aspect and concentrate on the benefits when there are already a lot of users. Very rarely will you have a scale of users to leverage in the beginning.

Along the lines of building single unit of good, don't build for anyone other than your active users. When smart people, investors, or potential users/customers weigh in on your product, they'll have some insights, but they are not your users (yet). In general, you should know the core value your active users get from your product better than them.

Build things for active users, I can't stress that enough. It's far too easy to fall into the trap of "If I build this or that feature they said they'd use, they will signup/use it." Do this enough times, you have a mish-mash of features no one wants.

Sometimes, you don't actually need to build out what you envision in your long term vision. You can leverage your landing page to set the users' expectations for what the application is suppose to do in its broad scope, ambition, and intent. As long as you solve the simple version of that core problem for users, they'll be ok with your un-polish.

If all of your potential users are all saying they want different things, either you haven't set the expectations correctly when you're selling your vision or you haven't nailed down a core value.

But what if you whittled things down and it looks too simple? Too laughable? Too stupid? To that, I say don't worry if the core value seems small as long as it's something people want or needs to use. Everything is deeper than it looks.

You can much more easily position and market yourself when more focused. And when it comes to partnering, or being acquired, there's less chance for conflict. This is all so logical and, yet, there's a resistance to focusing. I think it comes from a fear of being trivial. Just remember: If you get to be #1 in your category, but your category is too small, then you can broaden your scope—and you can do so with leverage. - Evan Williams

In addition, most things that we take for granted nowadays as being useful started off looking like toys. The car, plane, wikipedia, music radio, TV, facebook, rails, javascript, twitter all started off looking like a joke--toys that can't be taken seriously. And in their first inception, rightfully so. They had a lot of weaknesses overshadowed by other things that did it better. The horse could outrun the first car. The plane was an easy way to die. Can Wikipedia really be accurate with lots of anonymous edits? With music wireless boxes, concerts sound much better. So on and so forth.

That's not to say all things that look like jokes will become useful (converse is not true!), but don't be discouraged because your thing looks like a toy. Things are always deeper and more interesting the closer you look.

In the end, being able to identify your MVP takes clear thinking, understanding of your users, and the courage to be laughed at. 

Posted via email from The Web and all that Jazz