As an NFL fan, MVP has different meanings for me on weekends and business days. Without diving into the curiosity, today I’ll talk about the latter, starting with some general analogies and moving further with specifics on the mobile & web app design and development lifecycle. So let’s get started.

What does MVP stand for?

The term MVP takes on a solid meaning in the world of tech startups and companies around the world, especially in the Silicon Valley. Defined by Frank Robinson, CEO of SyncDev and popularized by authors Steve Blank and Eric Ries on 2011, the Minimum Viable Product (MVP) is a product with just enough features to gather practical insights about it and its continued development.

Now that you are familiar with the formal concept, let’s play with some analogies.

Your users don’t care about viability!

Do you want to do right by your users and by your business? Then you need to ditch the minimum viable product for good — and our ebook guide will show you how. Understand how and why the ‘minimum viable product’ theory holds a product back.

Also read our most recent article about it: Screw the minimum ‘viable’ product, let’s talk about value!

How does the MVP apply to a product development?

Have you ever seen the picture below?

Source: Dribbble

Differences here are straightforward: first approach shows the conventional strategy of investing time and money to implement the whole product before verifying whether customers want it or not. Second path allows having functional smaller versions to include customers’ feedback on the product lifecycle, validating the actual usage scenario, instead of simply relying on preliminary market research, which often provides misleading results.

That being said, the second approach seems the way to go, right?

Nowadays building a MVP requires more than having stages with functional versions. That approach was able to include customers on each product stage, but for startups to be successful and raise funding, things can be more challenging than that.

Take a closer look at the picture above and think how much of the motorcycle was actually useful for the final car. Seems like you will have to throw the motorcycle away and rebuild the whole product to come up with a complete car. Of course – chances of being successful are higher, which is great – but what if you could already start building the final product, instead of disposable intermediate states that are built for the sole purpose of validation?

Here we go:

Source: Expressive Product Design

Except for lucky guesses, investors don’t usually fund projects before having a solid plan to market it, which comes with the understanding of the product – and a beta version of it. Comparing the second and third approaches on the picture above, you can think that in the beginning the second one (sort of) validates your idea with less effort (time and money), since building a scooter still seems much easier than building an uncompleted car. The problem is: to get funding to market a car, you have to expose to investors a minimum viable product of a car (not a scooter), which happens only on stage four. Also, if you present the motorcycle and investors like what you envision, you are still far from having a car, and far from understanding the challenges of actually building a car, since you haven’t dived into it just yet.

Bottomline: the third approach is more adapted for current investors’ expectations, especially on software development, increasing chances to get funded before the end of the whole MVP and avoiding the whole product refactor during the MVP stages.

Alright! And what about developing an app?

The same MVP concept applies to the mobile & web app design and development. Judging by my experience, every new product starts with an idea – a huge idea. So the first step is to convert an idea into a solid development plan, where people get easily lost. Sometimes, the first iterations of an MVP may look too simple, compared to the number of ideas they have in mind. That’s understandable, but the focus here is definitely not building as many features as you can, but having a delightful, usable, valuable and feasible product from day one.

It’s hard to come up with a recipe that fits well for all contexts, but I wanted to try anyway and hopefully you’ll put this fundamental concept to work for you. Here is a list of steps that I believe will help you going from having an idea to building a complete MVP.

1. Perform an initial market study.

Before even starting thinking about the MVP, explore your idea’s potential: talk to users, search for competitors or similar products. There is a big chance that what you think is a completely new might already be implemented by someone else, and you haven’t discovered it yet. Trust me: I receive at least one app idea per day, and, assuming there are over 7 billion people in the world… well, you get the idea.

2. List all features that you envision for your application.

Yes, this is the moment to list all your dream features — no filtering. This step is essentially ideal to be done before you start looking for the right partners to develop your idea. Although you will focus on the MVP, it’s nice to share the list of features and see how they respond to them, so you can measure their level of confidence not only going over the MVP, but kind of feeling what they think about the whole product.

3. Describe what makes your app unique.

I’ve been in touch with many people that want an app with a chat, posts feed, push notifications, Facebook authentication system, Stripe integration, Spotify songs… and that’s all good, but what will essentially make people download your app? Usually there are two cases here:

• Your app can implement new algorithms willing to disrupt a market, like adding AI, augmented reality or image processing algorithms to better perform tasks that current apps already do, or;

• Sometimes people want to use common features in an unexplored market. I can’t count how many times I’ve been requested to estimate the effort to implement an Uber-like star rating system in a different context (and that’s a very good feature btw). In this case, it’s important to adapt the whole experience for that specific market, with some tweaks to adapt these features.

