Escaping the Feature Factory

How not to build Software Products

What is a Feature Factory?

“Our product must have this feature. Why? Because it should be there.”

“Let’s build this feature. Why? Because the client asked for it”.

Feature factories are companies or product teams that get into the race of building features rather than solving the problems of the user. Usually, the teams slipping into the Feature Factory mindset, think they are solving customer problems.

Building features comes at a cost and if it isn’t used by the end-users, it can affect the morale of the team, the success of the product, and hence your own. The features build in a feature factory (built without understanding the end user’s needs) bleed till death. In maintaining such features the teams spend time and effort which could have been devoted to more important tasks.

Why do Product Managers get into the trap?

Some organizations believe that adding a new feature always adds value to the product. Since a feature is a tangible and most easily noticeable aspect of a product, PMs/teams start to consider it as a measure of success.

Peer pressure is another reason which drives this mindset. A Product Manager on seeing their colleagues, building features might feel she is losing the race.

Building a feature brings a sense of achievement. This lures the product teams into the trap.

In some organizations, CXOs and clients also play a role in creating a feature factory. In many organizations, the teams are pressured to build certain features that are driven by the beliefs of one stakeholder.

The escape route

“Why a feature should not be built?” is an interesting initiation point. Asking this question starts a sequence of thoughts and activities where you’ll try to find reasons why not to build the feature you have decided to build. If at the end of this exercise you don’t have compelling answers, then only you should build the feature. This thought takes inspiration from the TDD concept which says — Don’t write the test case to validate the code, instead write the code to validate the test case.

The objective should not be to add a feature in the product or not, but to find out what your users really need. Here is the tricky part. Though the features are intended for the customers, it is not always wise to listen to the customers, especially when they are asking for features instead of sharing their problems. A feature is the result of customer needs, the product vision, and the technical capabilities of the team. The Product Managers should keep the baton in their hands while deciding the solution.

Not building a feature does not mean not solving the problem. The Jefferson Memorial case study is a classic example.

The Jefferson Memorial Story

Problem: One of the monuments in Washington D.C. is deteriorating.

Why #1 — Why is the monument deteriorating?
→Because harsh chemicals are frequently used to clean the monument.

Why #2 — Why are harsh chemicals needed?
→To clean off the large number of bird droppings on the monument.

Why #3 — Why are there a large number of bird droppings on the monument?
→ Because the large population of spiders in and around the monument are a food source to the local birds

Why #4 — Why is there a large population of spiders in and around the monument?
→ Because vast swarms of insects, on which the spiders feed, are drawn to the monument at dusk.

Why #5 — Why are swarms of insects drawn to the monument at dusk?
→ Because the lighting of the monument in the evening attracts the local insects.

Solution: Change how the monument is illuminated in the evening to prevent attraction of swarming insects.

Wrapping it up

There would be times when Product Teams might have to build features that, per their analysis, would not be useful to the customers, e.g., when a feature is built to pacify an important customer or to win a sales deal. What’s important is that the teams must know they are becoming a feature factory.

Experimenting is not bad at all, but you must start with an MVP and validate your assumptions before going all-in (check out how Dropbox did it, here). Then have the courage to kill off what doesn’t work. Remember the most important outcome of an MVP is learning.

“Innovation is not about saying yes to everything. It’s about saying no to all but the most crucial features,” as Steve Jobs said. So just go ahead and apply the Pareto principle and find the 20% features which will bring 80% of the results for your Product.

Here is an interesting clip from the movie “3 Idiots” that explains the concept quite well. Take a look.