How Prerna Kaul Automates 60,000-Page FDA Submissions and Coaches PMs with AI

Prerna Kaul uses AI for two very different kinds of work: assembling pieces of an FDA submission process that can stretch to 60,000 pages, and helping product managers rehearse difficult stakeholder conversations. Her approach is defined by strict scope, review, and human accountability rather than trust in the tooling.

Prerna says a full biologics submission can involve nearly 20 specialists, months of coordination, and millions of dollars in effort. Her prototype explored whether repetitive preparation work could move faster with generative AI, especially drafting, formatting, redaction, and collaboration. She is careful throughout the demo to separate a prototype from a validated regulatory system.

In this episode of How I AI, Prerna builds a local Streamlit prototype that generates synthetic trial data, redacts potential PHI, drafts part of a Common Technical Document, exports text and XML-shaped output, and tracks model cost per operation. The FDA document-generation workflow keeps those stages together while making the boundary explicit: this was synthetic local testing, not a validated regulatory system or an FDA-ready submission. She also demonstrates a Claude workspace that helps PMs rehearse fictional stakeholder conflicts using public-domain communication material.

The contrast between the two demos is useful. In the regulatory workflow, every output still requires review from clinical, regulatory, privacy, security, quality, and legal experts. In the communication workflow, the risk is lower, but human judgment still matters. The model can organize thinking and surface tradeoffs, but it cannot decide how a workplace conflict should be handled.

Building a synthetic FDA-submission workflow

Prerna focused on one module inside a larger Biologics License Application process. Rather than automate an entire submission, she built a prototype demonstrating document preparation, redaction, structured output, and cost tracking using synthetic clinical data.

Briefing Claude like a software engineer

Prerna started by giving Claude a product-style brief instead of a tightly scoped coding request. She described the business problem, why it mattered, the artifact she wanted, and the formatting and safety constraints. She framed the interaction the way a PM would brief an engineer before implementation.

"The thinking I had in mind is that Claude is a software engineer, and I'm talking to them and trying to tell them why it matters like any good PM would, and trying to tell them what end product we wanna produce as a result."

Claude returned a surprisingly complete first draft of the project, including:

• A Markdown implementation plan with setup instructions and workflow steps.
• A breakdown of the application's capabilities and responsibilities.
• A demo narrative for presenting the workflow to stakeholders.
• Starter Python code covering the major system components.

I point out that the original prompt was relatively short, but the model expanded it into architecture ideas, implementation tasks, and a presentation script. Prerna estimated that an equivalent planning pass between a PM and engineer could consume at least a week before any code existed. The draft arrived in minutes, but experts still had to validate assumptions, edge cases, and regulatory constraints.

Using synthetic data to test PHI detection

The prototype needed to redact protected health information inside structured records and free-text clinical notes. To avoid exposing real patient data, Prerna generated synthetic records for the demo.

Claude proposed a combination of medical named-entity-recognition components and regex-based rules, then generated implementation code. I joke that seeing regex generated automatically felt like a small miracle after years of writing brittle patterns by hand. Prerna said selecting and wiring together the right medical models would normally require collaboration between engineers and data scientists because clinical-trial formats vary across studies and therapies.

The prototype identified names, dates, and other identifiers inside synthetic notes and redacted them before document generation. But Prerna repeatedly emphasizes the limitation: passing a synthetic demo does not prove reliable PHI removal in production. A real deployment would still require validated de-identification methods, auditability, security review, and extensive testing.

Turning the workflow into a usable internal tool

After reviewing the generated Python code, Prerna wrapped the workflow in a local Streamlit application so non-technical colleagues could interact with it through a browser instead of a terminal.

That decision reflects one of her broader product-management lessons from working with AI systems: the real leverage often comes when a workflow becomes accessible to non-engineers. She describes using similar lightweight interfaces in other roles, including a tool that converted PRDs into Jira-ready formats so PMs did not have to duplicate requirements manually.

For the FDA-submission prototype, she launched the app locally from the command line, loaded an API key, and exposed controls for generating synthetic records, redacting PHI, and producing structured outputs. She notes that moving beyond a local environment would require authentication, encryption, logging, retention policies, and approved infrastructure.

# Example command to run a Streamlit application
streamlit run app.py

Inside the Streamlit app, the workflow generated synthetic participant data and clinical notes containing invented identifiers. The system scanned those records, highlighted fields it believed contained PHI, and produced redacted output. The demonstration showed the mechanics clearly, but Prerna avoided overstating the result. A successful synthetic example is not evidence that a real clinical system would perform reliably in production.

Generating structured regulatory drafts

Once the synthetic records had been processed, the prototype generated part of a Common Technical Document module. The output summarized participant counts, statistical details, study information, and clinical terminology in a format designed to resemble regulatory documentation.

Prerna explains that this drafting work is normally handled by medical writers coordinating across large stakeholder groups. Even a first-pass summary can involve weeks of iteration between specialists. One thing she found promising about AI collaboration tools was the ability for multiple stakeholders to work inside shared model contexts rather than passing comments around static documents.

