One of the product-management misconceptions Chris Jones (SVPG) argues against: that the PM's job is to decide what to build and hand it to engineering to figure out how — with engineering treated as a downstream execution function rather than a co-owner of the solution.
Illustrative analogy (Marty Kagan, via Chris Jones): "If you're a product manager... would you give [engineers] pseudo code and ask them to work from that pseudo code? And of course, that's ridiculous" — a fully-specified "what" handed to engineering is really just pseudo-code for the "how," and treating engineers as mere implementers of it wastes their judgment.
Supporting evidence for the collaborative alternative: "When I look back at the coolest product innovations, really the best ideas, nearly all of them came from engineers on the team" — the best solutions came from engineers acting as full problem-solving partners, not spec-takers.
Organizationally, this misconception shows up as a request for rigid role-clarity matrices — see RACI (Role-Clarity Matrix) as Product-Team Anti-Pattern and DACI (Decision-Role Matrix) as Product-Team Anti-Pattern — which Chris recommends replacing with genuine shared ownership. See also Product Trio, Extended Trio (Commercial Stakeholders in Product Trios), and Win-Together Culture (Breaking Down Silos) for the collaborative structures the best teams use instead.
In good Product Model (vs. Roadmap Model) companies engineers care about what is built, not just how it's built — reinforcing that the "PM owns what, engineering owns how" split is a misconception rather than a design goal.
Cagan calls outsourced engineering a "non-starter" for the product model: a smaller group of true employees, invested in the product and the customer, will consistently outperform a larger outsourced group executing someone else's specs.
A concrete shape of the handoff antipattern: a CEO tells a director, who tells the product manager, who tells the designer, who tells the engineer what to build — a waterfall cascade rather than a trio walking together (Product Trio). Idiodi notes that larger companies, with more hierarchy, layers, committees, governance, and top-down approvals, structurally reinforce this cascade; the fix isn't just individual habit but a company structure that lets product, design, and engineering resolve value, usability, and feasibility risk simultaneously instead of in sequence.
Из тем: The Product Operating Model