How To Shut Down Your Feature Factory

Are you developing software under pressure like a “feature factory”, but there never seems to be any economic benefit to the changes? Today I’d like to share some strategies to begin shutting this unhealthy work approach down.

The term “feature factory” was coined by John Cutler, a Senior Product Manager who's worked for several high profile companies. He wrote an article in the Hackernoon publication on Medium that introduced the concept to the masses.

When you read his article, you may, like me, find yourself nodding your head “YES!” to all of it. Anyone who has worked to produce software on a team that is a feature factory will immediately recognize many of the symptoms.

What is a Feature Factory?

I’d encourage you to read all of John’s articles for more details, but when you really boil it down a feature factory is a team or company that doesn’t know how to measure the business impact of their changes.

Set a Measurable Business Impact Goal for EVERY Change

When we’re in school many of us learn the scientific method. At a high level – you have a theory, you decide how to measure it, you design an experiment, and you record the results. Often our theories are proven wrong.

Unfortunately, when it comes to developing software many of us assume we can’t be wrong and do very little to handle that very real possibility. One of the first things that is necessary to shut down a feature factory, is to only make changes that can be measured as being successful or not in reaching an outcome.

Move Further Towards Cross-Functional Teamwork

When the people who work together to produce software are in separate departments, it often leads to people deferring design decisions to a UX, Product Management, or other design person. A cross-functional team actually strengthens the ability to deliver “the right thing” and NOT be a feature factory, because everyone can contribute to design ideas because they are dedicated to the success of ONE product.

Celebrate Outcomes Instead of Releases

When we start releasing software several times a day using things like DevOps and Continuous Delivery, we often will not hit a positive business outcome with each release. Because of the chance of failure, we should celebrate as a team when we reach a business outcome – not every time we release. John calls this “success theater”.

Cultivate a Culture Safe for Failure and Learning

When we plan a project that takes a long time to deliver, during that period there are assumptions about the value of what’s being built. There are no ramifications or learning until the end, and on some teams if the product doesn’t deliver on it’s expectations people are FIRED!

​To allow teams to be innovative and discover what they truly want, you must release small changes with the expectation that these may be “wrong”. This requires making it safe for Product Managers and others to take risks so they can learn.

Focus on Value NOT Efficiency / Utilization

This one is pretty self explanatory. If a team is constantly pushed to be as efficient as possible, they won’t have the relaxed and creative mindset necessary to make changes that contradict our initial assumptions!

Release Smaller Changes, More Often

To enable failures (learning) to have a smaller impact and cause less waste when it comes to budgeting – designing changes (experiments) that can run as FAST as possible and give us feedback EARLY is crucial.

Join my Patreon:  https://thrivingtechnologist.com/patreon

Learn about one-on-one career coaching with me: https://thrivingtechnologist.com/coaching

TechRolepedia, a wiki about the top 25 roles in tech:  https://thrivingtechnologist.com/techroles

The Thriving Technologist career guide:  https://thrivingtechnologist.com/guide

You can also watch this episode on YouTube. 

Related resources:

• John Cutler on Medium

Visit me at thrivingtechnologist.com