Product managers who cannot read code face a structural information asymmetry that leads to misaligned sprints, inaccurate estimates, and dependency surprises. The solution is not learning to code but learning to ask five core questions about any codebase: what systems exist and how they connect, what changed recently, what is fragile, who owns each component, and where are the dependencies. PMs who understand the technical landscape gain three advantages: estimation confidence (they can sense-check timelines), specification quality (they design around fragile modules), and stronger engineering relationships (they collaborate on solutions rather than negotiating about difficulty).
At Salesken, I worked alongside product managers daily. The gap between what PMs needed to know and what they could actually see in the codebase was enormous — and it cost us weeks of misaligned sprints.
By Priya Shankar
I spent a week trying to understand why one feature took three weeks to ship when another similar feature took two days. I asked every engineer I could find. The answers were all different. "The codebase is messy." "We had to wait for another team." "The API contract changed." "We didn't anticipate the dependency."
None of those answers were satisfying because they didn't tell me anything I could act on. So I did what any PM would do: I gave up. I accepted that some things are just slower for reasons I don't understand.
That's the wrong move. Here's what I actually needed to know: I don't need to read the code. I need to ask better questions.
The Questions That Matter
There are five things a PM should be able to answer about their product's codebase without reading a single line of code. If you can't answer these questions, your visibility into technical reality is too low.
First: who owns what? Not "who wrote this code," but "who is responsible for this module right now?" This matters because it's the difference between understanding constraints and guessing about them. If the payment module is owned by one person, and that person is on vacation, that's real information. If it's owned by a team, you have options. You can pull in resources. If it's not owned by anyone, that's the most important piece of information ( - it means there's a gap in the system.
Second: what's the most fragile part of the codebase? Every system has a bottleneck. A module that's old, that's touched frequently, that nobody understands, that has high coupling to other modules. That module is your risk center. As a PM, you want to know what it is because decisions that touch it are more expensive and riskier than decisions that don't. When you're evaluating a feature, "does it touch the fragile module?" is the most important question you can ask.
Third: what changed last sprint? Not "what shipped to users" but "what changed in the codebase?" The reason this matters is that technical work ( - refactoring, dependency upgrades, test suite improvements ( - doesn't show up on a product roadmap, but it's happening. If you know that last sprint was 30% refactoring work, you know why the feature velocity looked lower than you expected. You can calibrate your expectations. You can plan better.
Fourth: where is the technical debt concentrated? Every codebase has debt. But it's not evenly distributed. Some modules are old and messy. Some are clean. The PM needs to know which is which because it changes how you think about future work. If the next feature touches a low-debt module, it's probably low-risk. If it touches a high-debt module, you need more buffer.
Fifth: what would a new feature in this area need to touch? Before you commit to shipping something, you want to understand the surface area. A feature that touches one module is different from a feature that touches seven. A feature that touches modules that don't usually interact is different from a feature that touches modules that are already tightly coupled.
How to Get These Answers
You don't get these answers by reading code. You get them by asking the right people the right questions.
For "who owns what," ask the tech lead or the CTO. They should be able to draw you a map ( - "this person owns the API layer, this person owns the database layer, this person owns the frontend." If they can't answer quickly, that's information too ( - it means ownership is unclear and you have a risk center.
For "what's fragile," ask the most experienced engineers. They know. Ask "if you had to bet your career on what breaks first, what is it?" They'll tell you. It's usually correct.
For "what changed last sprint," look at the sprint retro and look at the commit history. But more simply, ask the engineering manager "how much of last sprint was refactoring vs. features?" They should know.
For "where's the debt concentrated," ask three engineers to name the modules they dread working in. The modules that appear on multiple lists are the high-debt ones. Or use a tool that maps this for you.
For "what would touch," ask the lead engineer on the relevant feature: "Walk me through what this feature would touch. What modules? What APIs? What databases?" You're not asking them to teach you programming. You're asking them to explain their system. Most engineers are happy to do this.
The Proxy Questions
But here's the real trick: you can also ask proxy questions that hint at the state of the system without needing explicit answers.
Ask your incident commander: "What's the module that generates the most incidents?" High-incident modules are usually the high-debt ones. If payment incidents are 40% of your total incidents, the payment system is fragile.
Ask about onboarding time: "How long does it take a new engineer to contribute meaningfully to the X module?" If it's two weeks, it's understandable. If it's two months, it's opaque.
Ask about test coverage: "Does the critical path have test coverage? What about the edge cases?" Low test coverage on complex code is a risk signal.
Ask about code review time: "How long do PRs sit in review for the payment module vs. the API module?" Long code review times are a proxy for opaque code.
None of these are perfect. But they all point in the right direction. If five different proxy signals all suggest the payment module is fragile, it probably is.
The Tool Option
The other option is to give yourself better access. A tool like Glue that shows you module ownership, dependencies, and change history lets you look at this directly. You're not reading code. You're reading metadata about the code.
You can ask "who owns the notification system?" and get an answer in 30 seconds. You can see "this feature would touch these modules" without having to sit down with an engineer and whiteboard it. You can see "this module hasn't been touched in six months" and know it's potentially fragile.
This is not a replacement for conversations with engineers. But it is a replacement for being totally blind. You go from having no information to having some information, which is a massive gap.
What Changes When You Know These Things
The first thing that changes is your estimation confidence. When you understand the technical landscape, you can sense-check estimates. You know why something takes three weeks instead of two days. Not because someone told you, but because you can see the system.
The second thing: your specs get better. If you know that a feature touches a fragile module, you can design around it. You can change the scope. You can choose a different approach. You make better decisions because you have better information.
The third thing: you build better relationships with your engineering team. Because you're no longer asking them to justify constraints that you can see and understand yourself. You're collaborating on solutions, not negotiating about difficulty.
Frequently Asked Questions
Q: If I ask engineers these questions, won't it seem like I don't trust them?
The opposite. You're taking their work seriously enough to understand it. Building codebase intelligence is about curiosity, not skepticism. Ask the questions in a spirit of curiosity, not skepticism, and most engineers love it. "Help me understand why this is complex" is very different from "why are you taking so long?"
Q: How often should I ask these questions?
The five core questions should be on your radar every quarter. But some of them change more frequently. "What changed last sprint?" is every sprint. "What's fragile?" changes slower ( - probably yearly or when you get a signal that something broke.
Q: What if the answers are "we don't know" or "it's complicated"?
That's valuable information. It means you have a visibility problem. The solution is either to invest in clarifying ownership and software architecture documentation, or to bring in a tool that gives you that clarity. Either way, you know you have a problem that needs solving.
Related Reading
- AI for Product Management: The Difference Between Typing Faster and Thinking Better
- The Product Manager's Guide to Understanding Your Codebase
- AI Product Discovery: Why What You Build Next Should Not Be a Guess
- Cursor for Product Managers: The Next AI Shift Nobody Is Talking About
- Product OS: Why Every Engineering Team Needs an Operating System
- Software Productivity: What It Really Means and How to Measure It