Zero to One in Regulated Spaces

The first time I built a health product from scratch, the founder asked me a simple question: "Can we just use Google Sheets to track patient data?"

The answer was no. The answer was going to keep being no for a long list of tools the team was already using. And that conversation, the one where you explain why the fast path isn't available, is where regulated product development actually begins.

I've led zero-to-one product builds in menopause health, longevity medicine, and clinical trial operations. Each domain has its own regulatory landscape. All of them share one fundamental truth: the constraints aren't obstacles to work around. They're the terrain you build on.

The constraint is the feature

In unregulated product development, speed is the primary advantage. Ship fast, learn fast, iterate. The mantra works because the downside of shipping something broken is a bad review or a lost customer.

In regulated spaces, the downside of shipping something broken is a compliance violation, a patient harmed, or a clinical trial invalidated. The calculus changes entirely.

At a menopause health startup, I led the zero-to-one build of a symptom tracking platform. The domain involves 150+ symptom types across hormonal phases, information that's deeply personal and clinically significant. We couldn't just build a tracker and iterate. We needed HIPAA-compliant infrastructure from day one. We needed clinical validation of our scoring logic. We needed to handle the reality that a patient typing their symptoms into a form is generating Protected Health Information, and that information has strict rules about where it can live, who can see it, and how long it persists.

These constraints shaped every product decision. We designed a token-based URL pattern so health signals never appeared in browser URLs. We audited every vendor in the stack for HIPAA compliance and flagged three that were leaking PII outside protected boundaries. We built the AWS infrastructure with BAA coverage before writing a single line of application code.

Was this slower than building on a consumer SaaS stack? Yes. Did it mean the product was trustworthy from launch? Also yes. In healthcare, trust isn't a nice-to-have. It's the product.

Clinician trust is earned, not assumed

The second lesson I keep learning: in health products, your most important users are often the ones you aren't building for directly.

At the menopause startup, our primary users were patients. But the product wouldn't work without clinicians trusting it enough to reference it in care conversations. A quiz that tells a patient they're in perimenopause is only useful if their OB-GYN agrees with the methodology.

We built a 20-member Clinician Advisory Board spanning OB-GYNs, nurse practitioners, urologists, naturopaths, and integrative medicine doctors across the US and UK. We designed an AI clinical validation system: a 5-step quality assurance process that used AI to simulate panel reviews on quiz outputs before they reached patients.

This wasn't a rubber stamp. The CAB challenged our symptom clustering model. They refined our phase detection logic. They pushed back when the confidence scoring was too aggressive. One clinician's feedback on the quiz results page, that we needed to normalize symptoms before explaining them, changed the entire content architecture.

At a longevity health startup, the dynamic was similar. We co-designed the Sperity Score, a daily wellness metric integrating HRV, glucose, biomarkers, and fitness evaluations, directly with physicians. The doctors weren't just validators. They were co-designers. The score worked because it reflected how clinicians actually think about patient health, not how engineers assumed they would.

Deterministic over probabilistic

In one clinical research engagement, we built a document triage system for trial startup operations. The temptation was to use AI for everything: classify documents, predict delays, auto-route reviews.

We chose a deterministic architecture instead. Rules-based logic. No machine learning. Every decision the system made could be traced to a specific rule that a human wrote and approved.

In regulated environments, explainability isn't optional. When an auditor asks why the system flagged a document as incomplete, "the model predicted it" isn't an acceptable answer. "Rule 14.3 checks for the presence of a signed consent form, and this document didn't contain one" is.

This doesn't mean AI has no place in regulated products. It means AI needs to be governed differently. At the menopause startup, we used AI for content generation and clinical validation simulation, tasks where the output was reviewed by humans before reaching patients. The AI accelerated work. Humans owned decisions.

The principle: in regulated spaces, use AI to speed up the human, not to replace the human's judgment.

The zero-to-one playbook for regulated products

After building in healthcare and clinical research, here's the playbook I keep returning to:

Start with compliance architecture, not features. Your first sprint should produce a data flow diagram, a vendor audit, and infrastructure that meets regulatory requirements. Not a prototype. The prototype is meaningless if it lives on infrastructure that can't go to production.

Build your advisory board before you build your product. Domain experts, especially clinicians, will reshape your assumptions. Better to learn that your symptom model is wrong before 800 people take the quiz than after.

Design for audit trails from day one. Every state change should be traceable. Every decision should be explainable. Retrofitting auditability into a product that wasn't designed for it's expensive and error-prone.

Ship the walking skeleton first. A walking skeleton is the thinnest possible end-to-end flow: data in, processing, data out. In regulated products, this skeleton must include the compliance layer. If your skeleton handles PHI correctly, everything you build on top of it inherits that compliance.

Respect the domain. Healthcare professionals have spent decades learning their field. Product people who show up and treat clinical expertise as an input to be processed rather than a partnership to be cultivated will build products that clinicians ignore.

Slower isn't slower

There's a common assumption that regulated product development is inherently slower. It's not. It's differently sequenced.

The upfront investment in compliance, clinical validation, and domain expertise means that when you ship, what you ship actually works. You don't spend six months post-launch fixing trust issues, rearchitecting for compliance, or re-earning the credibility you lost by moving too fast.

At the menopause startup, we launched an MVP in under six months. The quiz had 800+ completions. Organic search traffic nearly tripled month-over-month. The engagement rate exceeded industry benchmarks. This wasn't despite the regulatory constraints. It was because we built on a foundation that users and clinicians trusted.

Moving fast and breaking things works when the things you break are pixels on a screen. In regulated spaces, the things you break are people's health data, clinical trust, and patient safety.

Build accordingly.

---

I go deeper on the patient engagement and business model sides of this work in Building Products in Healthcare, and on the AI-specific challenges in AI Product Strategy in Healthcare. If your team is building in a regulated domain and the product challenges go deeper than compliance, let's talk.