From handoffs to collaboration

Rethinking how we build products with AI

Nina Slazinik, Senior Product Manager · Megan Casebier, Senior Product Designer · Obie · Nov 2026

How we build changed, in three phases

Part 1 · The problem

Once everyone could build, everyone built alone

Before

Before AI, we worked in silos.

Product defined requirements, design created the experience, and engineering built it. The process was slow and handoff-heavy, but responsibilities and review points were clear.

Then

AI blurred those boundaries, but didn't improve collaboration.

PMs started writing code, designers built apps, and engineers designed experiences. Instead of collaborating earlier, we were building independently.

So

The result was work that looked finished but wasn't.

Prototypes moved faster, but without the cross-functional expertise to make them production-ready. Gaps surfaced later, creating rework.

Examples

Keep scrolling to see all three

The Design QA tool: a walkthrough comparing Figma designs to the review app, listing 52 issues, each with a design-versus-app comparison
I. Built by a designer

Design QA tool

A designer built a tool to help design, QA, and engineering track where the app drifted from its designs. It looked functional, but lacked the integrations and reliability the team needed. Making it usable required more engineering work, so it was abandoned.

How would you rate our homeowners product?

PoorFairGoodExcellent

What could be improved?

Coverage optionsPricingEligibility rulesSpeed
Send feedback
Illustration. Survey Studio is an internal tool.
II. Built by a PM

Survey Studio

A PM built and launched a survey tool to collect feedback on an upcoming insurance product launch. The code needed engineering rework to avoid degrading existing systems. It proved valuable: it's still in use and being expanded by other PMs and engineers.

Vera's admin dashboard, showing sessions, spend and the long list of training features in the sidebar
III. Built by an engineer

Vera

An engineer built an AI chatbot to answer and triage support questions, with 13+ features for training the model. Only three were needed for the MVP. Without early product alignment, it was overbuilt, and it took four meetings to clarify the workflow.

The problem wasn't that we were building outside our traditional roles. We wanted to keep experimenting with that. But we were seeing what happened when we built without involving the people who knew the parts we didn't.

The question became: how could we use our expanded capabilities to work together differently?

Part 2 · Our first collaboration experiment

Agency Onboarding: faster, but still one at a time

Our first intentional attempt to build together using AI moved much faster than before, but we were still passing one idea down the line.

The brief

Insurance agents are how we grow. As we launched new insurance products, we needed to onboard more agents.

Onboarding was manual. Our agency development team reviewed applications, verified licenses, cleaned up spreadsheets, and manually added agents to our system, taking roughly 7 hours a week, with hundreds of submissions a month.

The process wouldn't scale. With a new insurance product launching in 90 days, our goal was to grow agent volume 5x. We needed an MVP that could streamline reviews, enable one-click onboarding, and reduce manual effort by at least 70%.

The full proposal is internal; a summary is in the appendix.

~7 hrsof manual work a week
90 daysto product launch
5xagent volume, the growth goal
≥70%less manual effort, with a one-click review queue
The spreadsheet agency development used to track submissions, rows colour-coded by status, details blurred
Where it started: one spreadsheet, colour-coded by hand. Details blurred.

How we approached it: one idea, four people, in sequence

Step 1Step 2Step 3Step 4
PM
Built a working app in Cursor
Design
Redesigned it with Claude and Figma
Engineering
Rebuilt it in our approved stack in an afternoon
Engineering
Monitoring, deployment, maintainability
Step 1: the PM's Cursor-built intake form for agencies, filled with placeholder data Step 2: the redesigned agency review screen in Figma Step 3: the agency review screen rebuilt in the approved stack, with demo data Step 4: the agency review queue in production

Four people, four steps, and one screen that barely changed along the way. If you're squinting to find the differences, so were we. That was the problem.

What changed for agency development

Before: by hand

  • Clean up spreadsheets
  • Dedupe submissions
  • Check licenses
  • Follow up with agents
  • Add each agent to our system

Now: the tool does it

  • ✓ Review the submission
  • ✓ Click add
~80–90%of the manual work removedOur estimate, based on what the tool now does. The goal was ≥70%.

What we learned

We were still doing handoffs, just faster.

Each person contributed in sequence rather than shaping the solution together.

We made architecture decisions too early.

