Obie · 0→1 Product Design · Post-Acquisition

After a $500M acquisition, I had four months to design an entirely new line of business

Obie built its business on landlord insurance. After the acquisition, leadership needed to prove the platform could expand into homeowners—a completely different product with different carriers, different underwriting, and different users. I led the design from architecture through launch.

Dec → Apr
4 months, new line of business
Bind-ready
Shipped on deadline, zero blockers
3 packages
HO3 / HO5 / HO6 with seamless switching
Carrier-agnostic
Architecture reused across future carriers
Property Information screen
Property Entry
Package Selection screen
Package Selection
Coverage Customization screen
Coverage Customization
Role Senior Product Designer
Timeline 4 months (Dec ’24 – Apr ’25)
Team Product, Engineering, Underwriting
Platform Consumer Insurance Platform
01The Challenge

A new line of business in four months, with zero room for error

Obie was acquired for $500M on the strength of its landlord insurance platform. Almost immediately, leadership set a mandate: expand into homeowners insurance by April. This wasn't a feature add—homeowners is a completely different product with different carriers, different underwriting models, different risk profiles, and agent workflows that share almost nothing with landlord.

The timeline was December to April. The product had to ship bind-ready on day one—meaning real agents could generate real quotes that produced real policies. And the architecture had to be built to scale, because homeowners was just the first expansion. Every design decision had to balance three forces in constant tension:

Agent Speed
  • Quotes in minutes, not hours
  • Seamless package exploration
  • No forced restarts or data re-entry
Underwriting Rigor
  • Strict Markel carrier requirements
  • Insurance score calculation (new for Obie)
  • Live API calls tied to risk changes
Platform Scalability
  • Reusable patterns, not one-off solutions
  • Future carrier onboarding efficiency
  • Align with Project Runway strategy

On top of these tensions, hard technical constraints shaped every interaction: Markel rates required live API calls tied to risk profile changes, insurance scoring was brand new to Obie, rater performance meant no "ping on every keystroke," and validation rules varied by package type. We were building on top of a landlord-era backend that had never contemplated any of this.

The core design challenge: In four months, build a quoting system for an entirely new insurance product that agents could use confidently on day one—without introducing underwriting risk, performance issues, or irreversible states—on top of a platform that was never designed for it.

02Starting Point

The platform that got Obie acquired wasn’t built for this

Obie's $500M valuation was earned on landlord insurance—a simpler, consumer-facing flow with minimal underwriting complexity. Homeowners is a fundamentally different product: insurance scoring (brand new to Obie), multi-carrier package comparison, risk-based underwriting questions that vary by package type, and professional agent workflows instead of consumer self-serve. Almost nothing carried over directly.

Before — Landlord Flow
Landlord property information flow
After — Homeowners Flow
Homeowners property information flow
Before — Landlord Underwriting
Landlord underwriting flow
After — Homeowners Underwriting
Homeowners underwriting details

The landlord flow (left) collected minimal property data in a consumer-friendly wizard. Homeowners (right) required deep property characterization, carrier-specific underwriting, and professional agent workflows—built on top of the same platform, in four months.

03My Role

Sole designer on a four-month, post-acquisition bet

I was the only product designer on this initiative, working in close partnership with Product, Engineering, and Underwriting from day one. There were no requirements handed to me—I was in the room shaping what this product would be, how the system would work, and what we could realistically ship by April.

Defined the system before the screens

Before opening Figma, I spent weeks in FigJam with Engineering mapping when validation, scoring, and re-rating would occur in the flow—decisions that would be nearly impossible to change once development started.

Drove the hard tradeoff conversations

When Engineering wanted to lock identity fields post-scoring and Underwriting wanted full recalculation on every edit, I framed a third option that satisfied both—and got sign-off from both teams in the same meeting.

Built for the next carrier, not just this one

Every design decision was made knowing homeowners was just the first expansion. I designed a section-based, carrier-agnostic architecture so the next carrier onboarding would be a configuration problem, not a redesign.

04Key Decisions

Four decisions made under pressure that shaped the entire system

