Technical Literacy for PMs

You do not need to write code. You do need to understand enough about how software works to have productive conversations with engineers, ask good questions, and recognize when a "simple change" is anything but simple. Technical literacy is not about becoming an engineer. It is about eliminating the communication gap that causes bad product decisions.

Why Technical Literacy Matters

Every product decision has technical implications. When you prioritize features without understanding their technical cost, you are making decisions with incomplete information. When you promise a customer a delivery date without understanding the engineering complexity, you are setting your team up to fail.

The PM who understands technical concepts can:

Spot when a proposed solution is over-engineered or under-engineered
Ask questions that surface hidden complexity before it becomes a surprise
Negotiate scope intelligently because they understand what is easy and what is hard
Earn engineering trust because they speak enough of the language to be credible
Make better trade-offs between speed, quality, and scope

Without technical literacy:
  PM: "Can we just add a field to the user profile?"
  Engineer: "That touches the auth service, the profile service, and the billing service."
  PM: "So... is that a yes?"

With technical literacy:
  PM: "I want to add a field to the user profile. I know this data is used
       by multiple services. Can you walk me through which services would
       need changes and what the effort looks like?"
  Engineer: "Good question. Auth and billing both read from the profile.
             Here is what we would need to do..."

Core Concepts Every PM Should Understand

APIs

An API (Application Programming Interface) is how different pieces of software talk to each other. When your mobile app shows a user's account balance, it is calling an API on your backend server to fetch that data.

Key things to understand:

REST vs GraphQL — REST APIs have fixed endpoints that return fixed data shapes. GraphQL lets the client ask for exactly the data it needs. REST is simpler but can lead to over-fetching or under-fetching data.
Rate limiting — APIs often limit how many requests a client can make per time period. If a partner integration is hitting your API 10,000 times per second, you need to understand why that is a problem.
Versioning — changing an API breaks existing clients. This is why "just change the API" is never as simple as it sounds. You need to maintain old versions while rolling out new ones.
Latency — every API call takes time. A page that makes 15 API calls sequentially will be slow. Understanding this helps you make better design decisions.

Databases

Databases store your application's data. There are two main families:

Relational databases (PostgreSQL, MySQL):
  - Data in tables with rows and columns
  - Strong consistency guarantees
  - Good for structured data with relationships
  - Scaling writes is hard

Non-relational databases (MongoDB, DynamoDB, Redis):
  - Flexible data structures
  - Easier to scale horizontally
  - Trade-offs on consistency
  - Good for specific use cases (caching, documents, time-series)

What matters for PMs:

Schema changes — changing the structure of a database table can be trivial or terrifying depending on the table size, whether it requires downtime, and how many services depend on it.
Migrations — moving data from one structure to another. "Can we restructure how we store user preferences?" might be a weekend project or a multi-month effort.
Indexes — these make database queries fast but add complexity. When you ask "can we add a search filter for X?" the answer depends on whether there is an index for X.
Data consistency — in a distributed system, keeping data consistent across multiple databases is genuinely hard. "Why can a user see different data on mobile vs web?" is often a consistency question.

Latency & Performance

Latency is how long it takes for something to happen. Users notice latency above about 100 milliseconds.

Typical latencies:
  Reading from memory:       ~100 nanoseconds
  Reading from SSD:          ~100 microseconds
  Network round trip (same region): ~500 microseconds
  Network round trip (cross-continent): ~150 milliseconds
  Reading from spinning disk: ~10 milliseconds

Why this matters: when you ask "can we fetch data from our EU datacenter for US users?" the answer involves physics, not just code. Some latency is irreducible.

Understanding performance helps you:

Set realistic expectations for page load times
Understand why some features are fast and others are slow
Know when caching can help and when it introduces new problems
Recognize that "making it faster" often means architectural changes, not code tweaks

Scalability

Scalability is how well your system handles growth. There are two kinds:

Vertical scaling — making a single machine more powerful (bigger CPU, more RAM). Simple but has limits.
Horizontal scaling — adding more machines. More complex but can scale much further.

The PM implication: features that work perfectly for 1,000 users might break at 100,000 users. "It works on staging" is not the same as "it works at scale." When engineering says a feature needs "scalability work," they are not gold-plating — they are preventing outages.

Technical Debt

Technical debt is the accumulated cost of past shortcuts. Like financial debt, it accrues interest. A quick hack that saved two days in 2022 might cost two weeks every time you touch that part of the code in 2024.

Types of technical debt:
  Deliberate: "We know this is a shortcut. We will fix it next quarter."
  Accidental: "We did not know this would become a problem."
  Bit rot:    "The libraries we depend on have moved on and we have not."
  Design:     "The architecture assumed 10 users, not 10 million."

What PMs need to know:

Debt is not always bad. Sometimes shipping fast and fixing later is the right call.
But debt compounds. Ignoring it long enough and feature velocity drops to near zero.
Engineers who constantly ask for "refactoring time" are not being lazy. They are trying to maintain velocity.
The best approach is dedicating a consistent percentage (15-20%) of capacity to debt reduction, not saving it for a "tech debt sprint" that never happens.

