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.

Test Early and Often

Yes, it takes longer for development to begin working on a project if you focus on building prototypes and testing with users early. But you ultimately launch products faster with a higher success rate when you put the effort in early.

How To Frame the Decision

When starting the process of laying out a plan to build a great product you must start by framing the decision. Great tips from Marty Cagan’s Inspired: How To Create Products Customers Love.

  • What problem exactly are you trying to solve?
  • Who exactly are you trying to solve this problem for (which persona)?
  • What are the goals you are trying to satisfy with this product?
  • What is the relative priority of each goal?

Here’s how I laid this out on the wall of a recent project. It’s pasted just before the initial wireframes.

Frame the Decision

Broken Windows Theory


This theory, most famously put into action by New York City mayor Rudy Giuliani, helped lower crime rates city-wide over a short period of time. Removing graffiti and cleaning up the city lead to lower crime and murder rates.

Monitoring and maintaining urban environments in a well-ordered condition may prevent further vandalism as well as an escalation into more serious crime.

It’s the small attention to details that matter most. Technical debt and shortcuts in your software and are contagious. By themselves they can easily be overlooked, but piled together it’s no longer fun to work in that codebase.

Just as graffiti makes a neighborhood rundown, so too does messy code affect an application. Pay attention to the small things and don’t release junk. Take a stand in your part of the application and the rest will follow.