19 ms·

Signs you’re working in a feature factory (2016)

1002 points by aphextron 7y ago

CameronNemo 7y ago
What do I do if upper management seems to be driving this process?
- layoutIfNeeded 7y ago
  Bail asap.
- wefarrell 7y ago
  Where this exists it's usually driven by management, especially #12. The fix is to shift focus towards measurements and a longer timeline. It's really hard to change management's focus, but you can implement that mindset for your and your teams work and once management sees the benefits it will be easier to convince them it's worth adopting.
- ipnon 7y ago
  If your input regarding how the company is run is valued by upper management, then make a clear argument that they are running a feature factory and what they can do to change. If no one cares what you think, then the best outcome for yourself and the your company is for you to find other employment. You labor is freed from the feature factory for more productive purposes and the probability of survival for your sub-optimal company is diminished, opening opportunities for more optimal companies in the same space.
rubyfan 7y ago
Much of this describes some of my past experience at a Fortune 100. That company is now undergoing much discussion at a senior level about agile delivery. Senior executives are walking around talking about tribes and chapters and have no idea what that really means or of the day to day work of teams. It’s unfortunate what will come out of it in the end is some people doing stuff now that will have new titles and maybe more ceremonies but not a substantive change from what they do now or the way work gets done. Middle management thinks they work in a factory and treat people like numbers. If you trust the same group of people to implement the change then you can bet their sole goal is to make it look good. Unless you change the middle then not much will change.
- tuanis 7y ago
  I actually feel like agile development can invite some of this behavior, because the focus is on shipping instead of value. Not saying agile is bad, just feels like a separate problem.
  - SpicyLemonZest 7y ago
    In principle agile is supposed to be guided by higher level processes accounting for this kind of strategic problem. In practice, yeah, I do sometimes see agile teams get away with writing "objective: ship my features, KR: 5 features are shipped".
- itronitron 7y ago
  I'm waiting for the inevitable open office plan that has a conveyor along it's primary axis for moving white boards along the production path, like in a modern factory. There can be a sub-team that programs robotic arms to sketch things on the white boards as they pass each stage.
ttoinou 7y ago
What's wrong with feature factory ? If you're delivering something good for clients.. No measurement / Success theater / core metrics This takes time and mental space. That you could better use to... crank a new feature! :)
- scribu 7y ago
  > If you're delivering something good for clients... That's the crux of it, isn't it? How do you know that what you're delivering is any good?
  - LaGrange 7y ago
    Depending on the customer and the work, I might not — or, to be more precise, I might only know some aspects of the product's quality based on what the customer tells me. Or I might only directly know whether certain aspects of what I'm doing are good. Arguably that's actually always the case, but if you're doing consumer-oriented mass-market stuff, then it's quite possible that "what the producer knows" overwhelms what the "customer" knows. But not all software is something you can dogfood or A/B test, and software developers are _very_ quick to assume that they know better than customers, especially if the customer is in some way locked-in.
  - lazyjones 7y ago
    > How do you know that what you're delivering is any good? How do you know it isn't? You need to implement it and see whether it's good or not.
    - dillonmckay 7y ago
      If you know it is going to be a nightmare to support, it will consume tons of resources (cpu/storage), and nobody wants to pay for it (or not pay enough to cover its costs), it is not good. As has been mentioned many times on this site, it is very easy to sell $2 for $1 all day long.
      - 7y ago
marstall 7y ago
unfortunately this is almost every place i've ever worked. so many good points here - but the most poignant for me is "celebrating shipping" vs celebrating customer success ... so true
johnkarahalis 7y ago
Feature 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 and more and more for no real benefit. I've quoted this before, but what Don Norman says in The Invisible Computer still applies: "Don’t ask people what they want. Watch them and figure out their needs. If you ask, people usually focus on what they have and ask for it to be better: cheaper, faster, smaller. A good observer might discover that the task is unnecessary, that it is possible to restructure things or provide a new technology that eliminates the painstaking parts of their procedures. If you just follow what people ask for, you could end up making their lives even more complicated."
- Alex3917 7y ago
  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.
  - cgriswald 7y ago
    > Those specific users won't use it anyway even if you add it I think people read this and think, "Why bother, then?" As someone who is often this user, I don't end up using your product because I've already moved onto a competing product or service; or because I never hear that you have added the feature. Whether your metrics move after adding the feature might be a matter of timing. There's also the chance I will come to your product in the future. Hypothetically, let's say you offer a password vault application, but I dislike it because it lacks a feature I want, so I end up going with your competitor who offers the feature. You add the feature, but I don't switch because I'm now content with your competitor. Later, your competitor starts pushing towards a subscription model while simultaneously showing a real lack of professionalism and social grace towards customers in public. Since you've added the feature that I thought was lacking, your product might now be an option for me. If you haven't added the feature, there's still no chance.
thomas 7y ago
In this framing, a factory is supposed to be bad? Aren’t factories efficient and the best way of producing things at scale?
- gfody 7y ago
  when it comes to software you do not want to produce code at scale. the fewer lines of code the better really. it'd be like measuring the quality of your genome by counting the rungs in your dna.
- vertex-four 7y ago
  Which is great, so long as they're not just creating debt for themselves by e.g. creating broken products that have to be recalled to be fixed by the factory.
- mongol 7y ago
  A factory can produce almost anything at scale, but how do you know it is worthwhile and providing the best possible value? In a "bad" factory, the "factory workers" are like cogs in a machine and have no influence over what is built. There is someone ordering to build this or that and they produce it. Feature factory is in this terminology should be seen as opposed an alternative process, where the "factory workers" themselves decide what to produce and how, and as long as the measured value stacks up, it will be more efficient and derive more shareholder value than the "feature factory".
- mr_tristan 7y ago
  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.
- jrockway 7y ago
  Factories are fine, but if you walk into a factory you're going to be finding a lot of people working on the factory itself. Process tweaks, new machines, maintenance, etc. In the software "feature factory", people have mostly forgotten about that, usually because someone does it "in their spare time". I guarantee you that no factory worker lubricates the machines off the clock. I am not sure why we should treat software any differently.
davzie 7y ago
I 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.
- SpicyLemonZest 7y ago
  The problem is that, if you're churning out features without thinking critically about why, your work might not even change the company. I've seen engineers, teams, even entire departments spend multiple quarters being a net drain on the company. But they never noticed, because they kept consistently defining release targets and hitting them.
  - lazyjones 7y ago
    > churning out features without thinking critically about why, your work might not even change the company Isn't this just speculation? Why would anyone build features without any thoughts about their benefit? In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.
    - SpicyLemonZest 7y ago
      There are a couple reasons I've seen why you'd do that. I'm sure there are others I haven't seen. * Sometimes companies have declared focus areas, and it's advantageous to be working in those areas. If the CEO says Project Foobar is going to be the next big thing, you want your team to be touching Project Foobar even if you have nothing valuable to contribute. * Some kinds of projects are costly to push back on. If someone comes to you and says "this is a security feature, I'm going to build it to increase security", you have to demonstrate that the system is secure without it and not just tell them no. * In some environments, people are measured by their ability to produce lots of features. This makes it embarrassing and politically damaging to not do a feature you proposed. So once it's publicly known that you have a feature, it's too late to think about whether it's useful, you have to just buckle down and do it.
gfodor 7y ago
Somebody 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.
- gfody 7y ago
  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.
  - gfodor 7y ago
    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.
    - gfody 7y ago
      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.
- SpicyLemonZest 7y ago
  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?
redwood 7y ago
This seems written by someone with an axe to grind.
- BossingAround 7y ago
  Don't we all have axes to grind?
