Talk So Engineers Can Build: A PM’s Field Guide to Developer Communication
Great PM–engineering comms = clear specs + early collaboration + context (the “why”) + realistic scope + debt-aware planning + steady rituals. It’s not just vibes: teams with high trust and psychological safety ship better and perform better.
Why communication quality matters (a quick reality check)
US cost of poor software quality was estimated at $2.41T in 2022, with technical debt ≈ $1.52T—that’s not a rounding error; that’s the budget. CISQ+1
Developers report ~17 hours/week on maintenance/refactoring and ~4 hours/week wrestling with “bad code.” That’s time not shipping value. Stripe
DORA research links high‑trust, generative cultures (where people can speak up and collaborate) with superior software delivery and organizational performance. Translation: communication culture isn’t fluff—it’s throughput. Dora+1
“If the first time your engineers see a product idea is at sprint planning, you are clearly a feature team.” — Marty Cagan. Silicon Valley Product Group
1) Write specs that don’t leak
(Clarity, detail, acceptance criteria, visuals)
Engineers thrive on specificity. Put user flows, empty states, failure modes, and acceptance criteria right in the ticket. This isn’t pedantry; it reduces ambiguity and rework.
Acceptance criteria reduce ambiguity and align everyone on “done.” Consider BDD-style (Given/When/Then) for testability. Atlassian
Standards exist: ISO/IEC/IEEE 29148 catalogs what “good requirements” look like—use it as a north star for wording and completeness. IEEE Standards Association
Pictures beat paragraphs. Good prototype specs clarify behavior, cut meetings, and lower comms cost; don’t over-polish—just-enough fidelity wins. Nielsen Norman Group+1
Copy/paste – Acceptance criteria (Jira-ready)
Scenario: Offline on submit
Given I’ve filled the form
And I lose connectivity on submit
When I tap "Submit"
Then the app saves locally
And queues the request
And shows a “Pending sync” state with retry
Anti‑pattern to watch:
“That’s not a defect; it’s a new story.”What devs mean: the spec didn’t say it—so it isn’t wrong; it’s undefined. Fix the spec, not the blame. ProductPlan
2) Listen early, listen often
(Involve engineers during discovery, not after scope is frozen)
Bring tech leads into discovery and design reviews. You’ll surface feasibility risks early and usually get better solutions.
Cagan’s warning (above) is famous for a reason; empowered engineers improve solutions when involved in shaping them. Silicon Valley Product Group
Instabug PM practice: hold pre‑planning with tech leads to walk through “the problem, the approach, and why it matters,” answering questions before sprint planning. instabug.com
One‑liner you can use:
“Here’s the problem and outcome we want; can you propose the leanest technical path?”
3) Always communicate the “Why”
(Vision, user problem, business context → motivation & better day‑to‑day decisions)
People do better work when they know why it matters. Self‑Determination Theory says autonomy, competence, and relatedness drive motivation; giving context feeds all three. Self-Determination Theory
At the team level, psychological safety (people feel safe to flag risks, ask “dumb” questions, push back) is a top predictor of delivery performance. That’s Project Aristotle + DORA. ReworkDora
Template snippet for your PRD header
Problem: [Which user, which pain, how we know]
Outcome: [Behavior we want to see; success metric/OKR]
Why now: [Strategic/contractual/market driver]
Guardrails: [Perf/SLA/scale/regulatory constraints]
4) Set realistic expectations (and respect engineering reality)
(No “just a small tweak” unless you checked)
Avoid the dreaded: “This shouldn’t be hard, right?” Some things that look tiny involve refactors, migrations, or gnarly edge cases.
Protect maker time. As Paul Graham put it: “On the maker’s schedule, meetings are a disaster.” Even one mid‑afternoon meeting can nuke the whole block. Schedule thoughtfully. Paul Graham
Interruptions hurt productivity (and quality). Recent research examined how different interruptions impact software work; the punchline: be intentional about sync vs async. ACM Digital Library
Practical moves
Ask for t‑shirt sizes (S/M/L) early; refine after grooming.
Batch your questions asynchronously; bundle clarifications to reduce context switches.
Replace “Can we do it by Friday?” with “What’s the smallest slice we can credibly ship by Friday?”
5) Prioritize and slice like a pro
(Clarity on P0 vs P1; small vertical slices; DoD vs AC)
Use a transparent framework (RICE) to rank investments; it de‑personalizes prioritization and makes trade‑offs explicit. Intercom
Or go simple with MoSCoW (Must/Should/Could/Won’t). Make “Won’t this time” explicit. agilebusiness.org
Keep stories vertical and small so they can be built, tested, and demoed within a sprint. (It also earns you credibility when you ship weekly.)
Definition of Done (DoD) vs Acceptance Criteria (AC)
AC = story‑specific pass/fail behavior.
DoD = team‑wide quality bar for an increment (tests pass, accessibility checks, docs updated, etc.). Use both. AtlassianScrum.org
6) Plan for tomorrow (technical debt, scalability, and reuse)
(Debt isn’t evil; unmanaged debt is)
Ward Cunningham and Martin Fowler remind us: debt can buy speed if you plan to repay; the interest is the extra effort future changes require. Use Fowler’s debt quadrant (deliberate/prudent vs reckless/inadvertent) in decision logs. martinfowler.com+1
This isn’t theoretical: technical debt is a primary driver of cost and slows feature delivery at scale. CISQ pegs US cost of poor software quality in the trillions. Treat debt paydown as first‑class backlog items. CISQ
Future‑proofing prompt to add to specs
Future considerations:
- Which parts might need to be configurable in 6–12 months?
- Adjacent features that could reuse this component?
- Any “one‑way doors” we should avoid?
- What’s the rollback/kill‑switch plan?
7) Run lightweight rituals that build trust (not meetings that drain it)
Pre‑planning with tech leads (30–45 min): share problem, constraints, metrics; collect feasibility questions. instabug.com
Backlog refinement: verify AC, edge cases, and test notes.
Demo Fridays: celebrate shipped slices; connect back to the why (OKRs, user impact). Culture matters—DORA shows culture ↔ performance. Dora
One‑minute PM checklist (before handing off a story)
User flow + empty states + errors captured
AC are testable (Given/When/Then)
Non‑functionals clear (perf, accessibility, SLA)
Analytics/telemetry noted
Out‑of‑scope explicitly listed
Rollback/flag plan considered
Micro‑scripts you can steal
Early involvement: “Before we lock scope, can you spot any landmines or a simpler path?” (Cagan would approve.) Silicon Valley Product Group
Expectation setting: “We’ll ship the core now (P0), then layer P1 niceties next sprint.” (RICE/MoSCoW backs you up.) Intercomagilebusiness.org
Debt honesty: “We’re taking deliberate/prudent debt here for the deadline and scheduling payback in the next PI.” martinfowler.com
Spec nudge: “If it’s not in AC, it’s a new story—not a bug. I’ll update the spec.” ProductPlan
Put it together: a mini PRD skeleton
1) Context & Why – user pain, target metric/OKR, success signal, constraints. Self-Determination Theory2) Scope (Now / Next / Later) – RICE/MoSCoW table; call out what’s not included. Intercomagilebusiness.org3) Flows & States – diagrams, empty/offline/error; link to prototype. Nielsen Norman Group4) Acceptance Criteria – BDD format; non‑functionals (perf/accessibility). Atlassian5) Telemetry – events, properties, dashboards.6) Risks & Debt – debt quadrant classification + payback plan. martinfowler.com7) Rollout – flags, phased rollout, rollback plan.8) Appendix – glossary (terminology matters), references to standards (e.g., 29148). IEEE Standards Association
Closing thought
Communicating well with engineers isn’t about writing novels; it’s about removing ambiguity, inviting expertise early, and reinforcing purpose. Do that consistently and you’ll see faster delivery, fewer “surprises,” and—best of all—engineers who see you as an ally.
And if someone asks for five new features by Friday, feel free to say:
“Absolutely—once you invent time dilation. Until then, let’s ship the smallest lovable slice.” 😄