Enter the Matrix: Organizing Product Management

Braintree is growing fast. The last year has seen the number of Treeps more than double. With this growth has come much discussion about to how to scale and yet keep the spirit of Braintree alive.

How to remain flat and flexible?

How to question everything and still get stuff done?

The product management team has been grappling with these broader issues as a group, but we have also been discussing how to align ourselves as Product Manager's (PM's) with the Developers internally, our Merchant customers (Developers and Business people) and our Products.

Mapping out the matrix for Product Managers.

Historically at Braintree, a Product Manager (PM) and a group of Developers formed a team based on the project. The PM supported development, helping out with requirements, testing and release coordination. The team and the company were small enough that the roadmap for the products evolved naturally through iterative development, rapid release cycles and the folding-in of customer feedback. However as we push up to a company size of 100 with 30+ Developers, 6 PM's, and offices in Chicago, California and New York, there was a clear need to divide and conquer, whilst all pulling in a few agreed upon directions.

So the PM team, in coordination with the CEO and all teams (developers, marketing, ops, sales etc.,) laid out 4 over-arching goals for the business. Under these headings fell all the product initiatives we had in mind. Not project level, but broader initiatives that may incorporate many projects. This was socialized around the company, debated and iterated over. At Braintree you are encouraged to question everything so this was a healthy, informative and sometimes heated discussion. But in the end we had a matrix of business goals and aligned product initiatives on which we could hang our hats.

Simultaneously the Developers were thinking about how to organize more effectively. There was broad agreement that there needed to be better consistency of people on a team. So 7 development teams were formed, either based around the large product initiatives such as international expansion, or continual areas of focus such as Infrastructure and Security. This reduced the push and pull of shifting team members based on projects, increases stability, and promotes efficiency as like-minded projects are worked by the same team. Importantly this is not permanent, there will be a constant undulation of developers between teams, but in a more controlled manner than the reactive approach we had before.

So how to line up the PM's to this new structure?

It is an interesting problem once you dig into it. The obvious solution was to align a PM with a development team and then divvy up projects as needed. But fundamentally this seems to reduce the responsibility of PMs to exclusive Project Management rather than Product Management and the needs of our customers. As a PM aligned to a development team, each PM is now focused primarily on the efficient and effective delivery of projects. Sounds good. But what about what is best for the Product and our Customers? What if that need does not align neatly with the developer team? Projects will inevitably cross team boundaries and fundamentally the Customer must continue to have a strong voice in the Products evolution. The PM should be championing that need regardless of internal infrastructure.

So in the hope that two is better than one, we chose to align PM's along both axes. Product and development team. Each PM has a product focus, say International, and at the same time we partner with a development team, effectively filling the Agile Project Manager role.

Because the development teams are similarly aligned by product initiatives, we tried to cross-over product and development team PM assignment as much as possible. So if a PM is responsible for the International product initiatives, you are also the PM for the International development team. However this was not possible 100% of the time because the product initiatives and developer teams are not exactly the same. Also, as I said before, projects can, and often do, cross team boundaries. So in that scenario a PM will follow that project and product initiative across development team boundaries, and advocate for the product, not the implementation team.

As an example, I am the PM responsible for Internal Tools, both the development team and the products. However I am also one of the PMs for Mobile products. So for Internal Tools there is a close pairing between product management and development team responsibilities. When I create stories for Internal Tools I am also the PM who prioritizes those requirements with the Development team. However for Mobile, I will gather requirements and write the stories but work with another PM and Development team to get them queued up.

Our hope and expectation is that this will maintain the real value of a PM, by emphasizing the Product and not the Manager. Which is also the Braintree way.

It was a challenging process that brought us to this decision and it has brought some complexity to our project planning. But we are giving it a go, at least until the end of the year. The biggest pain-point so far has been factoring in ‘out of band' urgent projects that naturally come up in a fast growing company. They not only jump over existing priorities, but often cross multiple development teams and product / PM assignments, causing much head scratching.

I will update on our progress in early 2013.

I would love to hear of how other companies have approached the same problem. Has anyone tried a similar solution?

Mark Tattersall Product Manager, tech- & web-fascinated, English football-obsessed (c'mon Leicester!), and one helluva regular guy. More posts by this author

You Might Also Like