This is not a provocation, it is an observation. In the majority of teams I have worked with over the past fifteen years, the Product Manager was either the person who made everything work, or the one who slowed everything down. There was rarely any middle ground. And when I started asking myself why, the answer did not lie with the people, it lay with what they were being asked to do.
The standard model looks roughly like this: the business has a problem, a PM translates it into specifications, designers produce mockups, developers write code. It is a pipeline. Each stage depends on the previous one. And at the center of this pipeline sits the PM, who is supposed to understand the customer, negotiate priorities with stakeholders, write specs detailed enough to leave no ambiguity, and still find time to think about strategy. These are four different jobs. Most people do one or two well. Almost no one does all four.
The result is predictable. In many organizations, the PM becomes a bottleneck not because they are incompetent, but because the role is overloaded by design. They spend their days in alignment meetings, translating between groups that could talk to each other if someone had thought to set that up. They write documents that attempt to remove all ambiguity from problems that are ambiguous by nature, then wonder why the team builds something that matches the spec on paper but misses the point entirely.
Here is what I have come to believe: no PM is better than a bad PM. A bad PM -- meaning not a bad person but someone trapped in a bad role definition -- does active harm. They insert themselves between the team and the problem. They make decisions that the team would make better, because the team is closer to the material. They create a dependency where none needs to exist.
The IT model versus the product model
Most companies that think they are doing product are doing IT with different vocabulary. The test is simple: look at what flows down from management to the team. If it is solutions, you are in IT mode, regardless of what is printed on the business cards. In IT mode, you need a PM, or at least a project manager, because someone has to coordinate the execution of solutions that have already been decided. It is logistics work, and there is nothing wrong with that, but let us call things by their name.
The product model is of a different nature. In a product model, what arrives at the team is a problem. Not a solution, not a feature request disguised as a user story, but a real problem that a real customer encounters, formulated well enough that the team can verify whether they have solved it. The difference seems subtle but it changes everything downstream.
When you give a problem to a team instead of a solution, several things happen. First, the people closest to the implementation space -- designers and developers -- begin generating solutions. Second, the range of possible solutions widens, because you have not pre-filtered it through the imagination of a single person. Third, and this is the part most managers find uncomfortable, the team takes ownership of the outcome.
Designers who know the customers
There is a persistent organizational fiction that designers need PMs to know what customers want. This fiction survives because in most companies, designers are kept at a distance from real customers. They receive secondhand information, filtered through PMs or through survey data that someone thought to share.
But this is a self-reinforcing constraint, not a law of nature. When designers spend time with customers, when they watch them work, listen to their complaints, understand the context in which they use the product, they develop an intuition for what matters that no amount of specifications can replace. A designer who has watched twenty customers stumble over the same flow does not need a PM to write them a user story. They have already internalized the problem, and they have been sketching solutions in their notebook for weeks.
Developers manage themselves
The other half of the equation is technical autonomy. The IT model assumes that developers are execution resources: they receive specs and produce code. This assumption creates a need for ever more detailed specs, because if the developer's job is to implement what is described, then any gap in the description becomes a defect.
In my experience, developers who understand the problem they are solving make better implementation decisions than any specification could prescribe. They know things about the system that no PM document captures: where the technical debt lies, which abstractions are fragile, where a small change in approach could save weeks of work. When you hand them the problem, they bring this knowledge to bear on the solution. When you hand them a spec, they park this knowledge and follow the instructions.
This does not mean there is no structure. Quite the opposite. A team without a PM needs more methodological rigor, not less, because there is no one whose job it is to impose order through force of personality. The methodology becomes the structure.
A framework that replaces the coordinator
The approach I use draws on Shape Up, Ryan Singer's work at Basecamp, adapted to the contexts in which I have operated. It has four steps, and the order matters.
The first step is to find a solution. This seems backward, but the logic is deliberate. You start from the problem, yes. But the first real work the team does is to explore whether a viable solution exists within realistic constraints. It is a short, focused investigation: can we solve this, roughly how, and what would the hard parts be?
The second step is to frame. Framing means describing the solution at the right level of abstraction, concrete enough that everyone understands what is being built, abstract enough that the team retains room to maneuver during implementation. Good framing involves fat-marker sketches rather than pixel-perfect mockups. Framing is what a PM spec tries to be but rarely succeeds at, because a spec tries to be exhaustive where framing tries to be clear.
The third step is to define the appetite. Appetite is not an estimate. An estimate answers "how long will it take?", appetite answers "how long is it worth?" The distinction matters. An estimate is a prediction about the future. Appetite is a business decision about investment. If the answer is two weeks and the team's best estimate is four, you do not negotiate the estimate, you reduce the scope or you kill the project.
The fourth step is to slice. Slicing happens after the appetite is set, and it is done by the team that will do the work. This is where you break the framed solution into pieces that can be completed one by one, where you identify the unknowns that need to be resolved first, and where you make the thousand small decisions that specs try to make in advance but cannot.
What it looks like in practice
In practice, operating this way means the person who would have been a PM becomes something closer to a product strategist or a PO, someone who maintains the list of problems worth solving, who ensures the team has access to customers, and who participates in appetite decisions. They do not write specs. They do not manage the team's daily work. They do not sit between the problem and the people solving it.
The first two weeks are always uncomfortable. Designers wonder who is going to tell them what to design. Developers ask where the tickets are. Stakeholders worry because no one is producing the tracking reports they are accustomed to. It passes. Once the team solves its first real problem end to end, without being told how, something shifts. They stop asking for permission and start asking for clarity.
The title of this piece is deliberately reductive. Some teams need a PM, and some PMs are extraordinary -- the kind who elevate everyone around them because they understand their role as that of a connector rather than a controller. But the reflex of hiring a PM every time a team struggles deserves to be questioned. Often the team does not need one more person. It needs a better method, more direct access to customers, and the trust to solve problems in its own way.