From builder to product thinker

This summer was my first hands-on run as a Product Manager in a complex, regulated space. I came in with a software background and a habit of shipping, but what I really wanted was the PM muscle: framing the right problem, aligning people, and proving impact. I worked across three threads: field workflow capture, AI evaluation, and enablement so that experts could move faster, trust their tools, and spend more time on the work that actually matters.

The challenge

Here’s the thing: great features don’t help if they’re hard to adopt or impossible to trust. We saw three recurring pain points:

1. Post-meeting capture is fragile. Manual CRM logging costs time and loses detail.
2. AI needs proof, not vibes. In a domain with high stakes, answers must be measurable and explainable.
3. Findability breaks without a shared language. If teams don’t tag and search the same way, knowledge stays buried.

What I worked on

Voice-to-CRM capture
Turned short spoken summaries into structured, reviewable entries so field teams could log richer notes with less friction directly into CRM system. I designed the schema-driven form, review checkpoints, and guardrails for edge cases. The goal: fewer clicks, better consistency, and notes that are actually usable later.

AI evaluation framework
Built a practical, repeatable way to judge responses: accuracy, evidence, relevance, depth, and clarity. Standardized prompts, created a shared “golden set,” and outlined how to automate scoring for both continuous and batch evaluation. This made conversations about quality concrete and helped prioritize fixes that move the needle.

Metadata and retrieval quality
Drafted a multi-level tagging approach so similar concepts roll up cleanly and searches return what people actually meant. Documented guidelines for synonyms and sensitive terms, plus examples that teach teams how to tag today and not regret it tomorrow.

Enablement that sticks
Wrote a step-by-step admin guide for internal configuration tasks and set up a Figma design library so UI patterns didn’t have to be reinvented. Fewer Slack pings, faster onboarding, and a shared language between PM, design, and engineering.

How I worked

• Discovery without drama: short working sessions with PMs, engineers, and domain experts to map the “current vs. ideal” flow.
• Decisions with receipts: defined acceptance criteria up front, ran small experiments, and captured tradeoffs in short RFCs.
• Tight feedback loops: weekly demos, side-by-side comparisons against external baselines where appropriate, and an explicit “definition of good” for each deliverable.

Outcomes

1. Faster, more consistent capture: fewer steps to log, clearer review checkpoints, and better-structured notes ready for downstream use.
2. Trusted AI decisions: a common rubric and shared datasets turned opinions into signals, reducing back-and-forth and surfacing the highest-impact fixes.
3. Quicker onboarding and reuse: clear docs and reusable UI patterns cut handoff time and kept teams aligned.

What this taught me about product

Traceability is a feature. In healthcare and life sciences, being able to show your work is part of the value.

Evaluate before you optimize. A good rubric beats a clever tweak when trust is the bottleneck.

Configure > customize. Schema-driven forms and tagging rules scale; one-offs do not.

Docs are product, too. The right page, at the right time, saves hours and prevents errors.

Adoption is a loop, not a launch. Solve the whole task from capture to review to retrieval or people won’t switch.

Final thought

This internship bridged builder instinct and PM judgment. Define “good” first, then ship. I focused on rails like defaults, review gates, and shared tagging so experts do the right thing with less effort. Trust is measured, not claimed, and adoption is a loop across capture, review, and retrieve. Configure beats customize. That’s the work I want to keep doing: build simple rails for hard problems and prove they work.