Doing More By Doing Less – Launching With a Lean MVP

Optimising for impact by understanding what’s most important for a new product to be able to priorities features wisely and deliver value quickly.

Launching a new product is hard. Not only the actual development is a challenge, but also the product planning and prioritisation of features constantly present difficult decisions.

A common keyword that is often quoted in this context is the Minimum Viable Product (MVP). This term refers to the smallest selection of features a product needs to have, to be a valuable product to users.

On Wikipedia, MVP is defined as:

“A minimum viable product (MVP) is a product with just enough features to satisfy early customers, and to provide feedback for future product development.” (Wikipedia: Minimum viable product)

Some argue that the term “MVP” no longer captures what is needed to build a successful product. Concepts like “Minimum Awesome Product” (MAP) as outlined in the article “Forget MVP — Here’s How You Build Your Minimally Awesome Product” from 2014 or a more recent writeup called “The MVP is dead, long life to the MAP. (Minimum Awesome Product)” are just redressing what MVP means. In my opinion, the core concept of MVP has probably shifted over the years, and “Viable” in 2018 does not only include functional aspects, but also usability. If it helps people to split it up in two concepts, MVP and MAP, sure, why not, but I do not really see a need for it. Sticking to MVP is also better for another very trivial reason: searching online for “MAP” might bring up many more irrelevant results than searching for “MVP”.

What makes a product viable?

The definition sounds straight-forward. The idea of an MVP seems like an easy concept at first. Of course you do want to minimise the time until you can launch, and still offer a useful product right from the start.

But when you actually start thinking about how this concept translates into a product roadmap, it gets tricky rather quickly. Having a Lean Canvas is a great starting point, since it should list the main problem, your solution and the unique value proposition you want to offer.

While approaching the MVP from the user perspective is essential, it is equally important to keep the technical complexity of the features in mind. Without question, the goal is to provide the best, smoothest and simplest, yet most capable product. But this is most likely not what an MVP usually looks like. To launch a product quickly, and maybe take advantage of getting to the market faster than potential competitors, requires clever choices.

Besides the question regarding which features have the most impact on the user and are perceived as most useful, the user view on the product has to be balanced with a well-informed developer view. Estimating complexity and development time, taking into account dependencies and other technical and non-technical constraints is key to come up with a realistic list of features that can be delivered within the targeted launch window.

Combining all the different aspects, you can define a workable sequence and put the features into an order that reflects all the different, sometimes conflicting requirements. The result of this analysis can then be split into different stages, different product releases, to form a roadmap that connects the product vision to the smaller, incremental steps, starting with the MVP.

What is the UnscrewMe MVP?

Right when we started building the web app, we outlined a high-level feature roadmap we wanted to follow for the first two or three releases. Our priorities were clearly driven by our Lean Canvas, with our first solution bullet point being “Provide an aggregated, consolidated overview of wine tastings in London”.

To be able to launch a product as soon as possible, functionality that would be easier to implement was prioritised over more complex, but potentially also more useful features. On purpose, we limited the scope of the initial feature set to the bare minimum, that would meet our main value proposition we listed in our Lean Canvas: “Saves people time and increases enjoyment.”

In terms of actual features, we translated the core goals to just three options:

• a chronological list of upcoming events
• a calendar view of the same list — to present chronological information in a more planning-friendly format
• a simple event search against title, description and location

This selection did not cover everything in our Lean Canvas, but represented a subset which might already be useful enough to justify a limited launch and gather first users — and also first feedback. Recognising the shortcomings, focusing on the baseline “Minimum” in MVP, we called the second planned release MVP+ — it sounds better than calling the initial release MVP-, right?!

What are the next steps after the MVP?

While putting all effort into the MVP is crucial to get something out into the wild, adjusting to advances, setbacks, and questioning the roadmap from time to time are just as important. Nothing should be set in stone. To keep in mind the bigger picture, it can help to formalise the initial high-level feature roadmap further, step by step, breaking it down into releases, or “milestones” in GitLab, and gradually adding more details to the overarching vision.

The milestones might start with only one or two short issues. Similar to the process of writing articles, when getting closer to one release, it makes sense to look at the next one and move from abstract features to actionable implementation tasks by extending existing issues and adding new ones, to develop a better idea of the way and workload ahead.

The MVP is only the very first step in delivering something useful. Building on the basic list, search and calendar views, we want to add personalisation features, to make using the product more convenient. Having a list of events is good, but having a list of events that I am interested in, and getting reminded of upcoming events, before I miss them, is better. And that is exactly what we want to offer next.

After a few months of working with Vue.js and the implementation of a range of features for the MVP, we will describe our development experience, what we like about Vue.js and highlight some stumbling blocks we came across.

(I finished formatting this article after some lovely wines at Passione Vino near Old Street, where I enjoyed an engaging conversation with a bunch of avid readers from Campus London about an interesting book. My favourite was probably a nice, somewhat lightish, balanced and tasty red from the Lombardy region in Italy, a 2014 SandroFay Il Glicine, Valtellina Superiore Sasella made from Nebbiolo grapes and grown on the Valtellina mountain in the Alps.We started with a funny and easy-drinking sparkling red — an off-dry, fruity Lambrusco Solco from winemaker Paltrinieri, located in the Emilia-Romagna in the North of Italy.)