More product, fewer product managers

Original Article ↗ Hacker News Discussion ↗

Engineers, managers, and longtime PMs debate whether modern software teams have too many product managers and too little actual product ownership. Many argue that PM work is essential—understanding users, the market, and strategy—but that the role is often misused as glorified project management, ticket wrangling, or internal politics, especially in large organizations. A recurring theme is that product management must exist, but it works best when PMs are few, deeply competent, close to both customers and engineers, and when more engineers are encouraged to be product-minded.

Role of Product Managers vs Other Roles

  • Ongoing confusion between “product” and “project” management; many orgs conflate them.
  • Some see PM as “project management with extra steps” (market, customer, strategy).
  • Others draw a clean split: PM owns why/what, project manager when, engineering how/who.
  • In practice, many PMs are forced into project coordination and Jira administration.

What Good PMs Do (According to Thread)

  • Act like “mini-CEOs”: understand customers, market, and business goals; shape vision and strategy.
  • Spend substantial time with users, sales, support; synthesize feedback into clear problems and priorities.
  • Bridge stakeholders and engineers, providing context, managing tradeoffs, and protecting focus.
  • Have enough technical/architecture awareness to understand constraints and sequence work intelligently.

Common Critiques of PMs

  • Many PMs are seen as ticket-shufflers, meeting-creators, or “bullshit jobs” with little real ownership.
  • Empire-building CPO orgs lead to PMs owning tiny slices (single pages, button CTRs) far from strategy.
  • PMs often micromanage “how” without understanding technical complexity, or avoid users altogether.
  • Engineers report PM-driven politics, status theater, and schedule pressure without clear product direction.

Engineers as Product Owners?

  • Some argue the best teams had no PMs: engineers, plus business stakeholders, talked directly to customers.
  • Counterclaim: most engineers are poor at product and project management without incentives and time; PM work still must be done by someone.
  • Example patterns without PMs: unclear goals, weak user research, internal “camps,” over-engineered but misaligned features.

Ratios, Scale, and Org Design

  • Consensus that “more PMs ≠ better”; ratios should minimize meddling and maximize autonomy.
  • PMs add most value when owning significant surface area (whole product or major module), not single screens.
  • At startups, many feel founders should do PM until they truly cannot; extra PMs too early become bureaucracy.

Technical vs Non-Technical / Domain Expertise

  • Many prefer PMs with at least some coding or systems understanding, especially for technical products or regulated domains.
  • Others emphasize domain and user expertise (finance, HR, medical, retail) over deep tech.
  • Best PMs reportedly combine user empathy, business sense, and enough technical intuition to discuss tradeoffs.

Incentives, Politics, and Culture

  • Incentive structures often reward technical output over user impact, discouraging engineers from PM-like work.
  • PM behavior is shaped by organizational incentives: if promotion is tied to slideware and big meetings, that’s what you get.
  • Several note that dysfunction blamed on PMs is frequently a leadership and culture problem, not inherent to the role.

Miscellaneous Side Threads

  • Brief but heated tangent about AI/stock “hero” images and their low-quality, generic feel.
  • Broader reflections on “too many roles” in big tech (PM, scrum master, QA, etc.) and the appeal of leaner, flatter teams.