You join a new company. The team has a backlog full of features requested by stakeholders. Every sprint starts with a prioritised list of things to build. The team ships on time, celebrates velocity, and moves on. Six months later, nobody can explain why churn is climbing. The features shipped. The outcomes did not.
This is the feature team trap. It feels productive because things get built. But building is not the same as solving. The distinction between feature teams and product teams is one of the most consequential decisions a product organisation can make, and most companies get it wrong without even realising there was a choice.
The Core Idea
A feature team receives work from elsewhere in the organisation. Product managers act as ticket writers, translating stakeholder requests into user stories. Engineers build what is specified. Success is measured by whether the feature shipped on time and on spec. The team is efficient but has no ownership over whether the feature actually moved the needle.
A product team, by contrast, owns a problem space. Instead of being told what to build, the team is given an outcome to achieve, like reducing onboarding drop-off by 20 percent or increasing activation for a specific user segment. The PM, designer, and engineers collaborate on discovery, decide what to build, and measure whether it worked. They have the authority to say no to feature requests that do not serve their outcome.