The critical things you need to know about building an MVP (part 2)

Quite often when I’m speaking to clients they’ll say something like this.

Or something like this

It always makes me nervous when I hear this. When you’re building software, it’s all to easy to focus on the product that you’re building. But with most projects, the actual ‘product’ bit is only half the story. This is especially true with start-ups. It’s normally more useful to think in terms of building a business, not just building a piece of software.

Think of the ‘whole product’ not just the MVP

What do I mean by this? Well, let’s say you were building a royalty payments system for the entertainments industry. You’ll need to make sure you do a great job of building an MVP that has the correct feature set to test your assumptions, but it doesn’t end there.

You’ll also need to have someone to administer the data in the system and also to run the servers. Then perhaps you’ll also need someone to provide support to your users. Basically you’ll need to build a team and systems around your product to make sure people can actually use the damn thing.
[thrive_leads id=’1011′]

With Q App we built out first MVP to allow users to order and pay from their phones in busy hospitality venues. And it did just that. So far so good. But right away we knew that we would need someone to set up the menus (not a simple job), someone to train the staff on how to use the system and someone to provide ongoing support to both users and bar staff when it came to actually using it. And that’s before we’d even considered marketing, sales etc.

Too often start ups (and established businesses) blow their seed money on a great MVP, but realise too late that they haven’t build the infrastructure around it.

Building the MVP is the first half of the whole cycle, not the end in itself

Let’s just remind ourselves of the actual Lean Startup cycle:

You’ll see that the ‘build’ bit is only one part of the process. It’s all too easy to forget the Learn and Measure bit.

In the first part of this blog post I talked a lot about working out your hypothesis and working back from that point to establish what features you need to include in your MVP. But when you finally put your baby out into the market place, there is one thing that is absolutely guaranteed:

Users won’t interact in the way you’d imagined.

So what then? Well you need to implement the other parts of the cycle. The measure and learn parts. And, to do this properly you’ll need to make sure that you can really test your hypothesis.

It’s all about the data

Let’s be clear about this. Having accurate data on how your product is being used is AS important in building the right feature set for your MVP. If you can’t measure how your users are interacting with your product then there’s no way of knowing what is working and what needs to be changed.

So what do we need to measure exactly? Well, anything that helps us evaluate whether our initial hypothesis was correct. And that means different things in different projects.

With Q App this was relatively simple. Our hypothesis was the users would want to use a mobile application that allowed them to order and pay in a busy hospitality venue, rather than waiting in line. We could work out if we were right or not by how many orders we had per night.

But that wasn’t the end of it. We also wanted to know how many opened the application but never went any further. Or how many went to the trouble of setting up an account, or even getting as far as the payment screen but failing to complete the transaction?

There are a number of tools available to do this, and selecting and configuring the right one is critically important at the beginning of the project.

And then we get to the learn and ideas part

I cannot think of one project I’ve ever worked on which behaved exactly as we thought it would when we released it to market. And in 9 cases out of 10 our initial traction was not as impressive as we hoped.

But if you’re disciplined about the way you work, that’s OK. You stay calm and you form a new hypothesis based on your initial MVP and the data you’ve gathered in the field – normally that if we change xxx part of the product or introduce xxx new feature we’ll improve our traction. You then release a new version of our product with these changes implemented and start the cycle all over again.

So in summary

What does all this mean in practice? Well it means we need to think of software development as a continuous process of refinement and testing and not just a one off event. Too often I have seen clients focus on getting to the release of the MVP, but not have too much consideration of what do to afterwards.

As Steve Jobs said:

t’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.

By following this method, most of the time (not always) we’ll eventually start to see traction in our product and sometimes we’ll even start to see the elusive but wonderful “Product/Market Fit”.

But that’s another blog post…

Share: