12 Signs You’re Working in a Feature Factory

Originally published on January 6, 2021.

12 Signs You’re Working in a Feature Factory

The idea of translating this article came after some conversations with Brazilian colleagues where we debated product management, the irrationality of some methodologies and frameworks that are highly prescriptive on almost everything developers need to do, but conveniently forget to prescribe fundamental aspects of product management such as (i) end-customer satisfaction and (ii) results/impact.

The result of all this: Much output, boss management, stressed and overworked people, [cargo cult](https://www.youtube.com/watch?v=F42A3R28WMU), dysfunctional teams, and companies literally burning money on numerous initiatives that are a pit of [opportunity cost](https://en.wikipedia.org/wiki/Opportunity_cost). The goal of the translation of the article is to show in the Portuguese language some of these signs, especially when working in a feature factory.

John writes about product management on his website and on Twitter. He also writes on his site called [Beautiful Mess](https://johnpcutler.github.io/tbm2020/) and is currently Head of Education at Amplitude.

I thank John in advance for his kindness in letting me translate his essay.

12 Signs You’re Working in a Feature Factory

Written by John Cutler (@johncutlefish) and translated by Flavio Clesio from the original article called 12 Signs You’re Working in a Feature Factory which was published on November 17, 2016.

 ([@johncutlefish](https://twitter.com/johncutlefish))

(Note: this was written in 2016. Recently — in late 2019 — I wrote a post about some things I’ve learned since then.)

I’ve used the term Feature Factory [TN0] at a few conferences over the past two years. I started using the term when a software developer friend complained that he was “just sitting in the factory, developing features and shipping them to the production line”.

How do you know if you are working in a Feature Factory?

1. No measurement of the impact relative to what was done. Teams do not measure the impact of the work performed. Or, if measurement does happen, it is done in isolation by the product management team and shared selectively. You have no idea if your work was successful;

2. Sudden shuffling of teams and projects (also known as Team Tetris). Instead of compelling and justifiable missions or initiatives, teams deal with features and project tasks. Teams have chronic problems with multitasking and over-utilization/burnout [TN1];

3. Success Theater [TN2] around “deliveries” with little discussion about impact. Much can be known about an organization according to the metrics it celebrates;

4. Infrequently acknowledged failures and wasted work. No features removed. The main success metric is features delivered, rather than the results achieved through the feature. Work is rarely discarded in light of data for subsequent learning. Often, the team lacks psychological safety as a prerequisite for admitting failures if they occur;

5. Lack of connection to core business metrics. Discussions about customer desires and business results are made sporadically. As a result, the team cannot link the work (effort) to the main business indicators, let alone customer satisfaction metrics. It is impossible to connect iterations with “what is most important to be done”;

6. No retrospectives by the product management team. Product managers do not conduct regular retrospectives on the quality of their product decisions, or even compare the expected benefits with those actually achieved. Developers need their software to pass both development and acceptance tests, but product managers do not. Product managers see velocity and production as their main performance indicators;

7. Obsession with prioritization. Mismatch between the rigor of prioritization (deciding what will be worked on) and the rigor of validation (deciding if it was, in fact, the right thing to work on). The rigor of prioritization is designed exclusively to pamper internal agendas so that people “feel confident”. A lot of work is required to determine which ideas will be worked on, leaving little room for adjustments and data-driven improvisation. Roadmaps show a list of features, not areas of focus and/or results;

8. No fine-tuning. Once the work is “done”, the team immediately moves on to the next “project”, without leaving time for iterations (based on data) with a focus on product improvement;

9. Culture of hand-offs [TN3]. Huge processes to “get work ahead” (i.e. filling JIRA with tickets) so that items are “ready for the development team to implement”. The development team is not directly involved in research, problem exploration, or experimentation and validation. Once the work is delivered, the team has little contact with support, customer satisfaction, and sales coming from what was delivered;

10. Large batches of features. Without the obligation to experiment, features are delivered in large single batches, rather than being delivered incrementally. You may even work in sprints (yay, we use “agile methods”), but nothing new is delivered to customers at the conclusion of each sprint;

11. Pursuit of short-term revenue. Features are implemented to close new deals/contracts. While not inherently wrong, economic justifications are often flimsy (at best) and do not take into account the non-linear increase in product complexity (you make the quarter, but pay for it many times over later). Again, this reinforces the idea that features are the unit of measure of value. Product decisions lack a solid economic foundation;

12. Appeal to hype [TN4]. Low visibility for refactoring work and reduction of product or technical debt. Low visibility of overall value relative to what was delivered. As mentioned earlier, the main measure of success is the delivery of new features. Little consideration for the health of the product as a whole as opposed to bright and new features resulting from hype. Little awareness of the impact of new features on the usability (and maintainability and extensibility) of the existing product.

Translation Notes

[TN0] — The original term “features” will be used instead of “funcionalidades” due to the fact that this anglicism is very common in software development, engineering, and product management teams.

[TN1] — The original term “over-utilization” can be translated as “superutilização,” but since we are talking about the context of software and teams of people, the term “exploração” (exploitation) seemed the most appropriate to me.

[TN2] — From the original “Success Theater” in which low-performance teams theatrically celebrate irrelevant metrics that for some reason show some performance but actually have no practical impact. Ex: Traffic increase of 25% (supposedly good metric) after a 10% marketing investment increase (how much more everything cost) but with sales stagnant at 1% (the metric that really matters).

[TN3] — From the original “hand-offs”. This means when work passes through many hands where each part is little involved throughout the entire process. Similar to assembly line work where each element of the line is only responsible for one part and has no knowledge of the whole.

[TN4] — The term “Shiny Objects” has a direct translation as “Objetos brilhantes,” but it is not a common expression in PT-BR. As the post was written in 2016, I decided to adapt and use the word hype just to give a bit more context of something that sounds like “brand new and has high appeal” for those reading in PT-BR.