In both cases, knowing what makes your app unique from day one will help out focusing efforts (time and money) from the very first moment.

4. Separate features in two lists: core features & add-ons.

Although you may have a huge list of items to develop from step 2, you have to focus on the starting point. Separate the list into most important features and features that can be done as add-ons after the MVP launch.

This step seems very straightforward, but sometimes feelings and dreams can be a trap and you will end up with a big set of features for the MVP. Review it as much as you can until you come up with a filtered and ordered list based on your knowledge about market priorities and requisites.

5. Find the right partner to develop your MVP.

There are many factors that you can take into account while looking for the right partner to build your MVP together with you. Some are minimum requisites, like quality, knowledge about overall technologies and experiences, but there are some qualifications that not many people remember, especially thinking about a long-term relationship, so here are the keywords I believe you should search for:

Communication

Firstly, the right partner is the one you can talk with every day: continuous communication. The MVP is already a simplification of the simple version of your goal – or at least it should be, but a change of plans during the process is normal and requires agile communication between the parties. Sometimes, there’s no time to go through the process of talking with the project manager, which will talk with the developer and so on. In short words, you should be able to talk directly to the developers if you need to change a button color right away, for instance.

Decision Support

Note that dev shops work developing mobile and web apps every day, and if you pick the right company, you will notice how many insights developers and managers can give you about your product. They definitely want to be involved in the end-to-end development, and you should allow it.

Open your mind, and scope. If you are willing to have the flexibility to change things through the process, you won’t feel good about working with a closed scope project. If you want your engineering team thinking about the application and alerting you about concerns throughout the development, which often lead to changes, let them think and discuss that with you. Also, open scope doesn’t mean you won’t have control over the time spent. If the company works clearly, they will estimate every feature, let you decide about it and track the time spent week by week. Then, you’ll be able to measure the team’s performance and discuss improvements on the workflow on a weekly basis.

You need a team that will be the extension of your own company, not just someone delivering lines of code.

Design

This is a huge topic, but I’ll go straight to my point. Unless it’s a more technology-specific MVP, which won’t require user experience at all, you’ll need the product design prior to the start of the development.

Discuss the flow between features on a screen by screen basis, go over the user experience back and forth and make sure everything connects smoothly.

You’ll also need a design team to materialize all your thoughts. Don’t try to skip the design process, otherwise there is a good chance that people will get lost while developing your app. Of course, there’s an extra cost for this stage, but believe me: it is worth it.

There is another reason for having a good design for the MVP: you’ll be able to get user feedback even prior to start the development, since many companies work with prototyped design as a standard. Yes – design MVP!

I recommend partnering with designers that work close to developers and understands both worlds, so they will be creative to design something that looks nice, but also simple to develop.

Full-Stack Engineering

There are many things you should take into account on the tech side of your development partner. One is their ability to work with both mobile and web stacks. Companies that handle only one will be inclined to offer you solutions within that specific stack. You don’t want that. You need a company that has technological capacity on both ends, mobile and web, and offer you what they believe it’s the best approach for your application. There are many discussions around building native and hybrid apps, as well as using different frameworks. Only partnering with companies that can develop products into different technologies will guarantee that they are proposing what they believe is the best approach for you.

6. Review the core feature list with the engineering team.

This step requires additional knowledge because you will review the list of features looking into the development side to come up with estimates of time and costs for each feature, thus having the final input for selecting the ones that you will want in your MVP.

It’s always important to evaluate your context. If your app has one core feature, already very simplified and that still will take a lot to develop, there probably won’t be much you can do. If you are willing to launch a proof of concept and get people’s feedback, you’ll have to pay the price.

Finally, even for those who decide that five or six features still fit in their MVP, it’s important to prioritize these features, since they still have to be developed in an order. This enables the dev team to release incremental parts of the MVP to a group of internal testers as they are developed, and help you keep a visual track of the progress in a more meaningful way.

Wrapping up

I hope you enjoyed our journey talking about the so called minimum viable product, the steps to come up with a solid MVP and some recommendations that can help you find the right partner to plan, design and develop your idea.

Don’t let your dreams obfuscate the fact that you can save time and money by having a well-defined plan for your MVP. Remember that there are companies that build many MVPs and working with a great company will definitely help you to come up with the best path to reach out your goal. Please feel free to share your thoughts/insights in the comments section 🙂

(Cover image credits: Freepik)