Several product practitioners have outlined a range of different views on (Product) team topologies. You’ll find a well written piece here. There are several contributing aspects to it. Listing a few of those below

– What is the team responsible for (ownership)
– How big can the team to function at the right speed (alignment at speed)
– How can we organise without creating dependencies (platform vs. customer facing)

My experience in Favrit so far

Team topologies around Value Stream

At the start, we believe we had a Value Stream organised teams. We were about 50 people in product team including PMs, tech, design, UX and data. A team responsible for all guest-facing app, one for customer-facing app and a bunch of teams doing “backend-stuff” like development-infrastructure, customer reporting, payment infrastructure and others

With the way we had organised, resulted in silos in the tech org, creating heavy dependency on who knows which part of the platform, and who has the deep insights on the user problems. For our org about to scale, these silos were not helping us create the magic moments at the intersection of opportunities in these areas.

Two Product teams with a designer in each

From this we transitioned to 2 Product Teams. At this stage, we went down to about 30 in the product team with two product designers. First, we pooled the entire team together, after which we broke it down into two groups depending on which part of platform was impacted. The members in the groups were inter-changeable based on their knowledge of the platform. To start with, we kept a cadence of 2-week cycles to deliver value to our users.

This worked better improving knowledge within the team. It was easier to the communicate to the rest of the org, the why and the what about the initiative. Over the course of time, it became harder to manage the sync in the 2-week cycles of the two teams. It happened mainly because some initiatives took longer than the others.

Team topologies structured around constraint

As a next experiment, we structured the team around a constraint. At this stage we continued to be 30 in the product team. Here we tried to leverage the theory of constraints and explore how we could speed up our org. We had a prioritised set of problems to solve. Depending on how many we believed were required to address the problem, we divided the team into 2-3-4 groups. The key consideration was ensuring that specific competencies were leveraged to the maximum. We were comfortable not sticking to the our 2-week cycles.

Seemed to work well at the start as we believed we would have great throughput. This turned unpleasant for the teams. It gave the perception that we were trying to maximise the constraint in the product development assembly line – the one developer! It wasn’t motivating for the teams and was harder to communicate cross-functionally.

2 Teams on Initiatives (with 1 UX)

From there on, we’ve moved to a stage where it’s one or two product teams depending on the initiative. These teams were big enough to fulfil the required roles on a tech perspective. And we had the designer sharing time between the two initiatives. We were not religious about the 2-week cycles, as some initiatives demanded the teams’ involvement for longer while others did not. While scoping solutions and thinking about technical choices we involved the entire product team in the brainstorming sessions. Here we discussed not only around the problem to be addressed but also around solution alternatives.

Everyone in the Product team can see the work in progress and has a say into the technical choices made along the way. This way, for now we accomplish good information exchange and knowledge sharing about the platform

What next

Every now and then, we’ve had proponents of “One team to do it all” and I’ve also had the other spectrum of the perspective. What I’ve made the choice on is looking at the need of the need of the business and the stage of the product for the market segment we were attacking.

Recently, I’ve come across the ShapeUp way of work from Basecamp, curious to know one more perspective.