The app exported both plain text and an XML-shaped file intended to mimic structured submission output. Prerna and I laugh about how exciting it felt just to see the XML download button working because strict formatting is one of the hardest parts of these workflows.

Prerna notes that the XML structure mattered because the submission format has rigid requirements. Still, the exported file was only a demonstration artifact and not evidence of FDA compliance.

"I cannot tell you how excited I was to see this button."

Tracking cost and runtime by operation

One of the most practical parts of the demo is the dashboard showing token usage, runtime, and cost per operation. The prototype tracked steps such as PHI redaction and document generation individually so teams could understand where compute costs accumulated.

Prerna says cost transparency became important whenever stakeholders questioned whether an AI workflow justified the expense. Rather than discussing costs abstractly, she preferred showing concrete numbers tied to specific operations and comparing them against traditional processes.

I point out that teams often react emotionally to model costs without comparing them to the labor involved in manual workflows. Per-operation tracking gave Prerna a way to discuss ROI more concretely, even if the calculation remained incomplete. A production system would still need to account for infrastructure, monitoring, validation, maintenance, expert review, and submission risk before anyone could claim true savings.

Building an AI coach for difficult PM conversations

Prerna’s second workflow is lighter operationally but familiar to many PMs: preparing for a politically messy meeting where stakeholders disagree, timelines are tight, and priorities conflict.

Instead of generating regulatory documents, this workflow generates preparation material. The coach produces stakeholder analyses, likely objections, conversation plans, and meeting structures. Prerna stresses that the system should only use fictional or sanitized scenarios, not confidential workplace information.

Generating a reusable communication framework

Inside the Anthropic Console, Prerna used Prompt Generator to create a structured XML-style prompt for what she called an Influence and Communication Coach. The prompt defined the model's role, reasoning process, contextual inputs, and response structure.

She also used prompt-optimization tools to refine the instructions in real time. Instead of treating prompting as a one-shot activity, she treated it more like editing a product specification.

Loading the project with communication references

Prerna added public-domain material from Project Gutenberg into a Claude Project as reference context, including classic communication and persuasion books such as:

• How to Win Friends and Influence People by Dale Carnegie
• Works by Jane Austen, which she says contain useful observations about human behavior and social dynamics.
• Other books focused on tactics, persuasion, and influence.

The references gave the model examples, frameworks, and language patterns to retrieve during analysis. Prerna was careful not to present this as model training or expert authority. The books functioned more like an attached reading list the model could search while generating responses.

Creating a fictional executive conflict

To test the workflow, Prerna asked Claude Sonnet 4 to generate a fictional high-stakes scenario involving privacy and accuracy concerns before a major customer presentation. The setup included a CEO, sales leader, legal leader, and clinical-data leader pulling in different directions.

The conflict felt realistic because each stakeholder had competing incentives. Sales wanted momentum with the customer. Legal and clinical stakeholders were worried about risk and accuracy. Leadership pressure increased because the presentation was close. I note that many PMs recognize versions of this dynamic even outside healthcare.

Turning stakeholder chaos into a rehearsal plan

Once the fictional scenario was generated, the coach produced a preparation package with stakeholder strategies, conversation sequencing, agendas, and objections. The AI communication-coach workflow shows how to build and test that structure with fictional or sanitized inputs.

• Situation analysis: An interpretation of the organizational conflict and the incentives driving each stakeholder.
• Leadership lenses: Hypothetical approaches inspired by well-known executives, used as strategic analogies rather than real advice.
• Communication references: Principles retrieved from the attached persuasion and communication texts.
• Strategic options: Different ways to frame privacy, compliance, escalation, customer trust, and delivery pressure.
• Preparation schedule: Suggested one-on-one conversations, sequencing, and a draft agenda for the final leadership meeting.
• Questions to anticipate: Potential curveball objections the PM should prepare to answer directly.

The appeal was immediate: many PMs know the stress of walking into an executive meeting without a stakeholder strategy. The coach cannot make the decision, but it can reduce blank-page anxiety and surface conflicts and questions worth preparing for.

Two prototypes, two different review standards

The two workflows in this episode sit at opposite ends of the risk spectrum, but they share the same pattern: AI accelerates drafting, organization, and synthesis, while humans remain responsible for review and decision-making.

The regulatory prototype helps explore document preparation with synthetic data, but it cannot bypass validation, privacy controls, or regulatory review. The communication coach can help PMs rehearse and structure conversations, but it cannot determine the right decision inside a real organization.

The most transferable idea from Prerna’s workflows is not the specific tooling. It is the discipline around scope and accountability. She starts with bounded examples, uses synthetic or fictional inputs whenever possible, tracks operational cost visibly, and identifies the human reviewer before trusting the output.

That approach works especially well in environments where paperwork, coordination, and preparation overhead are enormous. AI is very good at accelerating first drafts, structuring information, and reducing repetitive setup work. The closer a workflow gets to legal, clinical, regulatory, or interpersonal consequences, the more important human review becomes.