When is a Feature Factory... not?
honestprod.substack.com
honestprod.substack.com
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.
This post is a public service for potential investors.
1. Too much focus on user measurements can optimize products for the least engaged "marginal users": https://nothinghuman.substack.com/p/the-tyranny-of-the-margi...
2. Too much focus on measurements has also created the "engagement" trap on social media, where content is algorithmically optimized for click bait and rage bait.
3. As the post suggests, below a certain size, you don't have the data to measure. Depending on your market, you need to be well beyond product-market fit for even basic AB testing to be useful.
4. But yes, many a promising product has been killed by falling into a "consulting trap", where the dev team churns out incoherent features to win a few anchor clients.
My conclusion is that product design is hard. You can't just blindly follow metrics. You can't blindly throw poorly-integrated features at the wall.
This is one reason why good founders and product designers are incredibly valuable. They can be out there, listening to the customers, and trying to assemble everything they learn into a pattern. There may be data involved, but there's usually a lot of intuition, too. And engineering and support will also have valuable input.
I feel like that's a bit different from what most people think of when they hear "feature factory." When I hear feature factory, I think of an engineering team that has zero input into the product process and just builds whatever PMs or leadership says is important.
In the case of an early startup with no customers, I think if engineering teams get no justification, aren't involved in talking with customers, they are completely within their rights to complain about feeling like a "feature factory." The right solve isn't to say "actually -- we have no customers, so shipping a bunch of stuff isn't feature factory mentality" but to actively engage the team in product discovery conversations with users.
Yep, this was what I had heard referred to as a feature factory. No input of the engineering team, just take stories and churn out code.
When I would bring up suggestions that would improve long term quality and shave weeks off of projects, it was treated as "disruptive". Buzz off, thanks.