The term Feature Factory is when a software developer is just sitting in the factory, churning out features, and sending them down the factory line.

The Feature Factory

<ul><li>Teams do not measure the impact of their work. Or measurement is done in isolation by the product management team.</li><li>Rapid shuffling of teams and projects. Teams deal in feature and project assignments.</li><li>Success theatre around shipping, but little discussion about impact.</li><li>Infrequent acknowledged failures and scrapped work. The measure of success is delivered features, not outcomes.&nbsp;</li><li>No connection to core metrics. The team cannot connect work to key business and customer satisfaction metrics.</li><li>No product managers retrospectives on the quality of their product decisions.</li></ul>

Signs You’re Working in a Feature Factory

<ul><li>There is a mismatch between prioritising what gets worked on and deciding if it was the right thing to work on.</li><li>No tweaking. Once the work is done, the team instantly moves to the next "project", leaving no time to iterate.</li><li>The prevailing culture of hand-offs with no involvement in research, problem exploration, or experimentation.</li><li>Large batches instead of delivering incrementally.</li><li>Chasing upfront revenue.</li><li>Little appreciation for the health of the whole project and instead focus on shiny new objects.</li></ul>

More Signs You’re Working in a Feature Factory

<img alt="John Cutler" src="https://miro.medium.com/max/500/1*HP7zJEnq-tuDbekIvZvoJQ@2x" width="48" height="48">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?<OL><LI>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</LI><LI>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</LI><LI><a rel="noopener follow" href="https://medium.com/@johnpcutler/success-theater-b60a1666fe67#.5zjj95jy4" dir="ltr">Success theater</a> around “shipping” with little discussion about impact. You can tell a great deal about an organization by what it celebrates</LI><LI>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</LI><LI>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”</LI><LI>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</LI><LI>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</LI><LI>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</LI><LI>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</LI><LI>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</LI><LI>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</LI><LI>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</LI></OL>For translations of this post see: <a href="http://jeongmin%20kwon/" rel="noopener" dir="ltr">Korean</a>I’ve written about addressing this problem. Check out these posts:

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…

product

Product & Design

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?

<ol><li>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 </li><li>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 </li><li><a href="https://medium.com/@johnpcutler/success-theater-b60a1666fe67#.5zjj95jy4">Success theater </a> around “shipping” with little discussion about impact. You can tell a great deal about an organization by what it celebrates </li><li>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 </li><li>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” </li><li>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 </li><li>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 </li><li>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 </li><li>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 </li><li>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 </li><li>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 </li><li>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 </li> </ol>

For translations of this post see: <a href="http://jeongmin%20kwon/">Korean </a>

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

12 Signs You’re Working in a Feature Factory

The Feature Factory

Signs You’re Working in a Feature Factory

More Signs You’re Working in a Feature Factory

CURATED BY

Related collections

More like this