Take a Team Approach to Product Delivery

Teresa Torres contrasts two product managers: Jim, who is absorbed in delivery tasks and makes all the team's decisions, and Sally, who has time for customer discovery because her team shares the problem-solving load. She argues that modern products are too complex for individuals, so teams must specialize and then genuinely function as teams. Simply assembling people does not create a team, and teams need time to form norms, which often produces ineffectiveness and conflict. Her remedy is a living team charter that captures individual preferences, shared goals, operating norms, and clear roles and decision rights. The piece matters because unclear ownership quietly drains time and blocks product managers from discovery work.

01Key takeaways

• Ask whether you are the hero who answers every question or whether your team shares problem-solving responsibility.
• Have each team member share their work preferences, strengths, and goals before setting team direction.
• Write team goals that reflect what success means for your specific team, not only business metrics.
• Document meeting attendance, communication channels, availability, and tools so norms are explicit rather than assumed.
• Specify who provides input versus who makes the final decision for each key area, such as design, data models, and customer voice.
• Treat the team charter as a living agreement and revise it when norms stop working.

02Key sections

Two product managers, two different days

Jim spends his time on delivery and becomes the hero who solves every problem, while Sally focuses on customers because her team handles obstacles. The difference is how the team is structured, not just the title.

Teams, not individuals, ship products

As products grow complex and markets shift, work specializes across roles, but adding people to a project does not automatically produce a functioning team.

Use a team charter as a social contract

A team charter records goals, operating principles, roles, and individual preferences in a living document that the team agrees to follow and revise as it learns.

Build the charter step by step

Start by having each member complete prompts about their work preferences and strengths, share them, then set team goals and define norms for meetings, communication, availability, and tools.

Clarify roles and decision rights

Poorly defined ownership causes dependency delays, sign-off conflicts, and metric errors, so teams should specify who gives input and who makes the final call.

03From the post

“Jim, like many product mangers, spends most of his day with his engineering team. He clarifies requirements, triages bugs, and seeks out hidden dependencies. Sally, on the other hand, spends most of her time with customers. She's understanding their context, uncovering pain points, and identifying opportunities to delight. What’”

04Frameworks mentioned

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