Orcus90482 7y ago
I’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.
funfunfunction 7y ago
Feature addiction is exacerbated by VC. Without real consequences to a poorly planned product roadmap due to the years of runway afforded by massive funding rounds, entire orgs fall into the “one more feature” cycle and never focus enough on measuring success in terms of real dollars. No one knows what went wrong when all the money is gone and devs/designers/PMs rinse and repeat at a new well-funded startup.
- borski 7y ago
  This actually isn’t true. VCs don’t want companies to build features, they want companies to listen to users maniacally and find product-market fit, then focus on growth (and/or revenue) like mad. That companies focus on features is a management issue and a sign of a failing company, not a sign that VC is somehow bad.
  - funfunfunction 7y ago
    I agree that the issue is a problem of management. Though without oodles of cash to wash away missteps, poor management would be much more obvious. The ability to distill user feedback into the minimum number of valuable feature enhancements is what sets successful product orgs apart from failed ones. When cash is largely not a constraint, the tendency is to build exactly what each customer has said they want rather than try to come up with succinct improvements. The result is often bulky products that cost a fortune to maintain and only appeal to small number of customers. VC is good if used correctly. But dumping wads of cash into a company to develop a product that isn’t capital intensive (like web or mobile tech) has the tendency to create bloated product orgs which optimize for the wrong things.
  - whateveracct 7y ago
    Planning and building new features allows you to pad your slide deck tho
lr4444lr 7y ago
Sigh... At some point, most healthy adults who are not living in terrible circumstances come to the mature realization and compromise that their job is largely to produce value for someone else, not to be the primary source of personal fulfillment, and they come to understand that there is dignity in being productive, if not creative. Be creative on your own time. Lead a civic group. Be a good parent. Volunteer at a charity. If your main gripe at work is that you're on the value-adding side of a company, which is what feature dev is in software, you have it pretty good in this world. Change jobs if you must, but the realities of companies, especially as they gain traction, rarely means the grass is ever greener. If this is unsatisfactory still, start your own company. I just don't understand the problem here.
- lifeisstillgood 7y ago
  True. But imagine if you are also a shareholder in such a company - would you not want them to fix it?
- draw_down 7y ago
  > Change jobs if you must Or if a new job can offer you a better deal. If these jobs are all interchangeable, then you may as well interchange them for what benefits you most.
- braindongle 7y ago
  Disagree. This is an endorsement of accepting the fact that your work, your professional work, done by most of us at a job, makes you feel like a cog, a unit of production. It is better called a surrender than a compromise. Surely it's often case that life has people in this sort of scenario and there is no realistic way to a new path. In that case, sure, take care of your loved ones and yourself, stay put, and make the most of it. This scenario arises from the messy mix of circumstances and decisions. There is no blame. But! "Change jobs if you must", must, be changed to "Change jobs if you can.", especially for younger people. It's not mature to accept an unfulfilling job. It's a life-scale bummer. Tenaciously go after fulfilling work. Don't write off 1/3 of your remaining life. An approach that worked for me: distance yourself from the profit motive. It's not that hard.
ryandrake 7y ago
I'm surprised by so many negative comments here (actually, I'm not). This great piece summed up a lot of awful aspects about commercial software development that I've also observed over the past 20 years, but have been unable to organize together and articulate as single problem. People are asking why this is bad. One way to think about why the Feature Factory is bad is that it's mostly open loop: You "launch" feature after feature at the customer, but there's no real feedback coming in to understand whether what you're doing is worthwhile, to understand what to improve or fix, or to drive future decisions. The only feedback that gets measured are things like revenue and sales, and the only thing leadership sees as driving revenue is the constant spew of features--because that's all you're doing. The insights that you get from revenue are very generic: "Money is coming in--keep doing what you're doing" or "We're losing money. Do something different!". The insights you get from salespeople are even worse: "We'll land this sweet-ass deal (and I'll get my bonus) if only you churn out otherwise un-needed features X, Y, and Z!" I guess this is fine if you're an agency or consulting shop that just does one-off projects and then moves on to the next client. On the other hand, if you're writing software for actual people to use, trying to be the best in class at one thing, or building a platform to last decades instead of months, then your product will suffer if all you do is bolt half-baked features onto it over and over.
- BossingAround 7y ago
  I think the reason why I was confused is that it seems there's a very fine line between a feature factory and Google/Twitter/Facebook/Amazon/... At a lot of these high-functioning places, they seem to have "feature factory" moments with some tweaks (e.g. actually building metrics, refactoring, etc. so that the SW won't implode in 6 months down the line).
  - dillonmckay 7y ago
    People complain about it, but Google being able to literally ‘pull the plug’ and shutdown unprofitable or disproportionately resource draining projects is important to note. To me, that is a characteristic of the un-feature factory, or whatever the opposite would be called.
PragmaticPulp 7y ago
I suggest re-reading this article in the negative: Assume that your team implemented every single one of these bullet points perfectly, for every feature in every sprint. Now imagine that each of those bullet points is a recurring meeting invite on your calendar. Now imagine how happy you'd be spending all of that time in meetings or reading process-related e-mails so your company could satisfy the criteria of not being a feature factory. Does a feature factory sound so bad now? I thought this article was great when it first came out, but I've since changed my mind. I've seen too many engineers, especially junior engineers, become overly cynical about their jobs after reading too much into this one article. 1) With 12 different "signs" of a feature factory, it begins to read like a horoscope: Almost everyone reading it can find something to identify with. Multiply this across every different project or initiative at a company, and everyone can think of multiple times their job has resembled the descriptions in this article. Does anyone actually read this article and walk away thinking their company has never once resembled the vague signs in the article? 2) It begins with an implied assumption that working in a feature factory is a bad thing. Combine that with the horoscope-like 12 possible indicators of a feature factory, and the reader will always conclude that their workplace is the bad thing. 3) It sets unrealistically high standards. The alternative to a "feature factory" is defined in the negative in this article. Can you think of any company that would score a perfect 12/12 on every bullet point in this article across every team in every department? The process overhead would be significant, and it would very easily translate to a lot of meetings, e-mails, and overhead. The kernel of truth within the article is still very valid. Teams should absolutely take the points into consideration and apply them judiciously, where it matters. However, it's a mistake to use this article as a checklist by which to judge your company's process. Real work is always a bit messy, communication is never perfect, and just because you don't see these things with your own two eyes doesn't mean they aren't happening somewhere in the company. As a product manager, suggestions are always welcome and I'm happy to discuss reasoning for decision making, but I also don't burden the entire team with every detail of every step of the way.
- whatshisface 7y ago
  Most of the points in this article are relative, for instance what does it really mean to have no care for technical debt drawdown? How much care is not enough? However, one thing that it's specific about is the lack of measurement. There are some companies out there that have zero focus on customer feedback, and since there's only one zero, that indictment is not relative to people's expectations.
