Structure
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 change | Low change | High change |
| Task ambiguity | Low ambiguity | High 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.
| Approach | Examples | Communication Challenges | Code Challenges |
|---|---|---|---|
| Functional: split the team by the function of the work | Marketing, Sales, Development | Handovers lock in scope which leads to ineffective products | Shared code can lead to merge conflicts and path to production congestion |
| Features: create short-lived teams to deliver specific features | New search, add payment method, referral scheme | Potential for overlap in the work of different teams | Shared 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 journey | Awareness, Consideration, Purchase, Retention | Limited challenges as largely separate parts of a product | The 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 product | User, Product, Order, Payment | Teams need to coordinate to deliver user features as features users care about often span multiple technical entities | Limited 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:
| Inspiration | Search | Purchase | Support | Retention |
|---|---|---|---|---|
|
|
|
|
|
Product Team
Buyers
Product Team
Sellers
Stream
Catalogue
Stream
Search
Stream
Cart
Stream
Listings
Stream
Fulfillment
Stream
Analytics
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:
| Role | Skills | Responsibilities |
|---|---|---|
| Researcher | Customer interviews, surveys, data analysis | Uncover customer challenges and pain points |
| Designer | Sketching, wireframing, prototyping | Evaluate solutions |
| Developer | Coding, testing, deployment | Build 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.