Being a PM With an Engineering Brain (Without Becoming the Eng Lead)

I came into product from a Computer Science / AI engineering foundation, and I converted from an engineering-focused intern into a full-time PM. The technical background is genuinely a superpower — it lets me pressure-test feasibility, make informed trade-offs, and partner deeply with engineers instead of lobbing tickets over a wall.

But it has a failure mode, and it's worth naming: the moment your technical opinion becomes the answer instead of an input, you've stopped being a PM.

Where it helps

• Feasibility, early. I can tell in a discovery session whether "the model just handles it" is a real plan or wishful thinking. That saves a sprint of false hope.
• Trade-offs in the open. When there's a build-vs-buy or latency-vs-quality call on an LLM feature, I can hold both sides honestly instead of deferring entirely.
• Precise specs. I translate requirements into buildable specs — user stories, acceptance criteria, edge cases — so there's less PM ↔ engineering back-and-forth.

Where it hurts (if you let it)

The trap is subtle. You start suggesting implementations. Then engineers start waiting for your blessing. Then you're the bottleneck you were hired to remove.

The best technical PMs I know spend their credibility buying autonomy for the team, not spending the team's autonomy on their own opinions.

The rule I hold myself to

I bring feasibility as a question, not a verdict: "Does the eval harness cover the failure mode I'm worried about?" beats "just add a guardrail." The first invites the team's expertise. The second replaces it.

Especially with AI / LLM products — where guardrails, evals, and human-in-the-loop UX are still being figured out industry-wide — the humility to ask is worth more than the confidence to answer.