.png){kind=small}
Operation I.H.O.P.
The challenge
This three day workshop was intended to create a 100% self serve insurance product generator. The first of its kind, it was aimed at decreasing the amount of developer hours required to enter a new State while simultaneously allowing our Insurance team to create, modify, and test Insurance products in a quarter of the time.
The team
Design Lead and Lead Facilitator (me), Director of Product, Product Manager, Head of Research
The outcome
The ability to create a ready to use Insurance Product in 3 days. Which previously took over a month. Increased efficiency an Insurance Product Mangers daily tasks by bringing all their work and tools into one platform.
Who is Kin Insurance?
Kin is a mid-sized InsurTech startup named built-ins best places to work 4 years running, Forbes top 50 fintech startups two years running, who, by leveraging cutting edge technology and direct-to-consumer model, provide affordable insurance for some of most climate change impacted and least represented home insurance markets.
They sound great, so what's the problem?
Kin was planning on expanding their home insurance offerings into 10+ states in 2025 and the workflows for managing the fleet of insurance products weren’t scalable and were inefficient from a technical and business perspective. Without their own dedicated tool, Insurance Product Managers (IPMs) were stuck operating in a similar way to the legacy insurance agency’s that Kin sought to separate itself from.
Insurance products are managed in 10+ spreadsheets by up to 6 different people. Once these sheets are finalized they are submitted to the State Regulators for approval. The regulatory process can take 3+ months and depending on the state, the slightest detail can necessitate a change to be made, followed by a refiling. Once approved they are handed to the engineering team to build which would take at least month before they could launch.
How did we address the challenge?
An all in one 100% self serve Insurance Product generator called IHOP (Integrated Hub of Products). The first of its kind, it was aimed at decreasing the amount of developer hours required to enter a new state while simultaneously allowing our Insurance team to create, modify, and test Insurance products in a quarter of the time.
Our goal was to reduce the timeline by 3 months. To do this we'd need a tool that could be the source of truth, a repository of all things related to an insurance product. Something thats never been done by any legacy insurer in the game. Something revolutionary. Something Design Sprint-y.
We hosted a Design Sprint!
I was tasked as the Design Lead and primary facilitator. My responsibilities were to plan the 3-day workshop, determine the participants and presenters, outline the activities, and ultimately take the sketched out concepts and turn them in to a fully-clickable prototype for testing on the third day of the workshop.
.png)
Measure thrice, cut once!
01: Subject Matter Expert Interviews
purpose: understand the problem space and identify who qualifies as part of the core sprint team, as a SME presenter, or as a candidate for user testing.
Who:
- 3 Tech PM’s
- 3 Insurance PM’s
- 2 Engineering Managers
- 2 Engineers
What we learned on the Insurance side (Business)
- Insurance products are 4 things:
- State configurations - characteristics that transcend any given Insurance product offered in that particular state
- Insurance Product configurations - unique to each insurance product line
- Rates - an algorithm designed to accurately price a particular product
- Documents
- There were multiple sources of truth
- No clear ownership
- Change logs are non-existent
- For legal purposes, every released version of an insurance product needs to be stored
- Regulatory process unavoidable, inconsistent between states, and arduous
What we learned on the Product side (Tech)
- Most of the process requires simply copying a previous product then making several tweaks
- Changes after launch were inevitable and the code wasn't flexible enough to handle the frequent changes
02: Object Model the Backend
With the help of one of our Principal Engineers, a Engineering Manager and a Product Manager we got to work mapping out and identifying the parts of the system that would be affected by this work. We learned is that some of the changes would alter the fundamentals of how the system was built. We're proposing a large architectural change and as such we needed to understand the extent of its scope and the implications before we can get to creative problem solving.
03: Activity Planning and Logistics
I wanted to design a series of activities that maximized convergent and divergent thinking and allowed all the voices in the room to be heard.
Operation every voice heard:
I intentionally designed every activity in 3 phases:
- Individual brainstorming: where participants were encouraged to work with only the knowledge we gathered that day to formulate their own hypothesis for solutions
- Small groups collaboration: take what each person created at the solo stage and combine into a larger concept that’s reflective of everyone’s great ideas
- All together now: Then as an entire group unify the greatest hits from every concept into a solution that combines everyone's expertise and background
This was intentional for two reasons. First, not everyone feels comfortable speaking up and sometimes one voice can dominate the others. Secondly, if the end product is reflective of everyone’s ideas, then getting buy-in from an allocation of resources and accomplishing the work perspectives are that much easier.
Design Sprint time!
As the primary facilitator it was on me to steer the ship and keep everything moving on track.
Day 1: Understand the landscape and define the problem
01 Lightning Talks
Since insurance products are composed of 3 separate areas of focus we needed to get the whole group square on what each other does and why, as well as what pain points exist in the current workflow.
* Pivotal moment! We learned that we needed to put a lot of focus on maintaining the various insurance product offerings. This comprises a lot of their day and is a huge quality of life improvement
02 Taskflow Diagram
Following the every voice heard process outlined earlier, we mapped the process out from a user perspective to identify any pain points that could impede the effectiveness of our solution. When paired with our object model we had a great sense of any pitfalls that may impede our success.
Day 2: Concept Creation
With a firm grasp on the landscape of the problem it was time for us to draft and iterate on solutions. We started with the rapid idea generation exercise, crazy 8's, followed by a low-fi wire framing exercise in small groups, which we then combined as a full sprint team. The day ended with me and and an engineer turning into a mid-fidelity, fully clickable prototype ready for user testing the next day. While this was going on the rest of the team spent their time generating questions for the user testing sessions and discussing the technical constraints in preparation for the roadmap planning the following afternoon.
Day 3: Concept testing and road mapping
One of the goals of the UX Research team this year was to empower Product Managers to better understand our process of gaining insights into our customers. By having them not only sit in on studies but actually participating, we could get from data point to insights faster while fostering a desire to focus on user-centric solutions across Kin. This was a perfect pilot for this program and we even had developers running user interviews with our new concept!
We ended the three-day workshop with roadmap planning. This was important to include because often after design sprints its easy to look at the outcome as an insurmountable tasks when finished. Leading to potential delays or full blown postponement of the project and eventually design sprints as whole. This can be remedied by having the right people in the room but also taking the time to plan the work out in the subsequent months.
