I think the main argument of this essay is that if you're an early stage company with no customers, it's not a bad thing to churn out features to see what sticks in the market because you don't have the luxury of customers to talk to. And that in this case, people might falsely complain that they are a "feature factory."
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.
>>>> 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.
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.
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.
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've had a director explain to me in his serious, biz-school-insight tone that the tech org is a factory for tickets and his job is to run the factory. He would consider "feature factory" a compliment, aspirational.
Yeah, this is for sure a thing. I left a startup last year due to Product, UX, and CTO insisting that "everything is already figured out, just do it quickly" and then spoon feeding JIRA tickets to my team.
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.
9 comments
[ 510 ms ] story [ 2644 ms ] threadI 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.
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.
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.