Back to resources

The Changing Face of Life Insurance

Dev Processes
Leadership
Convincing
Ownership

24 September, 2021

null null

null null

null at PolicyGenius Inc.

Ben Picolo, Engineering Manager at PolicyGenius Inc., talks about an industry-changing that his team shipped amidst the chaos in the product line.

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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

10x engineer or 10x impact?

26 May

Hiring 10x engineers is hard for most companies. It’s a tough battle out there for talent. So how should most companies approach building their team?

Building A Team
Leadership
Hiring
Coaching / Training / Mentorship
Vaidik Kapoor

Vaidik Kapoor

VP Engineering - DevOps & Security at Grofers

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

Growing Through Different Engineering Lead Roles

8 May

Weiyuan Liu describes his experience moving up from an individual contributor, tech lead, and engineering manager.

Leadership
Coaching / Training / Mentorship
Career Path
Weiyuan Liu

Weiyuan Liu

Director of Engineering at Zillearn

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.