Product development requires a coordinated effort from multiple teams. But there are numerous ways that companies can structure teams, each with their own trade-offs. ZeroBlockers advocates for autonomous, empowered cross-functional teams.

Functional versus cross-functional teams

Functional teams are the most efficient way of organising people to do a specific known task because the deep specialisation enables higher quality work. But the challenge comes when the task is ambiguous or requires a range of skills to complete. In these cases, cross-functional teams are more effective because they enable quick back-and-forth sharing of ideas to find the best solution to a problem.

Functional Teams

Cross-Functional Teams

Rate of changeLow changeHigh change
Task ambiguityLow ambiguityHigh ambiguity

Scaling cross-functional teams

When you're starting out on a product, you might be able to have everyone efficiently working together in a single team. But as the product grows, the number of interaction points between people increases exponentially leading to a communication overhead that can slow down the team.

We need a way of splitting the team into smaller teams that can work independently but still coordinate effectively. But every approach to splitting the team has trade-offs.

ApproachExamplesCommunication ChallengesCode Challenges
Functional: split the team by the function of the workMarketing, Sales, DevelopmentHandovers lock in scope which leads to ineffective productsShared code can lead to merge conflicts and path to production congestion
Features: create short-lived teams to deliver specific featuresNew search, add payment method, referral schemePotential for overlap in the work of different teamsShared code can lead to merge conflicts, path to production congestion and tech debt as the pressure of a deadline leads to shortcuts
Journey Stage: split the team by the stage of the customer journeyAwareness, Consideration, Purchase, RetentionLimited challenges as largely separate parts of a productThe core entities are shared across the journey which can lead to merge conflicts, path to production congestion and the pressure of a deadline leads to shortcuts
Technical Entity: split the team by the technical entities in the productUser, Product, Order, PaymentTeams need to coordinate to deliver user features as features users care about often span multiple technical entitiesLimited code challenges as each team owns independent code bases

Separating by Journey Stage limits the communication challenges and splitting by technical entity limits the code challenges. To get the best of both worlds we can combine the two approaches. Using Domain-Driven-Design techniques we can identify independent value streams and duplicate the technical entities across the different teams. The overhead in duplication is more than offset in the removal of the blocking dependencies that would otherwise exist.

Example value streams

Looking at an e-commerce platform, the following value streams could be identified:

  • Catalogue
  • Recommendations
  • Search
  • Comparison
  • Promotions
  • Cart
  • Orders
  • Shipping
  • Support
  • Returns
  • Loyalty

Product Team


Product Team














Stream Team Members

Stream teams are accountable for the delivery of features within their value stream all the way from idea through to satisfied customers. This means that they need skills in uncovering customer challenges and pain points, prototyping and evaluating solutions as well as the skills to build the product. The core members of each Stream Team are:

ResearcherCustomer interviews, surveys, data analysisUncover customer challenges and pain points
DesignerSketching, wireframing, prototypingEvaluate solutions
DeveloperCoding, testing, deploymentBuild the product

In addition to the core members, the team will often need different business specialists to help build the product, based on the value streams they are working on. For example, early-stage value streams might need marketing specialists to help with product positioning and later-stage value streams might need customer support specialists to help with understanding the support processes.

Stream Teams will often need technical specialists to help build the product as well. For example, a team building a recommendation engine might need a machine learning specialist.

Was this page helpful?

We need to encourage innovation internally
© ZeroBlockers, 2024. All rights reserved.