Operating clarity for an AI-native clinical workflow
Product and design leadership for Nitro — turning a broad AI opportunity into provider-centered jobs, reviewable workflows, roadmap gates, and cross-functional decision discipline.
Product Design
De-risked an AI-native product bet through a five-provider research panel and a working prototype that providers completed unaided — before a line of production code was committed.
Held AI to drafting, synthesis, and recommendation; clinicians keep review, correction, and approval. Every provider tested validated the draft → edit → sign model.
Ran a signals → requirements → decisions traceability system across product, research, design, and engineering, so speed never outran accountability.
The work was less about making AI visible and more about making clinical responsibility visible.
Nitro is Tebra's ground-up, AI-native practice platform for solo mental health providers — the clinicians who run their own therapy and counseling practices. Rather than bolt AI onto a legacy EHR, the team reframed the entire product around the provider's day in six jobs: book and manage appointments, prep for the day, deliver care, get paid, the cross-cutting capabilities that connect them, and decide to buy.
I led product design direction across a cross-functional team spanning product, research, engineering, and PM, and directed an AI-augmented design workflow. My remit was strategy, design judgment, design-system stewardship, executive alignment, and review discipline — turning open-ended AI enthusiasm into jobs, requirements, gates, and artifacts that the whole team could inspect and stand behind.
Healthcare AI outruns accountability when teams optimize for generated output before the clinical workflow is clear. Nitro had to support real provider work — and earn trust — without ever implying that a model owned the record. Day-in-the-life research with solo providers surfaced the same pressures again and again:
- Documentation is a burden, not a tool — notes spill into nights and weekends, and providers keep a second, informal system just to remember the patient.
- No single platform covers the day; providers stitch together three or four tools and quietly use general-purpose AI as a shadow clinical assistant.
- Preparation is a gap, not a habit — many walk into sessions cold, which providers themselves named as a source of stress.
- The calendar is the command center — any product that treats it as a secondary screen loses.
- And AI assistance only works if it stays inspectable, source-aware, and explicitly approved by the clinician.
I shaped a decision model that connected provider research signals to PRD requirements, journey maps, design decisions, prototype evidence, and release gates — a continuous chain from "what we heard" to "what we ship." The goal was not to slow the team down. It was to make each move inspectable enough that speed never created hidden risk.
Frame by provider jobs
Anchored the product in the six jobs of a solo practice rather than a generic AI-assistant surface — so every requirement traced back to real provider work, not novelty.
Dynamic canvas, human decision
Replaced static screens with a context-aware canvas that brings the right work to the provider — while AI stays in draft, synthesis, and recommendation and the clinician owns review, correction, and approval.
Make the path inspectable
Traced 161 requirements to their evidence and gated the roadmap with prototype validation and review loops, so the team knew when a concept was actually ready to build.
For executive roles, the relevant evidence is the operating posture. I was not only shaping screens — I was helping the team decide what evidence should move a product bet forward, what belonged in the AI layer, and what had to remain deterministic system behavior.
I also ran the design practice itself differently: a cross-functional cadence with product, research, engineering, and PM, plus an AI-augmented design workflow that let a small team cover more research synthesis, requirements, and design review than its headcount implied. That is exactly the posture AI-first enterprise work demands — leaders who can make proposed work reviewable, defensible, and tied to human judgment.
Operating model
Stood up a signals → requirements → decisions system and an AI-augmented design workflow, raising the team's coverage and review quality without adding headcount.
Cross-functional alignment
Gave product, design, engineering, and leadership a shared language for risk and progress — and held the review discipline that kept it honest.
Trust boundaries
Kept provenance, approval, and review states central to the product model, so AI accelerated the work without ever owning the record.
Workflow and review evidence
The product needed to learn fast without asking clinicians to trust a black box with the record.
Nitro is heading into a focused first release with a small cohort of solo practices, so the honest proof here is pre-launch: a de-risked bet, a validated experience, and an operating model — not yet shipped revenue.
A de-risked bet
Validated the AI-native direction through a five-provider research panel and a working prototype — and scoped a disciplined first release rather than a broad, unproven launch.
A validated experience
Every provider tested completed the core workflow unaided and validated the draft → edit → sign model for AI notes, orienting to a brand-new canvas in under two minutes.
An operating model that scales
161 requirements traced to evidence and a 100-plus-point design review resolved before build lock — a repeatable system for shipping AI-native product safely.