The standard base unit of the product operating model: a product manager, a designer, and an engineer working together as the minimal cross-functional team for a product initiative.
Used at Datasite as the staffing baseline for each Spotify Squad Model squad. See Extended Trio (Commercial Stakeholders in Product Trios) for the Datasite-specific adaptation that adds sales or service management to this base trio.
A common misconception is that product management decides the what and why, while engineering only decides the how (implementation). Chris Jones (SVPG) argues that in the best companies, engineers are frequently the single best source of the ideas themselves, not just the mechanism for building them.
RACI and DACI matrices are held up as artifacts of the opposite mindset: they formalize "this is my job, that's your job" role clarity, which is the posture of a project model rather than a genuine Product Model (vs. Roadmap Model). The right starting posture is "we are doing this together" — not a pre-assigned division of who decides what.
Coaching line for PMs who resist input into the "what": "What company do you work for? This is not your company." Leadership sets outcomes/problems; the trio (and the wider team) collectively decides how to solve them. See also Win-Together Culture (Breaking Down Silos).
Engineers — or at minimum the tech lead — need to be in the room with the PM and designer during Discovery (Product Discovery Process) itself, not brought in for the first time at Sprint planning after the problem and solution have already been decided. A trio that only assembles at delivery time isn't really a trio; see the waterfall-in-agile-clothing pattern in Product-Model Transformation Anti-Patterns (Taxonomy) for what happens when this doesn't hold.
Christian Idiodi frames trio collaboration as risk ownership, not role handoff: the product team owns risk around value, the design team owns risk around usability, and the engineering team owns risk around feasibility (Valuable / Usable / Feasible / Viable). None of these risks resolves in isolation — a valuable idea nobody can build, or buildable technology nobody wants, both still fail. The trio's job is to walk as one unit through problem definition, discovery, design, validation, testing, and delivery, rather than pass a spec down a chain. He calls this "the constant grind and iteration of teams exchanging ideas, validating, and testing things together" — contrast with the cascading handoff pattern in Misconception: PM Owns the 'What', Engineering Just Executes the 'How'.
Из тем: The Product Operating Model