I lead product and build alongside engineering.
I use AI to turn product questions into working software, test it with users, and carry what we learn into production. I also build the tools and shared practices that help the team move faster on the next release.
Explore the workThe prototype changed what we built
Product leadership and engineering
Our first plan had clinicians inviting patients into an app for support between sessions. Walking clinicians through a working prototype showed us what that plan cost them: one more task in a day that was already full. We changed the first release to a scribe that cut documentation work, with the clinician reviewing each note.
I led the clinician conversations, built and iterated the prototype, set the roadmap, and joined engineering to deliver the first version within weeks.
The first release had fewer defects and needed a shorter user acceptance test than our previous launches.
From the patient chart to a signed visit note
I built this example separately, without employer code. The patients are fictional and the audio is simulated. Open a chart and try the scribe, then test a list of 50 patients, an interrupted session, or a failed save.
Clinical workspace
Patient list · fictional recordsTry switching patients during a session: the transcript stays with the original patient.
Specifications coding agents could build from
Alongside the product, we built reusable instructions for coding agents, a design system, and a development workflow tuned to our codebase. Clear specifications gave the agents the context to propose code changes and helped the team deliver follow-on work faster.
Work through the behavior before implementation
The functional prototype let us test logic and edge cases, including what a workspace looked like with 50 records instead of five. Product and engineering made those decisions before anyone built the production version.
How the prototype carried into engineering
Internal clinicians and prospective users tried the prototype with me. Their feedback shaped the first release. JavaScript facades stood in for live integrations, so we could exercise the experience with realistic data and controlled failures.
The product specification captured decisions we had already made in software. It gave product and engineering a shared reference for the behavior we expected, which we checked again during user acceptance testing.
Live use still exposed differences across devices and working habits. We continued gathering feedback and refining the product after launch.
The engineering workflow draws on Addy Osmani’s open-source agent skills, adapted to the team’s system.
Find out why a referral went unused
My work: 2024 to 2026 · Product and engineering
After Pyx Health acquired InquisitHealth, the company I co-founded, I built an AI platform to find out why people had not acted on a referral and match them with the support they needed. It runs across dozens of health plans.
I made barrier resolution the outcome the system learns from. Completing a task moves the work forward; the case stays open until we know whether the member got help.
A member may know where the food pantry is and still have no way to get there. This fictional example follows that barrier through to a navigator booking a ride.
- 09:14 · Context
A referral goes unused
A member has not acted on a food referral. Her coordinator’s notes mention cut hours and no car, so the agent starts from there.
- 11:52 · Assessment
Transport is the barrier
Asked what is in the way, she picks transport from a short list. Her answers show she is motivated and knows what to do but cannot get there, which puts her in guided support: resources plus follow-up.
- 11:52 · My decision
A navigator books the ride
The resource she needs is a ride, and the ride comes through a plan benefit that requires enrollment. I kept enrollment with a human navigator, so the agent routes the request and waits.
- 15:07 · Follow-up
The outcome stays open
The ride is booked. Food access is still pending, so the system keeps tracking it.
Read the full run, annotated
A peer coaching platform that reached 50,000 members
Acquired by Pyx Health
I co-founded InquisitHealth and led product and technology as the platform grew to serve more than 50,000 members. It paired people managing chronic conditions with trained peers who shared that experience. The work extended from reaching and matching members to the tools peers used on every call.
Keep the next action beside the conversation
A peer needed member history and open issues before the call, then a way to act on what came up during it. In Peer Copilot, I brought member context, the live call guide, and care actions into one workspace. A peer could arrange follow-up while keeping the conversation in view.
History and the plan for the call
The active issue and its talking points
Resources, follow-up, and escalation
The platform grew to include care coordination, operations, and content management before Pyx Health acquired InquisitHealth in 2024.
Feedback with enough context to act on
Open source
A comment like “fix this” needs the page and element it refers to. I built Pinflow to keep feedback attached to that context and export it as markdown a coding agent can act on.
It is open source, installs with one script tag, and is running on this site. Option/Alt-click an element, or press and hold on a phone, to try it.
Explore PinflowBefore InquisitHealth, I worked in healthcare digital strategy, enterprise data engineering, and product management. I have been a co-investigator on research funded through the NIH Small Business Innovation Research (SBIR) program.
In the press
Fierce HealthcareThe Activation platform launch MobiHealthNewsWhat healthcare AI needs to prove in 2026
I run Bricks & Motors, after-school LEGO robotics and STEM classes for elementary-aged children in northern New Jersey, Rockland County, and southern Connecticut.
Bricks & Motors