Week 40, 2026
I have spent almost three decades on both sides of product and engineering. First as an engineer. Then in implementation. Later leading Product Managers and engineering teams.
Over the years, I noticed something that most engineers will never say directly: product does not belong to Product Managers. Many of us act as if we own the product while engineering owns delivery. But the best teams I have ever worked with never operated that way. They acted like owners together. Different responsibilities. Shared outcomes.
Because of that, engineers often see things that PMs do not. They notice habits that help teams succeed and patterns that quietly create friction. Most are professional enough not to say these things out loud. But if they did, the conversation might sound something like this.
The best PM we ever worked with was not the smartest one in the room.
It was the one who made everything clearer. The one who told us what mattered, why it mattered, and what success looked like. Then got out of the way.
Many PMs think their value comes from having the answer. Most engineers would disagree. They respect PMs who reduce confusion, not PMs who dominate every discussion. If one point in this article is worth remembering, it is probably this one.
And once a team has clarity, the next thing they look for is consistency.
If everything is a P0, we stop believing any of it.
Every PM faces pressure. Customers. Sales. Leadership. Deadlines. Eventually everything starts looking urgent. The problem is that engineers notice very quickly when every request becomes the highest priority.
After a while they stop listening to what we say and start making their own decisions about what matters most. When we fail to choose the priority, someone else chooses it for us. Usually not the way we intended.
Priority confusion often leads to another signal engineers pick up on immediately.
When you change the spec on Thursday, we know it is not a small tweak.
Most of us have said those words. “It’s a small change.” “It should be easy.” Engineers usually know better.
A spec that keeps changing tells the team that the thinking is still happening. Not because the PM is bad at their job. Because they are still trying to understand the problem. The uncomfortable truth is that many PMs start development before they finish thinking. Engineers see that long before we do.
Which leads to a deeper point about how product discussions begin.
Tell us the problem before you tell us the solution.
Too many PMs walk into a room with a feature request and skip the why. We call it preparation. Engineers often experience it as a limitation.
Engineers cannot build something well if they do not understand what problem it solves. The best product decisions I have seen came from teams that were aligned on the problem first and argued about the solution second. Every time we lead with the problem, the solution gets better.
And how we work with engineering matters just as much as how we think with them.
We notice how you talk about our work to leadership.
Engineers remember who shares credit and who collects it. They notice the difference between “we built this” and “I drove this.” They notice who celebrates the team and who makes themselves the story.
Most engineers do not need recognition every day. But they do pay attention to fairness. Trust is often built in small moments. It is also lost there.
After all these years, I have come to believe that the PM-versus-engineering mindset is the wrong one. We should not try to be the smartest people in the room. We should be experts in defining why something should be done. Engineering should be experts in defining how it should be done.
Both groups should own the product. Both should own their craft. Both should bring expertise into shaping the scope of the work. Not in isolation from each other, but together.
The strongest teams are not made of PMs giving orders and engineers executing them. They are made of people solving the same problem from different angles. In the end, there is no “we” and “they.” There is only the team.
This newsletter reflects my personal views and experiences as a product manager. It does not represent the views, strategies, or opinions of my employer or any organization I am affiliated with.
