What Is Good Product Management?

An Engineer’s Perspective

From an engineer’s point of view, good product management is surprisingly simple to define and painfully obvious when it’s missing.

Good product management creates clarity. It helps engineers focus on solving the right problems, instead of just shipping features. Bad product management, on the other hand, turns engineers into ticket-takers, drains motivation, and slowly converts promising startups into feature factories.

Many of the best ideas about product management (e.g. from Elad Gil, Ben Horowitz, Lenny Rachitsky) converge on one truth: product management is not about managing engineers or writing specs. It’s about owning outcomes.

Product Management Is About Outcomes, Not Output

Engineers tend to think in systems, constraints, and trade-offs. We like clear problem statements and hate vague goals. The best product managers understand this instinctively.

Good PMs don’t start with “we need feature X.” They start with “users are failing at Y, and that’s costing us Z.” That framing matters. It invites engineers into the problem instead of handing them a predetermined solution.

Ben Horowitz famously described a good PM as someone who behaves like the “CEO of the product.” From an engineering lens, that doesn’t mean authority, it means responsibility. A good PM owns the success or failure of what gets built. They don’t blame engineering velocity, unclear requirements, or market conditions. They absorb complexity and turn it into direction.

This is why engineers respect PMs who are decisive. Someone who can synthesize inputs from design, engineering, sales, and leadership, and then make a call. Engineers would rather work with a PM who makes a wrong decision quickly and corrects it than one who never decides at all.

Early-Stage Product Management: Scrappy, Founder-Led, Execution-Heavy

In early-stage startups, “product management” is usually a misleading term. Most of the time, the founders are the product managers and that’s a good thing.

At this stage, speed matters more than polish. You’re still searching for product–market fit, and heavy process actively hurts you. Roadmaps longer than a few weeks are mostly fiction. What matters is learning fast.

Good early-stage product management looks like this:

• Talking to users constantly

• Shipping small changes weekly (or daily)

• Doing things that don’t scale

• Treating the product as a hypothesis, not a roadmap

Airbnb is the canonical example. When growth stalled, the founders didn’t debate features, they flew to New York, met hosts, and took photos themselves. That wasn’t “scalable product management,” but it solved the core user trust problem. The result was a step-change in growth.

From an engineer’s perspective, early-stage PMs (or founders acting as PMs) are valuable when they remove ambiguity and unblock execution, not when they introduce process. A great early PM is often half project manager, half user researcher, half firefighter. Yes, that’s more than one whole person, which is why founders usually do it themselves at first.

Hiring a heavyweight PM too early can be a mistake. Until you have product–market fit, vision matters more than coordination.

Scaling Product Management: From Shipping Fast to Shipping Right

Once product–market fit exists, everything changes.

The product now needs to scale across teams, customers, geographies, and use cases. This is where real product management becomes essential.

At this stage, good PMs start introducing structure, but only enough to maintain clarity. Their job shifts from “what should we build next?” to “how do we keep building the right things as the organization grows?”

This is where roadmaps start to matter. Not because they predict the future accurately, but because they align teams around priorities and trade-offs. Engineers benefit enormously from knowing why one project matters more than another.

Amazon’s “working backwards” approach is a great example of scaled product management done well. Writing a press release before building anything forces clarity on customer value. Engineers don’t just get requirements, they get context. That context enables better technical decisions throughout the build.

Facebook’s evolution from “move fast and break things” to “move fast with stable infrastructure” is another example. At scale, stability becomes a feature. Good product management recognizes when the definition of “good” has changed and adjusts incentives accordingly.

Where Product and Engineering Commonly Clash

Most product–engineering friction comes from one of three things:

1. Unclear priorities

   When leadership doesn’t explicitly choose between speed, quality, or growth, product and engineering will make different assumptions and conflict is inevitable.

2. Feature-driven thinking

   When PMs focus on outputs (“ship this feature”) instead of outcomes (“reduce churn”), engineers lose autonomy and motivation.

3. Lack of technical empathy

   PMs don’t need to code, but they do need to understand constraints. Engineers quickly lose trust in PMs who treat complexity as an inconvenience instead of a reality.

Good PMs reduce friction by making trade-offs explicit. They acknowledge technical debt, protect engineering focus, and say “no” — especially to sales-driven one-off requests that don’t align with strategy.

The best PMs also involve engineers early. Not to ask how long something takes, but to explore what’s possible. Many of the best product ideas come from engineers if you give them the problem instead of the solution.

What Engineers Actually Want From Product Management

If you ask engineers what they value most in a PM, the answer is rarely documentation or process.

They want:

• Clear goals

• Honest prioritization

• Context for decisions

• Protection from chaos

• Ownership and accountability

A good PM makes the team feel like they’re working on something that matters. They reduce cognitive load instead of adding to it. When things go wrong, they step forward not sideways.

Final Thought

From an engineer’s perspective, good product management isn’t about controlling the roadmap or translating business requests into tickets. It’s about turning ambiguity into clarity and effort into impact.

Great PMs make teams faster and smarter. They adapt their style to the company’s stage. And most importantly, they treat engineers as partners in solving meaningful problems not just builders of predefined solutions.

When product management is done right, engineers don’t complain about it. They barely notice it. Things just work.