On Composing a Product Team
P.S. You can read my latest article now: What Exactly Is a Product?
It’s not the most fun part of product management, but thoughtfully setting up a team is like wind to sailing — incredibly important. Put time into it, and your team will churn out product perfection. Skip it, and your team’s functionality will be like Swiss cheese — full of holes.
Let’s start by talking team size. The methodologies we covered last week work best in small groups, so you’ll need to split the people you manage into smaller teams. Teams need at least two people and should include no more than 5–8 folks. Go bigger, and you’ll not only get baked into a ‘too many cooks in the kitchen’ situation, you’ll be far from using your resources efficiently.
“…having multiple small teams will help you make products with Warren-Buffett-esque levels of success.”
I know splitting up your team sounds scary. Having one big team to manage is tough enough, right? Maybe. But if managed well, having multiple small teams will help you make products with Warren-Buffett-esque levels of success.
One great way to manage multiple teams is by running them competitively. This means having teams work in parallel to each other, drawing from the same codebase and focusing on the same overall goals. This works wonders, especially if your company is an early-stage startup.
Here’s why this method is so effective: more minds working towards the same goal means more great ideas and better solutions. Each team you mentor will come up with totally different approaches to how to solve problems. And instead of being contradictory, the teams’ approaches can enhance each other. Of course, moderation is required to make this approach successful; you need to avoid a ‘them vs. us culture’ as vehemently as vampires avoid sunlight, but facilitate appropriately, and you’ll get off-the-charts results.
“You need to avoid a ‘them vs. us culture’ as vehemently as vampires avoid sunlight.”
Some people might argue that this method of running a team is a waste of resources. They wonder why you’d ever want to have teams work on the same problem. After all, if each team tackles a different problem, you’ll have more output and more new features, right? Exactly right! But just because this thinking is justified, it doesn’t mean it’s useful. More features does not generally mean more success. Most startups succeed because they did one thing incredibly well, not a bunch of things in a merely mediocre manner.
Of course, there’s a tipping point here. When you get roughly three or more teams, the ‘friendly competition’ method of running teams runs out of utility. At this point, switch from a ‘monolithic’ to a ‘service oriented architecture’ like Twitter or Airbnb did and have each team work on their own service. Note, however, that this is very general advice. It’ll fit most scenarios, but not all, so adapt as needed.
“Creating successful teams is like feng shui; there’s an arrangement to follow for maximally auspicious results.”
Now, let’s talk about team composition. Creating successful teams is like feng shui; there’s an arrangement to follow for maximally auspicious results. The number one rule is to keep your teams cross-functional. Most software product teams ideally consist of one UX/UI designer and one or more full stack engineers. For some products, say, building software for space rockets, you’ll also need a team member that knows a thing or two about rocket science. Add on these domain experts or other analysts whenever it makes sense. No matter how you pair cross-functional cohorts, though, make sure each team has roughly the same capabilities. This will eliminate skill dependencies and set each group up to win like a hit film at the Academy Awards.
Once you have setup pinned down, it’s time to help the teams build something great! I like to grab tools from the Lean/XP/SCRUM toolchain as required instead of going all in on those (let’s be honest) dogmatic methodologies like stand-up meetings, pair programming, etc. Though hardcore SCRUM helps many teams establish discipline early on (check out this great video from the Ableton team for more), you should feel free to adapt to your team’s preferences.
As your team grows and learns, your management tactics and the teams you initially created may need to change. But fear not! If you start with these team-structuring fundamentals, your team will function fantastically, your resources will be used efficiently, and your product will be one step closer to excellence.
If you enjoyed reading this, please login and click “Recommend” below.
This will help to share the story with others.
Follow me @matthiaswagner
Thanks to Philip Stehlik, Kate Larsen, Drew Moxon, Katherine Krug, Gon Zifroni and Hannah Rothstein for helping with this.
