There’s a simple test for whether your engineering team is truly empowered: when do they first see the product ideas they’re being asked to build?
If the answer is “at sprint planning” or “when the story gets assigned,” you’re working on a feature team. Engineers are there to implement solutions that someone else has already defined. The work might be technically interesting, but the opportunity to influence what gets built is gone.
Empowered engineers see ideas much earlier. They’re involved in understanding the problem, exploring potential solutions, and helping define what should be built—not just implementing what’s already been decided.
This distinction matters more than most teams realize. It’s not about job satisfaction or feeling valued, though those improve too. It’s about whether teams can actually solve the right problems in ways that work for both users and the business.
Why most teams are feature factories
Most teams are there to serve the business, as Marty Cagan puts it. They’re given lists of features to build, acceptance criteria to meet, and deadlines to hit. Success is measured by delivery speed and specification compliance.
This feels efficient until you realize what’s actually happening. Product managers write requirements based on incomplete understanding. Designers create solutions for problems they haven’t fully explored. Engineers implement exactly what’s specified, even when they know it won’t work well.
The result is software that technically meets all acceptance criteria but doesn’t solve the underlying user problem. Features work as designed but feel clunky. Technical debt accumulates because teams build what’s specified rather than what makes sense.
As Cagan points out, “When a product manager is pressed to write a PRD with the detailed requirements, without doing the discovery work, they really have no idea if what they are describing will be effective” at solving the actual problem.
This is the feature factory trap. Teams become very good at building things quickly and exactly as specified. But they lose the ability to determine whether those things are worth building in the first place.
What empowerment actually means
Teams exist to solve problems for customers and the business, not to ship features that might not achieve the desired outcome.
Real empowerment means responsibility for outcomes, not just outputs. It starts with understanding the problem you’re trying to solve, not just the solution you’re supposed to implement.
But empowerment goes deeper than implementation autonomy. It means engineers get to figure out the best way to solve the problem, not just how to code a predetermined solution. This includes shaping the direction of what gets built, not just executing on decisions already made
This isn’t about giving engineers more autonomy over how they code. That’s already obvious—who else would make those decisions? True empowerment means involving engineers in problem discovery, not just solution delivery.
The challenge often lies with product managers transitioning from a project management mindset. In feature teams, product managers act more like coordinators than problem definers, writing detailed specs without the discovery work needed to know if those specs will actually solve the problem.
As a product manager building Atono, this hits close to home. Early on, I was writing detailed specifications and wondering why engineers weren’t more engaged. I thought I was being thorough. Actually, I was being prescriptive.
Why engineers are the best source of innovation
Engineers are often the best source of innovation, not customers, executives, or even product managers. This makes sense: engineers understand what’s technically possible in ways others don’t. They see elegant solutions that non-technical stakeholders miss. They spot technical approaches that fundamentally change what’s feasible.
But this only works if engineers see the problem before someone hands them a solution.
In my experience, engineers don’t resist this responsibility—they crave it. As Cagan observes, “The vast majority of cases, engineers love this. They were like, this is why they became an engineer. They wanted to invent, not just to code.”
Real innovation emerges when an engineer sits directly in front of a struggling customer and starts seeing approaches that nobody else was aware of. That direct exposure to user pain reveals solution possibilities that get lost in translation through requirements documents.
The discovery vs delivery divide
Most teams focus entirely on delivery because that’s what gets measured. Features shipped, stories completed, velocity maintained. But this misses the critical first step: figuring out whether you’re building the right thing.
As Cagan points out, “Our customers and our executives can’t tell the team what to build... because our customers and our executives, and rarely the product managers know what’s just now possible.”
When product managers write requirements without involving engineers in discovery, they’re specifying solutions based on incomplete understanding of what’s technically possible. Engineers implement exactly what’s written, even when they know better approaches exist.
The result is software that works as specified but doesn’t solve the actual problem elegantly. Technical debt accumulates because teams optimize for specification compliance rather than problem-solving effectiveness.
How product managers enable empowerment
The shift from feature delivery to problem ownership requires product managers to fundamentally change how they define and communicate work.
Give problems, not solutions. Instead of writing detailed acceptance criteria that specify exactly what to build, describe the user problem and the constraints that matter. Let the team figure out together, collaborating, sharing knowledge respective to their expertise.
Include engineers in customer conversations. As Cagan notes, “They hate to see customers unhappy. Especially with their products, and this is one of the biggest sort of wasted opportunities in so many companies.” Direct exposure to user struggle motivates engineers and reveals solution possibilities that aren’t obvious from written requirements.
Measure problem-solving, not just delivery. Track whether features actually improve user outcomes, not just whether they shipped on time and on spec. This aligns team incentives with solution effectiveness rather than specification compliance.
Provide strategic context. Engineers need strategic context to make good choices, understanding the product vision, strategy, and objectives. Without knowing business constraints and strategic priorities, they can’t make intelligent trade-offs between different technical approaches..
The hardest part is letting go of control over the solution while maintaining accountability for outcomes. It requires trusting that engineers will make better decisions when they understand the problem deeply than when they’re just implementing detailed specifications.
Why living stories matter
Stories become the foundation of empowered problem-solving when they evolve with the team’s understanding.
When stories capture reasoning behind features rather than just specifications, engineers can make intelligent decisions during implementation. When they include user context and success criteria, teams can optimize for the right outcomes. When they evolve as understanding improves, they become valuable references for future work.
This is why we’ve made stories central to everything in Atono. They’re not static requirements documents but living records of current understanding about problems and solutions. As engineers discover better approaches during implementation, stories evolve to reflect that learning, staying accurate and useful long after deployment.
This enables the kind of collaborative discovery that produces innovative solutions. When engineers can influence what gets built based on what they discover during implementation, both solution quality and team engagement improve.
The empowerment test
How do you know if you’re actually empowering your engineering team or just thinking you are?
Ask yourself: when engineers suggest alternative approaches during implementation, what happens? If the answer is “we stick to the original plan because we already committed to it,” you’re running a feature team.
Empowered teams adapt solutions based on what they learn during building. They have the authority to improve approaches when better options emerge. They’re accountable for whether features actually solve problems, not just whether they meet specifications.
Feature teams, on the other hand, only own specification compliance. That’s the fundamental difference in accountability.
The test isn’t whether teams can implement features efficiently. It’s whether they can discover effective solutions to real problems and adapt those solutions as they learn.
What this means for engineering teams
Building empowered teams requires product managers to change from project managers to problem definers.
Instead of optimizing for delivery predictability, optimize for solution effectiveness. Instead of preventing scope changes, enable intelligent adaptation based on discovery. Instead of writing detailed specifications, provide problem context and let teams figure out the best approaches.
This doesn’t mean abandoning accountability. It means shifting focus from compliance with specifications to achievement of outcomes. Once you give teams the power to figure out the solution, you can hold them accountable to the results.
The companies that figure this out build better software with less effort. They adapt faster to changing requirements. They retain talent longer because engineers feel like problem solvers rather than code production units.
When teams truly solve problems instead of just implementing features, they maintain clarity about why things work the way they do. They built it that way because they discovered it was the right solution, working collaboratively from problem definition through implementation.
This is what separates great engineering teams from feature factories. Not the tools they use or the processes they follow, but whether they’re empowered to use their full potential, their creativity, technical knowledge, and problem-solving ability—to discover and build solutions that actually work.