Dear Non-Technical PMs: You’re More Capable Than You Think
Many product managers who have no technical background want to learn code. We feel we are not “technical enough” to talk with the engineers.
As one of non-technical product managers, I used to tell them that you don’t need to learn code to talk with engineers. What you need to learn is curiosity, rational thinking and asking questions.
When I Became The Problem
Now I work on a data developer tool. I found myself saying that I was “not technical” enough to understand users, the data engineers’ daily work, and “not technical” enough to think about the next big move of the product. I found myself waiting for someone more technical to point me in the right direction.
It started with a humble mindset: “I’m not technical so can you tell me what is XX?” Sometimes I used it to guide the expectation: “I’m not technical so if you want to know what is XX or how to do YY, you need to talk to the engineers.”
Today I realized that’s simply not true. I used it as an excuse: “I’m not technical enough so (it’s ok) I don’t know XX.”
Getting the Advice from Community
I joined the Locally Optimistic peer coaching program to ask the coach how to be more technical to understand these technical terms and concepts. My coach, Ilan Man, told me that while concepts may be shared, the details are often different. It’s common for a data engineer who has never used BigQuery doesn’t understand what “schema” means in that context — it may have a different meaning in Snowflake. If I hear something I don’t know, a good engineer can explain the concept in a simple way to me.
All I have to learn is the concept. Asking why we need this, what problem we want to solve, why this function can solve this problem, ask many why and go deeper. When he said this, I was wondering: Wait❗ He is a data scientist and engineer, but he is telling me how do product work. This is how product managers operate: When people come to us, we ask problems behind the requirements.
His advice gave me confidence. I realized that technical terms are just shortcuts: labels that engineers use to communicate faster about the concepts underneath. But what really matters is understanding the underlying concept: What it is, why we need it, how it helps solve problems, and most important, what are the problems. Learning these doesn’t require me to be ‘technical’ in the traditional sense: I don’t need to write code, configure servers, or understand how to build the systems. It requires the same skills I already use as a PM: curiosity, systematic thinking, and asking the right questions.
For example, when I encountered terms like ‘runtime,’ ‘binary,’ and ‘artifacts’ in dbt documentation, I could read the English but didn’t truly understand. After talking with engineers, I learned what they meant: ‘runtime’ is when software is running (and we care because that’s when we use compute resources), ‘binary’ is a program ready to run (and we need it to integrate with other systems), and ‘artifacts’ are things produced after a program runs (and we need some informations from it).
I don’t need to memorize technical vocabulary. I need to understand the concept and why it matters for solving our users’ problems. The terms are just communication shortcuts: the real understanding comes from grasping the logic and purpose behind them.
The Wake Up Call
I felt confident with this new understanding, but then came the real test. When dbt changed their licenses, I didn’t realize it would change the ecosystem, while the engineers immediately sensed this problem. I thought 🤦♀️: “Oh, is that again? Because I don’t technical enough to think about that?”
The gap isn’t technical ability, it’s domain knowledge. I just need to know what to research.
I spent 10 minutes researching open source license history on Perplexity and immediately understood how license changes can disrupt entire ecosystems. The engineers had lived through the history so they know without research. The knowledge was there, waiting to be discovered. I just hadn’t looked for it before.
Things like this may happen again. I don’t know what I don’t know. But it’s OK. When I encounter something I don’t know, I can research it. With so many AI tools available, learning new concepts is faster then ever.
Building Context, Not Technical Skills
When I dive into open source projects, data developer tools, or emerging tech trends, I’m not learning to code. I’m building context. I’m understanding the landscape, the constraints, the opportunities. This context is what enables great product decisions.
Here’s the real superpower 💪. Start with user needs and work backward. Define what problems need solving without needing to know how to solve them. Break down complex requirements into focused conversations with engineers. Ask the right questions because you understand the context, not because you can write the code.
I Don’t Know YET so I’ll Learn
It should be flipped from “I don’t know” to “I don’t know YET so I’ll learn”. Funny enough, I’ve actually written about the power of YET before.
Writing is another great way to establish the confidence. When writing about the domain I work, the concept we discuss, the term I hear from the users, the functions we build in the product, I’ve discovered I’m good at breaking down complex concepts and making them accessible. My strength isn’t in implementation, it’s in translation and communication. That’s why I’m a product manager.
The real role of PM
Product management isn’t about being the most technical person in the room. It’s about being the best translator between user problems and technical solutions.
Stop using “not technical enough” as an excuse. Start building context instead.
