Avoiding the Wrong MVP Approach

“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.