Your MVP Is Minimal, But Is It Viable?

I just found this brilliant article by Alex Iskold…

alexiskold.stfi.re/2015/10/07/re-thinking-viability-of-your-mvp

He argues that the key to the vitality of new business ideas are feedback loops.
This is what makes natural systems alive and this is what makes great software alive as well.

To arrive at your MVP, strive to create a minimal product that has correct feedback loops.

 

Step 0: Talk to customers confirm you are onto something verbally.
Do the unscalable things to validate the market.

Step 1: Map out MVP based on your gut and understanding of the market.

Step 2: Remove features that feel unnecessary

Step 3: Combine features that can be combined, simplify

Step 4: Check the flows and feedback loops. Are you solving the problem you set to solve? Is the system dynamic enough? Will it be alive?

Repeat steps 2-4 until done.

 

What you are doing is you are focusing on minimal set of features, but not at the expense of viability.

 

How to solve the only problem you have

Here are some fake problems you think you have :

  • What shall we call this?
  • What color is the logo?
  • Should we include (insert desirable feature here)
  • Which blog platform is best?
  • Facebook or Google advertising?
  • Is C++ better than PHP?
  • Should we get an office?

Here is the only real problem you have :

  • Does this idea solve a problem for people who are willing and able to give me money?

 

How to solve the only problem you have :

Take stock of what you have in front of you. I assume that you have an idea – one that you generated out of your own genius, or something that your cousin told you at a party, or some variation on an idea that someone else turned into a business.

Try to write it out in one or two sentences.
Here’s an example…

“I’m going to sell an Android App to predict future weight loss, based on a person’s past failed diets.”

 

Will this idea solve a problem?

Yes, you say, of course it does. But, think about it – how do you actually know that it solves a problem? Maybe people don’t want to think about past failures. Maybe they don’t want to record numbers every day. Maybe they don’t want to know their future. You need to find out.

Will people pay to solve this problem?

Let’s assume that you’ve asked a bunch of people if they would like to be able to predict their future weight loss. A few say this sounds great. But maybe, when time comes to actually purchase your app, they decide that they really want to spend money on chocolate rather than some shiny new software to tell them they’re going to fail again anyway.

You need to come up with a way to ask them to actually pay for your solution – you will never know if you have an executable idea without doing this.
If people hand over money, you know you have a market for your product.

Is it possible to make this work?

Don’t ever ask software people if something is possible. Of course it’s possible. Every coder knows that they can make anything happen – given enough time and money (and enough bubblegum and string). Some of them probably can make magic happen.
So they will invariably say something like “Sure, this is awesome, and I reckon we could build this in a few months, and for too not much money. Half up front, and half on launch.”

 

Do not do this :

At this point, a lot of first-time entrepreneurs say “Woohoo, some people I know agree that this is a cool idea, and a developer said he could build something like this for $40K. I should go ahead and just do this thing!” Commit to the dream.

No.

 

Do this instead :

Figure out the things that are special about your idea. Do this by listing all the awesome features, and then one by one, take features off the list, and stop at the point where, if you remove one more feature, the whole idea evaporates in a puff of smoke. What you are left with is your core feature set.

 

Don’t design pages or screens at this stage. No colours, no branding, no perfect layouts. Sketch up every single one of those core features in terms of an interaction between your application and the user… e.g. (a) record my weight, (b) create a list of common meals, (c) record what I ate today, (d) note the result, (e) join a support group, (f) delete last years results, (g) scrub and start again.

Each of these “touch points” (computer/human interactions/interfaces) needs to address :

  • How do you get to this interaction (e.g. from a floating always-on menu, or in response to a particular set of circumstances)
  • What is the user input (e.g. a whole number of kilos, no decimals)
  • How the app responds, what to expect (e.g. displays projected loss based on a mathematical formula.. pokes out it’s tongue.. calls an ambulance…)

Along the way, make sure to ditch anything that really isn’t needed to define/test the concept. For example, you really don’t need to have a secure login system. For now, you can just take it as read that when you launch, that would be desirable. For a first pass, choose something simple like entering a unique username. You do not need to add an avatar, nor link up with Facebook or Tumblr – irrelevant, strike it from the list.

Then do this :

