5 Product Leadership Mistakes That Cost Me Millions (So You Don’t Repeat Them)
Product leadership is not for the faint of heart. The job is to embrace ambiguity and chart a course to a future that doesn't exist yet. You will make mistakes. The question isn't if, but how we can learn from them and avoid similar ones.
I’ve been in the arena for a while now—leading teams at Google and Amazon, founding two AI-driven startups, and seeing products succeed and fail spectacularly. My mistakes have cost lots of money, engineering effort and user trust, and, most painfully, led to letting go of people I cared about.
This isn't a confession. It's for our learning. I'm sharing my biggest mistakes to give you a cheat sheet, with some of the most deceptive traps that look like great opportunities. Recognize them, so you don't have to learn the hard way like I did.
Mistake #1: Chasing Shiny Objects (The Siren Song of "Synergy")
In my first startup, we built purchasing data analytics and marketing solutions for large consumer brands and financial institutions. We were two years in, hitting product-market fit, and seeing healthy revenue growth. We were focused and disciplined.
Then the shiny object appeared: mobile. Smartphones were taking over the world. Consumer apps were seeing exponential growth. I became convinced we needed a mobile strategy. I sold myself and my board on a vision: a consumer-facing mobile app for credit card users that would have "synergy" with our core enterprise business.
The Mistake: "Synergy" is one of the most dangerous words in business. It's often an excuse to lose focus.
I made a bold, and ultimately catastrophic, decision. I hired a new team of over 20 designers and engineers. We built a completely different product on a different tech stack for a different customer with a different go-to-market model. We were now two different companies under one roof.
Six months later, reality hit me like a ton of bricks. We didn't have the resources or the bandwidth to fight a war on two fronts. Our core business was suffering from the distraction, and the mobile app was a money pit.
I had to make the most painful decision of my career: I shut down the consumer division and laid off the entire team. I will never forget the looks on their faces. That mistake wasn't just financial; it was a deep emotional blow to our culture and morale.
How to Avoid This Trap:
Be the Best in the World, or Don't Bother. Before starting a new initiative, apply this brutal filter: "Are we determined to become, without question, one of the best in the world at this?" If the answer is anything less than a resounding "yes," don't do it. Being mediocre at two things is a recipe for failure.
Define Your Anti-Roadmap. A great strategy is defined by what you choose not to do. Create an "anti-roadmap"—a shared, explicit list of the markets, features, and customers you will ignore. This creates ruthless focus and makes it easy to say no to shiny objects.
Focus is a Verb. Focus isn't a poster on the wall. It's the daily, painful act of saying no to good ideas so you can execute on the great ones. It's about allocating 100% of your best resources to your #1 priority, not 10% to ten different priorities.
Mistake #2: Building on a Foundation of Unproven Tech
Googlers are dreamers. That’s what attracted me to join the company as a product leader. I want to build amazing, almost impossible, products leveraging cutting-edge technologies.
My first role at Google is at Nest, where I led the product team to define and build the future of intelligent smart home experience. We were bold and provocative: a truly proactive smart home system that anticipates your every need and takes actions on behalf of you and your family. The problem is, that vision requires a dozen underlying technologies to work perfectly in concert—sensor fusion, on-device processing, predictive models, audio and visual recognition, and more. The even more serious bottleneck is that users expect a very high level of certainty and reliability in their home, before they could be ready to adopt that proactivity.
After months and months of efforts in designing, prototyping and testing, we ended up winding down the initiative.
The Mistake: Committing to a product roadmap before the key enabling technologies are mature and reliable, especially for a consumer experience that reliability and control is critical (home experience).
How to Avoid This Trap:
Fall in love with feasibility, not just possibility. Innovation without pragmatism is self-sabotage.
Isolate and Attack the Riskiest Assumptions. Don't build the whole system at once. Identify the single biggest technical leap of faith you are making. Run a focused, time-boxed R&D sprint to prove or disprove that one assumption. This iterative, science-based approach to de-risking is how you separate science fiction from viable products.
Mistake #3: Over-indexing on a Single "Perfect" Customer
My second startup builds AI chatbot solutions for enterprise customer service. This was pre-LLM, when building a truly smart conversational agent was a monumental task. We were a small, hungry team of five engineers when we landed the dream design partner: Lyft.
They were a rocket ship in their boom days, and we were thrilled to be along for the ride. I dove in headfirst, embedding myself with their team. We lived and breathed their problems. We built our entire V1 product to solve Lyft's specific, complex use case for driver and rider support. And it worked. The launch was a massive success. Lyft became our biggest paying customer and a powerful logo that opened doors.
The Mistake: We hadn't built a real, scalable product. We had built a custom solution for one client. We were, in effect, a highly efficient, outsourced engineering team for our largest customer.
When we went to sell to our next ten customers in e-commerce, healthcare, and finance, we hit a wall. Their problems were different. Their scale was different. Their data was different. We discovered, to our surprise, that Lyft's use case was an outlier. We had optimized for the exception, not the rule. The "traction" we thought we had was a mirage.
The next 18 months were a painful process of "unlearning", and redeveloping. We had to rip out hard-coded logic, re-architect our data models, and fundamentally reposition the product. We had to tell new customers, "No, we can't do that yet," while our engineers worked furiously to generalize a platform we had built to be specific. Fortunately we gradually expanded our features and gained traction from other customers.
How to Avoid This Trap:
The Rule of Three. Never commit to a core product direction until you have validated the underlying problem with at least three unaffiliated, potential customers who fit your ideal profile. One customer is an anecdote. Two is a coincidence. Three is a pattern.
Abstract the Problem. When a design partner requests a feature, your job is not to just build it. It's to ask, "What is the universal problem this specific request is a symptom of?" If they ask for a "red button that does X," you need to understand the job-to-be-done behind the button. Build for the job, not the button. I know first-hand that it’s easier said than done, especially when you don’t have much leverage in the beginning.
Contractually Define the Relationship. A design partner is not a typical customer. The contract should reflect this. They get early access and influence, but in exchange, they commit to providing feedback on a generalizable solution. This frames the conversation correctly from day one. You're building a product with them, not for them.
Mistake #4: Believing You Can Force a User Habit
When I was at Amazon, I led discovery and engagement for Alexa. The Echo was the hottest gadget on the planet in those years. Everyone and their grandma has one on their kitchen counter or nightstand. We had a mandate: make Alexa an indispensable daily habit.
So we rolled our sleeves and shipped. We built features to "educate" users, prompted them with suggestions, and put "skills" on the device home screen. We relentlessly pushed all the amazing things Alexa could do, convinced that if users just knew about them and tried them enough times, they'd be hooked. Our adoption and engagement numbers were indeed amazing. But we were so focused on them that we forgot the cardinal rule: you can't manufacture a habit.
The Mistake: We were solving our organization’s problem, not the user's. Our metrics were focused too much on engagement, not enough on value. The result? We annoyed people. Quite a lot.
The infamous "By the way..." feature became a meme for a reason. Users ask for the weather and then get a lecture about listening to music. It broke user trust more often than we wished. A habit is the byproduct of delivering indispensable value, so much so that the user pulls the product into their life. We were pushing. We had to reverse a lot of efforts later on and rebalance the value we deliver and the growth efforts we make.
How to Avoid This Trap:
Solve for "Pull," Not "Push." Stop asking, "How can we get users to engage more?" and start asking, "What problem can we solve so masterfully that users can't imagine going back?" A great product doesn't need to nag. Its value is its marketing.
Measure Task Success, Not Just Engagement. Are users successfully completing their goals? Are they solving their problems faster or better than before? A user who opens your app once a week to solve a critical problem is infinitely more valuable than one who opens it daily out of annoyance and closes it immediately.
Practice "Quiet Confidence." A truly great product is confident in its core value. It doesn't need to constantly advertise its secondary features. Let users discover them organically through contextual, non-intrusive cues. When a user is already doing X, that might be the right moment to gently suggest Y. Don't shout at them when they walk in the door.
Mistake #5: Managing AI Products with the Old Playbook
When I switched teams within Google and led product efforts in launching Gemini, I saw firsthand how even the smartest, most experienced product managers were struggling to design and build AI products. For decades, we as product leaders were trained to build deterministic systems. You write a spec, the engineers build it, and we verify it by testing that the feature behaves predictably.
The Mistake: Applying this feature-driven, deterministic playbook to probabilistic systems like modern AI.
Modern AI is not deterministic. It's a core feature, not a bug. Demanding certainty, fixed timelines, and predictable roadmaps from a system designed to operate on probability is a recipe for disaster. It leads to brittle products that feel like clunky flowcharts, not intelligent agents. It leads to frustrated teams and missed deadlines. As I've written before, the failure rate for AI projects is over 80%, and this mindset is the primary culprit.
How to Avoid This Trap:
Make the Eval Framework the Product Spec. In the AI era, your most important document is not the PRD. It's your comprehensive evaluation framework. This "eval" is a suite of tests and benchmarks that defines what "good" looks like across multiple dimensions (e.g., accuracy, latency, tone, fairness). The team's job is no longer to "ship features"; it's to continuously improve the system's score against that evaluation framework.
Embrace the Probabilistic Mindset. This is the fundamental mental upgrade required. Stop thinking in binary terms of "right" and "wrong." Start thinking in confidence scores, accuracy thresholds, and acceptable failure rates. Your job is to define the boundaries of acceptable performance and guide the system towards that state.
The Way Forward
These five mistakes are five facets of the same core lesson: product leadership is not a static set of rules. It's a dynamic practice of adapting your mindset to the problem at hand. The playbooks that lead to success in one era can become the anchors that sink you in the next.
My goal in sharing these failures is to help you shortcut the learning process. Avoid these traps, and you'll be ahead of 90% of the field. You'll be free to focus on the real work: building products that matter.