Minimum Viable Product (MVP) and Agile Development

How a Well-Defined MVP Lowers Risk, Preserves Cash, and Wins Overs Investors

Agile development begins with defining the Minimum Viable Product (MVP), but for most clients getting there poses a real challenge. Five Talent’s C-level execs Ryan Comingdeer (CTO) and Preston Callicott (CEO) join Digital Engagement Manager Reese Mercer to discuss the benefits of a well-defined MVP and some of the stumbling blocks to avoid along the way.

RYAN: When we start working with a client our first priorities are to define the project scope and determine an MVP. We ask, what is the fundamental problem you are trying to solve? And then we take the time to understand both their vision for the product as well as the practical constraints that may affect it. Of course, clients will tell you they want all the features they have envisioned. It is their job to be the visionaries. And it is our job as consultants to translate those visions into tangible results and measurable success.

There’s a very typical triangle in project management that considers cost, time, and features. When defining an MVP, we ask clients to identify what is most important: Time to market? Your budget? Or the features that differentiate your ?
For example, if a client says that time to market is the priority, it is likely that we will have to cut features in order to make sure we finish the product quickly and get it out the door before their competition. If they tell us they have a budget constraint, then we need to look at fewer features and possibly a slower timeline.

Once we set the priorities, we use an agile approach to go after the objectives. Really, the core of agile is MVP because you always want to build a minimum of what you need in order to measure how people are going to use it. The ideal agile process is that you develop that first milestone, wait for feedback, and then adjust before moving on to the next milestone. It’s a discipline that requires both flexibility and some patience, but doing it saves resources and time, as you are building a product that is far more likely to succeed in the marketplace.

Most clients are accustomed to a waterfall approach which starts with setting milestones in phase 1, 2, 3 and so on, and keeps cranking along regardless of the user feedback. Of course, if you disregard user feedback early on or wait to get it until the very end, you may have invested a great deal of money in a final product that doesn’t address your customers’ needs.

That’s why every milestone should have a KPI (Key Performance Indicator). Good measurements keep you focused on the problem you are trying to solve and help you evaluate its success. You can then step back and decide what items are “nice to have’s” and what are requirements. You may develop a really cool feature but if you have no way to measure its success, it’s not an MVP.

PRESTON: Facebook and Google are both great examples of agile development and the use of MVPs. Facebook identified their MVP at the outset, which was a product designed solely to get Harvard college students to to rate students side-by-side using the school’s “facebooks” of student images. This MVP caught on like wildfire and quickly spread to other campuses. Only after getting serious traction did they start to add new features, keeping what the user-base loved and getting rid of what they didn’t. This approach led to high adoption rates and lowered the overall development risks.

For Google, everything is a MVP prototype. It can be a prototype for years and have millions of users. But when they decide that it is really not taking off, they kill it. It happens all the time. It’s become the go-to market strategy for tech companies, leaving behind the “build it and they will come.” approach of yesteryear. Now it’s build a small piece and see if anyone cares. If they do, build out some more features and re-test.

The challenge is getting clients to pare down their initial product/service concept to a MVP. Even after they do, the agile approach requires an ongoing dialog between the software developer and the client, doing sanity checks after every sprint. The constant battle is to extract from clients’ gray matter what they think they want and balance that against what they say they want, which is often not the same thing. Once we get this nailed, the next challenge is to test-case to see if users gravitate to the solution.

For example, we may be going along doing exactly what they told us and find out two weeks later that it wasn’t what they had in mind. Doing a constant mind map between what they think and what they see is created ensures we are on the same page. The hardest conversations happen when we look at the KPIs and performance measurements indicating that the market isn’t reacting the way they had hoped and we ask them to adjust or pivot. For someone deep in his/her own vision, that isn’t easy. Yet, as stewards of our clients’ resources, we want to be associated with their measurable success, not just building what a client wants.

REESE: I have a lot of empathy for clients when it comes to making those adjustments. It takes a lot of energy to think through the workflow, the phases, and the milestones. Once you’ve taken the time to lay out phases 1, 2, 3, and 4, it’s hard to want to shift back and evaluate what needs to be changed. But if you’re going to succeed, you have to be fluid and go with what the market is telling you.

I also think that people have become more forgiving and more relaxed about their initial expectations when it comes to your MVP. It used to be that you had to hit them perfectly right the first time or you would lose them. But it’s apparent today that if it’s a tool they really want, users will embrace it. Look at how many people use Craigslist even though they have a terrible user experience.

RYAN: I agree. Your MVP doesn’t have to be perfect. That is the beauty of agile. You simplify the initial product down to its most important function and then capture and carefully weigh the user feedback. Setting user expectations in advance is critical too, particularly with early adopters. Smart companies lay out their features roadmap and invite users to provide feedback throughout the beta and launch. This gives users a feeling of ownership and allows the company to adjust as needed.

PRESTON: As innovators, we have to uncover answers to questions we don’t even know we need to ask. Having the discipline to define the MVP, to use an agile approach that demands measurement and user feedback ultimately makes for far better products and far more successful companies. VC’s value this approach when considering early stage investments. They want to know the least amount of money they have to spend to prove the concept in the market. If there isn’t any traction, it allows them to quickly pivot and retarget what the MVP does. This is the most effective and least risky way to find out what your users want and what the market will respond to.

Back in the early 1990s and 2000s, companies used to enlist user groups when developing products for the same purpose, then crafted a complete solution based on their findings (i.e. “waterfall” development). However, user groups are fundamentally flawed because, even if you get people who are the key targets in a room, there is a massive gap between what they think they need and what they will actually use. They only know how to answer questions about what they know and are familiar with. They don’t know what they don’t know.

A good example: back then, Yahoo and others defined how search engine results were searched and presented, normally surrounded by screen-spam such as ads. Users accepted it, but the Google founders didn’t. When they began defining their MVP, they didn’t talk to anyone, especially users. They came up with a whole new idea isolated in a trailer on the Stanford campus. They decided, “no one is telling us this is a viable approach, but we think the simplest way to do searches for users is to just have a search box and nothing else, and show the results in a clean, easy-to-use format”. Had potential users been asked, they may have rebelled at the idea of a box floating on white space. Yet the

Google founders knew how to answer a question no one else was asking. They had employed an agile approach to the process and it worked beautifully.

To sum it up, an agile approach with a MVP as the target is the best approach to spin up a new product/service while minimizing the risk and maximizing the ability to pivot when needed.

Leave a Reply

Your email address will not be published. Required fields are marked *