You have your “core features”. Now you need to answer the next piece of the puzzle… can this be built?

Don’t ask a software engineer if it’s possible (see note above). Sidle up to a coder. Offer them a small but reasonable amount of money, or a piece of the action. Ask them to build a proof-of-concept model, based on your “touch points” flash cards. Nothing fancy, no colours or polished wording, just the basics.

The only brief should be “build something really simple, using any coding language you like, and any database, that demonstrates positively that all of these features (“touch points”) can be implemented on (platform like desktop, tablet, iPhone). It can be ugly as sin, but if something doesn’t work, then they have failed to build anything useful for you.

In most cases, you can get a rough working prototype in a few days, because you have a short list of well-defined expectations. No guesswork required, no need to pick just the right shade of lavender for the backgrounds. If you outsource through one of the freelance services, it’s not going to be expensive. But feel free to ask your geeky cousin who’s still in high school, as long as he knows how to write functional code. You’re not going to use this for your launch product. Don’t sweat the details.

Then do this :

If your geeky cousin or cheap contractor was not able to make something that jumped through your short list of essential hoops, then you have scored a victory. What, you ask, but isn’t that a failure?

It is a definite WIN if you can scrap an idea early, which can’t be executed. Take the afternoon off, open your notebook, cross that idea of your list, turn the page to the next awesome idea, and start over. The name of the game is to reduce your risk and generate revenue – it is not the process of forging on regardless with an unworkable or impractical idea.

You have now addressed the question ofCAN this idea solve a problem for people who are willing and able to give me money?”

 

Then do this :

If you get this far (a well-defined group of people think it’s a good idea and addresses a pain point. You have reduced the concept to a few core ideas, and you have tangible proof that it can be implemented at least on a rudimentary basis), then the next thing to do is discover if there is a real product/market fit.

 

The thing you are trying to discover at this point is :
“CAN this idea solve a problem for people who are willing and able to give me money?”

You have a rough functioning prototype. You have covered all the pain points of your defined audience.

Ask people to pay (yes, pay for the shitty prototype rough system you have). To fork over their chocolate budget.

You will probably have to come up with some sort of equally rough and unpolished sales pitch and marketing message. You may choose to buy AdWords, or retain a sales person to generate some leads.

If you can do that, then you have created your MVP (Minimum Viable Product). Take note of the fact that the working software you have to play with at this point, the really simple Android App (or HTML web app approximation that kinda works on a phone) is going to be NOTHING LIKE the final product.

And, really take note of the fact that the MVP is not just the software – your MVP is the problem, the software solution, the story, and a price point that generates real sales – in equal parts! Actually, all you need to demonstrate is a willingness to pay. If people click on the “pay now” option, then you can always have a response like “Thanks for your enthusiasm, we will contact you when the launch happens, and here’s a discount coupon.”

You may think that if you had a final, complete, polished version that it would sell a zillion copies in 24 hours, but the truth is that if you can’t sell the rough prototype, then it’s going to be an uphill battle to sell a polished final.
But, if you can sell this rough prototype, then selling a polished final version at launch will go 100 times easier!

 

If you have validated your MVP, then you have solved your only real problem.

The rest is downhill coasting. Well, not exactly downhill, but now you’re armed with confidence that you have something revenue-positive, with a definite market, and that the idea is executable.

You can go back to figure out the naming, branding, logo colours, blog platform, etc etc etc . You probably should do a second cycle of prototyping before committing to your final beta-release version. Some AB testing, some UI / UX, some hardware costings, etc etc etc

The goal is to deliver your MVP to the marketplace ASAP.

“Here’s something we built for you. Would you like to buy it?”

 

 

 

 

Only include what you can build

Don’t prototype features or functionality that cannot be implemented.

How many times do you get a nice looking PhotoShop design as your brief? It’s nicely sliced and diced ready to roll. Sweet. You are really happy, because the client has clearly got his shit together.

You start translating into HTML/CSS or binary code, or whatever you use, and about 24 hours into it, you’re looking at the details of, say, a harmless dialog box. This is the first time you read the little 8pt notes – and the wording says “search our suppliers’ databases, and return a formatted word document summary”.

Wow, you think, that’s an awesome idea.

