Topic 18 — Technical literacy for PMs

Goal: Understand enough about how software works to make good calls and earn engineers' trust.

Lesson 18.1 — You don't need to code (so what do you need?)

Maya is in a planning meeting at Lumi when Sam, the senior engineer, sighs and says, "Yeah, we could do that, but the auth flow would have to change." Everyone nods. Maya nods too. She has no idea what he just said, and she's pretty sure he can tell.

That gap is what this topic closes. Not by teaching Maya to code. She will never write the auth flow, and nobody expects her to.

What she needs is technical literacy: enough of the concepts and the vocabulary to follow the conversation and weigh in honestly. The bar is a PM's level of understanding, not an engineer's. You don't need to know how the engine is built. You need to know roughly what's under the hood, so you can tell when someone says "that's a quick fix" versus "that's a month."

With it, Maya makes more realistic decisions, asks sharper questions, and explains technical reality to Dan in sales without bluffing. Without it, something quieter happens: engineers stop trusting a PM who "doesn't get it," and her scoping starts going wrong in ways she can't see.

Maya has watched people learn it. Her own manager came from marketing and now talks shop with Sam like they grew up together. So this is doable, and the next four lessons are the core of it.

Lesson 18.2 — What actually happens when you tap a button

Maya opens the Lumi app and taps "Log in." A half-second later she's looking at her budget. Where did that half-second go?

Almost every product, including Lumi's, runs on the same three pieces. Picture them.

• The frontend (the client). This is everything on Maya's phone: the screens, the buttons, the login form she just tapped. It's built with technologies like HTML, CSS, and JavaScript. She'll never write those, but that's what's running on the device in her hand.
• The backend (the server). The brain. It lives on remote computers in the cloud, holds all the logic and rules, and does the heavy lifting. When something feels like "the app is thinking," this is where the thinking happens.
• The database. Where the data lives: every user, every transaction, every budget, stored and waiting to be looked up.

Now the half-second. Maya tapped "Log in," so the frontend sent a request up to the backend. The backend checked the database to see if her password matched. It found her, said yes, and sent back a response. The frontend showed her budget. Request, process, respond.

That loop is the request/response cycle, and it runs under nearly everything: the frontend asks, the backend processes (usually reading or writing the database), the backend answers, the frontend shows the result.

Frontend asks, backend thinks, database remembers, response shows.

Once Maya could see this loop, a lot stopped being mysterious. Why does the budget screen load instantly but the "yearly report" take three seconds? Because one is a quick lookup and the other makes the backend crunch a year of data first. Same loop, different amount of work in the middle.

Lesson 18.3 — Two words you'll hear every single week

Lumi's app shows the local weather on the home screen, next to the budget. Maya assumed someone built a little weather feature. Sam laughed. "We don't know what the weather is. We just ask someone who does."

That's an API (Application Programming Interface): how one piece of software talks to another. Lumi's app sends a request to a weather service through its API and gets the forecast back. Think of ordering at a restaurant. You don't walk into the kitchen. You tell the waiter what you want, the waiter brings it back. The API is the waiter between your app and someone else's.

PMs bump into APIs constantly: plugging in a payment provider, connecting two tools, or opening up Lumi's own API so partners can build on it. Knowing what an API is lets Maya reason about what's actually possible and what quietly depends on someone else's system.

The second word is the data model (or schema): how the product's information is structured and connected. Which "things" exist in Lumi's world (users, transactions, budgets) and how they relate (a transaction belongs to a user). Maya doesn't design it. But when Priya asks "can we show each user every transaction from the last two years?", the honest answer is "depends how the data is structured" — and now Maya knows enough to ask that instead of just promising it.

One more idea rides along with APIs: third-party dependencies. Modern products are partly built from other companies' services. Lumi uses an outside provider for payments, another for sending email, and the CEO keeps mentioning an AI service for that "assistant" idea. Leaning on these is fast, and it's smart. It also adds risk and hard limits. "We can't do that because our payment provider doesn't support it" is a real sentence Maya will say, and mean.

