Marty Cagan
Many technology organizations practice what appears to be agile development but is actually a rigid waterfall methodology in disguise. In these environments, management hands down external roadmaps and predefined solutions to technology staff. These groups function merely as feature teams that optimize for shipping output and meeting estimates rather than solving actual customer problems. This dynamic creates a culture of mercenaries who build exactly what they are told without questioning the underlying value or business logic.
When companies operate this way, they experience a massive failure rate in product efforts because they only validate customer need at the very end of the delivery cycle. Ideas originate from sales requests or executives, undergo heavy business case scrutiny before any data exists, and proceed through design and engineering in isolated silos. This disjointed sequence guarantees that a significant portion of shipped features will fail to resonate with the market or require costly rework.
True product teams operate on a fundamentally different premise by focusing on outcomes rather than specific feature outputs. Leadership assigns these teams a specific business or customer problem to solve, granting them the autonomy to discover the most effective solution. This shift requires a collaborative, cross-functional group typically consisting of a product manager, a product designer, and several engineers working together from the very beginning. Such teams behave like missionaries who deeply understand the customer and are directly accountable for the results of their work.
Empowerment demands technical excellence and continuous learning across the entire product surface. When teams are trapped in narrow silos working from team-specific backlogs, they suffer from diminishing returns and localized optimization. To remain adaptable and innovative, empowered teams must pull from a shared, objective-oriented product backlog prioritized by top-level business needs. This structure forces team members to expand their skills and prevents them from stagnating on a single product component.
Successful product discovery exists entirely to identify and mitigate four severe risks before writing any production code. Value risk asks whether a customer will actually choose to buy or use the solution. Usability risk questions if the user can figure out how to operate it. Feasibility risk determines if the engineering team has the time, skills, and technology to build it. Finally, business viability risk ensures the solution aligns with the constraints of sales, marketing, legal, and financial stakeholders.
Failing to address these risks upfront leads to expensive post-launch failures. Teams must run experiments and test hypotheses rapidly to separate good ideas from bad ones. By treating discovery as a process of evidence gathering rather than a formal approval stage, product organizations ensure they only invest heavy engineering resources into solutions that have a high probability of market success.
Effective discovery requires an intense focus on the problem space before ever entering the solution space. Many organizations mistakenly skip user research and jump straight into building what they think the market wants. The double diamond approach forces teams to diverge and explore the underlying customer challenges thoroughly, converging only when they can articulate a highly specific, actionable problem statement. Only after isolating the true customer pain point does the team begin generating potential solutions.
Once the problem is defined, the team diverges again to ideate creative ways to solve it. This involves brainstorming, mind mapping, and observing users in their natural workflows to identify points of friction. By maintaining a strict boundary between defining the problem and designing the solution, teams avoid the trap of building a brilliantly engineered product for a problem that does not actually exist.
Prototypes are the primary vehicle for answering risk questions at an order of magnitude less cost than building the actual product. Feasibility prototypes allow engineers to write throwaway code to test technical limits, while user prototypes range from simple paper sketches to high-fidelity interactive mockups to test usability. Live-data prototypes go a step further by using real network traffic in a limited capacity to prove that an idea genuinely changes user behavior.
The objective of a prototype is learning, not proving a preconceived notion. Product managers and designers must put these artifacts in front of target users and observe their interactions without leading them to the right answer. Because these artifacts are inexpensive to produce, teams can test multiple variations a week, discarding the failures and refining the successes based on actual user evidence.
A common pathology in product development is involving engineering and design far too late in the process. When product managers hand over completed requirements for engineers to simply code, they waste the team's greatest source of innovation. Engineers possess a unique understanding of what is technically possible and often suggest solutions that product managers and designers would never conceive. Bringing them into customer interviews and ideation sessions ensures that feasibility is woven into the concept from day one.
Similarly, product design must transcend mere aesthetics applied at the end of the cycle. Designers play a crucial role in product discovery by uncovering exactly how users want to interact with the system. They build the prototypes that allow the team to test value and usability simultaneously. Without this deeply integrated triad of product, design, and engineering, the organization defaults to a sequential, slow, and error-prone delivery mechanism.
Traditional product roadmaps function as rigid lists of prioritized features tied to specific delivery dates. These documents create dangerous illusions of certainty because stakeholders interpret them as hard commitments. In reality, at least half of the ideas on any roadmap will fail to deliver the expected value, and the ones that succeed will require multiple iterations. Managing by a feature roadmap forces teams to prioritize output velocity over actual problem solving.
The alternative to this trap is an outcome-based roadmap built on clear product vision and strategic objectives. Management defines the business results they need, such as improving retention or increasing conversion, and allows the product team to determine the sequence of experiments required to hit those metrics. This approach shifts the conversation with stakeholders from negotiating delivery dates to collaborating on business impact.
While the concept of fully empowered, autonomous teams represents an ideal state, practical application in enterprise environments often looks different. Many product managers operate within organizations that lack the strategic alignment or executive buy-in necessary to truly decentralize decision making. In companies optimized for top-down sales and predictable output, attempting to unilaterally implement pure product discovery can cause significant friction.
Despite these environmental constraints, the core principles of customer-centricity and outcome focus remain highly valuable. Product managers use these ideal models as an aspirational framework to gradually influence their company culture. By incrementally introducing prototypes, involving engineers in discovery, and tying features back to business problems, practitioners can slowly bend their organizations toward a more resilient and innovative posture.