Selected work

Leading Design at Inbox Health

Running the design function at Inbox Health: initiatives, OKRs, capacity, research, and the people around the work.

Director of Product Design → Director of Product Design & AI Operations · 2026 · Inbox Health

Design work at Inbox Health spans at least 20 engineers and, at one point, four product managers, and I sync with all of them. In 2026 I set up design initiatives and OKRs, built a way to see where design time goes, and decided what design takes on and what it hands to other teams.

Results

• Design initiatives re-planned each quarter: 9 in Q1 2026, 14 in Q2, 7 in Q3, and 2 so far in Q4.
• 98% of design sprint tasks link to an initiative (sprints 223 to 243), up from none in December 2025.
• Design-led share of estimated design time: 66% in Q1, 83% in Q2, and 71% in Q3 so far.
• On-site research in Guatemala gave the product operations team its first backlog and playbook.

The difficult part

What shaped the work

I am the only product designer across a seven-app platform, so design time has to be split between design-led initiatives and the product teams’ roadmap. Healthcare rules still apply: SOC 2 and HIPAA access controls, audit logs, and accessibility.

Who I worked with

Design work spans the App, AI, Front Office, SRE and integrations teams, plus Sales and the Upfront team. I sit in the App Team’s daily standup, product trio grooming, and the scrum of scrums. The product operations team is led by a colleague; my research gave it its first backlog and playbook.

The Problem

Design time nobody could see

Before 2026, design work at Inbox Health was tracked sprint by sprint. Tasks did not link to company initiatives, so nobody could see where design time went or what it supported. In December 2025, no design sprint task linked to a design or product operations initiative.

Goals and Initiatives

Initiatives first, then OKRs

In March 2026, as Director of Product Design, I set up nine design initiatives. Each one names a partner team and a primary KPI, such as revenue growth, customer experience, or risk reduction. In April I wrote the design organization’s 2026 OKRs from those initiatives and added design system goals to the 2026 product OKRs.

I re-plan the initiatives every quarter: 14 in Q2, 7 in Q3, and 2 so far in Q4. From sprint 223 to sprint 243, 98% of design sprint tasks link to an initiative. By September 2026 the shipped design work included payment-plan summaries and payment dates, AutoPay attestation for manual card entry, reusable dashboard components, and the mobile number step for messaging opt-in.

Capacity

Where design time goes

I built a model that turns sprint points into estimated design hours for each initiative. It splits design time between design-led initiatives and the product teams’ roadmap: 66% design-led in Q1 2026, 83% in Q2, and 71% so far in Q3. The largest single item in Q2 was the support workflow research in Guatemala, at 272.5 estimated hours. Enterprise configuration work was deferred in Q2 because of engineering capacity and priorities. I then took it on myself and designed, built and tested it with the engineering team. The eligibility exploration was dropped after Q1.

Research and Product Operations

A first backlog for a new team

In May 2026 I led on-site research in Guatemala with our support team: 9 teammates shadowed across 14 sessions in two days, and 138 improvement opportunities logged. The product operations team, led by a colleague, took that research as its first backlog and playbook. A second on-site visit followed in October 2026.

People

The internship and new partners

I wrote the role for our eight-week summer 2026 design intern and onboarded the intern onto the same Claude Code build loop I use. I reviewed each pull request before it merged. The intern merged 14 projects into the design environment and joined 3 client calls. That work is in the design environment, not in production. I also took part in onboarding a new product manager, and I run design critique frequently.

The Role Split

One role, two functions

In September 2026 my role became one role with two functions: product design and AI operations. Most of my planned capacity moved to internal AI operations. Product design stays end to end, and it comes first when the roadmap needs it.

Decision record

Decide where internal automation work is tracked

In September 2026, seven new product operations initiatives overlapped almost exactly with automation work tracked under design initiatives. The design side had 23 linked tasks, and the product operations side had none.

• Link each task to both initiatives: A task on two initiatives counts its points twice and inflates delivered hours, and the rollup only reads the design list, so reporting gains nothing.
• Move the work to product operations at quarter close: One migration instead of task by task, but each moved task needs its old link deleted by hand, and the capacity model has to be refreshed.

The decision: I ruled out linking to both. At quarter close I created six AI-assisted automation initiatives under product operations.

Outcome: The Q4 design list went down to two initiatives.

Set when design comes first after the role split

In September 2026 most of my planned capacity moved to internal AI operations. My agentic workflows keep design and AI operations running at the same time, so the real limit is where my attention goes.

• Keep product design as my default: Small in capacity, because both kinds of work keep running. My attention would stay on design even when AI operations needed it more.
• Design first only to unblock committed roadmap work, protect customer outcomes, or settle a critical product decision: The roadmap gets less of my default attention, but I am never the blocker on committed roadmap work.

The decision: I took the second rule. When committed roadmap work is waiting on design, I move my attention to that screen until I am no longer the blocker. I picked up that habit in my consulting days. Product-experience problems go to product design, internal workflow problems go to AI operations, and adopted processes go to product operations.

Outcome: undefined

Next case study: Carrier LYNX