Product management and team structures

- Dealing with multiple teams in a product development organization is always a challenge. When it comes to organizational structures, I'm willing to bet that if you visited 10 companies you'd see at least nine slightly different ways of organizing the teams. It can be a challenge to decide on the best way to structure teams of engineers, designers, and their product managers. Let's discuss a few common approaches. Firstly, I want to get one big point out of the way. There's no right way to structure your teams. The best model is the one that fits your company culture, resources, and the product you're actually building. Now let's start with the idea of platform teams. Imagine you have two apps, one for iOS and one for Android. A platform team model would mean that there's a separate team and thus a separate product manager for each platform. Many startup companies find themselves in this model as they grow, but there are big drawbacks. The primary issue is that you're likely to have major inconsistencies in each platform since the teams and work streams are separated. If the iOS team finds a great trick for increasing engagement on their platform, it's not guaranteed that the Android team will find out and develop the same thing on their side. So what's the alternative? A more recent model that's increasingly common is what's called feature teams. In the feature team model there's a permanent team of a PM, designer, and engineers dedicated to a specific feature or function area of a given product across all platforms. That means that if a team is in charge of something, like say search, they're working to optimize it on all of the platforms at the same time, while another team works on another area of the app in the exact same way. On the plus side this increases consistency in your product, enables those teams to really become experts over time. But as you may have guessed, the downside is that this model generally requires more people to make it happen since you'll need engineers for every platform type on each team, not to mention more designers and product managers. Now that we've got those basics, there's a couple tweaks to the feature team model you should we aware of. One of them is adding regular rotations so that instead of having permanent stations the teams rotate every so often to go work on a totally different feature area. A team working on search this month might be working in the chat system in six months. This helps everyone become familiar with all aspects of the product over time and bring a fresh perspective to things regularly. Facebook is known for using this model in their teams. Lastly, there's another tweak sometimes referred to as squads. These are just feature teams that work on improvements to a product on a per-project basis. sometimes across a few different features at once. After their goal is achieved, they rotate off to a new project. Note that the length of what is considered a project here is different at every company. But it's likely that it's based on achieving some definition of success through metrics established beforehand. So that's it. A few basic models of structuring your development teams. The vast majority of decently resourced software companies these days work in some form of a feature team model. But remember, there's no right way to do things. Always consider your end product, company culture, and resources before deciding on which model is right for your organization.