12 Signs You’re Working in a Feature Factory

Summary

The article discusses the concept of a "Feature Factory" in software development, where the focus is on churning out features without measuring their impact or connection to core business metrics.

Abstract

The term "Feature Factory" refers to a software development environment where teams are primarily concerned with producing features without considering their effectiveness or value to the business. This approach is characterized by a lack of measurement of the impact of work, rapid shuffling of teams and projects, and a culture that celebrates "shipping" features rather than evaluating their success. The article outlines twelve signs of working in such an environment, including the absence of retrospectives on product decisions, an obsession with prioritization over validation, and a focus on upfront revenue at the expense of product complexity. The author emphasizes the importance of connecting work to key business and customer satisfaction metrics, iterating based on data, and evolving the product management approach to avoid these pitfalls.

Opinions

The author criticizes the lack of measurement and validation in the feature development process, suggesting that this leads to a disconnect between work and business outcomes.
There is an opinion that organizations which celebrate shipping features without discussing their impact are engaging in "Success Theater," which is an unhealthy practice.
The article conveys that a true measure of success should be based on delivered outcomes rather than the number of features delivered.
It is suggested that product managers should regularly retrospect on their decisions to ensure alignment with expected benefits.
The author points out that an excessive focus on prioritization without equal attention to validation can lead to inflexibility and a lack of data-driven decision-making.
The culture of hand-offs and large batch releases is seen as detrimental, as it prevents teams from being directly involved in research, problem exploration, or experimentation and validation.
Chasing upfront revenue with new features is viewed as short-sighted, as it ignores the long-term implications of increased product complexity.
The article expresses the opinion that there should be more appreciation for the health of the whole product, including refactoring and addressing technical debt, rather than just the allure of new features.

12 Signs You’re Working in a Feature Factory

I’ve used the term Feature Factory at a couple conference talks over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, cranking out features, and sending them down the line.”

How do you know if you’re working in a feature factory?

No measurement. Teams do not measure the impact of their work. Or, if measurement happens, it is done in isolation by the product management team and selectively shared. You have no idea if your work worked

Rapid shuffling of teams and projects (aka Team Tetris). Instead of compelling missions or initiatives, teams deal in feature and project assignments. Chronic multitasking and over-utilization

Success theater around “shipping” with little discussion about impact. You can tell a great deal about an organization by what it celebrates

Infrequent (acknowledged) failures and scrapped work. No removed features. Primary measure of success is delivered features, not delivered outcomes. Work is rarely discarded in light of data and learning. Often the team lacks the prerequisite safety to admit misfires

No connection to core metrics. Infrequent discussions about desired customer and business outcomes. Team cannot connect work to key business and customer satisfaction metrics. Impossible to connect iterations to “what matters most”

No PM retrospectives. Product managers do not conduct regular retrospectives on the quality of their product decisions and compare expected benefits to actual benefits. Developers have “passing tests”, but product managers do not. Product managers view velocity and output as their key performance indicator

Obsessing about prioritization. Mismatch between prioritization rigor (deciding what gets worked on) and validation rigor (deciding if it was, in fact, the right thing to work on). Prioritization rigor is designed exclusively to temper internal agendas so that people “feel confident”. Lots of work goes into determining which ideas to work on, leaving little leeway for adjustments and improvisation based on data. Roadmaps show a list of features, not areas of focus and/or outcomes

No tweaking. Once work is “done”, the team moves immediately on to the next “project”, leaving no time to iterate based on qualitative and quantitative data

Culture of hand-offs. Front-loaded process in place to “get ahead of the work” so that items are “ready for engineering”. Team is not directly involved in research, problem exploration, or experimentation and validation. Once work is shipped, team has little contact with support, customer success, and sales

Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers at the conclusion of each sprint

Chasing upfront revenue. Features are implemented to close new deals. While not inherently wrong, the economic justifications are often flimsy (at best), and fail to account for the non-linear increase in product complexity (you make the quarter, but you pay for it many times over later). Again, this reinforces the idea that features are the unit of value measurement. Product decisions lack a sound economic grounding

Shiny objects. Low visibility for refactoring work and debt work-down. Low visibility for overall value delivery capabilities. As mentioned, primary measure of success is new feature output. Little appreciation for the health of the whole product as opposed to shiny new objects. Little awareness around impact of new features on usability (and maintainability and extensibility) of existing product

For translations of this post see: Korean

I’ve written about addressing this problem. Check out these posts:

Hacker Noon is how hackers start their afternoons. We’re a part of the @AMI family. We are now accepting submissions and happy to discuss advertising & sponsorship opportunities.

If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!