The seductive trap: When AI's greatest gift to product is its costliest pitfall
There's an electricity in the room when a team sees something work for the first time—not the kind of "it compiles" success, but a real, felt leap forward. It’s that moment when a prototype actually understands the user. When something previously unimaginable happens… and it happens fast.
I remember one of those moments earlier this year. A team I was coaching needed to understand how different user segments approached their product's core onboarding flow. They'd always struggled with the same problem: too many user personas to build for and to test. But this time, they used AI to build out different versions of the prototype for the different personas, all in a single afternoon. It was the start of “no excuses” for great research—the same room that once felt stuck now buzzed with purpose and focus.
Just last month, I experienced this magic myself while prototyping with V0 for a new product. What normally would have required wireframes, stakeholder reviews, and weeks of back-and-forth became an all-nighter of rapid iteration. I described the user flow and the problems to solve, and gave it some core parameters. I watched as a working prototype materialized—complete with realistic content, logical navigation, and even edge case handling I hadn't thought to specify. I iterated through the prompting flow and watched my dream prototype come to life. These moments stuck with me. Not just because it was impressive, but because it felt like an inflection point that would change how great products were built forever.
The best product teams have completely revolutionized their discovery process. Teams can now simulate user scenarios, generate realistic test data, and explore edge cases that would have been harder and more time-consuming in the past. The gap between "what if" and "let's see" has essentially disappeared. There are fewer and fewer excuses not to do product discovery when discovery is becoming faster for the best teams.
When building becomes more frictionless, teams start thinking differently about what's possible. They experiment more boldly, fail faster, and iterate with a fluidity that transforms how they approach product development entirely. Great product teams are becoming more empowered in ways we'd only dreamed about before. A crossing over into a different kind of product work:
More fluid.
More collaborative.
More ambitious.
This shift has been thrilling to watch, but with every breakthrough, I've also noticed patterns that give me pause. The same capabilities that are empowering teams to build faster and better are also leading them astray in surprisingly predictable ways. Lately, I’m finding myself guiding teams through the same 3 traps again and again that I'd like to share with you today:
Trap #1: Mistaking AI for Strategy
The first trap I saw was a client presenting “AI as their strategy.” Slide after slide showed AI features and capabilities, but I kept coming back to a simple question: Why?
If it doesn’t show up that directly, it often takes the form of questions like:
"Where's our AI play?"
"Can we add some LLM features to this?"
"Competitor X just launched something with chat—should we copy it?"
These questions don’t come from nowhere. There’s pressure—real or imagined—to “do something with AI.” And that pressure often leads to one of the most common traps I see: treating AI as the strategy, rather than a lever for the strategy.
The pause that follows when I ask "But what problem are you solving for your customers?" reveals everything. Teams become so enamored with AI's possibilities that they forget the fundamental truth of product development: technology serves strategy, not the other way around.
I've seen this pattern repeat across dozens of teams now. They start with a customer problem, discover AI can help solve it, then gradually shift their focus from the problem to the technology. Eventually, they're not building a customer solution enhanced by AI—they're building an AI solution in search of customers.
The most successful AI-powered products I encounter today are built by teams who treat AI as a powerful lever for their existing strategy, not as the strategy itself. These teams have something in common:
They can articulate their value proposition without mentioning artificial intelligence at all, because AI is simply how they deliver that value more effectively.
Trap #2: The Shiny Object Syndrome
A founder recently told me she was spending three hours every morning reading about the latest AI trends, models, and releases. She felt completely lost, questioning her roadmap, second-guessing her product direction, and wondering if she was falling behind by not chasing every breakthrough. "I don't even know what we're building anymore," she confessed.
I grounded her with a simple reminder: "The problem you're solving hasn't changed. AI is just—and should be just—a possible solution."
I call this entering the AI spiral—an endless cycle of experimentation with new models, rebuilding features with marginally better capabilities, and constantly re-evaluating product direction based on the latest AI breakthrough. It's insidious because it masquerades as staying current and being “innovative”.
The AI loop feeds an addiction to technical possibility at the expense of building solutions that actually work for the customer and the business. Teams get caught chasing the bleeding edge, convinced the next model release will finally unlock product–market fit. Meanwhile, the core problems they set out to solve remain untouched, buried under layers of technical experimentation.
Breaking free requires a disciplined return to first principles: What job is your customer hiring your product to do? How well are you doing that job today?
AI is not the problem, and often, it shouldn’t even be part of the solution. The best teams understand that to win, they need to solve their customers’ problems in a way that serves the business, with or without AI.
Trap #3: The Frankenstein Phenomenon
Here's the most subtle—and dangerous—pitfall of all. When building becomes cheap and fast, the natural tendency is to build more. I've seen teams launch entire feature sets in a week, layer AI into every touchpoint, and still hear crickets from users. Not because what they built was broken, but because it wasn't needed. The worst part is that it actually made their product less valuable and more complex.
There was beauty in the constraints imposed by expensive engineering. Every feature had to justify its existence. Every addition required careful consideration of complexity and implementation. Those constraints forced clarity and they were a key reason teams took the time to get it right before they built. In the past, the friction of building served as a powerful filter.
Now that building is cheap, that discipline has largely disappeared. Teams add features because they can, not because they should. The result is Frankenstein products—technically impressive monsters that solve everything, confuse users (and sometimes the business), and delight no one.
One team I coached built a beautiful AI assistant into their product—fast, sleek, deeply integrated. But usage flatlined because their users didn't trust automation for that task. What they needed was better visibility, not delegation. The team had built from capability, not need, and the best products are built the other way around.
You’ve made it to the end, so here’s the good news: I’m not going to leave you hanging with all these traps.
From watching dozens of teams navigate this transition, I've learned that AI's greatest gift to product teams—the ability to build faster—is also its most dangerous trap. The teams that thrive don't just embrace AI's capabilities; they develop new muscles for constraint and focus and use AI as a way to experiment and as a lever, not a strategy.
They've learned to see AI not as magic, but as amplification. It amplifies good product thinking and bad product thinking equally. It accelerates progress toward product-market fit and away from it with equal efficiency.
The most successful teams I work with today have learned to impose artificial constraints on themselves. They're more ruthless about feature decisions now than they were when engineering was expensive. They've discovered that in a world where anything is possible, the power lies (and has always lied) in choosing what not to build. This has not changed with AI, and I don’t think it will. It’s the essence of good product strategy.
Here's the principle I come back to, again and again:
Just because we can build it, doesn't mean we should.
The teams who thrive in this next chapter won't be the ones who move fastest—they'll be the ones who stay clearest. About their users. Their purpose. Their edge.
So the next time someone asks, "What's our AI strategy?"—try answering with a question of your own: What problem are we here to solve?
When you feel the pull of the AI loop, ask: Are we chasing the latest model or better outcomes for our users?
And when building becomes effortless, remember: Just because we can build it doesn't mean we should.
In the end, models will change, but human needs endure. And that's where the magic still lives.






Brilliant piece. Fully agree, especially on the danger of mistaking *tactical acceleration* for *outcome-based strategy*.
I’ve seen decks where the model was the main character and the customer barely made the cast list.
Honestly, every PM should be issued a shock collar that zaps them the moment they say “Let’s just AI it” without even a problem space drive-by.
We didn’t escape feature factories just to build bolted together Frankensoft products faster with cooler acronyms.
Just because building is easy now doesn’t mean judgment gets to be optional.