Feature factory

Also known as a code factory, a feature factory is a derogatory term for a software development team that focuses on rapidly delivering new features to the detriment of other important attributes, particularly internal qualities like maintainability and extensibility, leading to [technical debt] and a fragile codebase.

I believe the term originated in a 2016 blog post by John Cutler. He wrote a retrospective three years later.

Essentially, a feature factory refers to a [delivery model] in which software development work is reduced to a pipeline of feature specifications and tasks. Product design, user research, and other strategic thinking is handled by product managers or other stakeholders on the business side. The development teams have little involvement in the wider aspects of the software development life cycle, beyond coding and testing the features assigned to them.

Cutler identified 12 factors that identify a feature factory. I have consolidated and rewritten those, using my own words, below.

No measurement of impact, else impact assessment is done in isolation by product management and not subsequently shared with all other stakeholders. Having no connection to key metrics such as customer satisfaction and business outcomes, developers have no feedback on the impact of their work, contributing to a sense of disengagement and lack of purpose.
No validation of feature ideas. Feature development is not driven by user feedback loops, leading to misaligned prioritization of development work – there’s a disconnect between what is built and what users would actually benefit from the most. Revenue-driven development sees features being prioritized to help close individual deals, rather than to improve the product for all users. Furthermore, delivered features are not subsequently iterated based on feedback loops. Product roadmaps leave little leeway for even minor adjustments, let alone whole new directions. Once a feature is "done", the team moves immediately on to the next task or project.
Lots of "success theater" – the act of projecting an illusion of success through curated data, polished presentations, confident messaging, and abstract metrics like "story points burnt down" or "features shipped". Impact assessment, when it is done, is often superficial – based on surface-level "wins" rather than deep and meaningful outcomes delivered at a sustainable cadence. There’s an obsession with process optimization, over improving engineering quality, to maximize synthetic metrics of development velocity.
No product management retrospectives. Product managers do not conduct regular retrospectives on the quality of their product decisions. They do not evaluate the expected outcomes against the actual delivered outcomes. The key performance indicator for product development is the speed of feature delivery, not the value delivered to customers via those features.
Culture of hand-offs. Rather than focusing on ensuring the right things are built, project management is all about making delivery predictable, so that stakeholders "feel confident" that agreed deliverables can be done with the allocated resources (time and costs). So, rather than empowering teams to make decisions about how they decompose projects into manageable chunks of work, project managers front-load the development work with extensive up-front planning, to "get ahead of the work" and "having tasks ready for engineering".
Code monkeys. Development is reduced to mere coding and testing of someone else’s product design. Developers are not involved in research, problem exploration, experimentation, or feedback and validation (eg. via customer support channels). Consequences include poor trade-offs being made in system design, a lack of shared understanding of the problem space, and a lack of ownership and accountability for the overall success of the product.
Feature delivery is prioritized over long-term project health. Feature prioritization does not take into account the exponential increase in product complexity that results from adding new features without continuous refinement of the system design through refactoring. Technical debt accumulates, increasing the rate of incidents (due to brittleness) and incrementally adding drag to the throughput of new features. There is little to no investment in improving engineering practices, tools, and infrastructure such as automated testing, continuous integration/continuous deployment (CI/CD), and monitoring – further exacerbating the delivery problems associated with increasing complexity.
With prioritization of the product backlog decided with minimal input from technical stakeholders, features tend to be batched together into large releases. Big-bang deployments increase the risk of production failures and, because long periods of time elapse between releases, feedback loops are lengthened – further increasing the risk of misalignment with user needs. There is little opportunity for learning and adaptation, as features are not incrementally delivered and iterated upon based on user feedback.
Failures are not acknowledged due to lack of accountability, insufficient psychological safety, and/or ineffective feedback loops. Delivered work is not assessed based on data, learning, and other feedback, and so features are only ever added, never removed or reworked and refined. The consequence is that failing projects are scrapped late, after much time and effort has been expended, rather than being stopped early when it becomes clear that the product concept will not succeed.
"Team Tetris" – the rapid shuffling of teams and projects – is a symptom of top-down resource management. Teams are frequently reconfigured to meet short-term project needs, rather than being allowed time to establish themselves as stable, self-organizing, cross-functional delivery units, which are far more effective long-term.