October 14, 2022

It’s not always easy to build and design an MVP. Building an MVP is about building a scalable foundation first. One that accommodates a specific demographic and user base, one that solves a specific problem, and has just enough features so that early adopters can realistically use and test it.

Index

• What even is MVP?
• Is it possible to design a Minimum Viable Product?
• Where do we draw the line?
• Why do we do UX and UI planning and research when building an MVP?
• A Slippery Slope towards product failure
• What does all of this mean?

What even is MVP?

We often speak about minimum viable products, as a first “production” release in a product’s lifecycle. The first release is to determine if the idea behind the product can work. This ideology is often coupled with phrases like, “release often”, “fail fast” and “agile development”. It can be further broken down into 2 steps. Releasing a usable (viable) product with essential features first (not minimum functionality) that solves a specific need, and secondly, gathering feedback from end users to improve the product. A minimum viable product is not a prototype.

However, during product development, we often feel that the words “Minimum Viable Product” or “MVP” are not understood by everyone as the same thing.

Source: reddit.com/programminghumor

Building an MVP is often misunderstood by product owners, clients, stakeholders, and even the development team as building a complete, fully-featured product, almost like a car being built on an assembly line. A car being built on an assembly line has a linear outcome, i.e. we already know how it will look and function when it is complete. Also, in this example, the car first needs wheels but cannot drive yet, then it needs a body, but it has no windows or engine yet, and finally, at the end of the assembly line, you have your finished product and it can drive, but it is not functional or “roadworthy” until the moment it leaves the assembly line. In the end, we spent a lot of time and resources building a car, however, midway through the assembly line we realised that the product only needed to be a bicycle.

When working with Agile, we aim to produce smaller, usable features with each release so that the product owner, stakeholders and early adopters can test the product and provide their feedback.

In our example above, instead of trying to build a complete car, we should have first done some research, listened to what early adopters said, and then we would have realised that we only needed a bicycle. It is much simpler and has similar features to a car, such as being a method of transport from point a to point b, however, is much easier to build and assemble. Furthermore, the users do not need to go faster than 30km per hour. Once the bicycle has been tested and feedback has been received, new features can be added, for example, an engine or motor so that it can drive faster.

Eventually, we can grow and scale the product, add 2 more wheels and expand the product to become a car, or something similar, depending on feedback received from users. The difference with this approach is that we already have usable features after our first release, very early in the product’s lifecycle. We also did not spend a lot of time and resources on unnecessary features. This helps us to make decisions early on in the process. We aim to build a minimum viable product, not a full-featured, “all options included” end product.

Is it possible to design a Minimum Viable Product?

It’s not always easy to build and design an MVP. When it comes to design and UX, many designers don’t like the term MVP, because it presents a lot of difficult challenges. Designers often ask:

• How can you design something when the final product is not yet known?

• Is it even viable to create a design for an MVP?

• Why spend time and effort in UX and UI research when the product will ultimately change?

• How can usability testing be done when working on an MVP? And even if usability testing is done, what good is getting user feedback on a car when the final product ends up being a bicycle?

I think these questions are all valid and can be answered and addressed by adopting a hybrid design model. Thus, focusing on an initial design (minimal yet functional), with the information and knowledge you have, and over time, creating space to adapt and change the design to keep up with the evolution of the product. Thus leaving enough space for future changes or adding flows later in the process.

After speaking to a UX specialist, I learnt that these questions are a bit outdated or perhaps from a newcomer’s point of view, and I decided to change my response to these questions. We should always expect a product to change over time (based on the customers needs, the evolving product or results from UX research that has been done). Also, as pointed out by the UX specialist, usability testing is only done on a product once it is in production, to ensure the product is actually usable. However, qualitative research happens long before that in the product’s lifecycle.

Continuing with my point above, we need to expect changes. We need to build and design with change in mind. In development, we talk about writing code that is ETC (Easy to Change), meaning that we intend to write code that is easy to maintain and that is modular and component-based, so that it can easily be changed later in the product’s lifecycle.

Nine times out of ten, this is the inevitable outcome of most products anyways. Products always change and are always evolving. The only difference is that we don’t rethink or disregard our initial research, we adapt and change it slightly over time. We listen to user feedback and change our assumptions.

This is rarely ever done right, which causes the design and user experience to become out of sync with the product being built, resulting in a usability nightmare. The design no longer makes sense for the product that was built, or what is being built no longer fits into the design. Many times, we also see major changes and features being requested in a product’s initial development phase after most of the UX and design research has already been done, and before user testing has taken place, thus resulting in many incorrect assumptions being made.

Source: https://me.me/i/when-the-product-owner-adds-a-new-feature-during-the-eaef386e0cd447bd81d720e5afc779b6

Where do we draw the line?

