Building Cross-Functional Product Teams is Harder Than You Think
It’s not news that the rise of product-led companies requires new ways of working, built on the foundation of creating cross-functional product teams with specific aptitudes, fit for purpose on the product at hand. But guess what: building cross-functional teams is harder than you think it is, and if you miss the target it can hurt the whole team’s best effort at creating value for customers and the company alike.
Your cross-functional team’s deep knowledge of their subject matter is crucial to flagging obstacles and identifying constraints that stand in the way of your solutions. This is why it’s critical to ensure you have the right people with the right skills and expertise from the jump.
Why wait until you’re weeks or months into solution design to share your vision with other leads? Some folks may subconsciously be doing it out of avoidance (“If I wait to share my vision later, people can’t ‘poke holes’ before it even gets off the ground”).
I have some news: those holes – aka valid obstacles to getting the job done – are going to be poked either way. Wouldn’t you rather head into solution design with all the inputs laid out on the table instead of going back to the drawing board each time you learn of new constraints along the way?
Getting everybody together to talk about the problem before you get into solution design identifies the constraints up front so you can collaborate and design with them in mind. This is one of the best parts about human centered design: the really great stuff can only be discovered when the constraints are identified and understood.
Ready to try it out? Make sure these people are seated at the table for solutioning conversations:
Product lead: This person is the expert on the problem the team is trying to solve and the value the solution could deliver. They understand the business context, user context, and how to sift through a lot of data to synthesize it. The actual title for this role will vary based on the problem, org and needs (maybe it’s a product manager, or a product owner). Either way, they’re the expert for the job because they can sink their teeth into a problem and rally the team around it.
Tech lead (could be an engineer, architect, tech strategist, etc.): This person has deep knowledge of the enterprise’s existing technology, platforms, and strategy, and understands how to translate the product lead’s inputs and problem into solutions. They also have an ability to see around corners and can anticipate future needs based on the vision painted by the product lead (“What are the tech implications? Do we need new tools, or will our existing tools work if we use them in a different way?”).
UX/Design lead: Product-let orgs typically build things that humans interact with, whether they’re the org’s employees, customers, or users. That means you need a UX lead at the table to bring expertise on how real people use real tools to solve real problems.
Operations lead: Unless you plan on building something perfectly the first time (ha!), you need an operations lead at the table. Somewhere along the way, someone is going to be confused about the changes the team is making. If it disrupts a user who then phones the call center, is that team trained to handle the conversation? What about a client who contacts their sales rep when they encounter a snag – will that person know how to speak to the issue? The operations lead will understand the downstream implications for new ideas and technologies the team puts forth, and will be a partner in helping to implement new changes as releases demand.
When you have team leads present up front who can articulate constraints and then collaboratively create boundaries around them, the doers (engineers, architects, designers) are better set up for success, with fewer surprises and more impactful results.
Let’s be honest, if you skip the step of having the right people at the table from the start, you’re not saving any time, effort, or heartache. In fact, you’re only delaying getting it right. Why wait?