Working with Engineers

Why Technical Literacy Matters for PMs

You do not need to write code to be a great PM, but you do need enough technical literacy to ask good questions, understand trade-offs, and earn the trust of your engineering team. A PM at Flutterwave who does not understand why a currency-conversion feature needs a third-party FX rate provider will struggle to negotiate scope with engineering. A PM at Google who cannot follow a basic discussion of API rate limits will make unrealistic promises to stakeholders.

Technical literacy is not about being able to build the feature yourself -- it is about understanding enough of the "how" to make good decisions about the "what" and "when."

---

Concepts Every PM Should Understand

---

Estimation: Why "How Long Will This Take?" Is Hard

Engineers rarely give a single confident number, and PMs often misread hesitation as unhelpfulness. In reality, estimation is difficult because:

• Requirements are often incomplete when the estimate is asked for
• Unknown unknowns (a legacy system, an undocumented API) can double the effort
• Testing, code review, and deployment all take real time beyond "writing the code"

Common estimation techniques

• Story points: A relative sizing scale (often 1, 2, 3, 5, 8, 13) comparing a story's complexity to previously completed work, rather than predicting exact hours.
• T-shirt sizing: XS, S, M, L, XL -- useful for quick, early-stage roadmap conversations before detailed requirements exist.
• Planning poker: The whole team estimates simultaneously (often with cards or an app) to avoid anchoring bias, where the first number said influences everyone else.

A good PM treats an estimate as a probabilistic range, not a promise, and protects the team from being held to a number given before requirements were finalised.

---

Navigating Trade-offs with Engineering

Nearly every product decision involves a trade-off between speed, quality, and scope. A PM's job is to make these trade-offs explicit rather than pretend they do not exist.

Example: A fintech feature for instant airtime top-up

• Option A: Build a robust, fully automated integration with all telecom providers. Takes 6 weeks, handles all edge cases.
• Option B: Launch with manual reconciliation for failed transactions and only the two largest telecom providers. Takes 1 week, covers 80% of users.

A PM who understands the technical trade-off can make an informed call: ship Option B to learn from real usage, while engineering scopes Option A for the following quarter. This is far better than demanding "both, immediately," which usually leads to a rushed, buggy version of Option A.

---

Building Trust with Engineers

• Bring problems, not just solutions. Instead of "add a filter dropdown here," explain the underlying user problem and let engineers propose solutions -- they often find simpler ones.
• Protect focus time. Constant interruptions and shifting priorities are the fastest way to lose an engineering team's trust.
• Attend technical discussions, even if you do not lead them. Understanding why a decision was made helps you defend it later to stakeholders.
• Give credit publicly. When a feature succeeds, make sure engineering's work is visible to leadership, not just the PM's narrative.
• Learn to read a ticket. Understanding Jira/Linear status, blockers, and dependencies without asking for a verbal update every day respects engineers' time.

---

From Requirements to Shipped Feature: The Full Loop

1. Discover the problem through user research and data.
2. Define the requirement as a PRD with user stories and acceptance criteria.
3. Design lo-fi and then hi-fi screens in Figma.
4. Estimate with the engineering team using story points or T-shirt sizes.
5. Build, with the PM answering questions and removing blockers, not disappearing until launch.
6. QA against the acceptance criteria written earlier.
7. Launch and measure against the success metrics defined in the PRD.
8. Iterate based on what was learned.

This loop is the same whether you are at a five-person startup or a global company like Google -- the tools and ceremony scale up, but the core discipline of turning a real problem into a well-defined, well-estimated, and well-tested feature stays the same.

---

Try It: Build Your Own Mini-PRD

Use the interactive exercise below to practice assembling a lightweight PRD -- the same structure a PM would share with engineering before a feature is scoped. Fill in each field and watch the formatted PRD preview update as you type.