The ooovre Minimal Viable Product: Our Six Step Process

When people who don’t come from a digital background ask me if there’s one book they can read to help them understand a bit more about how digital works, I usually point them in the direction of Lean Startup by Eric Ries. For those of us who had been working in digital product and service development since the early days of the commercial Internet, Lean Startup was something of a revelation. It wasn’t the usual futurist froth found in books about the digital world, but practical advice from someone who’d been there and done it. It was something we could point colleagues and clients to and say, “look, you know that stuff I’ve been saying about how to do this, well someone else is saying it too, and he’s even been published.”

“Look, you know that stuff I’ve been saying about how to do this, well someone else is saying it too, and he’s even been published.”

There’s a lot been written about Lean in the five years since since Eric Ries wrote the Lean Startup, and I’m not going to cover that in this post. What I want to do is look how we took one of Eric’s central ideas and applied it to our start-up — ooovre.

The first, public version of ooovre is a Minimal Viable Product

The first release of ooovre is, to use Lean software development terminology, a Minimal Viable Product (MVP) (though we’ve called it a prototype on the site as MVP is an internal industry term and we wanted to use a more commonly understood term to help users understand that some functionality is limited.)

The Minimal Viable Product is a central concept in the Lean Startup. And on the face of it, it’s a pretty simple idea.

“the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort” — Eric Ries

An MVP can be anything from a simple one page marketing website outlining product features, a ‘smoke test’ using Google adwords, up to a more complex product release with a subset of the features.

MVPs are designed to help organisations understand as early as possible whether customers want a product.

It’s better to build something simple that tests the market rather than build something complex with a rich feature set and marketing plan. If you’re going to fail, then fail early with the minimum effort expended. An MVP differs from other forms of consumer testing because it is released ‘into the wild’ into the hands of customers.
What is minimal and what is viable?

So far so good, however, creating a minimal viable product is not necessarily as easy it sounds. After all, what is minimal and what is viable, what’s enough to get a good and reliable signal back from customers?

“The MVP is more minimal than you imagine” — Eric Ries

Developing an MVP can be challenging

All of which sounds very rational. However, actually developing an MVP is often easier said than done. What constitutes minimal and viable can be very different for different people and organisations – particularly if they’re used to only releasing feature-complete products that allow for no rapid iteration. The truth is that the design of an MVP is as much an art as a science — which depends on a range of conditions and variables.

What follows is a six-step process we used to help us work out how to develop an MVP for ooovre. (ooovre, in case you don’t know is a web app that helps people buy books online from local booksellers, the MVP is here, and there are more details here.)

These steps won’t work in every case, so it’s not a rigid ‘how to develop an MVP’ post. It’s a post about how we developed our MVP and the frameworks we used to make some of the judgment calls about what we want to achieve and what we thought was minimal and viable.

Our Six Step Process

See the MVP as part of a wider process

An MVP is part of a wider product and marketing testing process. While it can be a powerful tool to get real user feedback, it is not usually the first tool to test a concept. More standard approaches to concept development are with private closed groups of users – using design mock ups and even functional prototypes to help determine whether a concept is worth pursuing.

So for ooovre we developed a well designed mock up and then a rough functional prototype that both helped prove the concept and develop insight around functionality. Crucially it helped us establish the booksellers and customers responded really well to the concept.

Understand Your Users

MVPs are predominantly designed to appeal to early stage audiences — innovators and early-adopters (to use Everett Roger’s classification as popularised in Geoffrey Moore’s Crossing the Chasm). Early stage users will often be more understanding of products and services that have an interesting concept, but limited functionality. However, it is important to understand how comfortable your target users are with early stage products — not all user groups have the same capacity to work round limitations — a group of developers are different that a group of booksellers, are different than a group of working mums. The early adopters in each group have a very different set of tolerances.

So when we worked with our users for ooovre early on it became apparent pretty early on that while booksellers (one of our primary audiences) were all very keen on the concept, any MVP we developed had to deliver real value. It was clear that booksellers would need to see some kind of working site that actually helped their business if we were going to persuade them to get behind the project.

It was clear that booksellers would need to see some kind of working site that actually helped their business if we were going to persuade them to get behind the project.

Understand your Context

What constitutes an MVP varies widely depending on context, so, for example, if you’re an already established business an MVP can look a lot different to an MVP for a start-up with no track record. An already established business with a large and engaged audience can learn a lot from a ‘coming soon’ page with a nice product graphic outlining a set of features. It is of course possible to test concepts in this way for new businesses, and use media to reach an audience, however, it can be difficult to get useful feedback on broad concepts and direction of the business.

For ooovre, we understood that without a track record in this particular category we’d have to develop an MVP that showed more value than a simple product concept page or a smoke test.

Strip your product back to its core functionality

What exactly constitutes the minimum part of the equation is often the most difficult question to answer when developing an MVP. One way to approach this is to consider what the core function of the product is. The one thing that if removed would break the product.

In the case of ooovre it’s the book and bookseller search. The rest — bookseller pages, content creation tools, and community features are essential to grow the site, but it’s the search functionality that is central to our business. So this is what we pared ooovre back to. We’ve given examples of other possible functionality, but haven’t built the back end.

(Incidentally, this approach can also be a good early sense test of a product concept. If you can’t strip your product back to one key feature, then it might be a little unfocused.)

If you can’t strip your product back to one key feature, then it might be a little unfocused

‘Hack’ the user journey

Is there a way you can use established web services to ‘hack the user journey’?

For example, with ooovre we wanted to create an MVP that actually worked, ie. allowed users to search for and then order a book from local booksellers. To do this we had to ‘hack’ the users journey — to build a full back-end to the ordering and fulfilment process would have taken months and would have not advanced our understanding of user need in any way, so we just used email instead. Of course this results in some level of compromise to the user experience, but we felt it struck the right balance between usability and cost.

Test the concept — not the execution

High-quality design is an essential component of any digital product. We believe that an MVP for a mass-market consumer-facing product should be designed to the same standard as the finished product. A poorly designed MVP with a poor user experience will test execution rather than concept.

Which is why for ooovre we’ve put more effort into brand and interface design than we have building new features. We haven’t gone so far as to develop full design guidelines that work in every eventuality, but we have spent some time developing a clear idea of the brand identity and design language. It’s about striking a balance

So there it is, how we developed the ooovre MVP.

And while it may be a more maximal than the minimal MVP that some in the Lean community would espouse, we believe that given the context of user need and the wider aims of the business it was the right choice. We knew we had to prove to booksellers that we could deliver and a high quality product that added real value to their businesses. There are others who will no doubt be critical of the lack of some key functionality. But developing a successful MVP is about the balance between the minimal and viable. We believe that ooovre does that. And while it lacks some key features, it’s a working service that we believe delivers clear value to both sets of end users.

… developing a successful MVP is about the balance between the minimal and viable

In many ways this is the best part of the ooovre project for us, because even if we don’t raise the money through Kickstarter or other channels to develop a more fully featured version, we will have delivered something of real value to the people we want to support.

We’ve done this in our spare time over a period of less than six months — which is really the point of the MVP in the first place. It’s about creating something that helps you test a concept and move to the next stage with the minimum of effort.

Leave your comments

Your email address will not be published. Required fields are marked *