The Changing Face of Life Insurance

Problem

Early in 2020, my team shipped a significant new feature that changed the model for how we sold over half of our sold life insurance. Traditional life insurance underwriting follows a lengthy, invasive application process. Your application can take up to 30 - 40 days to be fully approved. Our new system would allow a significant number of people to get their health insurance over the phone within a day. We spent about 8 months building the MVP, and it was a great success.

Doing this required creating a complicated new distributed system, and we intentionally cut corners to complete the project on time. When we shipped it out, it became a massive success. Keeping it running, though, took significant manual engineering intervention. While spending significant efforts on maintenance, we had to add more features and carrier options, which made it incrementally more unsustainable and led to a tipping point. Despite keeping the service up and running for 6 months in this state, we needed significant reinvestment in the original systems to sustain the growth.

The essence of the problem was that sometimes justifying technical features to product managers and other leaders in and outside your organization is a challenge. Convincing those leaders that spending a significant amount of time on work that’s less visible can be hard to do.

Actions taken

My goal was to spend 1 - 2 months of the team’s time reinvesting in the distributed system we had already built. From something "crappy", to something that we needed to keep growing and sustaining the business.

To demonstrate impact for the product leaders in the room, it was important to us to demonstrate the customer problems this system created 一 what are the real problems it creates? We needed concrete evidence. We spent time documenting the specific problems caused by the existing system: more time spent waiting for a significant portion of our customers, painful back-and-forths with insurance carriers when applications weren’t in the expected state, and frustrated customer success teams that didn’t feel they had the information they needed to help their customers.

The original system was missing a cohesive definition of “success”. It relied on a hodge-podge collection of alerts to identify potential breakdowns. Because of this, we couldn’t reliably notify users when actions needed to be taken on the application.

I wrote up a strategy document to take to our product manager. Whenever I write up strategy documentation for technical work, I rely on the methodology proposed by the book "Good Strategy Bad Strategy." I compile the specific problems the product is facing, the underlying systems causing those problems, and how we need to rebuild the system or our processes to accommodate for that. Focusing on that user-facing story, and the reliability outcomes users expect, helps decision-making parties understand the problem. By framing the problem this way, I brought our product manager into the know on everything they needed to know to push on this problem as well as I could.

Information in hand, it was easy to lay out our argument to the CEO and talk about the problems in the technology and what we needed to rebuild. We planned to make sure that it was sustainable for the company, and in doing so, the CEO was impressed and product leaders endorsed the project. Using product-driven arguments was critical for getting the whole team on board with a gritty technical project.

Lessons learned

• When trying to sell a technical debt project, you have to start with the user. Try to figure out how users are impacted by something because, ultimately, the users are your source of business. If you can frame a technical problem in terms of how it is impacting your actual end-users, it would be an easy sell to anybody in the organization.
• You can rely on SLAs and SLIs in order to measure user outcomes. It gave us a strategy on what we could do and applied it on the chart to pinpoint how the problem was affecting our users. Although it is uncommon for more product-led organizations, there's no harm in giving it a shot. Take advantage of the tools from the product-facing side.
• Get small to large information written down in an accessible format for people to share and discuss. Also, when there is a problem, lay it out to the team in a way that helps everyone at every level to get aligned. Others might miscommunicate or forget a lot of the necessary details. There is no other successful way to do it.
• PMs are always looking to help you achieve the goals the team cares about. They want to help you push those tech objectives. By translating them into a language that they know and understand, they can drive those technical projects alongside you. Don’t ask your product people to be on the sidelines for technical debt objectives. Make it their priority as well.