12 Signs You're Working in a Feature Factory

12 Signs You’re Working in a Feature Factory

The idea to translate this article came after several conversations with Brazilian colleagues where we discussed product management, the irrationality of some methodologies and frameworks that are highly prescriptive about almost everything regarding what developers should do, but selectively forget to prescribe fundamental aspects of product management such as (i) end-customer satisfaction and (ii) results/impact.

The result of all this: excessive output, boss management, stressed/overwhelmed people, cargo cult, dysfunctional teams, and companies literally burning money on countless initiatives that involve a significant opportunity cost. The goal of translating this article is to invite reflection on some of the consequences and signs of working in a functionality/feature factory.

John Cutler writes about product management on his website and on Twitter. He also writes on his site called Beautiful Mess and is currently Head of Education at Amplitude.

I would like to thank John 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.

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

I used the term Feature Factory [TN0] at a few conferences over the last 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’re working in a Feature Factory?

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

2. Sudden switching 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 exploitation/burnout [TN1];

3. Success Theater [TN2] around “deliveries” with little discussion about impact. One can tell a lot about an organization by the metrics it celebrates;

4. Infrequent acknowledgment of failure and wasted work. Features are never removed. The primary metric of success is the functionality delivered, not the results achieved through the functionality built. 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 key business metrics. Discussions about customer desires and business results are held sporadically. Consequently, the team cannot link work (effort) to key business indicators, let alone customer satisfaction metrics. It is impossible to connect product iterations with “what actually needs to be done”;

6. Absence of retrospectives by the product management team. Product managers do not conduct regular retrospectives on the quality of their product decisions, or even compare expected benefits with those achieved in reality. Developers need their software to pass development and acceptance tests, but product managers do not. Product managers see velocity and the number of closed tickets as their key performance indicators;

7. Obsession with prioritization. There is a 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). Prioritization rigor is designed exclusively to pamper internal agendas so 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 focus areas and/or outcomes;

8. No fine-tuning/optimizations. Once the work is “done,” the team immediately moves to the next “project,” leaving no time for iterations focused on product improvement according to available data;

9. Hand-off culture [TN3]. Extensive processes to “advance the work” (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 development team has little contact with support, customer satisfaction, and sales resulting from what was delivered;

10. Large batches of features. Without the obligation to experiment, features are delivered in large single batches instead of 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. Chasing short-term revenue. Features are implemented to close new deals/contracts. While not inherently wrong, economic justifications are often fragile (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 for 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 regarding what was delivered. As mentioned earlier, the primary measure of success is the delivery of new features. Little consideration for the overall health of the product as opposed to shiny new features born of 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 “feature(s)” will be used interchangeably with the word “functionality(ies)” 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 superutilization, but since we are talking about a software context and teams of people, the term “exploitation” (exploração) seemed most appropriate to me.

[TN2] — From the original “Success Theater” where low-performing teams theatrically celebrate irrelevant metrics that for some reason show some performance but actually have no practical impact. Ex: A 25% traffic increase (supposedly good metric) after a 10% marketing investment increase (how much more everything cost) but with sales stagnant at 1% (the metric that actually 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 production 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” directly translates as “Objetos brilhantes”, but it is not a common expression in PT-BR. Since the post was written in 2016, I decided to adapt it 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.