Over-Indexing on Product Delivery Can Cost You Millions
When product discovery is neglected, the costs quickly add up. In one case from personal experience, the cost was 10 person-years of effort spent on a failed launch that didn’t resolve the underlying customer problem. Despite the growth of dedicated product organizations, many product managers still find themselves constrained by waterfall delivery structures designed with little autonomy that hinders their long-term product success. Product Managers frequently lack the ability to direct their roadmaps based on product effectiveness and customer value. The root issue often lies in organizational culture, where delivery milestones overshadow customer value and experimentation.
A few years ago, my team embarked on an ambitious initiative (one of many on our 5-year roadmap) aimed at boosting customer conversion through a page redesign. Our hypothesis was straightforward yet unvalidated: customers faced with numerous search results would convert better if offered curated paths. While the hypothesis is well grounded in customer feedback and data, leadership had made two crucial mistakes in the work: (1) they didn’t allow the people closest to the problem (the PM, UX designer, and engineering leaders) to define the solutions to test and (2) the investment to deliver value (25 person-years across technology and operational partners) was too high compared to potential revenue upside. Anyone familiar with the Product Operating Model might notice that these are challenges common to the IT-model of software delivery.
Because the product was tied to a core customer flow, extensive A/B testing was essential. Setting up the A/B test took a full year — twice as long as we'd planned — and building a production-ready version required an additional six months. Delivery time was exacerbated by several factors: building a durable experience rather than a quick POC (on the assumption we would be successful), tech stack complexity from an ongoing digital transformation, and challenges in integration testing from other teams in the same code base. And because of how large the change was, we found when we saw the experience in the dev testing environment that we needed to adjust requirements we hadn’t identified in mockups; in other words, we were fixing the plane while flying it.
When we finally launched, the results were disappointing: conversion rates dropped, and customer confusion increased. Our team had invested 10 person-years to building a solution that we hadn’t adequately validated our business assumptions or user needs.
This failure wasn't simply due to technical setbacks; it was deeply rooted in organizational culture and structure. The pressure to hit predetermined delivery milestones overshadowed critical thinking and discovery processes. Our product team lacked the psychological safety or autonomy needed to challenge assumptions and pivot based on evidence. We were tasked to move forward without collecting critical evidence about user behavior and establishing user feasibility and business viability of the feature.
This failure has stuck with me in my career and taught me that to avoid such costly mistakes, effective product leaders must focus on three key practices to change culture and create effective organizations:
Ownership of the Problem Space: Ensure teams clearly own problem-solving responsibilities, not just delivery execution. This means that PMs are responsible for outcomes as opposed to outputs.
Empowerment through Validation: Require comprehensive business and technical validation during the discovery phase, preventing untested assumptions from derailing major initiatives.
Cultural Alignment: Align organizational culture around customer value, not just delivery milestones, creating a culture of continuous discovery. Build and nurture a culture where teams continuously experiment, prioritize customer value, and view validated learning—not just hitting deadlines—as success.
Embedding a discovery-oriented mindset into the organization's DNA helps teams feel ownership, aligns incentives around customer-centric outcomes, and reduces the risk of costly failures like ours. Ultimately, this sort of change management requires clear and decisive product leadership. Leaders must define product effectiveness not merely in terms of completed features but in validated customer value. This needs to tie to specific metrics (which tie back to core business metrics). If you can’t tie the work back to business value, you’re investing engineering resources in work of questionable impact. Strong product leadership clearly communicates these values, provides teams with tools to succeed, and fosters a culture that embraces continuous learning and customer validation to prevent costly failures.
