Ask Teresa: Who’s Responsible for What in the Product Trio?

Teresa Torres argues that every member of the product trio (product manager, designer, engineer) is jointly responsible and accountable for all five risk areas: desirable, viable, feasible, usable, and ethical. Assigning each risk to a single role, such as engineering owning feasibility, creates silos and opinion wars rather than collaboration. She acknowledges members contribute different expertise and should lean on each other's strengths, but warns against formally naming a single 'lead' for each risk. Teams should be willing to let whoever is available run an assumption test when speed matters. The piece matters because it reframes role boundaries as a tool for forcing real cross-functional problem solving.

01Key takeaways

• Treat all five risk areas (desirable, viable, feasible, usable, ethical) as shared responsibilities of the whole product trio.
• Hold every trio member accountable for feasibility and usability, not just the specialist, to force real collaboration on trade-offs.
• Let the strongest person investigate a risk, but require them to share findings so everyone can evaluate them.
• Avoid naming a single 'lead' per risk area, since it defaults all of that risk to one role.
• When a specialist is busy, let another trio member run a quick assumption test instead of waiting.
• Actively counter role-based mental models because teams tend to fall back on old assignments.

02Key sections

Shared risk, shared responsibility

The trio is collectively responsible for building a product that is desirable, viable, feasible, usable, and ethical. Splitting risks by role leads to conflicts when the best option for one discipline clashes with another.

Responsible versus accountable

Each trio member should be both responsible and accountable for assessing every risk, even if this feels uncomfortable. That discomfort drives collaboration on trade-offs.

Leverage strengths without silos

Strengths should guide who investigates a given risk, but the findings must be shared so the whole team can evaluate them. Labeling someone as the 'feasibility lead' reinforces old silo thinking.

Go faster when it matters

Non-specialists, such as a product manager building a quick prototype, can often run early assumption tests when specialists are busy. Pixel-perfect design or deep engineering is rarely needed at that stage.

Watch for ingrained habits

Role assignments become default mental models that are hard to break. Teams should actively practice the model that everyone owns everything.

03From the post

“As a product discovery coach, I get asked a lot of questions. This makes complete sense—as people read my book, take one of my courses, or watch one of my talks, they naturally wonder about applying the concepts of continuous discovery to their own work. They consider the ideas”

04Frameworks mentioned

Summary and takeaways written by PM Atlas; quotes are short excerpts. © the original author.