Building your first MVP

You have been planning for the past 6 months. The idea sounds fabulous. You are going to solve a major problem with this software you want to build. There is a backlog of amazing features you wish to add. This will surely drive future users crazy. Now it is time to develop the initial version of your software, then sit back and wait for the well-deserved success.
You planned it all, so you think, so what can possibly go wrong?

The Anatomy of an MVP

The last sentence in the previous paragraph was a rhetorical question, you know. Even with great planning, there are still a million things that can go wrong, transforming your most fabulous idea into a flop. Let me give you some examples of the most frequent mistakes which can occur before, during and after MVP development:

• Building an overloaded product
• Misjudging your target audience
• Defining unrealistic budget or development timeframes
• Lack of development resources
• Undefined timeline to launch

Even if your idea is successful in principle, there’s much more to digital products. Both strategy and execution are equally essential and crucial to your plan.
If you are an established business, planning on launching a digital initiative, you should first transfer your business from offline to online, test your business idea, and importantly, don’t place all your bets on a single horse.
If you are a startup and this is your first digital product launch, make sure to partner with the right organization (like ours) whom will guide you through the process, without exhausting your entire budget before the first trials.

This leads me to the next question:

Don’t build your MVPs like this

What is an MVP?

The term Minimal Viable Product, (or Minimum Viable Product), has been around in the Lean Startup Methodology for a while now. However, before getting too deep into discussing this term, let’s try to understand what’s really important. The actual meaning of MVP.

• Minimum means the least possible features to make it a
• Viable
• Product

Wasn’t this simple?

Let’s make an example. Let’s try to imagine developing a “Music Rating” App. We’ll call our app “Singilici.us”. Our app will allow users to rate Music by famous Artists, listen to the music, share it with their friends, create fan groups and interactively chat with each other. What would be the minimum features needed to provide users with essential core functionality?

There are many aspects, but let’s look at this from a business point of view. A straightforward means of creating user accounts, listening to the music, and sharing it with their friends are the minimum required functionality we need to provide. This is the bare minimum needed to create the marketing aspects of our app – the bare minimum.

With these minimum requirements, we can allow our users to:

• Create a fully functional personal user account quickly
• Allow users to add their personal info and/or preferences
• Search and Listen to music
• Share links to their friends as an incentive to sign up for the app as well

The above is the minimum for our Marketing department to start work and get the first users (based on our target group) downloading and using our app. Arguably – the the first waypoint we aim to reach.

In the scope of the MVP, features such as Fan Group creation, invitation to Groups, Ratings, and Chat are not required and invalidates the “minimum” definition.

You must consider the economic impact of every single feature you develop. Development takes time, consumes resources, thus costing additional money.

Viable in the first instance, means functioning. Our Music Rating App must have a properly working backend and administrative interface. It should have an intuitive User Interface (UI). The User Experience (UX) should avoid crashes or avoid features misbehaving.

Finally, the P in MVP stands for Product, with no further explanation needed.

To summarize, the MVP is a tool, which at its core intent, is meant to provide only the needed features to make the Application usable.

Now that we talked about what an MVP is, let’s also have a look at what it is not:

Let’s start by stating that an MVP is not a prototype. MVPs are working software, which can be used by real users and solves real problems.

Moreover, an MVP and a Prototype are two different things. They are used in the different stages of the lean product development cycle. According to the “Lean Startup Methodology” of software product development, the full process is defined as:

• Prototype
• Minimum Viable Product (MVP)
• Product-market fit evaluation
• Scaling

Like with everything else in life, you can’t have it all. If you really are thinking of cutting corners and just release an MVP with everything in it, then the chances are you’ll have no time to properly write the required software code. Or worse, you’ll end up dropping too much viable functionality. This will not result in a real MVP. It will just be a “badly” designed application.

You need to learn to think in the mindset of your targeted end-users. They will not appreciate a badly designed app. Your well-thought idea, your app, won’t simply be viable.

There are also adverse side-effects on releasing badly designed apps. This includes scaring off customers and ensuring a bad reputation for your brand. All of which will be hard to fix later on.

Build your MVPs like this

MVPs are not proprietary to startups alone

It is commonly thought that MVPs are only used by startups. There is some truth in this idea. However, you need to appreciate that the philosophy of MVPs is a commonly applicable principle to companies of any maturity level. Obvious advantages for startups include:

• Pitching to potential investors
• Market testing
• Viability discovery

Now that we discovered what the MVP constitutes, what it is, and what it is not, let’s have a look into what matters for the MVP to make real sense.

Testing and Market Validation

As already mentioned above, one of the major reasons for developing an MVP is market validation of the original idea. The MVP will let you step beyond the hypothetical and into reality. It allows you to verify the idea and justify building it. You will also see if you are on the right track – or not.

For evaluation of an MVP success, you will need to apply metrics, which vary from product to product. You might want to measure:

• Amount of signed up users
• Number of active accounts
• Growth Rate
• User engagement metrics
• ROI related metrics

And a plethora of other metrics which are solely for the specific use case of the MVP in question.

Why are metrics important

Whilst I thought of pointing out some of the metrics in detail, I decided to take a different approach. The main reason for metrics is for taking data-driven decisions. Some creators will take their ideas as being successful for granted. Often implying that they are always “right”. Unfortunately, in most cases, they are not. You need a tool that allows you to make decisions completely impartially. This will decide upon any further progress of your MVP. This is why one of the ideas behind MVP, as a tool, is “validate, don’t guess”!

As simply as I can say it: Time spent not being present in the market, equals to wasted time.

There are more aspects to MVPs, like budgeting, resource calculation, good practices, and what happens after you launch your MVP. I will tackle these up in an upcoming article. Till then… stay tuned…!

Addition: 12 Nov 2019. Part 2 of “Building your first MVP” is now available. Continue reading here.