The feature factory antipattern treats teams primarily as implementers of predefined features or requirements. It measures delivery by shipped solutions rather than by contribution to business outcomes, product goals, or user value. section 1.2 section 8.2.10
A healthier alternative changes both the team’s mandate and the surrounding architecture:
- Give teams outcomes to achieve instead of feeding them predefined solutions, allowing them to discover useful approaches within a business subdomain. section 1.2
- Align a team to a bounded domain such as pricing, ordering, or search, so related concepts and changes remain together. section 1.2
- Support autonomy over product and technology decisions, deployment, and development processes, with software that can be changed independently. section 1.2
From prescribed features to discovered value
A public-sector team studying user personas, pain points, and KPIs realized that open data could support two new products: a simple service answering common energy-efficiency questions and property-level APIs for analysts. The shift from being told what to build to discovering these opportunities exemplifies an empowered product team. section 8.2.10
Use the four-characteristic model to compare feature-factory behavior with domain alignment, outcome orientation, team empowerment, and software decoupling. section 1.2
