Minimum Viable Product in Agile Development

For new entrepreneurs, building a minimum viable product (MVP) is synonymous with creating a new digital product. While this isn't accurate, it's not a bad thing. Minimum viable products are a great way to keep costs low and test ideas quickly.

The problems usually start when the same clients ask when their completed product will be ready. The answer to this question is "it depends" if you want to build a true MVP with an agile process or if you're looking to build a V1.0 of your fully featured product.

A true minimum viable product doesn't need to be pretty or fully automated. It should be the quickest path to providing the basic features of your product.

This sounds good in theory, but it can be a hard pill to swallow for entrepreneurs who are perfectionists. They've built up the idea of a game-changing product that will look beautiful and blow all its competitors away. But this is describing a V1.0.

Compared with an MVP, a first full version of a product can take months to design, develop and test. During this time, there's no chance for target audience to provide feedback and for the product to evolve. This approach doesn't fit with the concepts of agile development, but it's how the vast majority of projects are run.

In this article, we'll discuss how starting with an MVP is perfect for agile development and why this approach is the smart and less risky way for businesses to invest in new products.

Why does agile pair well with the MVP concept?

One of the guiding principles behind agile development is responding to change over following a plan. In the real world of software development, this means building a product in small pieces so quick adjustments can be made along the way.

Since your team is already set up to adjust to change, they should be prepared to quickly take on user feedback when the MVP launches.

A minimum viable product is the most lightweight version of a new product that can hit the market and be useful for users. This doesn't mean it's poorly designed or developed. Rather, it should be limited in what it can do. Users should ask for more features or for things to be changed.

Pairing agile with a MVP process gives your users the tools to drive the product development process. Think about it this way. You've got a list of 50 new features to build but you only have the time and money for 10 right now. Everyone on your team has a different opinion about which features will be the most valuable for target users. The best way to end these arguments is to hand the microphone to your users and ask them directly.

MVP Waterfall?

One of the other popular approaches to building software is called waterfall. Most agencies and developers accidentally fall into the trap of building waterfall products, even though they claim to be running agile processes.

Waterfall is defined by planning. All the features to be built are organised and defined at the start of the project and scheduled into a plan so the team can linearly work through them, start to finish.

In my opinion, there's nothing wrong with building an MVP using a waterfall approach as long as your MVP doesn't take months to build. If the waterfall planning doesn't extend beyond the MVP, then the product team can reap all the benefits of user feedback but with fewer interruptions to development, getting the MPV out the door quicker.

Many large teams have success with a kind of hybrid project management methodology where they plan a waterfall project and then execute it with scrum-style sprints and reviews.

So you've got a great business idea - a cautionary tale

Enough of the methodology theory. Let's talk about your product idea.

You've come up with a disruptive idea that solves problems other products on the market have failed to figure out. This product is something you've needed for a while, and you think other users will love it.

You research how to start and see thousands of articles talking about MVPs, gathering customer feedback, market research, developing a product hypothesis, and other overhead activities that don't seem appropriate for your idea. Your product already has competitors, so you guess there's no need to test the market. If your competitors, whose final product isn't all the hot, can acquire paying customers, then your idea should have no problem.

You don't want to waste any more time, so shop around for quotes. After interviewing a dozen different development agencies, you pick one. The guys seem clued on, and they understand your vision.

The project goes smoothly, even though it's taken 8 months to finish the product. That's water the under the bridge at this point. It's time to launch your product and show up your competitors.

You do your best to generate some attention on Linkedin, Facebook, and TikTok. You run a handful of paid ads to get customers in, and it seems to be working!

A week later, you've got 100 free trial members. Your support chat is going off the hook. Users are asking questions you didn't expect. They're having a hard time understanding how the product works and seem to think that it's missing important features.

A couple of weeks later, all the trial members have left, and you're left with no paying customers.

The problem is clear; adding a handful of missing features and cleaning up the product's user experience (UX) would have converted most of the trial customers. However, you've spent all the money your business could afford to invest in this idea.

