The century-old insurance company puts customer feedback at the center of software development.
Liberty Mutual, the Boston-based insurance company, is a good example of a well-established, successful company making the transition to customer-centric software development. Its experience is instructive for other enterprises that, like Liberty Mutual, face new competitive threats emanating from Silicon Valley and rising customer expectations when it comes to the digital experience.
“There’s a lot of disruption happening today in the marketplace, in insurance and other industries,” said Johnathan Reardon, vice president and senior director of IT at Liberty Mutual. “We’re facing emerging competitors that deliver new capabilities to market very quickly. So we need to be able to respond in kind, and quickly and iteratively test and learn from our customers to get new products and capabilities to market faster than we were previously able to.”
Customer Driven Product Development
In the Spring of 2017, an opportunity for Liberty Mutual to start developing its user feedback muscles presented itself. At the time, there was no way for customers to buy motorcycle insurance from the company online. Customers instead were required to call Liberty Mutual and speak live to an agent in order to do so. Reardon and his team hypothesized that making it easier to buy motorcycle insurance online — or at least start the process online — would lead to more applications and sales.
The question was, what should the team build? In the past, that decision might fall to an experienced vice president of sales or director of product management. But not this time. Instead, Reardon’s team worked with Liberty Mutual’s research department to find a dozen or so motorcycle owners and conducted face-to-face interviews with each of them. They continued interviewing other riders throughout the development process.
The goal of the interviews was for the team to learn what parts of the insurance buying process were frustrating for the bike owners so they could target those areas for improvement.
“The first four weeks of the engagement were loaded with customer-centered design. Our designers paired with the Labs designers and we worked as a team to determine what product should we build,” said Justin Robison, a Liberty Mutual developer who was a part of the team. “Rather than dictating what we were going to build, we had to figure it out. So there were a lot of interviews, a lot of prototyping, more interviews and more prototyping.”
The team also listened closely to how the interviewees spoke about their “bikes” (not their “motorcycles”, as the team learned) to ensure the application that ended up getting built used terminology that real motorcycle riders would relate to.
Reardon and his team, who partnered with Pivotal on the engagement, took what they learned in the user interviews and sketched a rough outline of a Shoddiest Viable Product, or SVP. SVP is a term created by Pivotal’s Adam Piel. It’s a variation on the better known minimum viable product, or MVP, which has succumbed to scope creep at many companies. Instead of referring to a product that includes just enough features to begin testing with early adopters, MVP often ends up referring to a fully-featured 1.0 version of a product. That defeats the purpose of a true MVP, which is to elicit real user feedback as soon as possible.
“You truly don’t start learning until you deliver something to market,” Reardon said. “With our more traditional delivery methods in the past, we could spend 9, 12 months or more defining and then delivering the ‘perfect’ solution before getting it to market. That’s time wasted where we could be learning from our customers and improving the experience for them.”
Case in point: what emerged as the motorcycle application SVP, which the team dubbed Moto internally, was a simple web application that required applicants to answer a series of questions about themselves and their bikes. Once submitted, the answers were sent to Liberty Mutual insurance agents who put together a quote. The applicant then receives an email from the agent with the quote, requesting him or her to call the agent to finalize the transaction.
“We had a hypothesis that we could build this UI, capture a little bit of data, and drive customers to our offline channel,” Robison said. “The actual product wasn’t that novel, but it’s a good way to gauge interest in your product and also start getting some actual sales.”
It’s hardly a fully-featured, self-service application, but Moto was just good enough to reduce some friction in the motorcycle insurance buying process, deliver some value to customers, and start generating feedback in the form of usage data. That feedback may lead the team to work towards a more robust application over time, but it also may not, Piel said.
“Maybe we learn that people would rather enter their information online and then talk to an real-life person by phone to actually buy their insurance policy,” Piel said. “If that’s the case, maybe we don’t need to build certain features or deliver what might traditionally be considered a “fully-featured” application. We build software hand-in-hand with users, continuously and iteratively.
“We could have spent months developing a comprehensive, really robust application based on what we thought users wanted, but what if after all that time, money and effort nobody used it?” —Daniel Bliss, Liberty Mutual
Thanks to this approach, it only took 28 days to develop and deploy the SVP to production — a fraction of the time it would have taken to ship a more complex application that may or may not have served the needs of customers.
“This approach allows us to iterate and make incremental improvements over time, which really reduces the risk of failure,” said Liberty Mutual’s Daniel Bliss, a product owner on the team. “We could have spent months developing a comprehensive, really robust application based on what we thought users wanted, but what if after all that time, money and effort nobody used it? That’s a huge risk. Making continuous, incremental improvements gives us tons of opportunity to course correct.”
And course correct the team did. In the initial user interviews, the dozen or so motorcycle owners told the team that they would expect the application to first ask for their names, followed by more detailed questions about their motorcycles. But after the application was live for a couple of weeks, the team experimented by changing the order of the questions and instead first asked about the customers’ motorcycles — make, model, year, etc. — before asking for their names and other personal information.
“We got an eight point lift in the number of people that made it through the questions if we asked them first about their motorcycle and then their name,” Bliss said. “Just flip-flopping those two things increased completion rates considerably, but it went counter to what we heard in the interviews. It really showed the power of learning from your how your users behave with a real, live product, in addition to asking them in an interview what they think they want.”
Listen, Learn, Repeat
Learning from its customers wasn’t the only change Liberty made to its traditional software development process. Working with Pivotal Labs, Liberty employed a balanced team approach when developing Moto: A single team made up of product owners, designers, and developers is responsible for the app from start to finish, including supporting the application in production. This differed considerably from Liberty’s traditional waterfall approach, which required siloed functional groups (developers, QA, ops, etc.) to pass the application back and forth between them with no one group truly owning the product.
“The whole team feels like they have equal stake in the objectives we set, which aren’t centered around old school things like scope, schedule, and cost,” Reardon said. “It’s about what is the customer value, what is the business value and what are the KPIs that confirm whether we achieved those. And then the whole team is held accountable for them.”
The team also developed the application using microservices design principles to increase flexibility as the application grows and evolves, and it is running the application on Pivotal Cloud Foundry®, Pivotal’s enterprise-grade cloud-native platform. Pivotal Cloud Foundry helps ops teams automate tasks like provisioning hardware and it supports continuous integration and continuous deployment practices, critical for the type of iterative development now in use at Liberty Mutual.
“With [Pivotal Cloud Foundry], there’s a lot of abstracting away of messy details that engineers don’t want to worry about and that they don’t care about,” said Robison. “It’s simple for me to deploy and get my software running. It’s also self-service, so it’s easy for me to control the characteristics of my deployed runtime. There are no handoffs. Those are some big benefits.”
The motorcycle insurance application went live April 2017. Within ten hours, it had delivered its first quote. By August, about four months after launch and with virtually no advertising, the application was producing an average of 20 quotes per day and a nearly 11% overall conversion rate.
The user flow of signing up for motorcycle insurance at Liberty Mutual.
“That’s an impressive conversion rate for a brand new online application,” Reardon said. So not only did the application make it to market in record time, it also performed better than other Liberty Mutual applications that were, on first glance anyway, more comprehensive and feature-rich.
The team pushed 45 releases to production in the 55 days after the initial launch of the motorcycle insurance application, all based on how customers were interacting with the app. And the learning hasn’t stopped. The motorcycle application is a living product that the team continues to support in production and improve over time based on user feedback to increase both the quantity of quotes delivered and conversion rates.
“There were a lot of factors that went into making this engagement with Pivotal successful, but none of it would have mattered if we weren’t listening to and learning from our customers from the start,” Reardon said. “We now have a product mindset. The motorcycle insurance product is never finished. We just keep learning from our customers and making the experience better and better for them.”
Liberty Mutual is hiring! If you’re looking for an exciting opportunity to help a leading insurer transform how they build software, click here.
