Accountability and Scaling a Product Team

Intercom published a fantastic post on building software and scaling a product team. Of particular interest are these point on accountability.

  • If the analysis of the problem to be solved is incorrect, it’s on the PM. Ensure appropriate research is done.
  • If the design doesn’t address the problem, it’s on the Designer. Ensure you understand the research and problem.
  • If the design solves the problem, but doesn’t fit with Intercom, deliver best practices, or is otherwise weak, it’s on the Designer. Ensure you understand our beliefs, patterns and principles.
  • If engineering doesn’t deliver what was designed, or delivers it late, it’s on the Eng Lead. Ensure you understand the problem being solved and design, plan appropriately and accurately before writing code.
  • If it goes out with too many bugs and broken use cases it’s on the PM. Ensure the team test realistic usage and edge cases.
  • If the team is spending too much time on fixing bugs and not adding new value per our roadmap, it’s on the Eng Lead. Ensure each project improves overall code quality.
  • If we don’t know how it performed, it’s on the PM. Ensure success criteria are defined and instrumented.
  • If it doesn’t solve the problem, it’s on the PM. Ensure there is a plan to improve product changes that don’t fully solve the problem.

This isn’t done to post blame but rather to assign ownership. If something is breaking down on your team, try tracing it back to one of these accountability issues.