We knew onboarding would grow into a broader agency management platform, but hadn't fully explored that vision. We now have features in two applications to merge.

Design came in late.

Much of the design work focused on refining an existing solution rather than helping shape the product vision from the start.

But we proved we could move fast.

PM and design contributed production code, including UI changes through PRs.

Part 3 · Our second collaboration experiment

Agent Portal: everyone in from the beginning

Eight people across product, design, engineering, data, and agency development explored the problem together before committing to a solution. We tested more ideas, aligned on a long-term vision, and narrowed it down to one small, measurable bet.

Same chart as Agency Onboarding. Different shape.

We started with support conversations, not a solution

Our PM and designer reviewed broker support conversations in Intercom, looking for patterns in where agents struggled. Many were contacting support for things they should have been able to do themselves.

To move quickly in our early startup days, we'd pieced together an internal insurance system, a consumer-facing quoting flow, and additional functionality to serve agents. It worked, but we'd never designed an experience specifically for them.

Our hypothesis: What if we stopped adapting existing tools and explored what a purpose-built agent platform could look like?

The old agent portal login, a patched-together page
The portal, before: a patched-together login…
The old agent dashboard: the internal system with a thin dashboard on top
…and the internal system, doubling as the agent “dashboard.”

Discovery, with engineering in the room

Product, design, and engineering explored FullStory sessions, funnel data, and agency development feedback together. We identified three core jobs for the agent portal:

  1. 01Orient and activate me
  2. 02Recognize me and my agency
  3. 03Help me move business forward

Way more ideas on the table

With AI, we could prototype ideas in minutes instead of weeks, so we put far more concepts on the table, from smarter quoting and onboarding to agent performance insights.

We tested them with agency development and against session recordings, and narrowed them down to the few that held up. Some promising concepts, like a command palette, didn't survive when we compared them against real agent behavior.

Ideas we triedWhere we landed

The moonshot, built live together

After narrowing the ideas based on feedback, our PM and designer prototyped the long-term vision in Figma Make, working in the same file at the same time, with engineering involved throughout. We shared the clickable prototype across the organization to make the vision tangible and show what we were working toward, not as committed scope.

The moonshot prototype's My agency screen
Built in Figma Make. Demo data only.Open full screen ↗

Three workstreams, in parallel

Instead of passing the prototype from one person to the next, we split into parallel workstreams to figure out how to move toward the vision.

Engineering

Architecture

Recommended building within our existing application, with a separate route tree, application shell, and design system for agents, while preserving the option to split into a standalone app later.

Technical recommendation ↓
Product, design & agency development

Identify #1 opportunity

Analyze the agent funnel to understand where agents drop off and where engagement could improve.

34,327 agents
45.7% ever quoted
23.1% ever bound
Funnel metrics ↓
Data

Establish baseline

Define engagement metrics and build a dashboard to measure deeper agent activity and track the impact of future changes.

The MVP: announcements and an agent-first experience

The plot twist

After exploring dozens of ideas and prototyping an ambitious vision, agency development challenged our priorities.

They believed sharing updates on new insurance products and underwriting guidelines would give agents more reasons to quote and engage with the platform. So we changed course, and aligned on two smaller first steps:

1 · Give agents more reasons to quote

Let agency development share targeted updates on new insurance products and underwriting guidelines directly on the agent dashboard, then measure whether they drive deeper engagement.

2 · Start building an agent-first experience

Introduce dedicated navigation and begin separating the agent experience from the internal application without building a new app.

We'll measure the impact of both against the engagement baseline established by Data.

The moonshot dashboard, with timely updates for the agent at the top
From the moonshot: timely updates right on the agent dashboard, the seed of the announcements MVP.

What we learned

We collaborated earlier, not just faster.

Product, design, engineering, and agency development shaped the vision together, then split into parallel workstreams instead of sequential handoffs.

Different perspectives changed our priorities.

Agency development challenged our assumptions and changed what we built first. Data helped us understand agent behavior and define how we'd measure success.

Engineering shaped the architecture before we built.

Unlike Agency Onboarding, we considered how the new experience would fit into our existing systems while preserving flexibility for the future.

We separated the vision from the MVP.

We explored an ambitious long-term experience, then aligned on a smaller, measurable first milestone rather than trying to build everything at once.

