PM–Engineer Collaboration
Field notes on working with engineering. Distilled from working as a PM at an early-stage startup.
Everything non-code is the PM’s world
Engineers are (rightly) focused on implementation — the code, the architecture, the trade-offs in how to build. Almost everything else — the problem, the requirements, the flows, the edge cases, the “why” — is the PM’s responsibility. Don’t expect engineering to fill the non-code gaps; that’s your job.
Start from logic to close the information asymmetry
You and engineering rarely share the same context — there’s information asymmetry in both directions. Bridge it by starting from logic: reason out loud from the requirements so the chain of “problem → why → what” is visible and checkable, rather than handing over conclusions.
What engineers want from a PM varies
There’s no single answer. For a human-facing product they may want UX clarity and flows; for an internal or data-heavy product they may want a precise list of items and states. Good PRDs are welcomed in both cases. Ask the team what unblocks them.
Team structures differ by business
Different businesses run different PM-to-engineer structures — and increasingly, specialized pods (e.g. a monetization-and-billing pod that owns all billing logic). There’s no universal ratio; match it to the product. Early on, you often just want one PM and two engineers building fast.
Learn from everyone, not just engineers
Talk to product designers and others on the team and learn their craft too. The PM sits at the center of the disciplines — the more of each you understand, the better your decisions.
Being technical is leverage
You don’t have to write production code, but being technical is powerful — even for a non-technical founder. Take on small projects, learn from your mistakes, and you’ll spec better, estimate better, and earn more trust from engineering. (More in Engineering-Practices.)