With a four-month timeline, there was no room for "we'll figure it out later." These were system-level architectural choices that had to be made early and right—because reversing any of them mid-build would have blown the April deadline. Each one required navigating competing stakeholder needs and making a call under real ambiguity.

01
When to trigger carrier rate calls
Balancing real-time pricing feedback against API performance and cost
The tension

Markel rates required live API calls tied to the risk profile. Agents expected instant pricing feedback, but calling the carrier on every input change was both technically risky and performance-prohibitive.

Options evaluated
  • Re-rate on every change — best UX, highest performance risk
  • Lock data after submission — safest system, poorest UX
  • Explicit re-rating checkpoints — predictable, performant, safe
Impact

Agents could understand when a change would affect price instead of experiencing opaque refreshes. System behavior became predictable while protecting against unnecessary carrier API calls.

02
Editing identity data after insurance scoring
Allowing natural corrections within a backend that assumed immutability
The tension

Homeowners required insurance score calculation for the first time at Obie—scores required PII and couldn't be recalculated arbitrarily. The landlord-era backend assumed identity data wouldn't change post-scoring. But agents routinely discover corrections mid-quote—and rebuilding the backend was off the table with an April deadline.

Options evaluated
  • Lock identity fields after scoring — breaks agent workflows
  • Allow edits without recalculating score — requires backend coordination
  • Recalculate score on every change — compliance and performance risk
  • Rebuild client infrastructure — ideal, but out of MVP scope
Impact

Bridged the gap between the landlord-era backend and homeowners requirements without the rewrite we couldn't afford. This became the pattern for every subsequent case where homeowners needed something the existing infrastructure didn't natively support.

03
Supporting package switching mid-flow (HO3 ↔ HO5 ↔ HO6)
Enabling fluid comparison without data loss or flow restarts
The tension

Agents needed to compare packages fluidly, but HO5 requires 10+ additional questions compared to HO3, with only 30% of questions universal across packages. Restarting the flow would mean re-entering substantial data. The easy path was to lock package selection early—but that would have broken the agent workflow and created technical debt for every future carrier.

Options evaluated
  • Lock package once chosen — simplest, broke agent workflows
  • Allow switching with full reset — data integrity, unacceptable time waste
  • Seamless switching with intelligent data preservation — best experience, most complex
How data preservation works during package switching
Agent starts with
HO-3
Complete quote in progress
Universal data carries over
30%
Shared questions port automatically
Only new questions surface
10+
HO-5 specific requirements
Switch back anytime
0 loss
Original quote preserved
Impact

A discovery session that might have taken 20+ minutes with restarts now happened seamlessly in real-time. More critically, this established a carrier-agnostic pattern: new carriers' packages plugged into the same section-based architecture. New carriers became a configuration problem, not a design problem.

Live Flow Package switching in the final quoting experience
Package selection showing seamless switching between HO-3 and HO-5
Agents can explore available packages across carriers and switch selections without data loss or flow restart.
04
What to expose vs. hide in coverage customization
Reducing cognitive load without sacrificing underwriting completeness
The tension

Homeowners has dozens of coverage options—many required for underwriting but not meaningfully actionable by agents during quoting. With four months to ship, we couldn't design for every edge case. But hiding too much risked agents feeling they lacked control over a product they were binding for the first time.

Options evaluated
  • Surface all adjustable and optional coverages — overwhelming, slows quotes
  • Hide advanced coverages entirely — agents feel loss of control
  • Curated MVP set, with others available post-bind — focused, shippable, expandable
Impact

Reduced cognitive load and accelerated quote completion by surfacing only what agents could actually act on. More importantly, this scoping decision is what made the April deadline possible—we shipped a focused, bind-ready product instead of an incomplete ambitious one.

Final Design Curated coverage customization experience
Coverage customization screen showing curated coverage options
Scroll to explore full screen ↓
High-signal, agent-actionable coverage options surfaced for quoting. More technical coverages reserved for post-bind policy editing.
Design for flexibility at the agent level, safety at the underwriting level, and repeatability at the system level.

This principle emerged from the four decisions above and later guided broader platform work under Project Runway.

05System Architecture

Designing the system, not just the screens

