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."
Also, some of my favorite quotes on this subject:
You listen to all your fans and they always say "You should add this" or "You should add that." They never say "Take this out, take that out." They say "add more, add more!" There's an old saying that I love about design, it's about Japanese gardening actually, that "Your garden is not complete until there is nothing else that you can remove." I think a lot of designers think the opposite way - "What else can we add to the game to make it better?" -Will Wright
"People don’t know what they want until you show it to them.” -Steve Jobs
"Writers and people who had command of words were respected and feared as people who manipulated magic. In latter times I think that artists and writers have allowed themselves to be sold down the river. They have accepted the prevailing belief that art and writing are merely forms of entertainment. They’re not seen as transformative forces that can change a human being; that can change a society. They are seen as simple entertainment; things with which we can fill 20 minutes, half an hour, while we’re waiting to die.
It’s not the job of the artist to give the audience what the audience wants. If the audience knew what they needed, then they wouldn’t be the audience. They would be the artists. It is the job of artists to give the audience what they need." -Alan Moore
― Antoine de Saint-Exupéry, Airman's Odyssey
Both cater to different markets but achieve simplicity within their markets well.
I only mean to say at least a few fans are actively asking for things to be removed, simplified, and (thoughtfully) refined.
Or so I can reason around that logic anyhow.
To be more clear: I only want to see the balances from specific accounts. The two chequing accounts in this case.
I don’t want to see the savings account that has a slowly (and automatically) increasing balance because then I subconsciously count that as “too much” and think things like “I could spend a little and it wouldn’t make a big difference”.
To be fair, I’m also working hard at shifting my brain after a lifetime of ‘paycheque to paycheque’ patterns and it’s not enjoying the shift.
The benefit of having it in a separate bank is that it hugely increases friction when you start thinking about spending it, since you have to move it back to your primary first. You can mostly forget about the specific numbers in it as well since it isn’t visible in your primary bank dashboard.
I just looked and there are other options available. I think this might be the excuse for me to go to Wealthsimple and start taking a more active role in making that money do some work.
You’re right for sure, and I do find benefit in the account overview, it’s just that I only want to see the “spending” accounts, and not the long-term savings accounts.
Much like it might change your financial choices if your bank overview also showed your available credit (instead of the balance owing) and a realtime update of home equity.
The replies I made to other users will hopefully clear it up.
(Not affiliated, just a happy customer that finally broke decades of bad financial habits due to this app and its attendant personal finance philosophy.)
That’s why I was frustrated when they changed from a summary of chequing account balances to a full “dashboard” that showed all accounts.
Up until then I was doing awesome avoiding the “I’m flush with cash” triggers because I was only seeing my actual spending money and not the bills account, the rent account, and the various proactive savings accounts.
Essentially I had all the benefits of YNAB principles because of the tools Tangerine provided
- 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.
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.
Betting on eventual competitor's incompetence in the future - is not a reliable strategy.
In such situation it may be better to implement that feature only when entrenched competitor with that feature will start pushing their customers away.
A smart purchaser will define their purchasing criteria based on the needs of their users, but in practice, I’ve found that some haven’t done an accurate job of determining their users needs, and/or inject their own agendas into the requirements.
It can give false negatives, especially with future looking and platform-type work, but it's a great heuristic for weeding out useless feature work
These users often understand what features are missing because they rely on them in other products. At that point your product is already dead to them.
It gets worse when you have a specialist of a given field consulting you on how to build software with his field in mind.
“A fish doesn’t think of water” is a fitting quote I once heard.
All you can do is observe, tweak and test.
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!
This article describes the last company I worked for very well: that company was and is struggling precisely because the senior leadership promoted a culture of feature releases without consideration for their impact and consistently changing the focus of feature development not based on data, but whim, so that the product was steadily losing focus and coherence.
I just wrote about this yesterday (https://teamsuccess.io/hdd). I work as a consultant with lots of Scrum teams, and many devs feel like they're just sitting in the factory, cranking out features. Without knowing whether they're adding real value to the end-user.
So what can you do to break free from the feature factory? Something that I recommend for the teams I work with, and noticed that actually works, is "Hypothesis-Driven Development".
In short, replace the items in your product backlog with experiments rather than user stories. Instead of starting with a user story or epic, start with a testable hypothesis. Then run small experiments that will prove or disprove that hypothesis.
My favorite question nowadays is "Wait, why are we building this feature again?" :)
"Add keyboard shortcuts",
The Todo item could be:
"Will keyboard shortcuts save time for the end users and result in [positive reviews from power users] that mention the shortcuts?"
Then, one sees that actually implementing the shortcuts is just one step among many.
Perhaps more to the point, it's disparaging having delivering features as the priority instead of delivering customer value.
What would be refreshing are internal ROI dash boards for each project and group instead of just technical dash boards.
On almost every project I've worked on this data is not available and there's never any real evidence presented to the practitioners for things such as tech stack or process decisions. Typically, it's just a bunch of assertions, hand waiving and requests of trust.
The nice thing about feature-driven-development is that it avoids the hard work of having to understand what you're actually doing.
You can make the hamster wheel spin really fast and persuade yourself you're really going places.
Until the wheel falls off.
Is this just a natural course for startups unless conscious effort is put in to counteract it? I mean in the earlier days of startups just delivering features and catering to customer asks might be a good thing.
If this matches what you’re currently installing, I suggest reconsidering your plans.
Medium organizations do need more process than small ones, but not all processes are good.
In particular, if you have a growing product, and the plan is to ship a ton of features without internal (to engineering) coordination, and without improving, or even maintaining the core product, then you’re probably doing more damage than good, and neither the developers nor the customers will thank you for it in the long run.
There is a whole spectrum of client-agency relationships, and some of them are more like a feature factory than others, and there's nothing wrong with that.
Some companies want to hire a development team to work as if they were in house developers. Some clients just want to ask for Feature X and have Feature X delivered. They keep most of the discussions about business value, metrics and forward planning internally.
It doesn't have to mean that you have a business with bad processes, it could just mean you have the latter client relationship and a fairly mature process of delivery that doesn't require constant turmoil, refactoring and retrospectives.
I guess my point is just that there are certain relationships where it's just not your decision whether or not feature X is a good fit. I wouldn't want people reading this article thinking their company is broken, when it's just a different type of engagement.
Sometimes the CEO wants a popup on the homepage, and every single person in the chain between the CEO of the client company and the Developer at the agency agrees that it's a bad idea, but you still have to implement it.
From experience, it's actually a really nice environment to work in. Everyone is good at their job and you don't have to deal with the clients directly.
https://www.zentao.pm/share/treeswingpm-97.html captures the reality very, very well.
Are your initiatives somehow removing the third step of define problem -> build solution -> learn from solution -> define problem?
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.
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.
But when management compares your output with Cowboy Chris, the fastest code-slinger in the West, they'll think he's better for the company even though he's racking up tech debt on his journey.
Ideally you'd get credit for the good work you do that makes the whole team more efficient.
A good management team is aware of which people are fast in short sprints but end up tangling things up on longer efforts, which people take time to build steam but never hit that slow-down, and which people fit other patterns (for example, the extremely rare fixers who can take Cowboy Chris’s shit and funnel it into something useful, or the even rarer speed demons who can sprint like that forever because they are like Chris but they work cleanly too)
Good engineers, given the chance, will find and stick with those managers too.
Not all advice works for all people in all situations, but this has proven great for me.
OTOH, not only can focussed refactoring make delivering the features it is associated with faster, but refactoring—delivery-focused or not—is a really good way tonbuild knowledge of and proficiency with a code base, so if you aren't doing huge quantities of non-germane refactoring, it can actually be a personal delivery-speed enhancer, as well as the benefits for the team.
A large part of management is making the implicit explicit, and communicating the outcome of these efforts.
None of these examples have anything to do with refactoring code, specifically, and the challenges faced within that work.
Which is usually a failure of communication. The whole "just trust us" bit doesn't work, and it takes real work to build a rapport with your stakeholders to earn "blind" trust, which is what most people are really asking for when they say "just trust us". This almost never happens, unless people have been working with each other for many years.
> then nitpick that "well that's not needed"
First, ask questions. Find out why they're willing to put energy into this - most people are not wasteful when they push back on things (most). Maybe their boss is riding their ass, and it's CYA. Maybe they're just stating a preference, so I'll ask questions to make this explicit ("So you just prefer it this way? No data? No customer feedback? Your boss didn't ask?").
Second, socialize things early and often. Tell people weeks, months, quarters in advance about some technical debt you're eventually going to get around to paying off. This gives people time to vent, challenge things, or say they're stupid. Use this time to refine your story, and get better at telling it in a way that gets the least resistance (don't need support, just fewer detractors).
Sometimes that "socializing" is complaining about a shared frustration. "Ugh, System X gobbled up Sharon's purchase order again and she has to spend another two hours after working salvaging things. Really wish they'd let us spend time fixing this, but you know how it goes."
By the time I've scheduled a meeting with stakeholders to discuss something (especially something I know will be difficult for them to see value in), I make sure I've individually discussed it with everyone in the room. When they see less disagreement between each other, there's less negative energy to build off. There may not be any positive energy, but that's much easier to deal with.
Today most of business side has simply become too incompetent to be able to complete a dialogue with devs. Same goes for dev side, but is nothing new.
> Today most of business side has simply become too incompetent to be able to complete a dialogue with devs
This is an example, and IMO discredits most of anything else you may be trying to say.
This is interesting and will take some introspection, but perhaps I can improve these situations by fostering better communication. Thanks for taking the time to respond.
Now, you will have other priorities. Make sure you aren't dropping them. But most things are communication based. In time, you will find ways to improve without disrupting. Backwards and forwards compatibility will be tools, not burdens. Stability of the core will similarly work for you, such that you may start choosing to leave parts alone as you focus on peripheral changes that will have clearer impact to users.
The stability part is hard to overstate. There is a reason the Arduino uno is relatively unchanged. There is massive value in having a stationary target for what you are building. Custom everything down the line is an easy recipe for failure. Even if there are improvements that can be made down that line.
Or alternatively, don't, because the message from management is that maintenance takes a back seat to shipping new features.
For example, my team has been using a home-brewed NodeJS-to-Kafka library. Now, everyone on the team understands that this library is suboptimal in a number of ways (most notably because the developer who wrote it is no longer with the company) and that it should be replaced by some alternative from Github. But this is a change that will require quite a few downstream changes (mostly because the way the existing library was used was not well-factored).
There's no way of doing this change without it being a separate story. It's just too big a change. It's also not really something that is easy to do efficiently in an incremental fashion -- having two Kafka libraries simultaneously in the codebase is an even worse situation to be in than having a single, suboptimal library. And management is not willing to authorize a separate story for a "refactoring" such as this one, even though it would result in significant operational savings (less memory usage, fewer server restarts, etc). So we bumble along, waiting until the pain becomes so severe that we're ordered to embark on a hasty rework in order to hurriedly patch in the new library when the system finally melts down.
I still consider it pretty much mandatory to build core system improvement into feature estimates but by being more explicit and interactive about it you can get good feedback to refine your own estimates of what parts are even worth improving. It may be that the product line that uses the subsystem you want to improve is about to go a new direction, for example, and the better thing to do is to start preparing for that subsystem to go away.
If you're going to be working on a part of the codebase that you know is difficult to work with, you need to pad your estimate whether you're planning to refactor it or not - either you use the time to do the refactor, or you use the time to sort out the bugs you introduced by working on scary code without refactoring.
This is the thing that I cannot agree with what so ever. Companies do not employ developers to write beautiful code. Companies employ developers to write code to support business. Every single code base that shipped contains warts that became obvious as soon as the final commit was one, which means that refactoring is a cost and costs need to be accounted for and prioritized according to business objectives ( which at the end is making money -- the money that pays developers salaries ).
There's a limit to when the invasiveness of bean counting is useful, and finding that limit is paramount.
Is it your claim that among FAANGs it is a normal practice to say "This will take X weeks" when in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X?
That's absurd. The reason those companies are making money is because they are costing every single thing. That's the reason why tech gets a seat at the table -- it is a cost and its top of the line managers understand that this is a liability and drive that understanding through the entire tech organization.
Terribly untrue. This is fundamentally what makes them "technology" companies, because of how engineering expenses are treated on the P&L and the say it has at the C-level.
There's a fundamental different between how things roll-up n your 3 sheets, vs. how your company internalizes those numbers and acts upon them.
You've made a lot of broad generalizations without backing anything up with specific examples. It's difficult to have a conversation with theoreticals and ideas.
This is misleading, you should not be refactoring some other random code. You should be refactoring the code you are adding to/changing as part of the work. And it should be in proportion to the size of the change.
If you have that feedback, you are good, mostly. Then you will learn to ship what is important to the business.
> Large batches. Without the mandate to experiment, features are delivered in single large batches instead of delivering incrementally. You might still work in sprints (yay, we’re “Agile”), but nothing new is reaching customers at the conclusion of each sprint
Lol, I've worked on "Waterfall" projects more agile than this...
Agile and Sprints can lead to this. You will see a lot of ceremony, and the team might increase their throughout. But you find your team disenfranchised and producing substandard code that doesn't really do what it needs to do.
I cannot imagine someone willingly adopting “no metrics”, “shiny objects”, “no retrospectives”, waterfall isolated processes, etc. so you must be just exaggerating? what exactly are your new efforts like?
It is impossible to verify with as little context as you have given whether this is a good or a bad thing. But it clearly has a lot of bad in it.
In the case of an "enterprise software project", the sales process is driven by feature lists. The result is described very well by https://firstname.lastname@example.org/msg001.... As frustrating as it may be for developers, a "feature factory" is in fact a rational outcome for the business.
If, however, you are trying to deliver real value to real existing customers who have real use cases, it is very, very important that you find ways to measure outcomes. The measurements might be internal to your clients, they can be soft, but they have to be measured. If you do not have such measurements, and there isn't transparency around them, then it is guaranteed that people aren't getting useful feedback upon which they can do better.
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.
I'm sorry, but this paragraph sounds like a pile of red flags wrapped up in a self-serving excuse. As an experienced software developer with decades of experience who has worked at companies like eBay and Google, being told this by management would make me question whether it is time to find a new job before this one goes downhill.
Yes, you want PMs to have a good sense of what is actually needed and to be an interface. No, you don't want devs involved in every choice. But I have never seen a PM who is as good as a good dev at looking at a customer need and figuring out whether there is a minor tweak to what already exists that can satisfy that need without building a new feature. And a system built as a collection of features that the devs have no context on is guaranteed to go wrong.
If you shut the dev side of your organization out of those conversations, I can guarantee bad results. No matter what excuses you give for your decisions.
This is dead wrong.
An example of an alternative that is appropriate for a lot of web companies (for example Google, Amazon and Booking) is an A/B test culture. Release features as A/B tests with transparent metrics. Share the metrics with everyone who is part of the decision INCLUDING devs. Proceed with general rollout of the features that actually produce positive results and rollback of the ones that don't.
When every feature has to be justified by actual customer impacts that have a concrete measurement attached, you get a much better product and more involved devs. The flip side is that when you start a project you have no idea whether you add millions per year to the bottom line or whether your feature will be a flop.
The challenge is that PMs and devs have to be willing to accept that sometimes they were wrong and that's OK. But the alternative is significantly worse, which is to have PMs and devs who are often wrong, refuse to accept it, and therefore fail to improve!
If this is the process Google follows, how do its products (e.g Gmail) get worse over time? (genuine question, not snark). Are some things (e.g loading speed) not measured? Perhaps the things measured ('time spent 'in app' ') don't measure customer satisfaction?
I know from experience that A/B testing can make it hard to have a coherent product design (Amazon's page is a good example of that). But it is still much, much better than the usual alternative.
Like you, I don't see the state this article describes as a bad thing. Sometimes, that's what it takes to survive.
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.
Almost all the points can apply to 90%+ of companies. They are carefully worded so that everyone can say oh wow, these apply to my company.
I had the exact same reaction as you to this article after seeing it again, and wanted to share why I've also changed my mind on this. I was in "a feature factory" for few years and absolutely hated it. After leaving and going to a "not-feature factory" AKA "employee-happiness machine", I miss the feature factory.
Imagine you're building a Great Pyramid with 100 workers. The workers can't see the Pyramid and don't care about why a Pyramid is important. Is there time to explain to each worker exactly why they're moving a specific block? What about time to "review" why that one block didn't fit?
"Real work is always a bit messy"
Would you care about anything else other than how quickly each block got into place? The Pyramid can only be completed when all the blocks are in place, and most importantly- each block doesn't have to sit perfectly, and also, you can get by without ever delivering a "perfect block".
This is why product managers will never be 100% aligned with engineers. Product managers see "is the block there" and engineers see "is the block perfectly set" and "why am I not being appreciated?" and "why do they only care about putting down blocks".
It's bizarre to read how this person is so opposed to "up and to the right", that's the key indicator of you business and what will pay your bills. Yes, everyone is always going to be obsessed with revenue and you will never stop hearing about it.
Of course as an engineer- Resolve tech debt. You have to. But from the view at the top, it's a very temporary detour and needs to be resolved quickly so they can continue pumping out features.
Yes, I am making the analogy that engineers should accept being a "slave" to the product manager, or more directly, the product itself.
I just want the damn PM to be able to tell me where the block should go instead of fucking around with bullshit vague descriptions like "the block should be in a good place". And after I get instructed to place a block midair somewhere, I'm going to want the PM to show that he actually decided "where" based on some kind of information and not by throwing darts.
It is also totally reasonable to expect that someone is looking at each block as part of the overall goal, and identifying that those blocks which were just placed on the ground next to the pyramid were a total waste of time. It doesn't have to be me - but if nobody is doing it, who says we'll end up with a pyramid at all!?
Especially building a block in midair. PM just doesn’t seem to realize the rest of the blocks aren’t there yet.
The problem with the Pyramids analogy is that the Pyramid was the goal. In software companies, features aren't the goal. Better products for customers are. The right features are the means to the end, everything else is a waste of time and an illusion of progress.
A feature factory is bad for the business not because it's not "fun", but because resources are tied up producing huge amounts of work that don't really matter.
Kind of like a civilization using its vast resources building giant piles of rocks in the dessert because that's what they've always done.
The pyramids were useless tombs that wealthy kings wanted because of religious beliefs.
As an engineer, I have spent many months building features that were disabled/deleted because the measurements showed they were no good after release.
Now, for the 1% of product managers who make the right call every time on their own, having an engineer participate in the discussion may be a burden. But in my personal experience, every product discussion I'm in I bring great value to.
But the only metric the manager cares about is how many blocks per week we're pumping out. And that's why we'll never get along...
The blocks, pyramids, tasks are often unfinished or neglected after completion. Because nobody has time to make proper utilization of it all!
But it also sounds that you're worried about engineers constantly challenging product manager's decisions? I don't think that's the implied end state. Engineers don't see all the input to PM's decisions, and yes it would be more comfortable for the PMs if the engineers just trusted them to get it right all the time. But we (I'm an engineer) aren't dumb. We know nobody gets it right all the time, and we don't expect you to. But if we never learn which things worked out and which didn't, and some of the why, then what you're asking for is faith, not trust.
You don't need to include engineering in the decision making (at least, not more than you need for feasibility and cost estimates.) You do need to include engineering in the feedback loop, because we're not dumb monkeys whose only value is in realizing your vision. We know more about what's possible, and how to overcome some types of challenges with relatively little effort compared to the cannon that you'd need to (ask us to) build.
No, that's the exact opposite of what I said. In fact, I explicitly ended my post with a call to action for engineers to communicate concerns, suggestions, and questions to their product managers.
> It doesn't pretend to prescribe that to fix this pattern you need to do the opposite of every one of his bullet points.
That's my point: The article seeds this unrealistic idea of an over-idealized product management process that explicitly includes the reader at every step of the way. It manufactures an anxiety in the reader that a feature factory is a vaguely bad thing and if you recognize any of these 12 vague points, you're working within the bad thing.
Again, my problem isn't with the core suggestions to improve PM process that might be elaborated in the author's other posts. My problem is with the trend of people reading this article, finding some point to identify with somewhere, and erroneously concluding that their employer is doing it wrong and that's a bad thing.
My point was that if you want to be involved in the decision making process, provide feedback, or understand the reasoning behind the decisions you should be proactive about communicating. Instead, I see too many people reading this article and passively becoming disgruntled with their employers, without taking any steps to be more involved. Or the more they are involved, the more the complain about too many meetings, interruptions, and process overhead consuming their time that they'd rather use for quiet focus to get their work done. You can't have your cake and eat it too.
It’s must be pretty comfortable to assume that the engineers here have never tried giving feedback in their workplace.
It's simply saying that you measure before you build a feature [and again after]. Any good product owner will already have data to support their prioritizations (e.g. this bug affects 10% of users, this feature only applies to 2% of users)
I think you've missed the point of my comment.
As I said, the core principles of the article are not wrong. It's the framing of the article that causes problems.
When engineers and other ICs read this article, they tend to assume that these planning sessions, feedback loops, retrospectives, and other mechanisms aren't happening because they don't personally see them. That's why I pointed out that most engineers wouldn't be happy if they were pulled into every single planning, retrospective, and feedback meeting that the product managers are doing. I'm not saying they're bad, I'm just saying it's bad to assume you work in a terrible feature factory if you don't see every item on this checklist.
This goes both ways, of course. It would be silly for product managers to read an article entitled "12 Signs You're Working In A Code Factory" and then start second-guessing all of their engineers' decisions or assuming the engineers aren't implementing proper process behind the scenes. That type of article would generate outrage on HN, but engineers second-guessing product management is always well-received in an engineer-centric forum.
I think you're missing the second point of the article here. Per the article point 1 "Or, if measurement happens, it is done in isolation by the product management team and selectively shared. You have no idea if your work worked"
So the article is also highlighting failure to share as a failure mode. Every good company I worked at, I [the lead engineer] had equal ownership as my product owner. The respected my opinion, learned not to doubt my warnings, trusted my intuitions, and made adjustments based on my recommendations.
That balance of shared ownership is a defining indicator that it's not a feature-factory, whereas a "I call the shots as product" mentality is more feature-factory.
Is it possible you [rightly] worry about this article because you are what it's talking about?
The first definitely knew what things weren’t working, and tried out new things all the time (which also didn’t work).
The second has no clue if new things are working (or at least, nobody bothers to inform me), but they’re quite successful.
It feels a bit unfair.
I had a similar eye-opening experience. I worked for a company that insisted on doing everything the right way, with mountains of process, planning, metrics, measuring, followups, reviews, and customer feedback. It sure felt like we had the recipe for success, and it felt like we were checking every item on this list. We always felt super busy, as if we were doing important work every minute of every day. Yet it took us forever to ship new features, and the onerous planning, review, and feedback requirements turned into planning gridlock.
I then switched to a company that focused on quickly shipping features above all else, only measuring feedback with random sampling of customers and spot checks of quality. All of our customers loved the company because we could deliver their features quickly, and they could always see that we were moving the product in the right direction.
It's difficult to communicate the stark difference between these two environments unless you've seen both sides of it. It's even more difficult to convince engineers that the process-heavy, data-driven approach isn't necessarily the best way to run a business.
No company has zero focus on customer feedback, but the company may not be taking the feedback through channels that are most visible to you.
One of my most eye-opening experiences as a product manager was realizing that the most important customer feedback was not from the vocal customers complaining loudly on social media. The most important customer feedback was number of new customers signing up and their retention rate. To my naive surprise, chasing the feedback of the loudest complainers and detractors rarely turned them into proponents, and was even less likely to turn them into paying customers.
Someone, somewhere, is always making decisions according to customer feedback in some form.
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.
The grass is always greener on the other side of the fence.
The problem with cog in the machine analogies is that people only think of the plus sides of having more input in decision making processes.
What people generally ignore is the added responsibility and liability that comes with being more invested in the decision making process. In my experience, after you start holding people accountable for making the wrong decisions, most people quickly go back to being happy about being a cog in the machine and taking orders from someone else. For the few who enjoy calling the shots and accepting the blame when things go wrong, you can always move up into management.
In most companies, accepting blame is career suicide. Most people who move up in management are good at taking credit for wins and pinning down someone else for failures, or moving on to different projects before their decisions come back to bite them. And that's the kind of management that leads to broken process that the OP mentioned in the article.
For many (probably most) people all jobs available to them will be unfulfilling. For the rest, many of the jobs can be fulfilling, but have unreasonable demands, like concentrating for 40 hours a week and constant stress.
Obviously everyone's body and mind are different and if yours can easily deal with stress and 40 hours a week of concentration, then go look for a fulfilling job. If you're like me, on the other hand, you will burn out due to weariness even in what is supposedly your dream job. In such case, the only way to win is to make as much money as possible and retire early. The alternative - working while constantly tired and grumpy till you're 65 - is grim.
I don’t think this is a good solution. It is certainly “A” solution, and one that many folks pick.
Software Development is ALL about creativity. It’s really hard to make computers work; the best developers make them sing. Time and again I’ve seen fairly mundane teams hire an engineer with the energy and drive to push the boundaries of what’s possible and end up doing great work. I do think that developers can be agents of change this way; it’s not easy but it’s possible. And it can be very fulfilling and inspiring to be both someone who benefits from great work and to be a person that does great work.
I do agree that life may decide your priorities for you at times. Kids, spouses, relationships are all very important and compete for time and at some point you have to decide if it’s worth it to put in extra to do great work. It doesn’t mean though that Software Engineering is devoid of creativity. It’s been pointed out that software engineers can be one of the most productive assets of a company, and that productivity isn’t achieved by magic but by creative problem solving.
At the end of the day, if you got hit by a bus, your company would send flowers to your funeral and have an open req for your position before your body was buried.
Which is exactly what I expect them to do. Its a business and not a family. They compensated me for my work, I don't expect them to cry for me when I'm gone, but to hire someone immediately to continue the business.
I do see your point but the difference is that in my perspective the emotional attachment to something I build lasts only as long as I'm building it. Once the thing is delivered, its up to the users to ultimately decide to use it or discard it. I think my emotional attachment is to the process of building things rather than to the thing produced by the process.
I do agree that if you want to see the thing you built get used then yes, very bad idea to get attached to that emotionally. But the way I see it, after its built its out of my hands.
I worked at a startup where the founder thought he was irreplaceable since he was the only one who knew how to modify and compile the custom C/MFC custom IDE/VM/compiler that he developed and everyone in the company had been using for years before I got there.
They somehow convinced him to show me how everything worked since I was the only person who had a C++/MFC low level optimization background. As soon as they were comfortable that I could do it, the board pushed him out, laid off a bunch of other developers and gave me the responsibility.
His name was never mentioned again.
If a crappy PM wastes an engineer’s time by having them churn out useless product features, the PM is ruining their own career and the career of the engineers.
It’s important to work on meaningful work in order to have a meaningful career. That doesn’t mean everyone needs to heal the sick, but it can mean a PM doesn’t waste my time making me do stupid shit like build a feature no one uses.
It’s very difficult to level up if you never build anything worthwhile. PM’s should focus on getting it right the first time or not doing it all, because in the world of software development, adding technical debt for something not worth anything anyway is worth less than doing nothing at all
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.
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?
- 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.
Wtf? I've worked mainly for startups, with a couple of large companies in-between, and I've had the exact opposite experience. The engineering in every startup has been fairly lean and efficient with a few mistakes here or there, and every large business has been an 'agile' hell where everything feels ludicrously slow and nothing gets done.
I've always avoided interviewing with FAANG etc because I just assumed they'd be in the latter category with the sheer number of employees they have. It's interesting to hear that Facebook actually runs smoothly.
It's the longest I've stayed at a company (worked a decade at startups and web dev companies) because of the freedom to constantly work on things that are interesting. For example I've changed the type of developer I am twice since joining.
So if it's worth a look if that's a style that works for you.
However, the baseline level of individual competence and motivation is relatively high, which seems to reduce the need for process.
EDIT: the medium-sized company I worked at (~200 engineers) probably falls into the category of "agile hell" you described. The startups weren't as bad.
The devil is in the definition. As an example, we have a tool that bootstraps a new Git repo and we're adding a feature that will include our company Rubocop config if it's a Ruby project. There is no reason on earth that this should take 3-5 developers a week to accomplish (never mind two). But it's a feature and it could be useful. And on top of all the other features, the tool is quite useful nowadays compared to the first extremely thin slice we did.
The trick is reducing what you're counting as a feature to the smallest thing that is actually worth bothering to use. It won't always fit into one or two weeks, especially if you're dependent on hardware manufacture, or beholden to the iOS store approval timetable or whatever. But for your line of business SAAS apps there's absolutely no technical reason why you can't do it; there may be human obstacles to doing so. (Hell, maybe we're all wrong and you shouldn't do it.)
There was one reporting app where I was the sole developer and it was only for internal use. My regular cadence was that I would field a series of questions every day. Better than 90% of the questions already had a documented way to solve it. But many days a new feature would be needed. Most features were delivered on the same day. That was a fun project, and my reporting system wound up adopted in every department of that company.
I have worked on a legacy codebase with a Kanban style ticket system. Most features were delivered in less than a week. However a significant fraction of "features" were actually bugfixes. Such is life with legacy code.
I have worked on systems where features realistically took a month or three, but we pretended to biweekly sprints. The sprint cycle seemed silly there.
We're also totally a feature factory and I know for a fact that I would hate to be on one of the development teams and am absolutely glad I do ops instead here.
The things we have the hardest time with are hiring and retaining senior talent and executing on difficult work that can't be accomplished over a period of a few sprints.
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.
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.
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.)
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.
The most common: product decisions are made higher up by well intentioned leaders who lack the product management expertise and the context the team does.
Usually this looks something like a sales person hearing from a couple of customers “we really need feature X”. The sales person doesn’t ask what actual problem they’re trying to solve but instead reports back “the market is telling me we need X!!”. An executive picks this up, writes a business case, and then hands a solution (build X) instead of the problem (our customers are struggling with Y) to a product manager. That PM is no longer really empowered to think about the overall outcomes but rather is tasked with discovering requirements and then project managing the feature through.
At some companies this is how all product decisions are made. It’s not that there is no thought about benefit, it’s that the wrong people are the ones doing the thinking and as a result you end up with teams who spends years never delivering anything actually valuable to their users.
I’ve seen quite a few features added simply ‘because we can’, without any thought to ongoing maintenance, support, or additional infrastructure requirements/costs.
A little bit of common sense and forethought can go a long way in preventing unprofitable or revenue-decreasing features from being added to the product.
If you keep adding features, without increasing your conversion rate or user revenue, you are simply decreasing your profitability.
Death by a thousand cuts.
Approximate costs can be estimated before hand.
You can even ask the customer if they are willing to pay a specific amount for the feature.
But, insisting you have to build and deploy a feature first, before you have any idea of its impact, that is, an expensive, and foolish way to learn.
* 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.
> In practice you never know how a feature is going to work out
Those two sentences are somewhat contradictory. If you think through the features you should know exactly how they further your initial goal. When you add things based on what some people might like, that's when you are guessing and you can't know.
This all boils down to having or not having a vision.
Some leaders have a vision and you can see the long-term goals, others (like Google) throw things at the wall to see what sticks then shuts them down. If you're not a monopoly, that strategy will not work.
And honestly yes, you shouldn't have product management. Projects should be coordinated by product leads and their engineers. The only people that can plan a vision for software are the people who make it. You're paying these engineers for their knowledge, use it in all capacities.
That's how you end up with: https://gcemetery.co/
tldr: agile tells you how to release, not what to release
If you follow the feature factory route, the team will just produce things they are told too. If it doesn't work, it's not the teams responsibility. They did what they were told to.
It shouldn't be external group pushing features into a team backlog.
Devs talk to customers, look at the logs, debug issues, look at the stats being logged out. As result they have far better understanding of product usage than most people higher up.
Stakeholder is anyone with an interest in a project.
Good developers either see what is happening and jump ship or just get bored and leave.
I’m not convinced ‘feature factory’ in itself is problematic (definition not provided). There is no problem (IMO) in optimising to ship features - as long as the overall approach is to measure impact/benefit/usage and then learn and iterate.
There are some features that seem like obvious wins on paper but actually do worse when you A/B test it.
They hurt business value and add needless complexity to the development process.
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.
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).
To me, that is a characteristic of the un-feature factory, or whatever the opposite would be called.
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.
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.
No measurement / Success theater / core metrics
That's the crux of it, isn't it? 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.
As has been mentioned many times on this site, it is very easy to sell $2 for $1 all day long.
And how do you know this in advance?
‘Will you pay an additional $x/mo for this feature?’
You can estimate your AWS costs for what the feature would cost for that user.
You can estimate dev and implementation time.
It doesn’t even have to be 100% accurate, but if the numbers come nowhere close to making sense, don’t pursue this further.
Now, there may be a future time where some fundamental cost changes, and it is worth considering again.
Users lie. Not even maliciously.
Clients will say they'd pay for it, then when you deliver it they'll say they realized that your competitor provides that and everything else that is really important to them in the standard fee. The competitor is actually no better, and would require the same amount of development to get to parity in other areas, but they win by claiming that everything will be rainbows.
Clients will say they'd pay for X, but once you deliver it they'll suddenly realize that it won't actually work for them until you also implement Y, but they won't pay any more for X+Y than they would for X alone.
Clients will say they'd pay for X, but once you deliver it they'll have shifted direction or something has changed and they don't need it anymore.
Clients will say they'd pay for X, but once you deliver it and they start using it they'll discover that it's not at all what they actually needed.
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
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.
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.
Not saying agile is bad, just feels like a separate problem.
Very good article, so good that my coauthor and I used the metaphor in our book.
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.
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.
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...
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.
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”.
Eventually pendo.io accumulated $208.3M in funding.
2) John Cutler now works for Amplitude (pendo.io competitor) that received $136M in funding:
3) Amplitude looks more successful than pendo:
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.
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.
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."
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.
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.
>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.
In this case, you can't fight for them if you don't know what they want or how the product is helping them.
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.
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.
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.