Product Teams Group and Structure

A Group is a cross-functional unit led by a Group Product Manager alongside one or more Engineering Managers.

Groups consist of:

Groups are oriented around a set of customer problems (“missions”). Those missions are not fixed or even exclusive; there might be times when multiple Groups are attacking the same problem. That’s both acceptable and (on the margin) expected.

As the team has grown, it has become increasingly difficult to communicate and collaborate, both within the Product team and across teams.

Previous versions of our Product organization could rely on organic communications and interactions to disseminate knowledge within the Product team, but we’re starting to see evidence that this kind of ad-hoc communication is becoming more difficult.

While I believe that what we’ve been doing is still working at the moment, I don’t see that being the case a few months from now. The kind of communication that got us here won’t get us to where we want to go.

A variation of this communication problem is that it has become harder to collaborate across teams. As we’ve grown, It has been “easier” to stay siloed within our respective functional units. This is often a second-order effect of a “The [X] team doesn’t listen” sentiment spreading.

This reorganization addresses that sub-issue. Since folks across teams will work and mix within individual Groups, we will preemptively prevent the spread of the harmful sentiment above in addition to getting more people involved in problem-solving to inform better resource allocation.

The end state we’re striving for is “highly aligned, loosely coupled”.

When it comes to how we work with Engineering, we’re going to further integrate engineering managers into Group rituals, with the intent of bringing them closer to the customer and reducing the time to resolution for any issues related to PM <> Engineering interactions.

There are no immediate implications related to working with teams outside of EPD, but we’ll look toward further cross-functional integration over time. Our current-best idea is to work with leaders of other teams to define time-bound tours of duty for select members of their team to help set a specific project up for success. This would be some non-negligible amount of their capacity as defined in collaboration with the leader). These team members would indirectly report to the Group PM for the duration of the tour.

We will start with four Groups pursuing the following missions:

These missions are not a collectively exhaustive list of what could be worked on, but simply what we’ve deemed to be the most important missions at this moment in time.

Yes, absolutely. Quarterly planning will be a forcing function to re-evaluate what missions we staff, but Groups are encouraged to shuffle as needed to respond to new inputs arriving throughout the quarter.

No. We’ll consider Group staffing to be “elastic” and the staffing may shift from quarter to quarter. What matters most is maintaining confidence that we are solving the most important problems for our customers. In other words, the bounds of the org structure should be viewed as guidance and not as rigid determinations of “ownership”.

We’re prioritizing speed and will seek to avoid roadmap coupling (e.g., “Pod A is not able to solve their problem because they’re waiting on Pod B to build something lower on their priority list”).

We’ll propagate the use of a set of rituals and artifacts that teams will leverage to mitigate the collision risk that this structure creates. On the Engineering side, we’ll assign specific "owners" for maintenance areas as we're doing now as well as use an internal open-source model where anyone can make a PR against any area under the assumption that the owner/maintainer is the subject matter expert and has to review/approve the change.

As mentioned, to start we’ll have Strategy & Operations and Product Operations team members embedded within these Groups. We’ll then work with cross-functional leaders to craft tours for members of their respective teams to work within a Group for a time-bound period when it’s deemed necessary.

“Embedding” means being:

The Group PM is the “portfolio manager” for the Group – they’ll be directing traffic, coordinating planning processes, and determining where the Group generally, spends their time.

The reason we caveat #3 with “case-by-case” is that the extent to which #3 is true depends on the ask and the opportunity cost. The leaders of the S&O and Product Ops units will have their own portfolio management authority and will have to work with the GPM to negotiate investments as needed.

If/when a member of a cross-functional team performs a tour within a Group, the Group PM would not have staffing discretion outside of the scope of the project that the tour is oriented around. But this cross-functional team member would be embedded for all intents and purposes – they’d attend weekly Group rituals and would indirectly report to the Group PM.

To set these embeddings up for success, there will be a “dotted line reporting” relationship between those embedded and the Group PM. Dotted line reporting simply means that the Group PM may write a quarterly review for the cross-functional team member. Management authority continues to reside with the functional leader. Note that Engineering Managers will also “dotted line report” to the GPM.

We already collaborate, but it’s becoming more difficult as we grow. With the goal being “highly aligned, loosely coupled”, this structure should enable greater alignment on where we’re investing, as well as provide more leverage to the Group PM (without incurring coordination costs). We’ll revisit if this slows us down and is counterproductive to our original goals.

The Group PM will have the option to write a quarterly review for those that are embedded within a Group. Of course, those embedded will be encouraged to write feedback in the other direction, as well.

Each Group will create its own public Slack channel where teams can work in the open, problem-solve, raise clues, and ensure that we’re working on the most important problems.

There will be a Weekly Group Meeting with:

That meeting will consist of everyone bringing a weekly write-up to the table and a long table read. To start, these meetings will be on the order of 6 or so people. Write-ups will be shared publicly post-meeting with individuals outside of the meeting, who will be encouraged to asynchronously read and comment. These meetings will be derivative of the existing Weekly Product meetings.

At the pod level, pods will continue to operate as they do today.

For quarterly planning, you’re expected to engage in our brainstorming and prioritization exercises.

The changes affect planning across two dimensions:

New products (e.g., BillTerms) will be isolated from the Groups. The Groups encapsulate the “staffing marketplace” product suite and we want to insulate our new upstarts from the necessary processes that Groups will maintain.