With a four-month timeline, getting the architecture wrong would have been fatal. Before opening Figma, I spent the first weeks in FigJam with the lead engineer defining how state, validation, and rating would behave as agents moved through the experience—decisions that would be nearly impossible to reverse once development started.

We started with rough system diagrams, then moved to screen designs, then prototyped the package-switching behavior. Underwriting signed off on every question set for each package—a rigorous validation process that ensured the data mappings were correct before a line of code was written.

System Map Final architecture for the Markel Homeowners quote flow
Choose
Product Type
→
Insured
Profile & Address
→
UW + Property
Questions
→
Show Packages
HO3 / HO5 / HO6
→
Agent
Chooses Package
→
Customize
Coverage
→
Quote &
Checkout
Dynamic checkpoint
Package branching point

Section-based underwriting architecture

Rather than designing a one-off homeowners flow, I built a reusable, carrier-agnostic framework. Underwriting rules, validation logic, and derived values were embedded directly into the UI structure without exposing complexity to agents.

✓

Carrier-agnostic framework — Questions rendered dynamically from carrier rules, new carriers plug in without redesigning flows

✓

Section-based reuse — Same property and underwriting sections reused across homeowners, landlord, and future products

✓

Safe, reversible editing — Agents move forward and backward while the system controls when validation and re-rating occur

✓

Progressive risk disclosure — High-impact underwriting questions surface early; standard properties take a low-friction path

Annotated Screen Underwriting details — section-based question architecture
Underwriting Details screen showing section-based architecture
Scroll to explore ↓
Each section maps to backend data calls and save moments, making the system naturally package-agnostic.
06Platform Impact

The acquisition thesis, validated by architecture

Obie was acquired on the bet that its platform could expand beyond landlord. The most important outcome of this project wasn't the homeowners product itself—it was proving that bet right. The architecture I designed made future carrier expansion a configuration problem, not a design problem.

Without this architecture
Markel HO3 → Custom flow
Markel HO5 → Custom flow
Nationwide HO3 → Custom flow
Future Carrier → Custom flow
Each carrier × package = unique design + engineering work
→
With carrier-agnostic architecture
Shared section-based framework
Markel HO3
Markel HO5
Nationwide HO3
+ Future carriers
New carrier = configuration, not redesign
Evolution Landlord customization (before) vs. Homeowners customization (after)
Landlord — Limited Customization
Landlord coverage customization
Homeowners — Full Customization
Homeowners coverage customization
07Outcomes

Shipped on deadline. Bind-ready day one.

Four months after kickoff, the system shipped on schedule with zero blocking issues. Real agents could generate real homeowners quotes that produced real policies—on a platform that four months earlier had never handled homeowners insurance.

Bind-ready day one
Zero blocking issues at launch
Full end-to-end quoting experience supporting HO3, HO5, and HO6 packages through Markel, shipped on schedule for the 4/6 launch date.
Carrier-agnostic
Architecture reused under Project Runway
Section-based patterns became the foundation for onboarding future carriers, reducing design and engineering overhead for each new integration.
Seamless switching
HO3 ↔ HO5 ↔ HO6 without data loss
30% of question data carries over automatically during package switches. Agent discovery sessions that previously required restarts now happen in real-time.
Instrumented
Validation metrics defined pre-launch
Quote completion rates, re-rating frequency, back-navigation behavior, and time-to-quote all instrumented for post-launch validation.

Quantitative performance metrics will be available following the April 6 launch. Instrumentation is already in place tracking quote completion rates, re-rating frequency, agent navigation behavior, and time-to-quote.

08Reflection

What I’d do differently

I’d push for agent testing earlier. We got the underwriting question sequencing right, but we got there through close collaboration with the Underwriting team rather than direct observation of agents using the product. There were late-stage adjustments to question ordering that would have been caught weeks earlier with even informal agent ride-alongs. In a four-month timeline, those weeks matter.

The broader lesson: when you’re building a new product on an acquired platform, the architecture decisions made in the first two weeks determine everything. The weeks I spent in FigJam before opening Figma felt slow at the time. In hindsight, they’re the reason we shipped on time.

The agents never knew there were three packages pulling from different question sets, different carriers with different rules, all running on a platform that was built for something else entirely. That invisibility was the whole point.