A feature team is a development team that implements end-user functionality end-to-end. Contrast this with a component team. Such a team owns an architecture building block, for example, a layer, a subsystem, or a collection of components or services, as figure 1 illustrates.
Figure 1 depicts a simple software architecture that consists of three layers: user interface, business logic, and data. Say that I want to develop an app that helps people eat healthily. A feature team might then develop the capability that allows users to see their eating trend, for instance. It would implement the feature as a vertical slice, from the user interface down to the data layer. A component team, however, might develop the business logic that calculates recommended calorie intake. The team would not touch any of the other layers but exclusively focus on the business logic.
When your product starts to attract more users, you typically require more development teams to sustain the growth, enhance features, and add new ones. This presents you with a choice: You can organise the teams primarily around features or architecture building blocks. This choice matters: It will affect your ability to progress your product and achieve its strategic goals, as I explain in more detail below.
Feature and component teams both come with benefits and drawbacks. The former have a strong end-user focus: They work on functionality that creates value for the end users. Feature teams can also consume items directly from the product backlog and turn them into working software. Additionally, they are loosely coupled and not dependent on the work of other feature teams. This has two benefits: First, it allows you to quickly test an idea and release a feature fake or early version of a feature, gather user feedback, and adapt it. Second, if one feature team fails to deliver, then you can usually still use the work of the other teams. But using feature teams can introduce user experience and architecture inconsistencies and it can lead to code duplication. In the worst case, each team creates its own user experience and user interface design, its own business logic, and its own data layer, to stay with the architecture example shown in figure 1.
Component teams avoid these drawbacks. As they are organised around architecture building blocks, they enforce architecture consistency. Additionally, it can be easier to staff component teams compared to feature teams. In figure 1, every feature team would need someone with the appropriate user interface design skills, for instance. On the downside, component teams often cannot consume items directly from the product backlog. The teams that own the business logic and data layer in figure 1 need technical requirements that describe the interfaces that should be created or enhanced. Translating end-user requirements into technical ones creates overhead and slows down development. What’s more, as component teams tend to build software for other development teams, they can lose sight of the end users and sub-optimise their building blocks: I have seen component teams who were more concerned about the performance of their components than the end-user experience.
I recommend that you prefer feature teams over component teams as long as your product experiences bigger changes. This is typically the case for brand-new products, products in the introduction stage, products that rapidly grow, and products whose life cycle is being extended, for example, by taking them to a new market or adding new features. But once your product is stable, once it has entered the maturity stage (and you don’t intend to extend its life cycle), then component teams tend to be a better choice, as figure 2 shows.
Features teams allow you to move fast, add new functionality, respond to user feedback, and adapt your product. This makes them better suited for coping with innovation, uncertainty, and change—challenges that are present at the early life cycle stages and a life cycle extension.
Component teams help you reduce cost and increase profitability by maximising reuse and ensuring architecture integrity. This is desirable for mature and declining products, where you typically focus on incremental enhancements and bug fixes, and cost reduction.
Consequently, it can be beneficial to change the team setup after a product has entered the maturity stage. But this should always be done with the agreement of the development teams: Telling teams that they will be disbanded and newly assembled conflicts with the idea of having empowered agile development teams.
You can, of course, combine feature and component teams. But the advice above still holds true: Be clear on the team setup that benefits your product most. For instance, when managing a young product, you might find it beneficial to have one component team that looks after the data layer. But if that’s what you decide to do, make sure that there is a good reason for using a component team, and keep the number of component teams to a minimum at this stage. Similarly, when you need to make a bigger change to a mature product like a substantial feature enhancement, you might want to use a feature team to get the work done.
Don’t forget, though, that teams need time to gel. Team members have to learn to trust each other and build connections in order to be able to effectively work together. Frequently changing the team setup is therefore undesirable.
Feature teams are also used in the agile scaling framework LeSS. The team topologies framework offers an alternative approach to organise teams. You can view feature teams, as described in this article, as a type of stream-aligned teams and component team as complicated subsystem teams.
OKRs—objectives and key results—are a popular goal-setting technique. But can and should you use OKRs…
For any business to succeed, it is crucial to make the right strategic choices. To…
Being empowered can make all the difference in doing a great job. Sadly, not all…
Products often don’t exist in isolation. Instead, they are part of a product portfolio. Think…
Product discovery has become increasingly popular in recent years as a way to determine the…
Strong product leadership is crucial to offering successful products and enabling product-led growth. Unfortunately, there…
View Comments
Hi Roman,
1. What is the data behind the statement that later in the life cycle a component would be better suited? The diagram is all nice and pretty, but is there real data behind?
2. Would a big fix not also necessitate touching the entire tech stack? Or better - one cannot possibly know. Having only a component team with limited knowledge maintaining the applications appears risky to me. I assume the MTTR would be considerably higher than for a feature team?
3. Beyond the small example you presented there are application platforms out there. E.g. one feature team develops a user facing application - already complex on its own and with its own backend, but that application needs backend services that are provided by a platform that is developed by other feature teams. Clearly, the application cannot prove e2e functionality without the platform. Would you agree or disagree that in this case we still had component teams and that unless the app teams gain the knowledge how to extend and maintain platform code they are not real feature teams?
Hi Christoph,
Thanks for sharing your questions. My answers to your questions are below.
Ad 1: As often in product management, the observation that component teams are better suited for mature products is based on personal experience and hence anecdotal data. Having said this, the objective in the later product life cycle stages is to increase efficiency and reduce cost in order to maximise the benefits the product offers, see my article Strategic Options for Mature Products. As component teams help maximise reuse and as tighter architecture coupling is usually acceptable when changes are only incremental in nature, it makes sense IMO to consider using component teams. But I would suggest that you carefully consider if changing from a feature to component team setup is worthwhile for you.
Ad 2: As pointed out in the article, feature teams are better suited to deal with innovation, uncertainty, and change in my experience. I therefore agree with your observation that feature teams are likely to be better at implementing a bigger fix.
Ad 2: Please see my article Leveraging Software Platforms.
Hope this helps!
Hi Roman, very nice article and gave a lot of good clarity, thanks! I have a question though- as you say, if a product keeps experiencing major changes then feature teams are preferred. However, if there are major changes then isn't that more likely to lead to inconsistencies and hence may be better suited for component teams? I personally prefer feature teams btw, but how do you recommend to address these potential inconsistencies or possible code redundancies? A mix of the 2 models perhaps?
Thanks for your feedback and question Sahil. You are addressing an important point. To mitigate the risk that feature teams introduce inconsistencies, the teams should regularly reflect on their work practice and create, review, and adjust shared standards, be they about the software architecture, the UX, or coding standards. This may be done as part of a cross-team or overall retrospective. Hope this helps!
Hi Roman,
Great article, thank you for sharing your thoughts!
I have one question regarding the component team approach:
Assuming that regardless of the maturity level, each incremental change should bring (end-user) value, how do you measure this value when the (component) team setup is more 'tech driven'?
In my view, the component team approach conflicts a bit with a lean approach, where a minimum viable product build is built by a vertical slice instead of one layer at a time.
In particular for SaaS solutions, where the maturity stage is limited in time, wouldn't a team always be working in 'feature team' mode?
Thanks for your considerations and for your great books on product management!
Hi Olivier,
Thank you for sharing your feedback. I fully agree that a minimum viable product (MVP) is best developed by one or more feature teams. That's why I suggest in the article that feature teams are "better suited for coping with innovation, uncertainty, and change—challenges that are present at the early life cycle stages". The latter includes the development stage, which results in an MVP.
If your product continues to experience bigger changes and never fully matures, then I would recommend that you stick to feature teams.
Hope this helps!
I love your mention that component teams are better for long-lived products. I agree with you that there is not a one-size-fits-all solution for team organization and that teams should be involved in the process. I have experienced using Event Storming and DDD to create enough collective intelligence around product architecture to make a good decision about team splitting. Event Storming is a collaborative design activity that can cope with a large number of attendees (20 or so). Here are other references (that I did not have the time to read yet, unfortunately) on the topic that you might find interesting:
* Dynamic Reteaming: "If changing team configuration hurts, let's do it more often."
* Team Topologies
Thanks for your post!
Hi Philippe,
Thank you for sharing your feedback and experience. I like to keep the longevity and staffing method of a team separate from its type. A feature team may well live for a long time, for example, and it may have been staffed by using self-selection.
Thanks also for sharing the references. I am sure that a more sophisticated team topology can be helpful. But for the purpose of this article--helping product people reflect on the effectiveness of the setup of their development teams--I wanted to keep things simple.
While I agree that teams experience change in their composition, my experience suggests that frequent changes usually results in low productivity and poor team spirit. This view is supported by Richard Hackman who writes in his book Collaborative Intelligence: "Teams with stable membership have healthier dynamics and perform better than those that constantly have to deal with the arrival of new members and the departure of veterans."
Hope this helps!