lifeisstillgood 7y ago
At a certain company size, there simply is not the level of control (ODA loops) to know what product to make or features to add - it is a fairly good survival strategy to have multiple teams duplicating huge amounts of work simply because a few will deliver the right thing. The internal politics of most organisations has a similar feel - lots of duplication looks like competing camps and frequently is, but the duplications is partly survival strategy (what if those others don't deliver) and partly evolution (one team will deliver something that actually fits the market.) Boy there are better ways to arrange it, but this seems to be a local maxima that's easy to reach.
antoineMoPa 7y ago
I'd rather work in a feature factory than a bugfix factory.
- samyel 7y ago
  Eventually a feature factory will turn into a bugfix factory as more and more unmaintained and potentially competing layers are added.
  - gfody 7y ago
    ..or some features are actually bugs, now your a bug farmer.
- wutwutwutwut 7y ago
  I on the other hand prefer fixing bugs over implementing features which not even the product manager can explain to me why the customer need.
xyst 7y ago
To a certain degree, and in my experience, all companies have this problem. Sometimes it’s at a team scale but for others it’s at an organization scale.
anonu 7y ago
This just sounds like regular software development.
adamzapasnik 7y ago
I worked at that kind of company, wouldn't recommend it to anyone. I could write a very long essay why it sucked so much, meh. In short, it's very easy to burn out and overall it's just stupid. The pace was surreal, some of the features very complex, many people were overworking. Everyone is super stressed out, the best decision is to just leave that environment. Bottom line, don't work for that kind of companies, because your value is equal to the speed of your fingers typing.
michaelfeathers 7y ago
Great article. It should add Technical Debt as a sign.
numbers 7y ago
Yes! Very well put together list because at my last role (in the same company) this was essentially what I was trying to escape and when I look at the work that team is doing, it’s not impactful or noticeable but the devs are always building some new complex thing that won’t even see the light of day once. On my current team, feature building is the second to last step (right before a retro) because product development requires many non-coding steps to first understand problem. Some times, I believe it should be “problem solving” instead of “product development”.
jugg1es 7y ago
I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement. It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input. There is a reason that the points in this article exist at all - because the alternative is actually worse!
- codingdave 7y ago
  It is a question of balance. Don't do a process just for the sake of the process. Don't do a feature just for the sake of doing a feature. If you cannot tie those things to actual business goals, that is when you have a problem.
- mceachen 7y ago
  The article is not saying "big feature" pipelines (where there is coordination across several teams) are inherently bad. The article is disparaging that process if it is the only process. (And I've worked at companies where this was nearly true). There must be efforts to experiment and refine (and possibly remove) existing features. There must be efforts to refactor and improve existing code, to make it easier to maintain, less painful to be on-call, and make it possible to add subsequent features without breaking existing functionality. You have to be able to do both large and incremental work to improve, in other words.
  - tomnipotent 7y ago
    > There must be efforts to refactor and improve existing code Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly. This has yet to fail me. Granted, I don't work in embedded systems and my code is deployed on owned & operated servers that's easy to update.
annoyingnoob 7y ago
I've heard this called 'being on the hamster wheel', you are running forward as fast as you can but not going anywhere. I've had an experience where I dreaded the daily stand-up, it was all about 'story points' in a mad scramble to find traction with customers. Management was stabbing in the dark, we didn't have a direction. Once we did have a direction we lacked the required input to push us in that direction.
pyb 7y ago
It's very interesting to see a huge cultural gap within the tech industry, from many of the comments here. Quite a few people are saying : what's so bad about the feature factory ? This sounds like a desirable environment. Whereas I, and many others here, see it as a living nightmare of endless busywork and improductivity. (I've once worked in an environment a bit like that, so I know they actually exist.)
- joegahona 7y ago
  I agree and think it’s a divide between product and engineering. Product managers (at least good ones) love thinking about the problem, while developers love thinking about solutions. I’m generalizing of course, and both mindsets are needed, but it’s the product manager’s job to make sure the developers are solving the right problems and not just launching features that don’t speak to a customer benefit.
squirrel 7y ago
[2016]. Previous discussions on HN: https://news.ycombinator.com/item?id=13639549 https://news.ycombinator.com/item?id=13639549 https://news.ycombinator.com/item?id=13044685 https://news.ycombinator.com/item?id=13044685 Very good article, so good that my coauthor and I used the metaphor in our book.
_drimzy 7y ago
Ah man. This makes me realize why my time at a recently IPO-ed tech company, as an engineer was so horrible. Except #10 the company is guilty of every single point.
dragonwriter 7y ago
While this focusses on places selling software (features added to close deals, etc.), it is probably an even more pervasive problem in internal IT shops—and a more tragic one, because internal IT organizations should be better positioned to tightly align on business value rather than sales, though this is often hampered by internal organizational structures which sometimes incentivize arms length, contracting-like interactions.
awinter-py 7y ago
> success theater such a good phrase. premature 'mission accomplished' is always embarrassing even when you're just the one stuck cringing and golf clapping in the corner Common thread here seems to be lack of argument / buy-in process. Central leaders need to (1) convince the team that tactics accomplish team goals and (2) have team goals. Bad teams do none of the above.
0xff00ffee 7y ago
I've had to make the decision to steer my design resources into "feature factories" because my customers are sometimes fickle. There are a number of instances where features were paid for, developed, and then not deployed. It hasn't become discouraging yet because there has been professional growth in developing methods for constructing and deploying said features, but I am concerned as to our financial ability to identify and reject contracts that are just un-exciting features. Most of my devs are satisfied with the paycheck despite the work, but a few are showing signs of not being valued. And I'm not sure how to address that yet to avoid losing them. It's like: taking a lame contract for $$$ vs. boring a good employee. I hate how personal it becomes, I feel like I'm cajoling them to do the work, ... it feels icky and toxic.
- sfink 7y ago
  I dunno, if I were an engineer in an environment like that I'd be fine with it if (1) you were up-front about this being a necessary hack to sustain the company for a bit longer, and (2) there is a vision and a process to refine that vision of where you would all like the product to go. (2) is so that these seemingly short-term features could either be seen as prototypes or first cuts at the future you'd really like to get to, or walled off as extraneous stubs that don't interfere with the core architecture. (1) is important because I feel good about helping keep the company afloat, but I feel crappy about just doing stuff that I know is bullshit simply because I'm told to (or worse, lied to that it's "important" for its own sake). This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Communicate that decision and why you made it to engineering; we love to hear that sort of thing. The safest answer that a salesperson can give is "yes". The safest answer that an engineer can give is "no". You can't let either side always win, but you can communicate the reasoning and importance to bridge the gap and make it a team decision even if it wasn't the team making it.
  - 0xff00ffee 7y ago
    Thanks for the feedback. That's pretty much how the discussions go. The team is small so I can still be 1:1 with them, and be direct about the state of things. >This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Yeah, this is a really good indicator. Heck, if this keeps up -I- won't want to do it anymore! Which I think is perfectly natural.
metalgearsolid 7y ago
Been there. Anecdotally, a good indicator of a feature factory is the turnover in marketing, a particularly gruelling department to be in when you are not finding any consistency with the message you've been tasked with communicating. That kind of situation is okay and perhaps even fun if you can count your colleagues with your fingers, but at companies larger than that, the general lack of understanding of what your software does is a kind of debt, perhaps even classifiable as technical debt. I tried to raise red flags to my bosses when our colleagues in customer support we're making feature requests for features we already had. The company as a whole lacked the courage or enthusiasm to tackle those design flaws, and instead would request additional features. I tried really hard to fight for removing features too...
ericmcer 7y ago
There is also a perverse incentive for employees to point this out. Why would a product manager highlight that the status quo is flawed? Why would an engineer shake stuff up and optimize tired old code instead of just cranking out a shiny new features? Raising these issues would ruffle a lot of feathers. I would not do that just to make my own life more difficult and possibly point out that my own position is redundant.
logicallee 7y ago
I don't know, everyone. All the best software is so great because whatever you want to do, you can find in 1 minute with a Google search. I hate googling and finding "I don't think this is possible. I know you can do this in (a feature factory competitor of what you Googled) but I don't think (what you googled) has this feature." I've seen comments like that thousands of times. Haven't you?
spectramax 7y ago
In this thread: When your whole life is based on assumptions of 98% of it is wrong, you're gonna defend yourself to the tooth. It is emotionally challenging and damaging to the ego. Watch Jim Keller (designer of A4/A4 Apple chips, Ryzen processor, x86 spec co-author and a legendary chip designer) make this point better than I can [Video link copied at 1:22:34 marker]: https://youtu.be/Nb2tebYAaOA?t=4954 https://youtu.be/Nb2tebYAaOA?t=4954 People would say that the author of this post is arrogant and want to reject the status-quo - But I would say the opposite, people who have vested interest in the status-quo because their reputation depends on it, their salary depends on it are the arrogant ones because they reject reality in favor of their own good.
gigatexal 7y ago
Oh man I’ve seen these signs first hand :(
nateburke 7y ago
As the average tenure of an engineer (or PM, for that matter) at many medium-to-large software companies edges towards two years, it is BARELY enough time for the average employee to 1) ramp up on HR stuff/culture, 2) understand the implementation of an existing system, 3) make and deploy a change to the system without incident. Best case, all of that takes 6-9 months, but the reality is more like 12-18. Having time to understand the "why" behind features in a deeply critical way is a LUXURY given this average 2-3 yr time frame. And all of this assumes an absence of reorgs, mission-critical integration work, etc., which further complicate understanding. The reality is that customer needs are changing so rapidly that even CEOs and heads of sales fail to grasp the "why" most of the time, and merely focus on just doing whatever it takes to win the next big contract. "When one can see no future, all one can do is the next right thing."
srmatto 7y ago
Here is the update to this article, 3 years later: https://amplitude.com/blog/12-signs-youre-working-in-a-feature-factory-3-years-later https://amplitude.com/blog/12-signs-youre-working-in-a-featu...
darepublic 7y ago
This sounds like every place I've worked at ever and I don't expect it to change anytime soon
sebringj 7y ago
IMO, this is an ego-centric article. Unless you're trying to change the world...be happy you have a continual stream of work. If they don't have a need to keep you busy that's when you should be worried. As a programmer, I try to keep my employer happy and I don't try to meddle in business decisions. I try to understand them as best as possible and give suggestions or ask questions when things are not clear or don't make sense but knowing that my job is to make the things to match specifications. When I see "feature factory" I initially thought it was good as you are building new things but didn't know it was a negative article until I started reading. I'm grateful in other words as I'm pretty normal, not some bright programmer working at SpaceX.
kwhat4 7y ago
Does this ever not happen? I am being serious... Have any of you worked at a company for any substantial period of time where some for of this has not become the norm?
scottshea 7y ago
I once worked in a place where we spent $100,000+ to add a feature that only two customers used. They paid around $8,000 for the feature. It was deemed a success. Features serve Hope while quantifying the value to customers rains on people's parades
titanomachy 7y ago
I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell us what to build, but acted more as an advisor for the engineering team leads. I think in some case scrum is an attempt to compensate for inexperienced management. I assume we just weren't "doing agile", but when I was younger it always left me feeling vaguely inadequate: if I was just more efficient and competent, maybe the 2-week sprint would fit better. Maybe that was the point. Has anyone here ever delivered useful features to users on that kind of cadence? What was it like?
- ebrewste 7y ago
  When I was doing full stack, solo development, I could get features with real customer value delivered in <= 2 weeks. The flexibility afforded when doing solo development in an area you are competent can unleash some great velocity, but has pretty predictable downsides (can't scale past what you can do yourself, when the project gets big enough, the context switching is a killer, etc.). I don't think I personally have ever hit this level of personal development velocity when working in a group bigger than two people.
- anonsivalley652 7y ago
  Yep. Agile theater often happens when whoever wears (or doesn't) the PM "hat" doesn't have a clue beyond their so-called certifications and amateur "expert" non-experience because they're afraid of appearing incompetent. Then, it reverts to: Big Design Upfront -> Big Deliverables at the End -> sad, expensive fail. Agile means: - Build-test-feedback-adjust loop is as tight as possible... hours or less to get a fix or a quick feature. - The end-users are involve from the beginning to constantly get what they really need (capture good requirements, not necessarily what they ask for directly) and feedback to make usability/feature improvements. - Someone is prioritizing fixes and features from what users need right now to do something useful, rather than arbitrarily shotgunning features in milestones. - Just enough intra-sprint time is dedicated to test improvements, bug hunting and refactoring. - Using continuous integration (CI) and/or continuous deployment (CD). - You are what you measure and post publicly. A giant dashboard in the office to show key metrics like open tickets, who's working on what, app load, app latency, shopping carts/sales, current scaled-infrastructure costs, etc. - Minimum ad-hoc meetings and very few scheduled all-hands. - Let developers focus on one or two tasks rather than constantly interrupting them. Some sort of office GTD system combined with industrial andon light towers to signal: serious concentrating, light work, need to socialize, or not in. - Unless you're building an elevator, fission reactor or an intersellar space ship, be against waterfall development. I'm forgetting a million other things like mindset and differences in processes, but the above is a rough sketch. I do this all the time: It's too easy and too comfortable to get wrapped-up in technologies, methodologies or building out elaborate processes and bussiness-y minutia, which I think is a procrastination / ego defense-mechanism because of a core fear of many people of rejection from the user(s). It's so very easy to build something for yourself, but emotionally more difficult to build things others will see differently.
reddygaru 7y ago
My software engineering course professor made the below statement which has served me well. Users know what they want but they don't know what they need. Figure out your user needs rather than tending to their each want.
emodendroket 7y ago
I mean, let's say I am. So what? As long as the checks are clearing, not my business.
fogetti 7y ago
Sadly this is the case in our company. I worked as a dev team manager for the last 9 months and I was constantly wondering why do we work on these features... The more time I spent with our CEO though, it turned out that he wanted to decide everything feature-wise. When I proposed that we should maybe do some market research or user interviews instead, he boldly declared that he knows the market the best. So go figure. No wonder that the whole company is a shit-show and we're losing a ton of money each year. Also when new features are prioritized I dared to propose to other managers that maybe we should tie the priorities to our business plan. Again our genius CEO told us that the business plan numbers should not be taken very strictly. The more I thought about this why would anyone give money to such a moron, I figured that he is basically a very effective sales person. He can easily convince you how great he is and his vision, but he lacks all kind of strategic or operational skills. And as someone commented here in HN before, he also has management myopia: "If I can't understand it, it must not be hard" he probably thinks. There was even a case when we looked for a product manager. This is not exactly the CEO's fault, but even 8 months were not enough to find one, even though that we interviewed perfectly capable and matching candidates. But there was always at least one person in management who found some excuses to ditch the candidate. Now in hindsight I think these people were afraid that the current status quo of the feature factory would change, so they sabotaged the whole PM candidate screening. So now everything in our company is as it is written in this post. Success theater (this might be the same BTW that is called vanity metrics by Eric Ries), no connection to metrics, no connection to user values, hand-offs, etc.
- texasbigdata 7y ago
  Jesus dude. Maybe you're spot on 100% right in terms of vision, in terms of business plan, in terms of psychological blindspots, in terms of product market fit, in terms of a path to profitability. You seem pretty smart so maybe it is fairly insulting to you to not be listened to. In what way is your world view helpful? And I want to be be gentle here, and not mean harm. In what way is it helpful for yourself, for your own wellbeing? Let's say you could fix the company and stop the losses. Then trying to do that seems worth pursuing. Let's say you can't! We've all come across situations hard and unmoveable. So now, unless some break happens for you (because it's unlikely they will wake up and listen to you if they never did before...just a pragmatic observation), you are stuck being chronicly slightly unhappy. It's not my place to suggest, and I'm trying to respectfully ask, would either maybe letting go or conversely doubling down and standing up for yourself and finding another job where they value you hurt you less? Completly serious question because everyone deserves to be happy. And also, a bit of conjecture, but if you're not profitable it's that same CEOs ability to communicate a vision that's funding payroll right? I'm not saying absolve him of every misgrievance because if the company isn't doing well it's ultimately on his shoulders. My point is maybe there's a softer path to walk here....? Not my place to ask though.
anonytrary 7y ago
I've never heard of this term before, but when I think of "feature factory", products like Jira and Yahoo! immediately come to mind. Such products feel like a sinking bag of features with no real cohesive, central purpose.
luord 7y ago
Most of the points come from disregarding the cardinal rule that every developer and development company should abide to (obligatory IMO): Fight for the users. In this case, you can't fight for them if you don't know what they want or how the product is helping them.
pugworthy 7y ago
Dear lord this is depressing to read. My personal annecdote here that's probably not a big contribution, but this puts a label so well on the product organization I just left on a large project @ a fortune 50 company. What's really bad is that the much larger R&D organization (who is I now know to label a feature factory), absorbed our smaller highly productive team that essentially did everything opposite to this. The things we thought we were good at were suddenly the huge flaws of our team - flaws that lead to a number of us leaving to get away from the huge amount of process that got laid on us.
filterfish 7y ago
Twelve out of twelve for my company. Yah us!
dennisgorelik 7y ago
1) When John Cutler (https://www.linkedin.com/in/johnpcutler/ https://www.linkedin.com/in/johnpcutler/) wrote this article in 2016 - he was working for pendo.io that already got ~$13.3M in funding: https://www.crunchbase.com/organization/pendo-io#section-funding-rounds https://www.crunchbase.com/organization/pendo-io#section-fun... Eventually pendo.io accumulated $208.3M in funding. 2) John Cutler now works for Amplitude (pendo.io competitor) that received $136M in funding: https://www.crunchbase.com/search/funding_rounds/field/organizations/funding_total/amplitude https://www.crunchbase.com/search/funding_rounds/field/organ... 3) Amplitude looks more successful than pendo: https://www.similarweb.com/website/amplitude.com https://www.similarweb.com/website/amplitude.com https://www.similarweb.com/website/pendo.io https://www.similarweb.com/website/pendo.io

1002 points by aphextron 7y ago

CameronNemo 7y ago

What do I do if upper management seems to be driving this process?

layoutIfNeeded 7y ago
Bail asap.
wefarrell 7y ago
Where this exists it's usually driven by management, especially #12. The fix is to shift focus towards measurements and a longer timeline. It's really hard to change management's focus, but you can implement that mindset for your and your teams work and once management sees the benefits it will be easier to convince them it's worth adopting.
ipnon 7y ago
If your input regarding how the company is run is valued by upper management, then make a clear argument that they are running a feature factory and what they can do to change. If no one cares what you think, then the best outcome for yourself and the your company is for you to find other employment. You labor is freed from the feature factory for more productive purposes and the probability of survival for your sub-optimal company is diminished, opening opportunities for more optimal companies in the same space.

rubyfan 7y ago

Much of this describes some of my past experience at a Fortune 100. That company is now undergoing much discussion at a senior level about agile delivery. Senior executives are walking around talking about tribes and chapters and have no idea what that really means or of the day to day work of teams. It’s unfortunate what will come out of it in the end is some people doing stuff now that will have new titles and maybe more ceremonies but not a substantive change from what they do now or the way work gets done. Middle management thinks they work in a factory and treat people like numbers. If you trust the same group of people to implement the change then you can bet their sole goal is to make it look good. Unless you change the middle then not much will change.

tuanis 7y ago
I actually feel like agile development can invite some of this behavior, because the focus is on shipping instead of value. Not saying agile is bad, just feels like a separate problem.
- SpicyLemonZest 7y ago
  In principle agile is supposed to be guided by higher level processes accounting for this kind of strategic problem. In practice, yeah, I do sometimes see agile teams get away with writing "objective: ship my features, KR: 5 features are shipped".
itronitron 7y ago
I'm waiting for the inevitable open office plan that has a conveyor along it's primary axis for moving white boards along the production path, like in a modern factory. There can be a sub-team that programs robotic arms to sketch things on the white boards as they pass each stage.

ttoinou 7y ago

What's wrong with feature factory ? If you're delivering something good for clients.. No measurement / Success theater / core metrics This takes time and mental space. That you could better use to... crank a new feature! :)

scribu 7y ago
> If you're delivering something good for clients... That's the crux of it, isn't it? How do you know that what you're delivering is any good?
- LaGrange 7y ago
  Depending on the customer and the work, I might not — or, to be more precise, I might only know some aspects of the product's quality based on what the customer tells me. Or I might only directly know whether certain aspects of what I'm doing are good. Arguably that's actually always the case, but if you're doing consumer-oriented mass-market stuff, then it's quite possible that "what the producer knows" overwhelms what the "customer" knows. But not all software is something you can dogfood or A/B test, and software developers are _very_ quick to assume that they know better than customers, especially if the customer is in some way locked-in.
- lazyjones 7y ago
  > How do you know that what you're delivering is any good? How do you know it isn't? You need to implement it and see whether it's good or not.
  - dillonmckay 7y ago
    If you know it is going to be a nightmare to support, it will consume tons of resources (cpu/storage), and nobody wants to pay for it (or not pay enough to cover its costs), it is not good. As has been mentioned many times on this site, it is very easy to sell $2 for $1 all day long.
    - 7y ago

marstall 7y ago

unfortunately this is almost every place i've ever worked. so many good points here - but the most poignant for me is "celebrating shipping" vs celebrating customer success ... so true

johnkarahalis 7y ago

Feature 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 and more and more for no real benefit. I've quoted this before, but what Don Norman says in The Invisible Computer still applies: "Don’t ask people what they want. Watch them and figure out their needs. If you ask, people usually focus on what they have and ask for it to be better: cheaper, faster, smaller. A good observer might discover that the task is unnecessary, that it is possible to restructure things or provide a new technology that eliminates the painstaking parts of their procedures. If you just follow what people ask for, you could end up making their lives even more complicated."

Alex3917 7y ago
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.
- cgriswald 7y ago
  > Those specific users won't use it anyway even if you add it I think people read this and think, "Why bother, then?" As someone who is often this user, I don't end up using your product because I've already moved onto a competing product or service; or because I never hear that you have added the feature. Whether your metrics move after adding the feature might be a matter of timing. There's also the chance I will come to your product in the future. Hypothetically, let's say you offer a password vault application, but I dislike it because it lacks a feature I want, so I end up going with your competitor who offers the feature. You add the feature, but I don't switch because I'm now content with your competitor. Later, your competitor starts pushing towards a subscription model while simultaneously showing a real lack of professionalism and social grace towards customers in public. Since you've added the feature that I thought was lacking, your product might now be an option for me. If you haven't added the feature, there's still no chance.

thomas 7y ago

In this framing, a factory is supposed to be bad? Aren’t factories efficient and the best way of producing things at scale?

gfody 7y ago
when it comes to software you do not want to produce code at scale. the fewer lines of code the better really. it'd be like measuring the quality of your genome by counting the rungs in your dna.
vertex-four 7y ago
Which is great, so long as they're not just creating debt for themselves by e.g. creating broken products that have to be recalled to be fixed by the factory.
mongol 7y ago
A factory can produce almost anything at scale, but how do you know it is worthwhile and providing the best possible value? In a "bad" factory, the "factory workers" are like cogs in a machine and have no influence over what is built. There is someone ordering to build this or that and they produce it. Feature factory is in this terminology should be seen as opposed an alternative process, where the "factory workers" themselves decide what to produce and how, and as long as the measured value stacks up, it will be more efficient and derive more shareholder value than the "feature factory".
mr_tristan 7y ago
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.
jrockway 7y ago
Factories are fine, but if you walk into a factory you're going to be finding a lot of people working on the factory itself. Process tweaks, new machines, maintenance, etc. In the software "feature factory", people have mostly forgotten about that, usually because someone does it "in their spare time". I guarantee you that no factory worker lubricates the machines off the clock. I am not sure why we should treat software any differently.

davzie 7y ago

I 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.

SpicyLemonZest 7y ago
The problem is that, if you're churning out features without thinking critically about why, your work might not even change the company. I've seen engineers, teams, even entire departments spend multiple quarters being a net drain on the company. But they never noticed, because they kept consistently defining release targets and hitting them.
- lazyjones 7y ago
  > churning out features without thinking critically about why, your work might not even change the company Isn't this just speculation? Why would anyone build features without any thoughts about their benefit? In practice you never know how a feature is going to work out and benefit or harm the company, you just have to try it. Not trying is a sure way to lose to bolder competition.
  - SpicyLemonZest 7y ago
    There are a couple reasons I've seen why you'd do that. I'm sure there are others I haven't seen. * Sometimes companies have declared focus areas, and it's advantageous to be working in those areas. If the CEO says Project Foobar is going to be the next big thing, you want your team to be touching Project Foobar even if you have nothing valuable to contribute. * Some kinds of projects are costly to push back on. If someone comes to you and says "this is a security feature, I'm going to build it to increase security", you have to demonstrate that the system is secure without it and not just tell them no. * In some environments, people are measured by their ability to produce lots of features. This makes it embarrassing and politically damaging to not do a feature you proposed. So once it's publicly known that you have a feature, it's too late to think about whether it's useful, you have to just buckle down and do it.

gfodor 7y ago

Somebody 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.

gfody 7y ago
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.
- gfodor 7y ago
  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.
  - gfody 7y ago
    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.
SpicyLemonZest 7y ago
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?

redwood 7y ago

This seems written by someone with an axe to grind.

BossingAround 7y ago
Don't we all have axes to grind?

Orcus90482 7y ago

I’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.

funfunfunction 7y ago

Feature addiction is exacerbated by VC. Without real consequences to a poorly planned product roadmap due to the years of runway afforded by massive funding rounds, entire orgs fall into the “one more feature” cycle and never focus enough on measuring success in terms of real dollars. No one knows what went wrong when all the money is gone and devs/designers/PMs rinse and repeat at a new well-funded startup.

borski 7y ago
This actually isn’t true. VCs don’t want companies to build features, they want companies to listen to users maniacally and find product-market fit, then focus on growth (and/or revenue) like mad. That companies focus on features is a management issue and a sign of a failing company, not a sign that VC is somehow bad.
- funfunfunction 7y ago
  I agree that the issue is a problem of management. Though without oodles of cash to wash away missteps, poor management would be much more obvious. The ability to distill user feedback into the minimum number of valuable feature enhancements is what sets successful product orgs apart from failed ones. When cash is largely not a constraint, the tendency is to build exactly what each customer has said they want rather than try to come up with succinct improvements. The result is often bulky products that cost a fortune to maintain and only appeal to small number of customers. VC is good if used correctly. But dumping wads of cash into a company to develop a product that isn’t capital intensive (like web or mobile tech) has the tendency to create bloated product orgs which optimize for the wrong things.
- whateveracct 7y ago
  Planning and building new features allows you to pad your slide deck tho

lr4444lr 7y ago

Sigh... At some point, most healthy adults who are not living in terrible circumstances come to the mature realization and compromise that their job is largely to produce value for someone else, not to be the primary source of personal fulfillment, and they come to understand that there is dignity in being productive, if not creative. Be creative on your own time. Lead a civic group. Be a good parent. Volunteer at a charity. If your main gripe at work is that you're on the value-adding side of a company, which is what feature dev is in software, you have it pretty good in this world. Change jobs if you must, but the realities of companies, especially as they gain traction, rarely means the grass is ever greener. If this is unsatisfactory still, start your own company. I just don't understand the problem here.

lifeisstillgood 7y ago
True. But imagine if you are also a shareholder in such a company - would you not want them to fix it?
draw_down 7y ago
> Change jobs if you must Or if a new job can offer you a better deal. If these jobs are all interchangeable, then you may as well interchange them for what benefits you most.
braindongle 7y ago
Disagree. This is an endorsement of accepting the fact that your work, your professional work, done by most of us at a job, makes you feel like a cog, a unit of production. It is better called a surrender than a compromise. Surely it's often case that life has people in this sort of scenario and there is no realistic way to a new path. In that case, sure, take care of your loved ones and yourself, stay put, and make the most of it. This scenario arises from the messy mix of circumstances and decisions. There is no blame. But! "Change jobs if you must", must, be changed to "Change jobs if you can.", especially for younger people. It's not mature to accept an unfulfilling job. It's a life-scale bummer. Tenaciously go after fulfilling work. Don't write off 1/3 of your remaining life. An approach that worked for me: distance yourself from the profit motive. It's not that hard.

ryandrake 7y ago

I'm surprised by so many negative comments here (actually, I'm not). This great piece summed up a lot of awful aspects about commercial software development that I've also observed over the past 20 years, but have been unable to organize together and articulate as single problem. People are asking why this is bad. One way to think about why the Feature Factory is bad is that it's mostly open loop: You "launch" feature after feature at the customer, but there's no real feedback coming in to understand whether what you're doing is worthwhile, to understand what to improve or fix, or to drive future decisions. The only feedback that gets measured are things like revenue and sales, and the only thing leadership sees as driving revenue is the constant spew of features--because that's all you're doing. The insights that you get from revenue are very generic: "Money is coming in--keep doing what you're doing" or "We're losing money. Do something different!". The insights you get from salespeople are even worse: "We'll land this sweet-ass deal (and I'll get my bonus) if only you churn out otherwise un-needed features X, Y, and Z!" I guess this is fine if you're an agency or consulting shop that just does one-off projects and then moves on to the next client. On the other hand, if you're writing software for actual people to use, trying to be the best in class at one thing, or building a platform to last decades instead of months, then your product will suffer if all you do is bolt half-baked features onto it over and over.

BossingAround 7y ago
I think the reason why I was confused is that it seems there's a very fine line between a feature factory and Google/Twitter/Facebook/Amazon/... At a lot of these high-functioning places, they seem to have "feature factory" moments with some tweaks (e.g. actually building metrics, refactoring, etc. so that the SW won't implode in 6 months down the line).
- dillonmckay 7y ago
  People complain about it, but Google being able to literally ‘pull the plug’ and shutdown unprofitable or disproportionately resource draining projects is important to note. To me, that is a characteristic of the un-feature factory, or whatever the opposite would be called.