If only there was a different way to approach this problem.

There is, and it's building a minimum viable product with an agile methodology.

Why should we start with a Minimum Viable Product?

The story above highlights the reasons for starting with a minimum viable product.

1. MVPs help with uncertainty

The toughest part of software development isn't complex algorithms, machine learning, or artificial intelligence. It's picking which features to build.

Knowing which features users will choose to use is almost impossible without watching over their shoulders and collecting real feedback. The MVP approach provides a way to test if your product's combination of features will be useful.

2. MVPs can help with early cash flow

Product development is expensive. Most of the big SaaS companies you're familiar with have received hundreds of thousands (even millions) of dollars in investment to fund their products.

Unless you're shaking hands with investors, getting cash into your business to fund future development should be an immediate goal. If your MVP is valuable enough to customers, they'll be happy to pay for it even without all the great features you're planning for the long-term vision.

3.MVPs are cheaper than a full V1.0

MVPs are the cheapest and quickest way to market. Even if you're completely committed to your product idea and 100% certain it will succeed, it doesn't hurt to save some cash on the way.

4. Pivoting from an MVP is easier

Note that I've used the word "easier" rather than "easy". Modifying a product in any significant way isn't easy, and it can take a decent chunk of time. An early-stage MVP is the best place to pivot because the true foundations (like a design system, heavy integrations, and completed data model) haven't been laid.

How to get your MVP right on the first try

Just because you're building a lightweight product doesn't mean you should jump in without a waterproof plan. Going through a full product roadmapping process will save you countless hours and tens of thousands of dollars.

A product roadmap is a blueprint for your new product that lists everything required to build the MVP. In a similar way that you wouldn't try to build a house without a blueprint, you shouldn't try to build a product without a roadmap.

Our team specialises in helping entrepreneurs and established companies create their product roadmap. The process usually takes 4 to 8 hours of meetings and covers four steps; goals, flows, features and selection.

Note: you can absolutely do this process by yourself! However, there are parts where working with an experienced team are going to save you a lot of time and money.

Goals

Building a successful MVP is almost impossible if you can't define what will make it successful. In some cases, this is saving your team 10 hours of manual effort each week. In others, it's building a new service and reaching 1,000 paid users in 12 months.

Different goals will influence the kind of design and development decisions during the project. For example, if the tool is being built to improve staff efficiency and is intended for a team's internal use, there's no point in adding tool tips or dumbing down the interface for the general public.

Our advice is to avoid overcomplicating this step. The best way to define success criteria is to answer these questions:

1. What problem are you trying to solve?
2. What happens after you solve this problem?
3. If you could wave a magic wand and create a new solution, what three qualities you’d most want it to have?
4. What does a win look like in this situation?
5. Where do you want your business to be in 6 months? 1 year? 5 years?
6. When do you expect this project to turn a profit?

When we walk clients through the Product Roadmapping process, we ask take them through a list of 25 - 30 questions of this vein that dig deeply into their goals. Almost everyone we've worked with has admitted they didn't think through this part before starting, and have gained some serious insights into what they're trying to do.

Flows

Recording user flows accurately is the secret to creating great software. User flows are the steps a user takes to achieve an outcome. A great example is changing your Instagram profile picture. The steps to achieve this outcome are:

1. Log in
2. Open your profile
3. Select to edit your profile picture
4. Browse your media gallery for a new picture or upload a picture from your device storage
5. Edit the photo if it needs cropping or filters
6. Confirm
7. Go back to your feed to double-check it's implemented

Digital product design needs to accommodate user flows in ways that make sense. It's a similar concept to sidewalks which need to be pathed logically for pedestrians to get to their destination quickly.

If you can't answer the question, "what do my users want to do with my app" then you need to take a step back and figure that out.

Features

Once all the primary user flows are laid out, it's time to break them into features, so you have a full list of everything that needs to be designed.

