This seems written by someone with an axe to grind.
Signs you’re working in a feature factory (2016)
21–30 of 286 posts
Re: Signs you’re working in a feature factory (2016)
#22I’ve found #8 to be very important. If you don’t allow for revisions you get code rot and suddenly every new feature becomes exponentially more difficult to implement.
Re: Signs you’re working in a feature factory (2016)
#23In this framing, a factory is supposed to be bad? Aren’t factories efficient and the best way of producing things at scale?
The problem is that "shipping stuff" is not what companies are supposed to be solving. They're supposed to be providing _value_ to customers and investors.
A "feature factory" model is bad because it masquerades as progress.
"Value" is harder to define, and often can't be measured _simply_ with metrics - you need metrics for insights, but most metrics are very much trailing indicators. Also there are lots of silly metrics like "tickets closed" that are easy, and naturally companies gravitate towards anything easy as the number of people rises. And factories love metrics.
Re: Signs you’re working in a feature factory (2016)
#24Somebody asks for a feature, you build it, they pay you — that’s data. Data isn’t just spying on your users to see how they behave.
A big part of product management's function is buffering all the features being asked for so that they can take a step back and design a solution that isn't just 100 new features. The feature factory process is mostly a symptom of product being bad at their job.
Sure, but my point was that this article seems to be focused on data-driven product decision-making. Creating good designs with far reach in my view is unrelated. I wanted to counter the narrative that unless you are spying on your users and using that to 'prove' your features are being successful you are doing a bad job at product development.
It's certainly possible in my mind to do requirements gathering, feature design, implementation, deployment, and iteration without automated data collection from user behavior. You can, you know, talk to people. Nowadays when someone says "data-driven" they typically mean "instrument the hell out of your product and observe user behavior." Perhaps that's not what the author is getting at. But if they are, I think it's important to tell people to not feel guilty for not spying on their users. If you are doing the follow-up work to actually communicate with customers to understand their needs, you should feel confident that you're doing your job well. And you should be proud that you are doing so without having to spy on people.
Re: Signs you’re working in a feature factory (2016)
#25Feature addiction is real. This post points to perverse economic incentives as being one possible cause, but I have also seen this happen in open-source projects. It's a matter of listening to the wrong people, in my view. User feedback is incredibly valuable, but when user feedback comes in the form of GitHub issues rather than careful testing and conversation, the team will inevitably find themselves building more…
Most times when users say they won't use a product because it's missing a feature:
- Those specific users won't use it anyway even if you add it
- The problem they identified is a legitimate problem that was preventing other people from using it
- Whether your metrics actually go up depends on where that feature was in the critical path of your funnel. All else being equal, fixing legitimate problems with your product is unlikely to move your metrics much, because most (randomly distributed) problems aren't at the frontier of the critical path.
It's a mistake to think that adding features that customers ask for will immediately improve your core metrics, but it's also a mistake to think that features that don't visibly improve your core metrics were a mistake to add.
Re: Signs you’re working in a feature factory (2016)
#26Earlier quoted context omitted.
A big part of product management's function is buffering all the features being asked for so that they can take a step back and design a solution that isn't just 100 new features. The feature factory process is mostly a symptom of product being bad at their job.
Sure, but my point was that this article seems to be focused on data-driven product decision-making. Creating good designs with far reach in my view is unrelated. I wanted to counter the narrative that unless you are spying on your users and using that to 'prove' your features are being successful you are doing a bad job at product development. It's certainly possible in my mind to do requirements gathering, feature…
totally agree, it's also possible to have built a feature that users have to use but aren't happy about - then the data can be misleading.
Re: Signs you’re working in a feature factory (2016)
#27Somebody asks for a feature, you build it, they pay you — that’s data. Data isn’t just spying on your users to see how they behave.
Sure it is. "Spying" is just a deliberately loaded term to make it seem bad. What would you think of an office manager who set things up only according to requests, never trying to observe and anticipate employee needs?
Re: Signs you’re working in a feature factory (2016)
#28I don't actually understand what's bad about this, maybe someone who is in a company like this can explain why it's a negative? I am working with a company that is moving more towards this approach and I'm really enjoying it. Isn't this essentially what Basecamp's Shape Up method advocates for? Not everyone feels they need to be building something that changes the world I suppose. Each to their own.
I think the high-level summary of the article is ‘fire-and-forget development’ - ie producing features, but not measuring impact/benefit/usage.
I’m not convinced ‘feature factory’ in itself is problematic (definition not provided). There is no problem (IMO) in optimising to ship features - as long as the overall approach is to measure impact/benefit/usage and then learn and iterate.
Re: Signs you’re working in a feature factory (2016)
#29I don't actually understand what's bad about this, maybe someone who is in a company like this can explain why it's a negative? I am working with a company that is moving more towards this approach and I'm really enjoying it. Isn't this essentially what Basecamp's Shape Up method advocates for? Not everyone feels they need to be building something that changes the world I suppose. Each to their own.
A combination of sign 3, 8 and 12 can be awful. The features that are shipped are half-baked, teams always say that they will come back and refactor it but of course never do. Developers start to care less and less about quality because that isn't what gets rewarded. Feature ship rates go up in the short term but in the long term slow down as the spaghetti gets worse and worse.
Good developers either see what is happening and jump ship or just get bored and leave.
Re: Signs you’re working in a feature factory (2016)
#30I don't actually understand what's bad about this, maybe someone who is in a company like this can explain why it's a negative? I am working with a company that is moving more towards this approach and I'm really enjoying it. Isn't this essentially what Basecamp's Shape Up method advocates for? Not everyone feels they need to be building something that changes the world I suppose. Each to their own.
There is a danger of a useless product which has 120 features.