Over at XING, I collect and share interesting posts regarding product management. You can follow that link share collection here.

Last week, my favorite post was from Paul Adams: What we learned from scaling a product team.

It is great that Paul shares his practical learnings how they run their product organization at Intercom. It is worth noting that the size of a product organization has a huge impact on the way to organize. According to Intercom’s blog, Paul wrote his post about eight months ago when the team had four product managers, four designers, and 25 engineers. At XING we have around 25 product managers, 30 UX people, and 150 engineers in our product teams. Many of the findings and procedures are also helpful for a company of our size.

Paul mentions four important areas:

1. A set of guidelines for decision making
2. Clear accountability
3. A lightweight, transparent, comprehensive roadmap
4. A culture of goal setting

The guidelines at Intercom seem to describe how they want to work. I like three elements in particular: the sense of urgency captured in the quote ‚Every day counts‘; the insight that no tool can actually replace human interaction (post-its, by the way, are also at XING the most used technology); and the commitment to plans (i.e. thinking upfront) while being flexible enough to learn from new information.

Those kind of guidelines are helpful whenever you want to create alignment on a value level. At XING, we have six values that everybody tries to live up to:

1. Listen
2. Be couragous
3. Make mistakes
4. Ship it
5. One voice
6. Be accountable

In addition, we also defined a north star for our product community. This is more tailored to the way we want to develop products and ourselves as professionals.

P@X-north-star-graphic-final

The second building block Paul mentions is a about the accountability for the different roles (product, design, and engineering) in a develoment team. We don’t have that written down role definition in this destilled form. I like it a lot, though, and should be applied in our teams as well. In fact, those clear responsibilities apply to any product development team in any company regardless of company size – because they apply on team level.

I also like the different levels of granularity in the roadmap and the interlocked system of goals Paul talks about. Whenever you try to scale an organization, such a system of cascading goals helps to create alignment of commitment and autonomy of units.
The overall strategy (or product strategy themes at intercom) provides guidance at the highest levels. It creates clarity of intent. This is then broken down in smaller packages and subgoals. Once teams have subgoals that are aligned with overall company goals, the teams gain the autonomy to reach their goals.
At XING, we use a format called Auftragsklärung for this cascading goal-setting. You can read more about it here.

The most refreshing part of Paul’s post is his explanation how things get on a roadmap. He mentions three sources: (1) things they believe in, (2) qualitative feedback, and (3) quantitative feedback. His descriptions resonates well with me. Mainstream posts mostly talk about A/B testing and quantitative methods as the one and only approach. Yet the other two sources are equally important – for true disruption probably even more important. The difficult part, however, is to know when to apply which source …

Link: What we learned from scaling a product team.