Our team have adopted a modified approach to writing user stories, which is a clean way of describing what a feature should do. Using our Instagram profile picture example again, one of the features would be photo editing.

The user stories for this feature would look like this:

Resizing & cropping

As an authenticated user
When I've picked an image to edit
And the image is displaying at it's default aspect ratio
Then I can resize the display area to make it bigger or smaller
And I can crop the edges of the photo to make it a different shape
So the photo will display at my ideal ratio and size

Filters

As an authenticated user
When I've picked an image to edit
And the image is displaying in the editor
Then I can apply any available filter
And the filter will visually apply to the image
So I can see how the filter will change the image

There's no shortcut through user stories.

Our team will spend a day or two reviewing each story and agreeing on an effort estimate. If the quote doesn't fit our client's budget, they get the chance to pick and choose which features they'll combine to make the project the right investment size.

Selection

Once you've got a full list of the features that could potentially make up your application, it's time to decide which ones will make up your MVP. It's best to be analytical during this process otherwise, you can end up trying to build a product that's more of a V1.0 than an MVP.

When we go through this process, we'll assess each feature to determine:

1. Can it be handled manually while the app is getting off the ground?
2. Can we implement a workaround that will achieve the same goal?
3. Is the feature critical to the MVP's unique value proposition?

If a feature can't be handled manually and there's no workaround, it's in contention. If the feature isn't part of the MVP's core value, then we'll leave it for later.

Finally, when the list of features is laid out, it's time to determine how long the MVP will take to build. If the estimates indicate the MVP will spend more than a couple of months in development, we'll look for quicker approaches for some of the bigger features.

Is product roadmapping worth the effort?

Yes, it's 100% worth the effort. Having a plan for everything that will go into your MVP is a huge time saver. You'll have to coordinate between different team members as your MVP comes together (unless you're doing it solo). Having a single source of truth to point at when explaining how things should work keeps everyone on track and results in better products.

How to build your MVP

We recommend taking one of two approaches to build your MVP;

1. No-code prototype
2. Coded prototype leveraging micro-services

No-code prototype

Using the no-code approach, you become the system designer and developer. It's significantly quicker than writing code if you have a clear vision of what you're building and how it will piece together.

The no-code prototype works best for businesses that are productizing a service. For example, an MVP for an online subscription-based individual health care planning service. Technically, this example only needs a customer-facing website to explain the concept, a form to collect the details, calendar software to schedule the appointments, a customer relationship management system to hold details, and a payment processor to collect fees.

These are all the tools required to build this idea:

• Website: Webflow
• Forms & CRM: ConvertKit
• Calendar: Google Calendar & Calendly
• Payment Processor: Stripe Forms
• Integrations: Make

Alternatively, you could manage the entire thing in a dedicated no-code MVP service like Bubble.

The downside of this approach is:

1. You need to have thought through how everything will connect which can be hard if you're not technically inclined
2. There will be features you can't build
3. If you want to jump to a coded product, you'll need to start from scratch

Coded prototype leveraging microservices

If you're building an MVP for your business idea and have some cash to invest, this is the best option. Even though the goal is to build a robust, scaleable product, time can be saved by piecing together pre-made services.

For instance, if you were planning on creating a new streaming service to compete against YouTube, rather than building your own encoding engine and video player, you could leverage a service like Bunny.net, which offers both of these features. Similarly, instead of building a custom content management platform, you could modify an open-source CMS like Strapi.

The idea is to modify existing tools rather than build everything from the ground up. These parts can all be rebuilt in the future when you've achieved reliable cash flow.

Takeaways

If you take anything away from this write-up on building an MVP with agile, it's that you want to test your concepts quickly and often. The trap too many entrepreneurs get caught in is wanting their MVP to be perfect. If it's perfect, then you're moving too slowly.

Q&A

Have questions that we haven't answered? Leave a comment below, and someone from our team will get back to you in a day or so!