"We want product engineers, not a feature factory" has become a cliché in job postings and company culture decks. But what does it actually mean? And more importantly, how do you build an organization that actually operates this way?
Having worked with teams across the spectrum, we've developed some opinions.
The Real Distinction
The difference isn't about skills or seniority. It's about how decisions get made.
In a feature factory, product decisions flow one way: product managers decide what to build, designers decide what it looks like, engineers decide how to build it. Each group optimizes for their own domain. Nobody owns the outcome.
In a product engineering culture, those boundaries blur. Engineers push back on product requirements that will be expensive to maintain. Designers understand technical constraints and design within them. Product managers involve engineering in prioritization, not just execution.
This sounds obvious. But implementing it requires changes that most organizations resist.
Why It's Hard
The feature factory model persists because it's easier to manage. Clear boundaries mean clear accountability. You can measure each group independently. When something goes wrong, you know who to blame.
Product engineering requires comfort with ambiguity. If an engineer pushes back on a requirement and the product doesn't succeed, was it the engineer's fault for pushing back, or would it have failed anyway? If a designer accepts a technical constraint that makes the UX worse, who's accountable for the outcome?
Most managers prefer clear accountability to better outcomes. That's why feature factories are so common.
What Actually Changes
In the teams that do this well, we see specific, concrete differences:
Engineers attend customer calls and user research sessions. Not every engineer on every call—but regularly, so they have direct exposure to user problems rather than filtered requirements.
Product managers write specs that include engineering input from day one. Not "here's what we want, tell us how long it takes," but "here's the problem, let's figure out the solution together."
There's explicit time allocated for technical investment. Not "we'll refactor when we have time" (which means never), but actual capacity reserved for work that doesn't ship features but makes future features faster.
The default answer to "why don't we just..." is "let's find out" rather than "that's not our decision." Engineers are expected to have opinions about product direction. Product managers are expected to have opinions about technical architecture.
The Uncomfortable Parts
This model has costs.
It's slower in the short term. Having engineers involved in product decisions means more people in more meetings. Requirements take longer to finalize because they get more scrutiny.
It requires higher-caliber people. An engineer who can only execute well-defined tasks won't thrive when asked to challenge product direction. A product manager who can't handle pushback won't survive when engineers have real power.
It creates conflict. When everyone has opinions about everything, there are more disagreements to resolve. This is healthy, but it's also exhausting.
How to Get There
If you're currently running a feature factory and want to change, here's what we've seen work:
Start with one team. Pick a team with a strong tech lead and a product manager who's open to working differently. Let them experiment while the rest of the org continues as usual.
Change the metrics. Stop measuring engineering by "features shipped" or "story points completed." Start measuring by outcomes: user metrics, revenue impact, system health. This forces cross-functional ownership.
Make space for disagreement. If engineers never push back on requirements, that's a sign they're either not engaged or not empowered. Treat pushback as a feature, not a bug.
Accept that it will feel slower. You're trading short-term velocity for long-term velocity and better outcomes. That tradeoff won't be visible for 6-12 months.
A Warning
Some companies claim to want product engineering but actually want feature factory with better marketing. You can tell by looking at how decisions actually get made.
If product can override engineering concerns without discussion, that's a feature factory. If "product engineer" just means "engineer who sits in more meetings," that's a feature factory. If engineering's role is to say "how long will this take" rather than "should we do this," that's a feature factory.
The label matters less than the reality. And changing the reality requires changing power structures, which is harder than changing job titles.