They say that if you're aiming for faster, cheaper, and better, you can only choose two. But the Agile principle of the Minimum Viable Product (MVP) allows you to start out fast and cheap and then move toward the best version of better with the benefit of acquired insight and experience.
The MVP is a key component of the Agile philosophy. It is a first draft of a project, including only the most important components that are required for the product to be functional. Focusing first on critical functionality provides the most efficient way to get to a working prototype—delivered faster and cheaper than in a traditional project management setting. Once an MVP is functional, you can test it out and discover what works as expected while maintaining the flexibility to adopt additional functionality as insights emerge.
Most importantly, the exercise of defining an MVP forces the user to distill their work down to its core essence, to define what truly matters and what is critical. Even just the exercise of defining an MVP can spark inspiration and lead to breakthroughs in product design.
Agile is most commonly applied in software engineering, but you can easily adapt Agile principles to building actuarial models or performing pricing exercises. The key is to break a project down into small and manageable chunks, put them in order of priority, and then start at the top of the list. This method ensures that the most critical work happens first, that you get a first draft ready as soon as possible, and you have the flexibility to learn and adapt as you go.
In every corporate project in which I've been involved, ideas and plans evolve over the course of implementation. Sometimes you uncover an unexpected technical challenge, or a new idea strikes once a product has been simmering in your mind. Or once you start to build things out, assumptions don't pan out and the reality turns out differently than expected.
By starting with a core deployment, you leave room for flexibility and evolution. Mistakes are less costly because you haven’t overbuilt the wrong features or added unnecessary complexity. And in the event of a catastrophic failure, you have an early exit strategy without investing as many resources.
Adopting an agile philosophy and starting with an MVP requires a paradigm shift throughout an organization. It doesn’t mean you can’t write a 100-page manual, but it does mean you shouldn’t finish it before you start implementation. Starting with an MVP also requires buy-in from management because they must be comfortable putting resources behind something that isn't fully baked.
An MVP can be thought of as Day 1 of a project. It’s version 0.1, and there is a clear expectation that there will be Day 2 work requiring resources (Note: this is not the type of Day 2 work you put off for eight years until you realize that customers have already become eligible for a feature you haven’t built yet). After all, it’s often much easier to revise a bad first draft than it is to craft something eloquent and thoughtful from scratch.
Check out my upcoming webinar, Agile Development for Actuaries and Insurance Professionals, on April 24 at 1:00 ET, where I will dive into Agile best practices and discuss how they can be implemented throughout insurance companies and actuarial work.
Laura McKiernan Boylan, FSA, CERA Laura heads the Risk Selection team at Haven Life, MassMutual’s in-house startup that is setting the pace for innovation in life insurance. She works with a team of software engineers to build technology that supports direct-to-consumer life insurance sales and underwriting. Prior to joining Haven Life, Laura was an actuary at AXA US. She worked on predictive underwriting, financial advisor analytics, hedging, and reinsurance. Laura received an A.B. in Applied Mathematics from Harvard College.