The product trio

Product management is deciding what to build and why, then checking whether it worked. It is not project management (tracking dates), not backlog administration (grooming tickets) and not "the person who writes the PRD." Those activities show up. They are not the job.

In strong teams, product is a trio: a product manager, a designer and an engineer (or tech lead) who share ownership of outcomes. You do not need a PM title to play your seat in that trio.

The big idea

The PM usually owns the business case and the prioritization narrative. Design owns usability and interaction. Engineering owns feasibility, architecture and operational cost. Discovery — talking to users, testing assumptions, shaping solutions — is shared work, not a handoff chain.

A restaurant brigade is a useful picture: the floor, the kitchen and the menu have to agree on what "good" is tonight. The analogy breaks when one person is wearing all three hats, which is common on small teams. The roles still exist; one human is just playing all of them.

What product management is not: a waterfall gate that throws requirements over a wall, a proxy for the CEO's feature list, or a role that exists so engineers never talk to customers. If your "PM" only writes tickets from stakeholder requests and never runs discovery, you have a backlog manager — and engineers still need product thinking to fill the gap.

For day-to-day collaboration patterns, see working with PMs.

Walking through it

A ticket arrives: "Add CSV export for invoices." A handoff team estimates, designs a download button and ships. A trio asks who reconciles invoices today, how long it takes and what "done" means for ops.

Suppose ops spends 40 minutes reconciling by hand. The trio might learn that the job is "know whether to start new work for a client," not "download a file." The solution might be a status badge, not a CSV. Discovery changed the delivery.

Agile standups, sprint planning and a perfect Jira board will not catch that. Those tools optimize delivery. The trio's job is to keep discovery on the calendar so delivery has something true to build.

Common mistakes

• Treating the PM as the person who writes tickets. Tickets are an output of discovery, not a substitute for it.
• Engineers waiting for a perfect spec. Feasibility and operational cost belong in the conversation while the problem is still being shaped.
• Calling status meetings "discovery." If nobody talked to a user or ran a test, you were planning delivery.

Check yourself

1. Your PM grooms a backlog of stakeholder requests and never speaks to customers. What role do you actually have?

A backlog manager. Discovery still has to happen, and engineers need to help fill the gap.

2. Why does "the spec is clear" not mean the trio is working?

Clarity of solution is delivery. The trio also has to share the problem, the user and how you will know it worked.

Key takeaways

• Product management decides what and why, then learns whether it worked — it is not project management.
• The trio (PM, design, engineering) shares discovery and outcomes.
• Delivery rituals cannot rescue a backlog that was never checked against real problems.

Further learning

Marty Cagan on Lenny's Podcast is a clear tour of what great product teams do: discovery, strategy and empowerment.

Next: how engineers practice this on every ticket in product-minded engineers.