Menu

Avoiding the Wrong MVP Approach

by Jared M. Spool

“We could make our customers happier and save the company a ton of money, all at the same time.” That was the pitch behind the innovation team’s new idea.

Yet, many at this 120-year-old insurance company weren’t convinced. They thought it could never work.

The innovation team’s idea was conceptually simple: The insurance company’s claims adjusters use photographs to assess the damage and fill out claims reports. Instead of sending professional photographers out to take the pictures of damaged vehicles and homes, they’d let customers send in their own pictures.

The company pays those photographers a lot of money. Plus, there aren’t enough of them, so customers often have to wait. Customers often need to be present when the photographers show up, which means missing work or other responsibilities. The current process is slow, frustrating, and expensive.

On the surface, it seems like a great idea. However, there are questions to resolve. Could customers take photos good enough for adjusters to do their job? These photographers go through extensive training to ensure the pictures capture the right information.

What about an MVP?

The claims processing product team was chartered with figuring out how to make something like this work. In the olden days, they would just dive in and build working functionality, hoping it would work great when launched. But, it never worked great.

To prevent a poor launch experience, the executive team had latched onto this idea of a Minimum Viable Product or MVP. They could create and deliver an MVP quickly, to see if this idea of customer-supplied damage photos might work for the claims adjusters.

What exactly is an MVP?

For many organizations, they’ve come to use MVP to mean a less functional, limited implementation application. Build it quick, get it into the hands of customers, and see how they like it.

Yet, a limited functionality version, for customer-supplied claims photos, would still be a lot of work. They’d need a way to upload the photos to the company mainframe systems, used for claims processing. They’d have to build something that attached the photos to the correct customer’s claim records. They’d have to change the adjusters’ workflow to let them know the customer had added new photos. That’s a lot of difficult system-wide changes for something that’s an unproven idea.

This isn’t how MVPs are supposed to work. Eric Ries, who coined the term in his book, The Lean Startup defined an MVP as something that “allows a team to collect the maximum amount of validated learning about customers with the least effort.” The innovation team could learn about customer-supplied photos with a lot less effort than building a limited functionality version. So, they did.

Iterate on the learning

The team started by breaking down the questions they needed to answer. The first question was, could they get customer-supplied pictures that would be good enough for the claims adjusters?

To answer this question, they simply recruited a small handful of claims agents to help with an experiment. When those agents would get a call from from a customer opening a new damage claim, they’d ask that customer to send in some photos. Maybe those photos would be good enough?

Turns out, they weren’t. The customers didn’t know what the claims adjusters would need, so the pictures didn’t have the right information. (My favorites were the customers took smiling selfies of themselves in front of their damaged home. Fun pictures, but not good enough.)

The team iterated. They asked the same claim agents to repeat this experiment, this time sending the customers specific instructions on what to photograph. The pictures that came back were better, but still not good enough.

The team iterated a few more times. Eventually, they hit upon the right set of instructions to do the job. The pictures coming in from customers were now good enough for the claims adjusters to do their work.

MVPs: No coding necessary

Without writing any code, the team learned what they needed: customers could supply valuable pictures. That was only the first step, but it was a big one. (Next up: could they easily get those pictures into the existing claim system?)

MVPs often don’t need code, but teams forget this. Our organizations are so used to solving every problem with software that we forget that we can learn what we need by faster, more effective means.

The teams that use MVPs most effectively focus on what you need to learn first. Then they ask how they can best learn it. Often, you can avoid writing any code altogether.

About the Author

Jared M. Spool is a co-founder of Center Centre and the founder of UIE. In 2016, with Dr. Leslie Jensen-Inman, he opened Center Centre, a new design school in Chattanooga, TN to create the next generation of industry-ready UX Designers. They created a revolutionary approach to vocational training, infusing Jared’s decades of UX experience with Leslie’s mastery of experience-based learning methodologies.

How to Win Stakeholders & Influence Decisions

Did you know you can influence the most important decisions in your organization... and love your work while you do it?

You can, and it's your time to make it happen. Not only is it your time to influence the most important decisions in your projects, it's also your time to influence the most important decisions in your organization.

Get the tailored support you need to have your stakeholders trust you 100% so that you go to work every day knowing that you're doing the work you love and serving your users' needs -- all without being micromanaged by stakeholders.

Join our How to Win Stakeholders & Influence Decisions program!