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

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.

But it’s a career. Work defines a career.

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

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.

> But it also sounds that you're worried about engineers constantly challenging product manager's decisions?

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.

A big change we incorporated is working more closely with the data analysis team. It helped us create analytics that were more useful for them, and helped us answer some good user centric questions, like which features were used most, why were others not used, how long were they taking to load, etc...