Deployment & Release Processes

How code gets from an engineer's laptop to production:

Typical deployment pipeline:
  Local development
    -> Pull request & code review
    -> Automated tests (unit, integration, end-to-end)
    -> Staging environment
    -> Production deploy (possibly canary or blue-green)
    -> Monitoring & rollback if needed

Key concepts:

Feature flags — toggles that let you deploy code without activating it for users. Essential for gradual rollouts and quick rollbacks.
Canary deploys — releasing to a small percentage of users first, monitoring for problems, then expanding.
Rollback — reverting to the previous version when something goes wrong. Not always as simple as pressing a button, especially if database changes are involved.
CI/CD — Continuous Integration and Continuous Deployment. Automated pipelines that test and deploy code. If CI is broken, nobody can ship.

Understanding this helps you:

Know why "just deploy a fix" might take an hour, not five minutes
Appreciate the value of feature flags for your launch strategy
Understand why hotfixes are stressful and why engineers resist "just ship it now" pressure

Infrastructure & Cloud

Most modern applications run on cloud providers (AWS, GCP, Azure) rather than physical servers.

Common cloud concepts:
  Containers:    Packaged applications that run the same everywhere
  Kubernetes:    Orchestrator that manages containers at scale
  Serverless:    Run code without managing servers (AWS Lambda)
  CDN:           Content delivery network, caches static assets close to users
  Load balancer: Distributes traffic across multiple servers

You do not need to configure any of these. You need to understand that infrastructure decisions have cost, performance, and reliability implications. "Can we just spin up more servers?" has a dollar cost attached.

How to Build Technical Literacy

Read Architecture Documents

Most teams have architecture docs, even if they are outdated. Read them. Ask an engineer to walk you through the system architecture on a whiteboard. Understand which services talk to which, where data lives, and what the critical paths are.

Attend Technical Design Reviews

Sit in on design reviews. You will not understand everything. That is fine. Over time, patterns will emerge. You will start recognizing when a proposed solution is simple or complex, and you will learn the vocabulary.

Ask Questions Without Pretending

The worst thing a PM can do is pretend to understand something technical and make decisions based on that false understanding. "I do not fully understand this — can you explain it differently?" is always a valid thing to say.

Good questions to develop a habit of asking:

"What is the simplest version of this we could build?"
"What are we assuming that might not be true?"
"What breaks if we get 10x the expected traffic?"
"Is there existing infrastructure we can reuse?"
"What is the riskiest part of this from a technical perspective?"
"How would we know if this is failing in production?"
"What would make this easier to change later?"

Learn to Read a Dashboard

You do not need to write monitoring queries. But you should be able to look at your team's dashboards and understand the basics: error rates, latency percentiles (p50, p95, p99), throughput, and CPU/memory utilization. When something goes wrong, you want to understand the severity without needing an engineer to translate for you.

Pair With an Engineer

Spend an hour watching an engineer work. Not writing code — but going through their process. See how they debug a problem, how they read error logs, how they navigate the codebase. This builds empathy and understanding in ways that no documentation can.

Recognizing Hidden Complexity

One of the most valuable skills a technically literate PM develops is the ability to sense when something is more complex than it appears.

Red flags that a "simple change" is not simple:
  - It touches shared infrastructure (auth, payments, notifications)
  - It requires a database migration on a large table
  - It changes behavior that other teams depend on
  - It involves third-party integrations
  - It requires real-time data synchronization
  - "We have never done anything like this before"
  - It requires backward compatibility with existing clients

When you hear these signals, resist the urge to minimize the complexity. Instead, work with the engineer to find the version of the feature that delivers the most value with the least hidden complexity.

Common Pitfalls

Overestimating your technical understanding — knowing the vocabulary is not the same as understanding the implications. Stay humble.
Using technical knowledge to micromanage — learning about databases does not mean you should have opinions about schema design. Stay in your lane.
Anchoring on past experience — "at my last company this was easy" ignores that every codebase and architecture is different.
Treating all technical work as fungible — "we have five engineers, so we can build five features in parallel" ignores dependencies, shared context, and collaboration needs.
Dismissing technical concerns as excuses — when an engineer says something is hard, they are almost always telling the truth. The productive question is "what would make it easier?" not "why is it hard?"

Key Takeaways

Technical literacy is about having productive conversations, not writing code. Understand APIs, databases, latency, scalability, technical debt, and deployment processes at a conceptual level.
The goal is to make better product decisions by understanding technical constraints and trade-offs. You should be able to ask good questions and recognize hidden complexity.
Build literacy gradually: read architecture docs, attend design reviews, ask engineers to explain their work, and learn to read monitoring dashboards.
The most dangerous PM is one who thinks they understand the technology better than they do. Stay curious, stay humble, and always verify your understanding before making decisions based on it.
Dedicate consistent time to technical debt. It is not optional maintenance — it is the cost of keeping your product velocity sustainable.