The only trouble is, (a) the suppliers do not grant access to their database, (b) most don’t even have a searchable database, (c) there’s no way on God’s green earth that you are going to be able to format in Word, and (d) would all these suppliers actually allow you to munge their data in with their competitors and displayed on your app as your own?

Bother. So you go back to the client, ask what this little dialog means, and they say “Oh, well, we thought this would be great on the demo. It will let our potential customers see the awesome stuff we have in mind for the launch release.”

“But what about a, b, c, & d (above)?”,  you ask them.

“Oh, well a, b, d, I guess you’re right, but we saw someone else format things kinda like Word once. So (c) is proof that we can do it. Maybe you can do one of those cluster-the-cloud techie things. You know.”

This project not only raises 100 red flags, but it’s this sort of thinking that will come back to bite you in the bum. Not during alpha or beta phases, but probably about a week before the launch party (once all the marketing budget has been locked in).

The early test audiences, focus groups, pre-sales results might be totally based on this one awesome feature.

The one awesome feature that nobody has any clue how to actually build. (Well, there’s a rumour that some guy in Slovenia can do it, but only if you get his whole family residency visas, and hire his cousin.)

But when you get to launch, everyone says “Where’s that awesome killer feature we saw in your prototype? The one that I’ve been telling everyone about. Show us how it works, and we’ll drop shit-tons of money in your lap right this instant.”

“Well,” you say “we removed that since you saw the prototype, because it just didn’t work. Only a couple of our suppliers could provide data, and only if the other was hidden, and of course you can’t format 700-column tables in Word, and there were some legal issues. But hey, look how you can pick your own avatar in the social sharing screens…”

You forgot the “Viable” bit of the MVP.

When you are building a prototype, and you don’t quite know if some small part will work, then don’t show it to anyone until that small functionality has been proven. I’m not talking about common stuff that’s a variation of something you or everyone else has done a dozen times, just the stuff that is a kinda-new idea, or if it’s central to your concept.

Try leaving it out. If your idea still works, then it shouldn’t be included in your MVP prototype. If your idea just doesn’t work without it, then you’ll need to figure out how to make it work, before you go any further.

You might like to build a Functional Model first – some simple little single-purpose bit of code that demonstrates that you can, indeed, hook into suppliers databases, and format the results. You don’t need anything pretty, and nobody is going to look at it. It’s just a proof-of-concept tool.

Then you can go ahead and happily make a prototype, complete with the pretty little dialog box – without your awesome feature working at first, because you have proven to yourself that it will work in the end.

Or, if your Functional Model fails, then you don’t even have to build a prototype of the app at all.
Cheap, quick, risk eliminated.
Time to try another idea.

Your Rosetta Stone

In product development, the minimum viable product (MVP) is a method that exposes your idea to potential customers in a tangible form, so that they can grasp your vision, and give valuable feedback before committing resources. It’s a way to find a profitable product/market fit, or to exit gracefully. Minimum time and cost, minimum risk.

The prototypes that you build in the process also become nice little Rosetta Stones, which you can use to translate between client-speak, customer-talk, sales- marketing- and tech-nish.

Specifications usually grow from of a team of people with different backgrounds, different skills, different expectations, and vastly different ways of talking about abstract ideas and concepts.

Let’s use a simple web app as an example:

The developer takes the specs, and sees the words “landing screen”.
He knows what that is, and he builds a “landing screen”, a screen that welcomes people to the app, and has a bunch of buttons for all the possible actions that a user could want.

Oops, the marketing guy also knows what a “landing screen” is – that’s the place that prospects are directed to land on when they click on a Google AdWord.

Oops, the CEO also knows what the “landing screen” is – that’s where the company logo goes, and the corporate vision is explained.

Even a quick-and-dirty prototype has the power to immediately translate the phrase “landing screen” into something that everyone disagrees with. This is a good thing. Everyone’s now on the same wavelength. Everyone is speaking the same language.

People are very flexible with the labels they use for things, and maybe this team decides that in future they are going to call this the “dashboard”, or the “buzz box” or whatever …

One thing’s for sure, if they had handed over their beautifully worded specs as a “final design specification” and waited for a final product to be built, then they’d be in trouble.

The few extra hours spent on a prototype are worth it every time.