How I Scoped a Car Insurance Decision Tool Into a Small Shippable Product

My working hypothesis was that car insurance is a better product problem than it first looks.

On the surface it seems like a narrow finance workflow. You get a few quotes, compare prices, pick one, move on.

In practice it is messier than that.

People are usually comparing a mix of:

• Comprehensive
• TPFT
• Third Party

And they are not just comparing price. They are also trying to hold onto:

• excess
• sum insured
• insurer name
• notes on what feels different between quotes
• the fact that different policy types are not direct substitutes

That often turns into a bad decision environment.

Too many tabs. Too many screenshots. Too much half-memory. Too much "I think this one was cheaper, but I can't remember what I was giving up."

That was the part I found interesting.

The problem was not that people lacked quote sources. The problem was that the decision itself was annoyingly hard to structure.

Why I thought this was worth building

I did not want to frame this as "insurance advice."

That is a different product, a different trust model, and potentially a different regulatory surface area.

What felt more useful was a decision-support tool:

• somewhere to enter your own quotes
• somewhere to compare policy types cleanly
• somewhere to make the tradeoffs visible
• somewhere to see where the knee point sits between premium and protection
• somewhere to come back to the decision without rebuilding the context from scratch

That fit Finance Watchtower reasonably well.

The broader product thesis is that a lot of personal finance pain is not "I need a more complicated system."

It is:

• "I need a clearer picture."
• "I need to stop losing context."
• "I need to reason about this decision without opening a spreadsheet."

Car insurance sits neatly in that category. It is recurring, slightly annoying, easy to mishandle, and important enough that people do not want to make the decision carelessly.

The product problem I was actually solving

Once I looked at it properly, the user problem was not "help me buy insurance."

It was closer to:

Help me compare the quotes I already have, understand what kind of policy each one actually is, see the tradeoffs more explicitly, and make a cleaner decision without pretending the tool knows what is best for me.

That distinction mattered a lot.

If I had aimed at "help users choose the best policy," the scope would have expanded immediately.

Now I would need to answer questions like:

• what counts as "best"?
• how personalised is the recommendation?
• how much confidence should the product claim?
• what advice-like wording needs to be avoided?
• how much insurer or policy metadata needs to be normalised first?

That path gets expensive fast.

It also quietly changes the product from a structured comparison workspace into something that looks more like a recommendation engine.

I did not think the product had earned that yet.

The framework I wanted the tool to encourage

Part of the product value here is giving users a clearer way to think, not just a place to store quotes.

One framing I wanted to make more visible was the knee point between premium and coverage.

If one quote is meaningfully more expensive, what is the user actually getting back for that increase?

That could mean:

• lower excess
• broader cover
• a higher sum insured
• fewer uncomfortable gaps in edge cases the user cares about

It could also mean not much.

That is where I think the tool becomes useful.

The point is to make those tradeoffs stare back at the user instead of leaving them buried across tabs. If the premium is, say, 20% of the car's value, that should feel legible. Maybe it is still the right choice for this user. Maybe it is not. But it should not stay hidden inside a quote flow that makes every option look vaguely reasonable.

I like product features that expose the shape of the decision without pretending to collapse it into one universal answer. Different users will have different risk tolerance, cash flow, driving context, and tolerance for downside. The product should help them see that more clearly, not flatten it into generic advice.

What the weak version would have looked like

There were two bad directions available.

The first was an internal-prototype version:

• keep everything client-side
• preload example quotes
• treat persistence as optional
• optimise for a nice demo rather than a durable workflow

That would have been fast, but not especially trustworthy.

If a user is entering real insurance quotes, losing that work across devices or sessions is a bad experience. It makes the tool feel toy-like.

The second bad direction was overbuilding:

• shared insurer catalog
• recommendation logic
• richer quote history
• advice-adjacent product copy
• a much broader insurance subdomain

That would have sounded more ambitious, but it would have delayed the point where the feature became genuinely usable.

So the real job was to find the smallest version that still felt real.

How I scoped it down

The version I ended up aiming for was narrower, but stronger.

The core decisions were:

1. Keep it inside the existing car module rather than turning it into a separate product.
2. Support the three core policy types as first-class user-entered quotes.
3. Persist the workspace to the backend so it survives sessions and devices.
4. Let users create their own reusable insurer labels.
5. Keep the product language informational rather than advisory.

That produced a much clearer v1.

The user can open a dedicated insurance workspace, enter their own quotes, compare Comprehensive, TPFT, and Third Party, save the data, and come back later without losing context.

That is not flashy, but it is a real product shape.

A small modeling decision that mattered

One detail I liked here was treating insurer labels as user-owned convenience data rather than trying to force a canonical insurer model too early.

Each quote stores its own insurer label.

The saved label list is just there for reuse and autocomplete.

That avoids a bunch of unnecessary complexity around renaming, deletion, and shared catalog consistency.

It is a small point, but it reflects the broader product choice: keep the first version honest about what it needs to be.

Why I cared about persistence so early

One of the easiest traps in product work is to confuse "the flow works" with "the product is usable."

For this feature, persistence was part of the product, not a polish item.

If someone is comparing insurance options over more than one sitting, or wants to revisit the decision after talking to someone else, the workspace needs to still be there.

That is especially true when the feature is about reducing mental load.

If the product makes users reconstruct the same context every time, it is failing at the exact job it claims to do.

What I deliberately did not build

I left out a lot on purpose:

• no recommendation engine
• no insurer marketplace
• no shared insurer catalog
• no purchase flow
• no advice-style "best option for you" language
• no broad insurance platform framing

Some of that may become useful later.

But I think it is usually a mistake to expand scope just because the edge of the current feature suggests a bigger category.

The better question is whether the smallest version already creates a useful decision environment.

That is what I wanted to test first.

What surprised me

What surprised me was that the strongest framing was not really about insurance.

It was about decision quality.

Once I stopped thinking of the feature as an insurance add-on and started treating it as a decision-support workflow, the scope got easier to judge.

The right question became:

"What is the smallest product that helps someone make this decision more clearly?"

That is a much better product filter than:

"What features do insurance tools usually have?"

My current view

I increasingly think a lot of useful product scope comes from identifying decisions that are important, recurring enough to matter, and still too messy for people to manage comfortably in their heads.

Car insurance fits that pattern.

The first version does not need to be smart in a grand sense.

It just needs to make the decision legible.

That is the part I wanted to ship first.