Lesson 18.4 — Why "small" is the most dangerous word in the room

Maya once told Dan a feature was "a small change." Sam spent two weeks on it. She learned something that day: "small" is a feeling, not an estimate.

The biggest payoff of technical literacy is understanding trade-offs — being able to follow why engineers call something hard, slow, or risky, so you can scope it well. Four come up over and over.

Technical debt. To ship Lumi's first version fast, the team took shortcuts. Those shortcuts now make new features slower to add. Picture a house someone built in a hurry: livable, but every new room is a fight because the wiring's a mess. Sometimes you take the shortcut on purpose to hit a deadline, and that's fine. It's only dangerous when nobody admits it's there. Maya's job is helping the team weigh shipping speed against cleaning up.

Build vs. buy. When the CEO wants the AI assistant, Maya faces a classic fork. Build it themselves for full control, but spend months? Or wire in an existing AI service through its API, fast but now they're dependent on it? Neither answer is automatically right. Knowing the trade-off is the point.

Edge cases and scale. "It works for one user" and "it works for a million users" are different sentences. The Excel export Sam wrote runs fine on Maya's test account with 40 transactions. On a customer with 80,000, it might choke. Things that are simple at small scale can turn brutal at large scale, which is why Sam cares about cases Maya would never have thought of.

Why estimates vary. A "small" button move and a "small"-sounding change to how data is stored can differ by weeks. So when something gets estimated high, Maya's best move isn't to push back. It's to ask "what makes this hard?" and actually listen. That question makes her decisions better and tells Sam she respects the work.

She doesn't resolve any of these the way Sam would. She understands them well enough to weigh them and explain them to Dan and the CEO.

Lesson 18.5 — Answering your own question in five minutes

Dan asks Maya: "How many users actually used the weekly-budget feature last week?" The old Maya files a request with the data analyst and waits three days. By the time the number comes back, the meeting it was for is over.

PMs are increasingly expected to be hands-on with data, at least enough to answer the simple stuff themselves. Three tools cover most of it.

Reading dashboards and basic analytics (Topic 9) is the floor. Maya should be able to open the analytics tool and read the charts without help.

A little SQL goes further. SQL is the language for asking a database a question, and it reads almost like English: select these columns, from this table, where this thing is true. Maya isn't becoming an analyst. But "how many users opened the weekly budget last week?" is a question basic SQL can answer in a couple of lines, and learning that much is very doable.

And spreadsheets (Topic 13) handle the quick slice-and-dice once she's pulled the numbers.

Being even a little data-hands-on changes Maya's speed and her credibility. She validates a hunch in minutes instead of waiting days for a ticket. Put it together with everything above, and the whole goal of this topic comes into focus: be technical enough to make great product decisions and partner well with engineers, without ever needing to become one.

Worked example — Scoping a "simple" request

Dan drops a request in Maya's lap that sounds like nothing: "Just let users export all their data. Everything. Including their payment history and the emails we've sent them." Old Maya says "sure, easy." New Maya pauses and runs it through everything in this topic.

The user's own records — their account, their transactions, their budgets — live in Lumi's database. Exporting those is straightforward.

But payment history doesn't live at Lumi. It sits inside the third-party payment provider, reachable only through its API. That API might rate-limit how fast Maya can pull data, might lag, might not even expose everything she'd want. The email data is in yet another outside tool, with its own quirks.

So "export everything" was never one task. It's an easy part (Lumi's own data) bolted to two risky, dependency-bound parts (the integrations Dan didn't know were integrations).

Maya scopes a first slice: export Lumi's own data now, this sprint. She flags the payment and email pieces as harder follow-ups, not a no, just a later. And instead of promising it all by Friday, she walks over to Sam and asks, "What makes the payment export tricky?"

Technical literacy turned a naive yes into a plan Sam respects and Dan can sell.