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.

 

Start broad, then go deep

The currently accepted wisdom is to start with “horizontal” prototypes, followed by “verticals”.

Horizontal prototypes

Horizontals are simple mockup simulations used during the project scoping phase. They are primarily used to get an overview from the user’s perspective.

Horizontals give a broad view of the entire system, so you can concentrate on the big picture, rather than getting bound up in the details. They are best used for understanding relationships across the whole system, for demonstrating the scope, and ensuring all behaviours are covered. It is possible to develop one entire layer of the design without having to consider the “how” of the technical implementation. Issues of consistency can be noticed and addressed (similar interactions are grouped by actions or location).

A horizontal user interface prototype allows you to gather more information from customers and designers. It also allows you to confirm business requirements, define/clarify the scope of the project, and get buy-in from the key stakeholders.

Horizontals can sometimes be presented in sales demos, to get exposure in the media, or to make advance sales.

The process of building a horizontal prototype can enable good preliminary time and cost estimates, but may increase the influence of the planning fallacy.

All essential user interactions are covered, every screen and menu and function is shown in some form. Most importantly, none of the features are fully functional.
No real work can be done.

Some level of functional simulation is occasionally required, so that the prototype can be evaluated properly. For example, some dummy location data and mapping might be displayed, or pre-recorded videos play in place of a live webcam when a button is clicked. Sometimes this can turn simple horizontal prototypes into evolutionary prototypes, where the prototypes slowly transform into the final system by adding more and more functionality.

For simple projects, this may be desirable. But this approach can undermine the greatest benefit of a throw-away prototype – that the rough and simple nature of rapid throw-away prototypes allows, and in fact invites, large structural changes with very little risk or effort, before any coding takes place.

 

Vertical Prototypes

Verticals seek to demonstrate the complete functionality of a single feature, or a small set of features. They focus deeply on technical issues and are rarely shown to potential customers or non-technical stakeholders. Occasionally, they expose problems in a sub-system that may require changing the scope or the number of user interactions. The aim is to make sure that it’s possible to implement all the core features envisaged for the completed project. Where the product innovation is primarily a novel arrangement of common technical practices and solutions, there is less need for vertical prototyping.

Vertical prototypes are only used early in the cycle where proof-of-concept for a core feature is needed. Data processing volume testing, network sizing and latency tolerance, performance engineering, load balancing, code optimizations – identifying or solving problems “behind the scenes”.

These technical prototypes can be created in parallel with the interface, or built in advance of the user interface, or built after the interface is designed.
But they are commonly built to prove a concept, then thrown away.
If built early in the development cycle, it is not always known which platform/language will be used for the final product. Verticals generally do not allow for interactions with other features, use cut-down or dummy databases, and code is rarely optimized. Trying to re-use this code would take more time than starting fresh on the final build.

Modular Development

Where the end product is a series of modules, rather than a single system, it may be better to “start deep”.

Vertical prototyping may be the best method to use. Individual modules can be built with little regard to the ‘big picture’ as exposed by horizontal prototyping. Where the general architecture has been decided in advance (e.g. objective C on iOS) then it may be most efficient to adopt evolutionary vertical prototypes – simple operational frameworks that can be iteratively refined.

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.

When to Prototype

  • When your product is multi-functional
  • When there’s a steep learning curve for newbies
  • When you need buy-in from diverse stakeholders
  • When you find it difficult to describe with words and arm-waving
  •  When you are not sure of the requirements

    Prototyping is most beneficial in systems that have lots of interactions with the users. Apps that require inputs, decisions, logins, and manipulations.

The more things that a person can do with your system, the more combinations there are, and the more ways there will be for them to forget, lose their place, make errors, miss the point, and get frustrated.

Those who design and build the software and interface get to be really really familiar with all the nooks and crannies of the interactions, so they become blinded to the “first time experience”. They know that once a new user has done something a couple of times, it gets really easy, and their focus groups have proven that all they need is 15 minutes to become a pro.

What you are going to be selling is always a first-time experience.

You need to build a prototype that reflects this – so you can test out your prospects’ first-time experience. If they take more than a few seconds to understand how to interact, then you’ve lost them for good.

Another scenario that demands prototyping is whenever you have a team of people from a mix of backgrounds/expertise all working together to launch a new product.

A prototype is essential to allow everyone to see what you’re talking about, to be able to compare notes on the same thing, using the same language.

You can use even the roughest paper mockup, to demonstrate and communicate – to the boss (or your business partners), to developers, graphic designers, investors, banks, sales and marketing.

Each one of these people might be able to point out valuable insights extraordinarily early in the product creation cycle, that will save countless hours, get you to market quicker, and reduce your risks.

Not sure of your software/hardware requirements?

A first-pass (alpha) prototype is a great tool to use for getting initial cost and time estimates from software coders and data architects. It allows them (and you) to get a better appreciation of what data will need to be stored and manipulated, and what the likely hardware needs are.

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.