This post basically argues you can be a successful feature factory if you’re driving feature prioritisation with data… but when you’re small, you can often get away with it because eg. You’re feature cloning a competitor.

It’s sad to see this seriously proposed, because it shows a deep lack of understanding.

Features are never the problem.

You can have a million features and be working on a million more and be perfectly ok, if those features do not impose constraints.

Constraints are the problem.

When you add a feature, well engineered or not, you probably add some constraints to your system.

As time passes, the effort to maintain all the existing constraints scales with the constraint count.

The difference between a feature factory and good engineering is that good engineering means when you implement a feature, you minimise the set of constraints it adds.

There is no amount of data and thoughtful prioritisation that can save you if you don’t put effort into understanding and maintaining your constraints, and if you don’t understand your constraints, you can’t thoughtfully discard some of them when you need to.

When you’re small, the set of constraints you have is small, so solving the N constraint problem is easy.

As you scale up, the problem becomes harder.

You can have a big product, but if you don’t understand the difference between features and constraints, you’re doomed to one of those “why aren’t we agile any more” conversations.

Feature factories aren’t bad because they’re fast. They aren’t bad because of a focus on shipping or iterating and pivoting… they’re bad because they slap on constraint after another onto a system until you can’t breathe without something breaking.