What is an MVP?

An MVP is a work of art. It is a high-quality, sophisticated, and powerful system that has been built in a methodical and targeted manner.

An MVP serves the needs of its clients while enacting enjoyable and streamline experiences for its users. It keeps errors to a minimum and helps push forward a client’s global reach for innovation and change.

Any development team can build a solid software product. The key to building a Most Valuable Product, however, rests in an understanding of four essential constructs; the client’s core business values, product’s key functionalities and highest value add features and an incremental building strategy.

Before we start, let’s get one thing clear; building a website is NOT like building a building.

Software Development - Like a Growing Plant

When planting a seed, we do so with the knowledge that as the plant grows, it will evolve and change into something that cannot be perfectly predicted. The changing circumstance will influence the shape, colour, and overall presentation of the plant making it impossible to predict its “final” image in exactness. Developing software products is very much the same.

The seed for the product is planted in the initial meeting with the client. The plans are then laid and ideas begin being constructed into realities. As the product begins to take its first iterative shape and form, clients often realize that additional or different features could prove better for the user and more profitable for their business. Project requirements then often alter and change to meet these circumstances and the project’s scope and costs change along with it.

When building a building, the plans that are laid out in the beginning generally do not witness much (if any) change. The building is constructed in the systemized and enduring steps that were decided upon at the forefront of the project. Software projects, however, often grow and evolve as they progress. As a result, the vision being worked towards is almost always completed with preparedness for change that occurs as the project develops.

Additionally, when the construction of a building comes to completion, the building is done. There are no changes that can be made (at least without great cost to many). Software products have no “end”. They can and are added to, built upon, and altered to continue the product’s lifecycle in an infinite manner.

This dynamism is what makes software development projects more like a growing plant than the construction of a building.

Now that we’ve got that sorted out, let’s get to it!

How to Build an MVP

Conduct an initial scope meeting with your client

The first step when building an MVP is to have a great scope meeting with your client.

The client’s ‘goal’ for this meeting is to gather an idea of project costs and timeline. This will (understandably) be the goal for most of your clients. While it is your job to serve their needs as best you can, it is also your job to explain to your client that software is not designed upfront, executed, and enacted in solidified steps. Remember, building software is not like building a building.

When the question arises about cost totals (which it will), provide your client with an educated estimate but explain that the product being created needs to be developed in a manner that allows for changes in scope. You can reference our explanation of the plant growth analogy above should you require some inspiration ;)

Keeping all of this in mind, YOUR goal for this meeting is to obtain as much information about your client’s product as you can. The more information you have the better decisions you will make while actually coding.

1. Determine CORE business values

Core business values can be described as the principles, ideologies, and tenets that make a business tick. These beliefs, ideals, and codes are at the heart of everything a business decides to do and stands as the driving force behind their organization.

Basically, they inform how actions geared towards their business goals are fulfilled.

An elevator pitch can give you insight into these values. These 2 minute spiels are short, concrete, and have usually been picked apart to highlight the key values of an organization. However, to understand the core business values in relation to their envisioned product, you’re going to need to dive a bit deeper.

Start by asking them questions like:

1. Why do you want to build this product?
2. What do you NOT want this product to be?
3. Who is your target market? (Get them to be as specific as possible - i.e. voters between the ages of 18 and 35 who live in Alberta)
4. How will you know if we are successful in the first month? How will you know if we are successful overall?
5. What concerns do you have about this project?

When you feel as though you could deliver an elevator-style pitch about your client’s business, you have secured a solid understanding of their core business values and can proceed to inquire about product functionalities.

2. Establish Key Product Functionalities

When scoping out requirements for any project, it pays to stay as disciplined as possible.

As we mentioned before, software development is unpredictable. The more disciplined your scope management is, the more readily prepared you’ll be for the instances in which the scope changes. To stay disciplined in your scope management, you must have a deep understanding of the product’s envisioned core functionalities.

Start by asking your client questions such as:

1. Who will be using this product?
2. What role does this individual hold within the organization?
3. What pain point does this feature/product solve?

The goal here is to determine, with as much clarity as possible, the ways that the product will be interacted with and what problems it will be asked to solve.

Once you feel you’ve obtained an understanding of the product’s purpose, how it will be used, and the main tasks it will be asked to perform, you can start talking about product features.

3. Determine Highest Value Add Features

Not all features are created equal nor does every software build require every feature to function. In fact, too many features and your build will take too long and cost too much to be viable. However, some do prove more essential when building a functioning product. For example, a booking app for a therapist website or a shopping cart for an online marketplace.

These tools have an inherently high value in relation to the product they’re meant to serve because without them, users of the site wouldn’t be able to complete the site’s main function.

Certain features, however, can be added on at a later date, like a Google maps feature for the same therapy website or a customer service chat app for the online marketplace.

While these features are nice to have and will ultimately, enhance the user’s experience, in the long run, they are not essential for making the site run or performing key functionalities.

Rather than thinking about what features we can build in the first draft, we want to take a lean approach to product development and think about what features we can NOT build in our first iteration.

Think of this as the minimalist’s approach to software development. Stripping down conceptualized software products down from their fully “finished” forms to reveal the absolute barest frameworks with which the product can still solidly and effectively fulfill its purpose.