PragmaticPulp 7y ago

I suggest re-reading this article in the negative: Assume that your team implemented every single one of these bullet points perfectly, for every feature in every sprint. Now imagine that each of those bullet points is a recurring meeting invite on your calendar. Now imagine how happy you'd be spending all of that time in meetings or reading process-related e-mails so your company could satisfy the criteria of not being a feature factory. Does a feature factory sound so bad now? I thought this article was great when it first came out, but I've since changed my mind. I've seen too many engineers, especially junior engineers, become overly cynical about their jobs after reading too much into this one article. 1) With 12 different "signs" of a feature factory, it begins to read like a horoscope: Almost everyone reading it can find something to identify with. Multiply this across every different project or initiative at a company, and everyone can think of multiple times their job has resembled the descriptions in this article. Does anyone actually read this article and walk away thinking their company has never once resembled the vague signs in the article? 2) It begins with an implied assumption that working in a feature factory is a bad thing. Combine that with the horoscope-like 12 possible indicators of a feature factory, and the reader will always conclude that their workplace is the bad thing. 3) It sets unrealistically high standards. The alternative to a "feature factory" is defined in the negative in this article. Can you think of any company that would score a perfect 12/12 on every bullet point in this article across every team in every department? The process overhead would be significant, and it would very easily translate to a lot of meetings, e-mails, and overhead. The kernel of truth within the article is still very valid. Teams should absolutely take the points into consideration and apply them judiciously, where it matters. However, it's a mistake to use this article as a checklist by which to judge your company's process. Real work is always a bit messy, communication is never perfect, and just because you don't see these things with your own two eyes doesn't mean they aren't happening somewhere in the company. As a product manager, suggestions are always welcome and I'm happy to discuss reasoning for decision making, but I also don't burden the entire team with every detail of every step of the way.

