A feature team builds a list of requested features. A product team owns an outcome and decides what to build to reach it. That difference decides how you plan, how you budget and what you end up with.
Below is how feature teams and product teams differ, why we choose to work as a product team, and what that means for the client.
What is a feature team?
A feature team is a team that receives a list of features and builds them. The roadmap is a set of requests, usually from stakeholders or clients, and the team’s job is to deliver them on time.
Success is measured by output: was what we agreed shipped, on budget and on schedule?
The term has a second meaning in Scrum and LeSS, where a feature team is a cross-functional team that builds a complete feature end to end instead of one technical component (see LeSS feature teams). This post uses the other meaning: a team that is handed features to build, as opposed to a product team that is given a problem to solve.
What is a product team?
A product team is a cross-functional team that is responsible for an outcome, such as a business result or a change in user behaviour. It gets a problem to solve, not a list of solutions.
The team does its own discovery: it talks to customers, tests assumptions and measures what users actually do. It decides what to build based on that and is held accountable for the results. This is the idea behind empowered product teams in the product operating model. Marty Cagan describes the difference in Product vs. Feature Teams.
Feature teams vs. product teams: the differences
| Feature team | Product team | |
|---|---|---|
| Starting point | A list of features | A problem or outcome |
| Roadmap | A fixed list of requests | A set of bets that changes with what the team learns |
| Planning | Quote and plan upfront | Short cycles, adjusted as results come in |
| Discovery | Done before the work or outside the team | Continuous and part of the team’s work |
| Who decides what to build | Stakeholders | The team, together with stakeholders |
| Success is measured by | Features delivered on time | KPIs and changes in user behaviour |
Why a feature team pushes you towards waterfall
When a team is given a list of features, someone has to put a price and a date on that list before the work starts. That forces a waterfall way of working, even if the team uses sprints: quote upfront, predict upfront and advise upfront on how effective each feature will be.
We see this most in the money. Because the scope is fixed before anything is learned, we have to add an extra margin for risk to every quote. We then risk quoting too high or too low, and both are bad for the client.
Quoting too high means the client pays for risk that may never happen.
Quoting too low hurts the client in two ways. Either we are left with a project that is not worth our time, and we cannot put our best resources on it. Or we ask for additional work to close the gap, which means the client faces unexpected work and costs they did not plan for.
You cannot know upfront what users want
To get a quote, a feature team needs a chunk of work large enough to price. That chunk combines things that are well understood with things that are not known yet.
The result is that assumptions are turned into feature requests. Nobody can know upfront what users want, so part of what gets built will not matter, and you only find out afterwards.
A product team works differently. It can go and sit with customers to understand demand, and it can monitor KPIs on user behaviour. When a small change ships, the data shows whether behaviour changed or not.
That makes it possible to build what brings you to the target, and to stop building what does not.
Product teams for experts who are not technical
Many of our clients are experts in their field but have no experience with how tech product development works. For them we take ownership and guide them through the process.
We build a strategic roadmap, work it out, plan all layers down to the sprints and monitor the KPIs. In our experience this lets us make much more impact. Some clients have even given us equity.
How we make the value visible from the start
Budget is the hardest part of this conversation. A client who has not worked with us yet needs to trust that they get something substantial for the price.
The worry is understandable. Clients who have not worked with us before are often wary. They fear a retainer in which hours are burned without a clear result, or even worse, hours that only exist on paper.
That is why we are driven by value and outcomes, and why it becomes clear within the first three months. In that period we create a strategic roadmap, define the KPIs and provide value directly. If we do not, we guarantee your money back.
Working as a product team with Wise Minds
A Wise Minds product team as a service works this way from the first day. If you are not sure what to build first, read how to determine your next feature or look at our product discovery services.
For the people in such a team, see how to structure a software development team and the difference between a product owner and a product manager.
Want experienced product leadership without a full-time hire? See product management as a service.
Frequently asked questions
What is the difference between a feature team and a product team?
A feature team builds a list of features it is given. A product team is given a problem or outcome and decides itself what to build to solve it, based on discovery and data.
What is a feature team in Scrum?
In Scrum and LeSS, a feature team is a cross-functional team that can build a complete customer-facing feature from start to finish, without depending on other teams. It is the opposite of a component team.
What is the difference between a feature team and a component team?
A feature team works across all technical layers to deliver a complete feature. A component team owns one technical part, such as the database or the API, and other teams depend on it.
What does a product team need to work well?
Access to customers and usage data, a clear outcome to work towards, the skills to design, build and test in one team, and the authority to decide which solution to build.
Can a company have both feature teams and product teams?
Yes. The label describes how a team gets its work. Many companies have teams that are handed solutions next to teams that are given problems, and move toward the second over time.