--- title: PMs Don't Need to Code, but They Do Need to Understand teaser: A Product Manager doesn't need to code, but understanding technology can completely change the quality of conversations, decisions, and collaboration with engineering. tags: playbook,product management,communication,collaboration,learning author: Mariia Sus published_on: 2026-08-19 --- One sentence I've heard many times is: "Product Managers don't need to be technical." I agreed with it for years. I still do - I don't think PMs need to code. But over the last couple of years, I've changed my mind about something else: I do think PMs need to build technical literacy. Not because developers need help coding. Not because PMs should review pull requests. Simply because becoming familiar with the technology helps you make better product decisions. **The moment I realized I had a gap** When I joined a more complex product, I had meetings like this: Developer: *"We'll keep the old SDK as a fallback and gate the new one behind a feature flag."* Me: ![](https://images.thoughtbot.com/xqiov36atv291chd3qts4wp2xh0f_masha-blog-image.png) I had no idea what that meant. So I smiled, nodded, and quietly made a list of words to google the second the meeting ended. For a while I felt a bit guilty about that. Shouldn't I have just asked, right there in the room? But here's the thing - it's hard to know what to ask first, when you don't understand half the sentence. So I did the only thing that actually worked: I quietly built the vocabulary on my own time first. And once I had it, technical discussions became much less intimidating. **The day estimates started making sense** Sometimes people hear, *"PMs should understand tech,"* and reply, *"You should trust the developers."* Absolutely! I trust developers 100%. But trusting someone doesn't mean you shouldn't keep up with what they're saying. Having that context lets you have a more meaningful discussion instead of simply accepting things at face value. One situation made this click for me. Imagine a developer says: *"This small feature will take three weeks."* If I don't understand what's behind the estimate, I have no choice but to accept it. Three weeks sounds like... three weeks. But if I have enough context, I can ask: *"What's making it expensive? Is it authentication? A third-party integration? A database migration?"* **I'm not trying to challenge the estimate - I'm trying to understand what drives it.** Those answers matter. They help me see the trade-offs behind the number instead of treating it as something I simply have to accept. And that's the real difference. I'm no longer just relaying information between developers and stakeholders. I'm actually partnering with the team. **The trap I almost fell into** When I decided to become *"more technical",* I made the classic mistake. I wanted to learn... everything. Backend. Frontend. Cloud. Databases. Networking. Security. Architecture. Payment SDKs. Kafka. (*The only Kafka I knew back then was a writer* 😂) Three days later I had 37 browser tabs open and somehow understood even less than before. What actually worked was much simpler: one concept at a time. One week it was feature flags. Another week deployments. Then authentication. Then environments. Not because I bought a course, but because those topics came up in conversations with my team. **The product became my classroom.** **Learn the language, not programming** Every profession has its own language. Doctors. Lawyers. Designers. Developers too. You don't need to know everything. But understanding words like Pull Request, Branch, Deployment, Prod, and Release means you're no longer lost in every engineering discussion. The same goes for bigger concepts: authentication vs authorization, environments, incident response, dependencies. You don't need to become the expert. You just need enough knowledge to follow the conversation. **Does every PM need this?** Honestly, it depends. When I worked on products searching for product-market fit, I didn't feel a huge need for technical knowledge - the biggest questions were about users, problems, and direction. Later I joined more mature products with bigger systems. That's when I started feeling uncomfortable. I couldn't follow conversations. I couldn't spot risks. I couldn't explain why simple-looking changes sometimes took weeks. Same PM. Different product. Completely different demand. So no, I don't think every PM needs the same level of engineering knowledge. But I do think every PM benefits from continuously learning enough to work more effectively with their engineering team. **My biggest takeaway** You don't need to code or become a software engineer. And you definitely don't need to pretend you understand OAuth scopes. (I'm still working on that one 😄) If you're building software, it's worth learning how that software works. Not because developers need your technical input, but because every concept you learn helps you ask better questions, spot risks earlier, and ultimately make better product decisions. Looking back, learning how software is built hasn't made me a software engineer. But it has made me a better Product Manager, and I'm still learning 🚀.