whatshisface 7y ago
Most of the points in this article are relative, for instance what does it really mean to have no care for technical debt drawdown? How much care is not enough? However, one thing that it's specific about is the lack of measurement. There are some companies out there that have zero focus on customer feedback, and since there's only one zero, that indictment is not relative to people's expectations.

lifeisstillgood 7y ago

At a certain company size, there simply is not the level of control (ODA loops) to know what product to make or features to add - it is a fairly good survival strategy to have multiple teams duplicating huge amounts of work simply because a few will deliver the right thing. The internal politics of most organisations has a similar feel - lots of duplication looks like competing camps and frequently is, but the duplications is partly survival strategy (what if those others don't deliver) and partly evolution (one team will deliver something that actually fits the market.) Boy there are better ways to arrange it, but this seems to be a local maxima that's easy to reach.

antoineMoPa 7y ago

I'd rather work in a feature factory than a bugfix factory.

samyel 7y ago
Eventually a feature factory will turn into a bugfix factory as more and more unmaintained and potentially competing layers are added.
- gfody 7y ago
  ..or some features are actually bugs, now your a bug farmer.
wutwutwutwut 7y ago
I on the other hand prefer fixing bugs over implementing features which not even the product manager can explain to me why the customer need.

xyst 7y ago

To a certain degree, and in my experience, all companies have this problem. Sometimes it’s at a team scale but for others it’s at an organization scale.

anonu 7y ago

This just sounds like regular software development.

adamzapasnik 7y ago

I worked at that kind of company, wouldn't recommend it to anyone. I could write a very long essay why it sucked so much, meh. In short, it's very easy to burn out and overall it's just stupid. The pace was surreal, some of the features very complex, many people were overworking. Everyone is super stressed out, the best decision is to just leave that environment. Bottom line, don't work for that kind of companies, because your value is equal to the speed of your fingers typing.

michaelfeathers 7y ago

Great article. It should add Technical Debt as a sign.

numbers 7y ago

Yes! Very well put together list because at my last role (in the same company) this was essentially what I was trying to escape and when I look at the work that team is doing, it’s not impactful or noticeable but the devs are always building some new complex thing that won’t even see the light of day once. On my current team, feature building is the second to last step (right before a retro) because product development requires many non-coding steps to first understand problem. Some times, I believe it should be “problem solving” instead of “product development”.

jugg1es 7y ago

I'm part of the technical leadership at a company who is transitioning from small to medium-sized company. This article is disparaging virtually all of the initiatives we're trying to actually implement. It's actually really hard to transition from anarchy into a more process-oriented where each person has a role to play so that Devs are no longer responsible for literally everything because everyone is used to Devs doing everything. PMs used to verbally communicate vague ideas of what the customer was looking for and it was up to us to interpret and decompose and deliver on dates agreed upon without our input. There is a reason that the points in this article exist at all - because the alternative is actually worse!

codingdave 7y ago
It is a question of balance. Don't do a process just for the sake of the process. Don't do a feature just for the sake of doing a feature. If you cannot tie those things to actual business goals, that is when you have a problem.
mceachen 7y ago
The article is not saying "big feature" pipelines (where there is coordination across several teams) are inherently bad. The article is disparaging that process if it is the only process. (And I've worked at companies where this was nearly true). There must be efforts to experiment and refine (and possibly remove) existing features. There must be efforts to refactor and improve existing code, to make it easier to maintain, less painful to be on-call, and make it possible to add subsequent features without breaking existing functionality. You have to be able to do both large and incremental work to improve, in other words.
- tomnipotent 7y ago
  > There must be efforts to refactor and improve existing code Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly. This has yet to fail me. Granted, I don't work in embedded systems and my code is deployed on owned & operated servers that's easy to update.

annoyingnoob 7y ago

I've heard this called 'being on the hamster wheel', you are running forward as fast as you can but not going anywhere. I've had an experience where I dreaded the daily stand-up, it was all about 'story points' in a mad scramble to find traction with customers. Management was stabbing in the dark, we didn't have a direction. Once we did have a direction we lacked the required input to push us in that direction.

pyb 7y ago

It's very interesting to see a huge cultural gap within the tech industry, from many of the comments here. Quite a few people are saying : what's so bad about the feature factory ? This sounds like a desirable environment. Whereas I, and many others here, see it as a living nightmare of endless busywork and improductivity. (I've once worked in an environment a bit like that, so I know they actually exist.)

joegahona 7y ago
I agree and think it’s a divide between product and engineering. Product managers (at least good ones) love thinking about the problem, while developers love thinking about solutions. I’m generalizing of course, and both mindsets are needed, but it’s the product manager’s job to make sure the developers are solving the right problems and not just launching features that don’t speak to a customer benefit.

squirrel 7y ago

[2016]. Previous discussions on HN: https://news.ycombinator.com/item?id=13639549 https://news.ycombinator.com/item?id=13639549 https://news.ycombinator.com/item?id=13044685 https://news.ycombinator.com/item?id=13044685 Very good article, so good that my coauthor and I used the metaphor in our book.

_drimzy 7y ago

Ah man. This makes me realize why my time at a recently IPO-ed tech company, as an engineer was so horrible. Except #10 the company is guilty of every single point.

dragonwriter 7y ago

While this focusses on places selling software (features added to close deals, etc.), it is probably an even more pervasive problem in internal IT shops—and a more tragic one, because internal IT organizations should be better positioned to tightly align on business value rather than sales, though this is often hampered by internal organizational structures which sometimes incentivize arms length, contracting-like interactions.

awinter-py 7y ago

> success theater such a good phrase. premature 'mission accomplished' is always embarrassing even when you're just the one stuck cringing and golf clapping in the corner Common thread here seems to be lack of argument / buy-in process. Central leaders need to (1) convince the team that tactics accomplish team goals and (2) have team goals. Bad teams do none of the above.

0xff00ffee 7y ago

I've had to make the decision to steer my design resources into "feature factories" because my customers are sometimes fickle. There are a number of instances where features were paid for, developed, and then not deployed. It hasn't become discouraging yet because there has been professional growth in developing methods for constructing and deploying said features, but I am concerned as to our financial ability to identify and reject contracts that are just un-exciting features. Most of my devs are satisfied with the paycheck despite the work, but a few are showing signs of not being valued. And I'm not sure how to address that yet to avoid losing them. It's like: taking a lame contract for $$$ vs. boring a good employee. I hate how personal it becomes, I feel like I'm cajoling them to do the work, ... it feels icky and toxic.

sfink 7y ago
I dunno, if I were an engineer in an environment like that I'd be fine with it if (1) you were up-front about this being a necessary hack to sustain the company for a bit longer, and (2) there is a vision and a process to refine that vision of where you would all like the product to go. (2) is so that these seemingly short-term features could either be seen as prototypes or first cuts at the future you'd really like to get to, or walled off as extraneous stubs that don't interfere with the core architecture. (1) is important because I feel good about helping keep the company afloat, but I feel crappy about just doing stuff that I know is bullshit simply because I'm told to (or worse, lied to that it's "important" for its own sake). This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Communicate that decision and why you made it to engineering; we love to hear that sort of thing. The safest answer that a salesperson can give is "yes". The safest answer that an engineer can give is "no". You can't let either side always win, but you can communicate the reasoning and importance to bridge the gap and make it a team decision even if it wasn't the team making it.
- 0xff00ffee 7y ago
  Thanks for the feedback. That's pretty much how the discussions go. The team is small so I can still be 1:1 with them, and be direct about the state of things. >This also makes it possible to track the trajectory of the company over time. When you're doing better, you can afford to turn down these types of requests. Yeah, this is a really good indicator. Heck, if this keeps up -I- won't want to do it anymore! Which I think is perfectly natural.

metalgearsolid 7y ago

Been there. Anecdotally, a good indicator of a feature factory is the turnover in marketing, a particularly gruelling department to be in when you are not finding any consistency with the message you've been tasked with communicating. That kind of situation is okay and perhaps even fun if you can count your colleagues with your fingers, but at companies larger than that, the general lack of understanding of what your software does is a kind of debt, perhaps even classifiable as technical debt. I tried to raise red flags to my bosses when our colleagues in customer support we're making feature requests for features we already had. The company as a whole lacked the courage or enthusiasm to tackle those design flaws, and instead would request additional features. I tried really hard to fight for removing features too...

ericmcer 7y ago

There is also a perverse incentive for employees to point this out. Why would a product manager highlight that the status quo is flawed? Why would an engineer shake stuff up and optimize tired old code instead of just cranking out a shiny new features? Raising these issues would ruffle a lot of feathers. I would not do that just to make my own life more difficult and possibly point out that my own position is redundant.

logicallee 7y ago

I don't know, everyone. All the best software is so great because whatever you want to do, you can find in 1 minute with a Google search. I hate googling and finding "I don't think this is possible. I know you can do this in (a feature factory competitor of what you Googled) but I don't think (what you googled) has this feature." I've seen comments like that thousands of times. Haven't you?

spectramax 7y ago

In this thread: When your whole life is based on assumptions of 98% of it is wrong, you're gonna defend yourself to the tooth. It is emotionally challenging and damaging to the ego. Watch Jim Keller (designer of A4/A4 Apple chips, Ryzen processor, x86 spec co-author and a legendary chip designer) make this point better than I can [Video link copied at 1:22:34 marker]: https://youtu.be/Nb2tebYAaOA?t=4954 https://youtu.be/Nb2tebYAaOA?t=4954 People would say that the author of this post is arrogant and want to reject the status-quo - But I would say the opposite, people who have vested interest in the status-quo because their reputation depends on it, their salary depends on it are the arrogant ones because they reject reality in favor of their own good.

gigatexal 7y ago

Oh man I’ve seen these signs first hand :(

nateburke 7y ago

As the average tenure of an engineer (or PM, for that matter) at many medium-to-large software companies edges towards two years, it is BARELY enough time for the average employee to 1) ramp up on HR stuff/culture, 2) understand the implementation of an existing system, 3) make and deploy a change to the system without incident. Best case, all of that takes 6-9 months, but the reality is more like 12-18. Having time to understand the "why" behind features in a deeply critical way is a LUXURY given this average 2-3 yr time frame. And all of this assumes an absence of reorgs, mission-critical integration work, etc., which further complicate understanding. The reality is that customer needs are changing so rapidly that even CEOs and heads of sales fail to grasp the "why" most of the time, and merely focus on just doing whatever it takes to win the next big contract. "When one can see no future, all one can do is the next right thing."

srmatto 7y ago

Here is the update to this article, 3 years later: https://amplitude.com/blog/12-signs-youre-working-in-a-feature-factory-3-years-later https://amplitude.com/blog/12-signs-youre-working-in-a-featu...

darepublic 7y ago

This sounds like every place I've worked at ever and I don't expect it to change anytime soon

sebringj 7y ago

IMO, this is an ego-centric article. Unless you're trying to change the world...be happy you have a continual stream of work. If they don't have a need to keep you busy that's when you should be worried. As a programmer, I try to keep my employer happy and I don't try to meddle in business decisions. I try to understand them as best as possible and give suggestions or ask questions when things are not clear or don't make sense but knowing that my job is to make the things to match specifications. When I see "feature factory" I initially thought it was good as you are building new things but didn't know it was a negative article until I started reading. I'm grateful in other words as I'm pretty normal, not some bright programmer working at SpaceX.

kwhat4 7y ago

Does this ever not happen? I am being serious... Have any of you worked at a company for any substantial period of time where some for of this has not become the norm?

scottshea 7y ago

I once worked in a place where we spent $100,000+ to add a feature that only two customers used. They paid around $8,000 for the feature. It was deemed a success. Features serve Hope while quantifying the value to customers rains on people's parades

titanomachy 7y ago

I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell us what to build, but acted more as an advisor for the engineering team leads. I think in some case scrum is an attempt to compensate for inexperienced management. I assume we just weren't "doing agile", but when I was younger it always left me feeling vaguely inadequate: if I was just more efficient and competent, maybe the 2-week sprint would fit better. Maybe that was the point. Has anyone here ever delivered useful features to users on that kind of cadence? What was it like?

ebrewste 7y ago
When I was doing full stack, solo development, I could get features with real customer value delivered in <= 2 weeks. The flexibility afforded when doing solo development in an area you are competent can unleash some great velocity, but has pretty predictable downsides (can't scale past what you can do yourself, when the project gets big enough, the context switching is a killer, etc.). I don't think I personally have ever hit this level of personal development velocity when working in a group bigger than two people.
anonsivalley652 7y ago
Yep. Agile theater often happens when whoever wears (or doesn't) the PM "hat" doesn't have a clue beyond their so-called certifications and amateur "expert" non-experience because they're afraid of appearing incompetent. Then, it reverts to: Big Design Upfront -> Big Deliverables at the End -> sad, expensive fail. Agile means: - Build-test-feedback-adjust loop is as tight as possible... hours or less to get a fix or a quick feature. - The end-users are involve from the beginning to constantly get what they really need (capture good requirements, not necessarily what they ask for directly) and feedback to make usability/feature improvements. - Someone is prioritizing fixes and features from what users need right now to do something useful, rather than arbitrarily shotgunning features in milestones. - Just enough intra-sprint time is dedicated to test improvements, bug hunting and refactoring. - Using continuous integration (CI) and/or continuous deployment (CD). - You are what you measure and post publicly. A giant dashboard in the office to show key metrics like open tickets, who's working on what, app load, app latency, shopping carts/sales, current scaled-infrastructure costs, etc. - Minimum ad-hoc meetings and very few scheduled all-hands. - Let developers focus on one or two tasks rather than constantly interrupting them. Some sort of office GTD system combined with industrial andon light towers to signal: serious concentrating, light work, need to socialize, or not in. - Unless you're building an elevator, fission reactor or an intersellar space ship, be against waterfall development. I'm forgetting a million other things like mindset and differences in processes, but the above is a rough sketch. I do this all the time: It's too easy and too comfortable to get wrapped-up in technologies, methodologies or building out elaborate processes and bussiness-y minutia, which I think is a procrastination / ego defense-mechanism because of a core fear of many people of rejection from the user(s). It's so very easy to build something for yourself, but emotionally more difficult to build things others will see differently.

reddygaru 7y ago

My software engineering course professor made the below statement which has served me well. Users know what they want but they don't know what they need. Figure out your user needs rather than tending to their each want.

emodendroket 7y ago

I mean, let's say I am. So what? As long as the checks are clearing, not my business.

fogetti 7y ago

Sadly this is the case in our company. I worked as a dev team manager for the last 9 months and I was constantly wondering why do we work on these features... The more time I spent with our CEO though, it turned out that he wanted to decide everything feature-wise. When I proposed that we should maybe do some market research or user interviews instead, he boldly declared that he knows the market the best. So go figure. No wonder that the whole company is a shit-show and we're losing a ton of money each year. Also when new features are prioritized I dared to propose to other managers that maybe we should tie the priorities to our business plan. Again our genius CEO told us that the business plan numbers should not be taken very strictly. The more I thought about this why would anyone give money to such a moron, I figured that he is basically a very effective sales person. He can easily convince you how great he is and his vision, but he lacks all kind of strategic or operational skills. And as someone commented here in HN before, he also has management myopia: "If I can't understand it, it must not be hard" he probably thinks. There was even a case when we looked for a product manager. This is not exactly the CEO's fault, but even 8 months were not enough to find one, even though that we interviewed perfectly capable and matching candidates. But there was always at least one person in management who found some excuses to ditch the candidate. Now in hindsight I think these people were afraid that the current status quo of the feature factory would change, so they sabotaged the whole PM candidate screening. So now everything in our company is as it is written in this post. Success theater (this might be the same BTW that is called vanity metrics by Eric Ries), no connection to metrics, no connection to user values, hand-offs, etc.

texasbigdata 7y ago
Jesus dude. Maybe you're spot on 100% right in terms of vision, in terms of business plan, in terms of psychological blindspots, in terms of product market fit, in terms of a path to profitability. You seem pretty smart so maybe it is fairly insulting to you to not be listened to. In what way is your world view helpful? And I want to be be gentle here, and not mean harm. In what way is it helpful for yourself, for your own wellbeing? Let's say you could fix the company and stop the losses. Then trying to do that seems worth pursuing. Let's say you can't! We've all come across situations hard and unmoveable. So now, unless some break happens for you (because it's unlikely they will wake up and listen to you if they never did before...just a pragmatic observation), you are stuck being chronicly slightly unhappy. It's not my place to suggest, and I'm trying to respectfully ask, would either maybe letting go or conversely doubling down and standing up for yourself and finding another job where they value you hurt you less? Completly serious question because everyone deserves to be happy. And also, a bit of conjecture, but if you're not profitable it's that same CEOs ability to communicate a vision that's funding payroll right? I'm not saying absolve him of every misgrievance because if the company isn't doing well it's ultimately on his shoulders. My point is maybe there's a softer path to walk here....? Not my place to ask though.

anonytrary 7y ago

I've never heard of this term before, but when I think of "feature factory", products like Jira and Yahoo! immediately come to mind. Such products feel like a sinking bag of features with no real cohesive, central purpose.

luord 7y ago

Most of the points come from disregarding the cardinal rule that every developer and development company should abide to (obligatory IMO): Fight for the users. In this case, you can't fight for them if you don't know what they want or how the product is helping them.

pugworthy 7y ago

Dear lord this is depressing to read. My personal annecdote here that's probably not a big contribution, but this puts a label so well on the product organization I just left on a large project @ a fortune 50 company. What's really bad is that the much larger R&D organization (who is I now know to label a feature factory), absorbed our smaller highly productive team that essentially did everything opposite to this. The things we thought we were good at were suddenly the huge flaws of our team - flaws that lead to a number of us leaving to get away from the huge amount of process that got laid on us.

filterfish 7y ago

Twelve out of twelve for my company. Yah us!

dennisgorelik 7y ago

1) When John Cutler (https://www.linkedin.com/in/johnpcutler/ https://www.linkedin.com/in/johnpcutler/) wrote this article in 2016 - he was working for pendo.io that already got ~$13.3M in funding: https://www.crunchbase.com/organization/pendo-io#section-funding-rounds https://www.crunchbase.com/organization/pendo-io#section-fun... Eventually pendo.io accumulated $208.3M in funding. 2) John Cutler now works for Amplitude (pendo.io competitor) that received $136M in funding: https://www.crunchbase.com/search/funding_rounds/field/organizations/funding_total/amplitude https://www.crunchbase.com/search/funding_rounds/field/organ... 3) Amplitude looks more successful than pendo: https://www.similarweb.com/website/amplitude.com https://www.similarweb.com/website/amplitude.com https://www.similarweb.com/website/pendo.io https://www.similarweb.com/website/pendo.io