What PMs Who Came from Engineering Know That Others Don't
Engineers ask questions in system design meetings that most PMs never think to ask. Here's what changes when you understand the systems under your product.
There are questions that come up in engineering meetings that most PMs never think to ask. Not because they're unintelligent — because they haven't sat in the rooms where those questions get answered.
Having spent years building production systems before moving to product, I have a specific kind of literacy that informs every product decision I make.
The Architecture Question That Changes Everything
"What happens to this feature at 10x scale?" is a question most PMs never ask. Most products never reach 10x scale anyway, so it seems irrelevant.
But the answer reveals something more important than the engineering concern: it reveals what assumptions are baked into the design. When engineers answer this question, they're telling you what they've optimized for — and what they haven't.
A PM who can ask that question, understand the answer, and make a deliberate tradeoff decision is doing something valuable that a spec-writing PM can't do.
Reading a System Diagram
Early in product conversations, I often ask for a quick architecture sketch — even just a whiteboard photo. Most PMs find these useless. I find them essential.
A system diagram tells you:
- Where the data lives and who owns it.
- Where the latency lives — and whether a user-facing feature is constrained by it.
- Which parts of the system are well-understood versus exploratory.
- Where a new feature will add complexity that may not be visible to a user but will matter in 6 months.
Three Patterns Worth Knowing
- Async vs. sync: if a critical user flow depends on asynchronous processing, what happens when the queue backs up? This is a product failure mode, not just an engineering one.
- Data model vs. UI: the hardest features to build aren't the ones that look complex — they're the ones that require restructuring the data model underneath a simple UI.
- Caching assumptions: features that feel instant in development sometimes feel slow in production because they depend on cache warming. This matters for your retention data.
The Leverage Point
None of this means PMs should be making technical decisions. They shouldn't.
What it means is that PMs who understand technical constraints can create product specs that don't ignore them. They can have the conversation about tradeoffs with engineering instead of being handed tradeoffs after the fact.
The best product outcomes I've seen happen when the PM understands the system well enough to know which constraints are real and which are just defaults.
Understanding architecture doesn't mean making architecture decisions. It means asking better questions.
How to Build This Literacy
You don't need to learn to code. You need to learn to think about systems.
- Ask your engineers to walk you through one architecture decision per sprint — not to critique it, but to understand it.
- Read the ADRs (Architecture Decision Records) if your team keeps them.
- When a feature is estimated higher than expected, ask what the complexity actually is.
- Read one system design book — Designing Data-Intensive Applications by Kleppmann is the one I recommend.