Ditch the Feature Factory

Picture this

You are a developer. Like most others, you work in a silo. You are assigned your share of the pie and as requested, you churn out feature after feature as per your Product Owner's requirement. You dutifully complete the tasks! Then one fine day, the Product Owner walks in and asks you to pull out one feature you had built as it is not really relevant.

Your morale comes crashing down, doesn't it? The days and probably nights or weekends spent building it flash before you. Product consultant John Cutler calls this scenario a feature factory, where the focus is more on output rather than outcome. Though you keep building a lot of features, the value addition is minimal. Typically in a feature factory, teams fail to regularly measure the impact of their work, take stock of where they stand, which direction they need to move in, and have no metrics in place to measure their value.

Potentially Perilous

Being in a feature factory setup not only affects the morale of developers, but can even affect the fortunes of a company. Let's take the case of a fledgling software product company whose flagship product's sales were sky rocketing a few years ago. In a bid to bolster revenue, the management kept adding more capabilities to the product. The poor developers had no other option but to build all the features mandated by the Product Owner. The product ended up being complex without adding value to the end user. The sales obviously started declining and this forced the management to go back to the"drawing board" to rethink their strategy.

"Being able to take needless work out of the system is more important than being able to put more work into the system." - Gene Kim

Exiting a feature factory

So we now know the perils of a feature factory. How do we avoid falling into such a feature factory trap ourselves? Taking care of a few simple aspects can help us move towards building a healthy backlog of features. Let's look into these aspects in detail.

1. Set up a vision board:

   Every organization has a vision and in certain cases each product has its own vision and a set of objectives. Roman Pichler's vision board suggests capturing the target group, the user needs, the key product features, and the business goals. This not only acts as a beacon for teams, but also helps them envisage and validate their product strategy.

2. Define value based metrics:

   Most enterprises merely resort to financial metrics. However, it is highly recommended that equal or more focus is given to defining value based metrics to help identify the quality of the product and the company's agility. Value based metrics include customer feedback, support issues, quality numbers and so on.

3. Drive towards a goal:

   Every feature in the product should align to a business goal. This is to ensure we are not deviating from our product vision and what we set out to do. Most often, product team members are unable to relate to the big picture or understand what the business is trying to achieve. Read more about this alignment in the article 'Connecting the dots: Business and Development'.

4. Track your objectives:

   This is an extension of the previous point. Enterprises spend a lot of time tracking the progress of product development and individual team efforts but fail to track the progress made by the released product, to gauge how close it is to its initial objectives. So there must be clear cut metrics defined for each objective and the Product Owners must make sure that these objectives are met after the release execution. Popular enterprise Agile framework SAFe^® calls it Program Increment (PI) objectives.

5. Kill dispensable features:

   This is where a value based metric like customer satisfaction index comes into the picture. Monitor customer feedback and immediately remove features which are not mapped to any customer usage or those that are not used as intended to. Though this might result in trashing months of effort, eventually it would make the product clutter free and it would therefore rise higher on the quality index.

Ultimately it all boils down to trust. The team must definitely know the purpose behind building the product and the expectation of their prospective users. Defining the vision board, objectives, and other metrics ushers in transparency, in addition to boosting the morale of the team. The foot soldiers (developers!!) might just be able to provide valuable inputs to the product that were not foreseen by the Product Owners.