Podcasts Technology Thriving Technologist How To Shut Down Your Feature Factory

How To Shut Down Your Feature Factory

Published: Sept. 30, 2017, midnight

Are you developing software under pressure like a \u201cfeature factory\u201d, but there never seems to be any economic benefit to the changes? Today I\u2019d like to share some strategies to begin shutting this unhealthy work approach down.

The term \u201cfeature factory\u201d was coined by\xa0John Cutler, a Senior Product Manager who's worked for several high profile companies. He wrote\xa0an article in the Hackernoon publication on Medium\xa0that introduced the concept to the masses.

When you read his article, you may, like me, find yourself nodding your head \u201cYES!\u201d 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\u2019d encourage you to read all of John\u2019s articles for more details, but when you really boil it down a feature factory is a team or company that doesn\u2019t know how to measure the business impact of their changes.

Set a Measurable Business Impact Goal for EVERY Change

When we\u2019re in school many of us learn the scientific method. At a high level \u2013 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\u2019t 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 \u201cthe right thing\u201d 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 \u2013 not every time we release. John calls this \u201csuccess theater\u201d.

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\u2019s being built. There are no ramifications or learning until the end, and on some teams if the product doesn\u2019t deliver on it\u2019s expectations people are FIRED!

\u200bTo allow teams to be innovative and discover what they truly want, you must release small changes with the expectation that these may be \u201cwrong\u201d. 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\u2019t 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 \u2013 designing changes (experiments) that can run as FAST as possible and give us feedback EARLY is crucial.

You can also\xa0watch this episode on YouTube.\xa0

Related resources:

\xa0

Visit me at JaymeEdwards.com

Find me on Facebook at JaymeEdwardsMedia

Find me on Twitter as @jaymeedwards