Patton’s Rule Tell Them What to Do, Not How to Do It for Empowering Product Teams

Why do so many brilliant engineering teams spend months building software that nobody actually uses? Empowering product teams requires a fundamental shift from dictating specific solutions to defining clear business problems. When you stop acting like a taskmaster and start acting like a leader, you unlock the creative potential of your entire organization.

Focusing on Outcomes Instead of Outputs

Marty Cagan’s book Inspired highlights a famous quote from General George S. Patton: "Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity." In the world of tech, this means a Product Manager shouldn't hand a designer a finished wireframe or tell an engineer which database to use. It’s the difference between a "feature factory" and a high-performing innovation team.

This mindset matters because it addresses the core reason most products fail. Cagan notes that as many as nine out of ten product releases fail to meet their business objectives. Often, these failures happen because the team was given a solution to build before anyone validated if the solution actually solved a real problem.

Giving Designers Creative Latitude for Empowering Product Teams

Product Managers often fall into the trap of doing the interaction design themselves. They draw the buttons and map out the navigation before the designer even joins the project. Cagan argues that this severely limits the contribution of a good designer. True empowerment happens when you give a designer a target persona and a specific goal, like "increase the checkout conversion rate by 10%."

High-performing teams understand that user experience design isn't just a "pretty veneer" added at the end. It's a collaboration that happens from day one. McKinsey research shows that companies with high design-maturity scores see 32% more revenue growth than their peers. When you let specialists own the "how," they apply expertise that a Product Manager simply doesn't have.

Respecting Engineering Feasibility while Empowering Product Teams

Engineers are often the most underutilized resource in a company. Most PMs treat them as order-takers who just write code to match a spec. Cagan suggests that the best ideas often come from the engineers because they know what’s becoming possible through new technology. Bringing an engineer into the discovery process early helps you avoid building "house of cards" infrastructure that collapses under scale.

Instead of handing over a 50-page requirements document, show the engineering lead a high-fidelity prototype. This allows for a two-way conversation about what’s feasible and what’s too expensive. According to Cagan, you don't have a spec worth building until you have evidence that your solution is valuable, usable, and feasible. This collaborative approach ensures that the people building the product are invested in the outcome, not just the output.

Learning from HP and Apple

Cagan shares a story from his early days at HP. The team spent a year building an AI workstation that cost $100,000. It met every technical standard, but when it launched, nobody bought it. The failure wasn't in the engineering; it was in the discovery. The team was told exactly what to build as a solution, without anyone checking if the problem was worth solving.

Apple operates differently by focusing on the emotional experience. The hardware exists solely to serve the software and the user's needs. Apple doesn't just add features for the sake of it; they obsess over how a product makes a user feel. This level of focus is only possible when the leadership sets a vision and lets the specialists execute the details with extreme precision.

Three Steps to Lead Without Micromanaging

1. Draft a one-page opportunity assessment. Instead of a list of features, write down exactly what problem you're solving, who the target user is, and how you'll measure success. This aligns the team on the "what" before anyone touches the "how."

2. Invite your lead engineer and designer to every customer interview. They need to hear the user's frustration firsthand. When they see a user struggle with a prototype, they'll be naturally motivated to find a better way to solve that pain point.

3. Replace your feature-based roadmap with an outcome-based one. Stop promising specific buttons by Q3. Instead, commit to solving a specific user problem, like "reducing onboarding time to under two minutes," and let the team figure out the best way to get there.

Where Patton’s Advice Faces Friction

This approach isn't always easy to implement in every organization. Some critics argue that junior teams lack the experience to be left alone with a problem. They might need more guidance and hand-holding until they develop better product sense. In highly regulated industries like healthcare or finance, some "how" details are actually legal requirements that must be followed strictly.

Others point out that stakeholders often demand the certainty of a feature list. Executives like to see exactly what they're paying for in a roadmap. Moving to an outcome-based model requires a high level of trust and a cultural shift that many traditional companies struggle to make. Despite these hurdles, the results of empowered teams far outweigh the comfort of a rigid plan.

Focusing on objectives rather than feature lists allows specialists to do their best work. When you define the problem clearly and step back, you stop being a bottleneck and start being a leader. Empowering product teams is the only way to build products that customers truly love. Replace your next feature request with a problem statement and a specific success metric.