People get caught up in the glamour, trying to build a perfect system, trying to accommodate a single user, trying to change the product without enough feedback, and losing track of what they were trying to accomplish. The process turns south when teams fail to test products and features properly with actual users before releasing a product, thus resulting in unhappy customers and higher development costs with more risk. One of the biggest challenges during this process is keeping investors happy. However, I believe that if you explain this process to investors, they might be able to walk the path with you, rather than potentially harming the product with short-sighted decisions.

This doesn’t mean that an MVP is an excuse to write bad software or follow bad design principles. However, finding a balance between design, development, user needs, and customer expectations is important. All of this needs to be managed and managed well. A product owner needs to decide which features get priority, and which are placed on the backlog, but even more important, which feature requests (from stakeholders or themselves) are binned. To achieve a first production release, we need to make hard decisions along the way.

Chasing perfect software should never be the initial goal. Sometimes, we need a product that is good enough.

Source: reddit.com/programminghumor

You need to find the middle ground to get a product to production and meet customers’ needs. Although slightly in a different context (focused more towards software development, but the same principle can be used with product development), I enjoyed this quote from the Pragmatic Programmer, by Andy Hunt:

“You Can’t Write Perfect Software. Did that hurt? It shouldn’t. Accept it as an axiom of life. Embrace it. Celebrate it. Because perfect software doesn’t exist. No one in the brief history of computing has ever written a piece of perfect software. It’s unlikely that you’ll be the first. And unless you accept this as a fact, you’ll end up wasting time and energy chasing an impossible dream.” ― Andrew Hunt, The Pragmatic Programmer: From Journeyman to Master.

Why do we do UX and UI planning and research when building an MVP?

Building an MVP is about building a scalable foundation first. One that accommodates a specific demographic and user base, one that solves a specific problem, and has just enough features so that early adopters can realistically use and test it, but at the same time still resembles the end product. However, part of that scalable foundation is the user experience.

You’ve got to start with the customer experience and work back towards the technology – not the other way around. - Steve Jobs 1997

This is why initial planning and research are key. Before we start building a product, it is important to understand a user’s fundamental needs and manage their expectations. It’s just as important to understand how a user interacts with a system so that we can learn how to accommodate them and improve their experience. Doing this will build a user’s confidence in a product and incentivise them to return and continue using the product. One of the most common reasons for product failure is caused by “invisible friction”.

A Slippery Slope towards product failure

Building an MVP can sometimes be an extremely delicate process. We need to maintain a balance throughout the development cycle and each feedback loop, and if anyone in the process loses focus (the product owner or product manager, the stakeholders or investors, the development team, or the design team), the project can get derailed from its intended course.

Product owners and even development teams often lose track of what they initially set out to do, which is building an MVP. Over time, they treat the MVP as the end product, keep adding larger features before the first release, with all bells and whistles included, and without proper user feedback. There is no feedback loop or no reviews to ensure that everyone is still on the right track. Furthermore, the design and UX research stops after the first project sprint and is never revised or adapted. At the same time, pressure grows larger and larger as investors and stakeholders want to see the product in production.

Source: reddit.com/programminghumor

Project managers need to ensure that development teams stay on par with the project goals and build only what is required, as quickly as possible. This does not mean we are building unusable, suboptimal products, or that we will never achieve our end goal, it just means that we will get functional, usable features and meaningful feedback sooner. We can then release a product that our customers need instead of building a product that we like.

The same principles that form part of Agile development, form part of building an MVP. I always share this video with anyone who is not familiar with Agile development and product ownership, and I think it is just as relevant in this scenario.

I would like to conclude this article with a quote from the book “The Lean Startup”, by Eric Ries.

“In the Lean Startup model, an experiment is more than just a theoretical inquiry; it is also the first product. What percentage of people in the target market actually perform the behaviour you expect them to? The extrapolation won’t be perfect, but it will establish a baseline behaviour that will be far more accurate than market research.” —Eric Ries

What does all of this mean?

At the end of the day, you need to be smart when designing and developing a product. Choose your words carefully and be very specific the next time you say “I just need a simple app”. A simple application is a “hello world” one-liner. Applications are complicated by default. You need to listen to your customers, you need to adapt and change accordingly and you need to know when to say “no”.

Building a product is never a “simple” or “easy” task and the process is never perfect (really!), especially when building an MVP. Sometimes you need to be pragmatic and come up with quick and practical solutions along the way. As a product owner, you need to understand what it is you are building, especially if you have a small budget. You need to know how to manage stakeholder expectations, when to say no, and continuously help the development and design team stay on track to build the MVP. Don’t lose focus!

– As a web company, we build progressive web applications and small to medium-sized products that are MVP-focused while still performing a substantial amount of UX and UI research, conceptual designs, and adapting where it makes sense. If you are a product owner or a small to medium enterprise (SME) and require a web application or product solution, get in touch with our team at [email protected].

Back