The Credibility Crisis: You can't manage what you don't deeply understand
- Arun Nukula
- 14 hours ago
- 3 min read
Introduction
You are in a high-stakes meeting with a key enterprise customer, or perhaps a quarterly review with your VP of Engineering. Someone asks a pointed question about how a specific feature handles an edge case, or why a certain integration keeps failing.
The room turns to you. You freeze. You offer a vague "I’ll have to check with the team on that."
The energy in the room shifts instantly. You have just lost "credibility currency."
There is a dangerous misconception in modern tech that a Product Manager is purely a facilitator—a connector between business, tech, and design who manages spreadsheets and moves Jira tickets.
While facilitation is part of the job, it is hollow without the core requirement: Deep, visceral knowledge of the product you are responsible for.
A PM who doesn't fully understand their product is like a chef who doesn't taste their own food. They are just following a recipe, hoping it turns out okay.
Credibility with Engineering: The "Bullsh*t Detector"
The quickest way to lose the respect of your engineering team is to propose features that are technically impossible, wildly expensive due to architectural constraints, or already exist in a different form.
Engineers possess highly tuned "bullsh*t detectors." If you treat the product as a black box where you shove requirements in one side and magic comes out the other, they will stop trusting your judgment.
Why deep knowledge matters here: You don’t need to be able to write the code, but you must understand the implications of the code. When you understand the product’s architecture, dependencies, and technical debt, you change the conversation.
Instead of asking: "Can we build this by Friday?" (A nagging question).
You ask: "Given the constraints of our current API gateway, what’s the fastest way to solve this user problem?" (A collaborative, informed question).
When engineers know you understand the "how," they trust you more with the "what" and the "why."
Ruthless Prioritization requires knowing where the bodies are buried
Product Management is essentially the job of making painful trade-offs every single day. Prioritization is impossible if your knowledge is superficial.
If you don't understand your product deeply, every feature request looks equally difficult and equally valuable. You become susceptible to the "loudest voice in the room"—whether it's a big customer or a pushy sales exec—because you lack the objective knowledge to push back.
Why deep knowledge matters here: Knowing your product means knowing its fragilities. You know that adding Feature X seems simple on the surface, but it touches a legacy codebase that breaks whenever you look at it funny. You know that Feature Y is a quick win because the groundwork was laid last quarter.
Deep knowledge allows you to accurately assess "effort vs. impact," ensuring your roadmap is based on reality, not wishful thinking.
True Empathy: Moving beyond "The User Wants X"
It’s easy to read a user research summary that says, "Users are frustrated with the export function." It’s another thing entirely to feel that frustration yourself.
If you don’t use your product regularly—dogfooding it, trying to break it, experiencing its friction points firsthand—your empathy is theoretical.
Why deep knowledge matters here: When you know the product deeply, you understand the workarounds users have invented to deal with your product’s shortcomings. You don't just see a feature request for a "better search bar"; you understand that they need a better search bar because the current navigation taxonomy is confusing and leads to dead ends.
Deep product knowledge allows you to translate vague feelings of user dissatisfaction into concrete, actionable product specifications.
The Difference Between "Technical" and "Product Fluent"
A common pushback to this advice is: "But I'm a business PM, not a technical PM!"
Understanding your product deeply is not about being the best engineer in the room. It’s about being "product fluent."
The Engineer knows exactly which lines of code need to change to fix a bug.
The Product Fluent PM knows that this type of bug usually stems from the fragile integration with Vendor X, and that fixing it carries a high risk of breaking the reporting module.
Get Your Hands Dirty
If you find yourself relying too heavily on others to explain how your own product works, take it as a warning sign.
Stop managing the Jira board for a day and start managing the product. Log in as a new user. Try to accomplish a complex task without reading the documentation. Sit with the customer support team for an afternoon and listen to what calls are coming in. Read the API documentation even if you don't fully understand it.
Knowledge is leverage. The more you know about the intricate machine you are steering, the better your decisions will be, and the more successful your product will become.
Comments