Part 4 · What we know now, and where we're headed

AI lets anyone build, but it doesn't replace the judgment of product, design, or engineering.

It changes when and how we apply that expertise.

How our process evolved

Sequential handoffsBefore AI
Faster handoffs with AIAgency Onboarding
Exploring and deciding together before buildingAgent Portal

The biggest change wasn't building faster. It was bringing the right expertise in before important decisions were made.

Takeaways

Building alone isn't the problem. Staying alone is.

Independent prototypes are valuable, but turning them into products requires expertise across disciplines.

Prototypes are decision tools, not finished products.

They help us explore ideas, challenge assumptions, and align before committing to a solution.

The vision and MVP serve different purposes.

An ambitious prototype helps us see what's possible, but research and cross-functional perspectives determine what we build first.

We still need ownership, just fewer handoffs.

Each discipline brings different expertise. The goal isn't to eliminate roles, but to involve them earlier in decisions.

Where we're headed next

For the agency management platform

Agency development toolsAgent-first experience

We're building toward a connected experience. We'll start with announcements and dedicated agent navigation, then continue working toward our long-term vision, using engagement data and cross-functional conversations to decide what comes next.

For how Obie builds

We're continuing to experiment with AI and how our teams collaborate. We want to bring product, design, and engineering into discovery earlier, while empowering people to work beyond their traditional roles when it makes sense. That might mean designers contributing frontend code or PMs building internal tools with engineering support.

We don't expect one process to fit every project. Over the next six months, we'll try different approaches, learn what works, and keep evolving how we collaborate.

We don't have all the answers. But we do know that when anyone can build, our expertise doesn't matter less. We have more opportunities to apply it together.

Appendix

The supporting material

Most of our working docs live in internal tools, so we've summarised them here rather than linking out.

▸Agency Onboarding proposalSummaryInternal

Onboarding was a manual, fragmented process that wouldn't scale with a new product launch. The proposal set out a phased approach: replace the old web form with a secure intake form that collects everything up front, give agency development a review queue with one-click approval, and automate license checks.

  • Roughly 7 hours a week of manual work, hundreds of submissions a month
  • Goal: grow agent volume 5x within 90 days of launch
  • Target: at least 70% less manual effort
The first app's review queues: approved pending licensing check, approved, denied
The first version's review queues. Names blurred.
▸Agent Portal research & product visionSummaryInternal

Agents are a distinct, revenue-generating group with their own goals, roles, permissions and measures of success, but their experience had been layered onto a system that also serves internal teams and clients. Discovery combined support conversations, FullStory sessions, funnel data and agency development feedback, and landed on three jobs: orient and activate me, recognize me and my agency, and help me move business forward.

▸Technical discovery & recommendationSummaryInternal

Keep evolving the agent experience inside our existing application, and give it its own route tree, shell and design system so it can be redesigned as a separate product. The existing system already holds the data, quote-to-bind, policy management, agency relationships and agent licensing; separating it would mean rebuilding or re-exposing all of that. The structure keeps the option of a standalone app open for later.

▸Agent funnel & engagement baselineSummaryInternal

Of 34,327 agents, 45.7% had ever quoted and 23.1% had ever bound a policy. Data is building a dashboard to baseline four measures before the MVP ships:

  • Active agents: share of agents who quoted in the last 12 months
  • Portal engagement: sessions per active agent per month
  • Quote activity: quotes per active agent
  • Production: share of active agents who bound at least one policy
▸Proposed milestonesSummary
  • M0 · Engagement baseline (in progress)
  • M1 · Announcements + experience foundation: announcements on the dashboard, agent-specific navigation, a lightly reorganised home
  • M2 · Make home more actionable: timely actions, product and appetite guidance
  • M3+ · Broader portal evolution: visual refresh, design system, personalisation
▸Every idea on the tableIdea wall
The idea wall from Agent Portal discovery: concepts grouped by job
▸What we tried firstLo-fi concepts
Lo-fi concept: one screen designed for three kinds of agent
One screen, three agents
Lo-fi concept: Flight Deck, a dense dashboard for high-volume agents
Flight Deck
▸Moonshot: the guided tourScreenshot
The moonshot prototype's guided tour for first-time agents