The Changing Face of Life Insurance
24 September, 2021
null at PolicyGenius Inc.
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.
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.
- 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.
Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader
As a Lead or Manager, one could naturally incline more towards being either people oriented or task oriented. Which is better? Do you know which side you lean more towards?
Kamal Raj Guptha R
Engineering Manager at Jeavio
Supporting principles on why being data led (not driven) helps with the story telling.
Head of Engineering at Xero
Why DevSecOps matter and what's really in it for you, the team and the organisation?
Head of Engineering at Xero
The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.
Head of Engineering at Xero
Recruiting right people is the single most important decision for the company. Building a great platform, product and company is hard. Getting the right people into the company is twice hard.
Senior Software Engineering Manager at Anaplan