What to Expect When Building A Minimum Viable Product (MVP)

At Viget, we often have clients come to us with ideas for a new app, but limited budget or time to get it launched. In their mind, they’ve envisioned a final product with all the bells and whistles needed to overtake their top competitor from day one. In reality, we know they need to get a product out quickly, recruit users, and then add features that make sense for both their company goals and their user base. This is when we would recommend an MVP approach.

MVP stands for minimum viable product, or, as entrepreneur and author Eric Ries writes the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort”.

Even the best, most complex applications on the web started out as an MVP. It needed to do just one thing, and do that thing well, to begin. Over time, features were added until they became the applications they are today.

Take Facebook for example. If you’ve ever read about the company’s history, or watched The Social Network, you may remember the original idea Zuckerberg and classmates toyed with was a site that would display pictures of classmates and have users rate if they were attractive or not. While that idea was quickly shut down, it soon morphed to an online directory of Harvard students. People could see who was in their class and find the friends of friends. That’s it - no videos, no albums, no reactions. This was their MVP.

So, for clients who may be ready to set out on their own journey to an MVP product, we’ve pulled together some things that are helpful to keep in mind.

What should I expect when building an MVP?

An MVP is your app’s first introduction to the world and will allow you to do several things: 1) hedge your risk by spending less time, effort, and money than you would on a higher fidelity product, 2) prioritize the features you think are most important or unique, and 3) learn from the market by collecting valuable user feedback to inform future versions of the app.

Don’t let the lower amount of time and effort fool you. Developing an MVP is a difficult process that requires clients to be responsive, make hard decisions, and remain flexible. Coming into the project with an open mind, a dedicated product strategy, and discrete user stories will put you on the road to success.

The most important thing to know at the beginning is that the focus of an MVP is functionality rather than aesthetics. Unlike websites, which are intentionally built around visuals and content, apps are about the relationships between data. Because of that, you need to be prepared to talk about what your app does more than how your app looks. To say this another way, your first dev demos are going to be far from beautiful - just check out an early demo for a client's email platform below. But that’s ok! We’re demonstrating the very basics of your product - your product is now accepting entries, or you have a database - and that is much more important than having a flat, static, but beautiful image.

It’s also important to be able to separate yourself from a list of “dream” features. If you’ve been thinking about this app for a while, you may have a mile long list of cool features that would set your product apart from the competition. That’s great! We want you to keep those in mind, but it’s important to understand that not all of them will make it into the MVP. It may be helpful to ask yourself: “What is the ONE thing that my users need to be able to do?” Then, focus first on the functionality that answers that question. Part of this may involve looking at services you can use now to eliminate the need to build that functionality right away - like relying on Google Meet for video conferencing rather than building your own person-to-person chat.

When building an MVP, it’s important to keep the user in mind. Be willing to get the app in front of them as quickly as possible, even if it still needs to be polished. As your users interact with your MVP, they’ll break things, or find ways that existing features are painful. There may even be some features they never even use! Gathering feedback from users will help you make a plan for moving forward, and bring definition to the features that will be most successful.

Stay focused on the very initial use case. From a business perspective, it’s important to think about contingencies before or as your app scales. But in an MVP, you shouldn’t build around “what if X happens?” or “we need a plan for when Y causes Z.” This can be an expensive trap to fall into. Wait until those things happen, if they ever happen, and then approach. In the meantime, keep your focus on the most simple version of the feature at hand.

Finally, leave time and space for future decisions. Throughout the MVP process, you’ve had to make a number of challenging tradeoffs. Perhaps you had to decide between doing one feature at a  deep level or doing multiple features at a very shallow level. It can be exhausting! Just remember, you don’t have to, and shouldn’t, make final concrete decisions when building an MVP. Your goal is to put an app in your users hands and retain a level of flexibility that allows you to incorporate their feedback and respond to changes in your industry.

Why is this process different than a site redesign?

Typically, designing a website happens using a waterfall methodology, which is a linear approach to development. You may start with content development, and once that’s approved begin design. After you’ve seen and approved all the page templates and mockups, the developers begin coding the front- and back-end. After this, there’s typically a dedicated QA period. The website will launch once everyone is satisfied with this process. This approach is popular because clients can make a lot of the decisions about how the site will look and work up front, before designers and developers even begin to work.

When building an MVP product, however, an agile approach is preferred. Agile development emphasizes iteration, testing, and incorporating feedback before moving on to the next iteration. This approach focuses more heavily on the user experience, team collaboration, and responding to user feedback. In this approach, you’re unlikely to get a blueprint of your product on day one. Additionally, your team will be required to make quick decisions throughout the course of the project. Because teams are focusing on just one or two features at a time, a delay in decision making can bring the project to a standstill. The benefits to this approach, though, are increased project control, the ability to quickly react to change, improved customer satisfaction, and a working product early on.

What should I look for in an agency partner for my MVP?

When looking for an agency to take your product from idea to an MVP, we recommend choosing a partner that has both designers and developers in-house. It’s crucial that these two groups are working alongside each other and are able to respond to changes in the project plan based on user feedback or other business decisions. Bonus points for agencies that recognize the iterative workflow needed for MVP projects and take a lean and efficient approach to staffing.

Look at the agency’s portfolio of work. Have they worked with startups in the past? Startups have a lot on the line when it comes to launching a product and getting it into users’ hands quickly - so it’s important to have a partner who values simplicity and is transparent when they spot unnecessary complexity. Additionally, agencies with startup experience understand tight budgets and can move your project forward by thinking proactively about constraints and allowing that to drive project scope.

You also want a partner who has built a product before. As mentioned above, building a product is a very different process from building a website. Agile, as a process itself, is iterable and dynamic. The team building your product should be able to guide you through the highs and lows of this process, know when it’s time to shift directions to meet critical deadlines, and build features with an idea for how they can scale in the future.

Here are a few MVP projects we’ve built at Viget over the years:

• Konfab
• Optify
• Privia

What happens after I build an MVP?

After launching an MVP, many clients choose to undertake a more formal approach to user testing and research. This could include 1:1 interviews with early adopters, shadowing users as they move through the app, or conducting surveys with a portion of your user base. We also encourage clients to collect qualitative data through platforms like Google Analytics.

Post-launch is also a good time to dust off that list of dream features. Think about what made it into the app, and what didn’t. Compare your list to the user feedback and think about how your app will scale. One approach could be keeping your existing features and working to make them more robust. Another approach could mean keeping the MVP versions of the feature(s) you have and adding more. Finally, work with your partner agency to figure out timing and needs.

Next stop, V1!