This ‘minimalist’ or lean development approach is key when building an MVP. It grants you the ability to make code modifications more easily, work in a more detail-oriented manner than tackling the entire project at once, and lets you pivot on the plan quickly when needed.

It also helps keep production costs down by getting the product out in front of real users quicker, simultaneously granting you access to valuable user feedback that needs to be considered when developing products for people.

It can be difficult to adopt this mentality if you’ve never tried it before. However, we’ve found that it helps to ask yourself the question

“Does the business model hold up if you throw this feature away?”

If the answer is yes, the feature should be built at the very beginning. If the answer is no, you could consider adding it at a later date.

Scope Meeting: Helpful Tips

1. Listen Actively

During your initial scope meeting, you need to be actively listening to your client.

This means that when your client is talking, you are intently listening. You are avoiding thinking about what to say next or what you should be responding with and are instead giving your client your full and immediate attention.

You are focusing on their words, visualizing their ideas, staying present, and conceptualizing the steps you need to take to manufacture these ideas into reality.

Active listening requires you to not only hear what your client is saying but commit it to memory (indeed.com). This helps you to respond in a manner that moves the conversation deeper.

This will help you understand the desired process for the product and help you develop something that satisfies these values.

2. Ask open-ended questions

Your client should be doing most of the talking during your initial meeting. You are there to gather as much information as possible so you can figure out how to turn their idea into a successful reality and to do this, they need to be telling you their ideas.

If you’re finding that this is not the case, you may need to frame your questions to be more directional.

For example, questions that employ idioms such as “how”, “what”, and “why” tend to be more effective for information retrieval than “yes” or “no” questions.

This is simply due to the fact that yes or no questions don’t dive deep enough into a concept to further your understanding of someone’s idea from their perspective. You want to get your client thinking about their product as systematically as possible. Asking them open-ended questions will help them describe their ideas to you in a minute and thorough way.

3. Seek more information

You want to ensure that your understanding of your client’s envisioned product is as comprehensive, function and feature accurate, and in line with their core values as possible.

Enlist the phrase “tell me more” when you think something can be dug into at a deeper level and don’t be afraid to revisit something at the end of the meeting if you weren’t 100% certain about it.

Your client will appreciate your commitment to their vision and you won’t have to second guess yourself while coding.

4. Summarize

Take a few minutes at the end of your meeting to clarify, with a summary, any lengthy discussions you made have had. Be sure to clarify what you understand the conclusion to be.

This will prevent any miscommunications that could end up derailing your project down the road in the case that something was misunderstood.

Additionally, you should give a summary of what each party is responsible for before the next time you meet. Again, this will simply provide clarity and set everyone on the right track before being able to wander off it.

Now that you have gathered a solid understanding of your client’s envisioned product AND deemed it viable, it’s time to get building!

Develop the Product

1. Address project concerns early

As mentioned in our initial set scope of questions, any concerns that you or your client have regarding the project should be brought up in your initial meeting. If not then, as soon as possible afterwards.

The earlier you’re able to pivot on a plan, the less amount of leg work that will need to be put into stopping and starting a plan that is already well in motion.

Backtracking, adjusting, and solving problems for features costs time, money, and headspace that simply can’t be afforded when trying to develop an MVP.

Your client will respect your dedication to their time and your team will thank you.

2. Develop in increments

As mentioned in the Features section of this guide, you want to make your first build as lean as possible. To do this you determine what the highest value add features are for your product and select them with a minimalist mentality.

Remember, we only want to build what we think the highest value add features are in our first build so that in the case our initial value assessment was wrong, we can pivot on the plan quickly and keep time and cost losses to a minimum.

When you develop your products in increments AKA keep your first draft as lean as possible, you have a much better chance at retaining this goal. It’s easier to bounce back from a month or two of costs than a year into a project.

For the first draft build, ONLY develop the features that serve to fulfill the key functionalities of the product. This will help you create the most user-friendly, cost-effective, and valuable product for your client.

3. Apply feedback from the first release

Having completed your first build, you can now launch the “barebones” version of the product as your ‘first release’.

The first release is intended to get the product out in front of real users, really quickly to help you obtain valuable user analytics and feedback.

As mentioned, the earlier real people get to use your product the earlier you can make changes to make it that make it more user-friendly.

4. Evaluate your success

Lastly, you will need to monitor whatever analytics were discussed with your client during the core business values briefing of your scope meeting. In the initial set of questions provided, we included:

“How will you know if we are successful in the first month? How will you know if we are successful overall?”

This question exists so that your team can obtain a measurable figure for determining your product’s success.

“People have to actually purchase it. It doesn’t matter how good a product is if, in the end, nobody uses it.” - Don Norman, The Design of Everyday Things

Whether it’s page views, conversion rate, average time on site etc., these figures will help you determine what your team did right or what needs to change to turn your product into an MVP.

And there you have it!

You have successfully developed your first MVP!!

We know it was a long and arduous journey but you have reached the mountain top.

Revel in your successes but prepare for the trek back down, your boss tells us you have a new project starting Monday…

Like and give this post a share if you found it helpful and informative and keep checking back for more development-driven content!!!