What is in common between Auto Insurance and Lean Startup?

​It has been over a year since I wrote about parallels between Agile coaches and surgeons, and since then, the idea of finding similarities where those are not naturally obvious inspired me on multiple occasions. Sharing another “similarity story” below.

In mid-2020, when the Pandemics started, I informed my car insurance company that I am staying at home and am no longer using my car. To my pleasant surprise, they sent me a $30 check (to be honest, this is less than 1% of my car insurance for three cars in NJ, but who counts!). In two months, however, my auto insurance agent sent me an auto insurance renewal bill. It was 4% higher than the previous one.

I called the agent to tell him that none of us is driving yet, and he answered that there were fewer people buying cars, fewer people buying insurances, and if they were buying, then basic coverage only, since there were few people driving and few cars on the road. As a result, cost overhead was higher for insurance companies, and they had to raise prices to pay their personnel and maintain their business. Keep in mind, mine is one of the largest insurance companies in America.

As much as I was unhappy with this raise, this logic made sense, so I paid an extra premium. This year, I got my next renewal. I clicked on the “View Insurance” button prepared to see the decrease. On the contrary, I was surprised to see a 9% increase again. At this time, I wrote again to my agent telling him that this increase is high and unexpected. The agent sent me back an e-mail stating that the more people are driving around, hence more risk and more accidents, so the company had to raise insurance costs again. You cannot win with insurance companies, I thought.

So, what does lean startup has to do with insurance companies, you will ask? The answer, in my mind, is quite simple. The essence of a lean startup is to validate hypotheses and make product decisions based on the result of this validation. Say, we want to start a meetup and we are not sure which title or description will attract more visitors. In this case, we may want to announce two sessions within another, well-established meetup, and check which one gets more attendees subscribed to it. Or a new professional training business sets up a website with ten different trainings  announced before those are even developed to get statistics on how many users expressed interest in signing up for each session. Or a new startup wants to validate their product idea for a new device, new software, or a new service, so they send their sales team to collect information on how many people are ready to purchase it, subscribe to it, or invest in it before the product is built.

When validating a hypothesis, it is extremely easy to fall in love with the solution vs. the customer problem that they need solving. I spoke with a bright and talented startup founder recently. She told me about her idea and the three-month research their team has done to prove it. They wanted to build software for a specific community organization. She told me that they spoke with hundreds of members of similar organizations and all of them were interested in their service. When I asked her about the subscription model, she told me that none of these members were ready to pay for it because usually, municipalities sponsor similar organizations. I asked her if they spoke with decision-makers within those municipalities, and she said that they have not spoken to them yet because all the members assured her that they would advocate for buying these services. When I asked her a question about TAM (total addressable market), she quantified the number of members of these organizations vs. the number of organizations or their CFOs.

I suggested that she speaks to CFOs within these municipalities and other relevant decision-makers instead to validate their hypothesis. In a week, she invalidated the hypothesis because she found out that though they also found the service highly beneficial, none of them could afford to pay for it. This finding allowed them to pivot and explore another business idea, which did not involve municipal investment.

This reminds me of how many years ago when running lean startup experiments for a test prep company, we focused on students and their experience. We gamified and customized our test prep apps, which did not impact the revenue. Why? This is similar to the situation with the startup founder above. Who pays for test prep apps? If it is SAT or ACT, these are not students, these are parents. Do parents care about gamification? They actually see this as a distraction. What they care about is the ability to see how their kids are progressing. Their most desirable feature is a progress dashboard, which addresses their pain point of not being aware of the progress their child is making while using this app. Once we built such a dashboard, sales immediately went up 15%.
​
What do all these three situations have in common? Using a little bit of intelligence and logic, we can validate or invalidate any hypothesis. The only way to avoid blind spots when working backwards from customer need is to be rigorous, narrowly targeted, and highly disciplined in answering the basic questions: who is the customer? what is the customer’s major pain point? how does our product help the customer in solving this problem? are they willing to pay for it? Only this way we will be able to build products that delight the customers, the actual ones, not the ones that we established using the flexible logic of a car insurance agent.