Tech founder and ex-VP of Product says AI is making product teams worse — not better
Discover why faster product development doesn’t guarantee better outcomes, and how AI can improve product decisions when paired with strong workflows and clear conviction.
Adam Root
Founder of Root Ventures
AI Impact: AI is making product teams worse by removing safeguards against poor decision-making.
System Focus: Effective product leadership focuses on systems rather than AI models or features.
Evidence-backed: Prioritizing evidence-backed systems improves execution and reduces scaling of incorrect ideas quickly.
Workflows: Integrated, AI-powered workflows enhance product development from data aggregation to decision validation.
Trust Concerns: AI's plausible accuracy poses risks; true accountability requires human oversight in decision-making.
Adam Root has held VP of Product roles at various tech companies. And he is currently the founder of Root Ventures, where he builds workflow-driven SaaS products.
We sat down with Adam to understand how AI is changing the product lifecycle — and how it’s actually making some teams worse along the way. Here’s what he told us.
AI is making product teams worse
AI is making most product teams worse, not better — because it removes the friction that used to protect teams from bad decisions.
Want more from The CPO Club?
Sign up for a free membership to complete reading this article:
Have an account? Log In
Over the past 17+ years, I’ve scaled SaaS platforms, led AI-driven initiatives, and driven measurable outcomes, including growing revenue from $20k to $400k MRR and delivering enterprise-scale impact. Earlier in my career, I believed the hardest part was building, shipping features, scaling teams, and executing against a roadmap. What I’ve learned, especially in the last few years, is that the real challenge is turning ambiguity into conviction. AI has made that distinction impossible to ignore.
Today, anyone can generate a prototype or ship quickly using AI tools, but most teams still struggle to translate that into real traction. I consistently see strong technical teams building faster, but without a clear product thesis. They layer AI onto workflows that were never designed to succeed. The result is more output, but not more impact.
That realization fundamentally changed how I approach product leadership. I now treat each product as a system of truth rather than a set of features. It starts with deeply understanding the problem, validating it with evidence, and sequencing decisions in a way that creates leverage. Only then does AI become a true multiplier. Without that foundation, it just accelerates noise.
So today, my focus is less on tools and more on creating clarity, aligning teams around what matters, why it matters, and how it drives outcomes. Because when the system is right, execution compounds.
Building an AI-native portfolio
Right now, I’m building a small portfolio of AI-native and workflow-driven SaaS products across different domains, each designed to sit at the center of real user behavior, not just add features on top.
Sotia is a system of intelligence built around behavioral data, starting with Slack, that helps leadership understand execution health in real time. It translates communication patterns into signals about alignment, decision velocity, and risk, effectively creating a new layer between raw activity and executive insight.
In parallel, I’m building VowVista, a marketplace platform in the wedding venue space focused on solving decision confidence for Gen Z buyers. It addresses a fragmented, high-emotion purchase by combining transparency, structured data, and guided workflows to help users move from exploration to commitment.
Alongside those, I’m continuing to develop AI-native platforms in construction and field operations, where we capture multimodal inputs like voice, photo, and video from the field and turn them into structured, actionable intelligence for operators and executives.
Across all of this, the common thread is building products that operate as systems of record and systems of intelligence, designed for real workflows, with a delivery model that combines rapid iteration with production-grade reliability.
Why product leaders should focus on the system, not the AI
AI is not the product. The system around it is.
Most teams start by focusing on the model, the feature, or the capability. But in practice, the model is the least differentiated and often the easiest part. The real work is everything around it: the data, the workflow integration, the UX, the trust model, and how the output drives an actual decision or action.
If you get that wrong, AI will make your product look impressive without making it useful. You’ll ship features that demo well but don’t get adopted, because they aren’t embedded in how users actually work or make decisions.
The real work is everything around AI: the data, the workflow integration, the UX, the trust model, and how the output drives an actual decision or action. If you get that wrong, AI will make your product look impressive without making it useful.
If you get it right, AI becomes a multiplier. It turns messy inputs into structured insight, reduces friction in real workflows, and creates leverage across the system.
If I had known that earlier, I would have avoided over-investing in the “intelligence” before validating the workflow. In a few cases, we built impressive capabilities that technically worked but didn’t change user behavior because they weren’t embedded in how work actually got done. We had to go back and redesign around the workflow, not the model.
How evidence-backed systems can improve execution
I’ve shifted from building features to building evidence-backed systems before writing code — using AI as a synthesis and validation layer early in the process.
In the past, even strong teams would move from discovery to specs relatively quickly. That model breaks in an AI-augmented world because the cost of building has dropped so much. You can generate and ship solutions faster than you can validate whether they should exist. What that creates is a new failure mode: teams scale the wrong ideas with incredible speed.
Discovery now needs to become a continuous, system-driven function, not a phase. That means:
- Aggregating real signals at scale, including user behavior, support data, win-loss, and qualitative inputs
- Using AI to synthesize patterns across those inputs, not just summarize them
- Explicitly mapping problems to workflows and measuring whether the product is actually addressing them
- Continuously revalidating assumptions as new data comes in
For example, I’ll run structured prompts across multiple data sources to surface recurring problems, map them to workflows, and explicitly test whether the product is actually solving them. That process often invalidates initial ideas or reshapes them significantly before they reach design or engineering.
What changed as a result is the quality of conviction. We build fewer things, but the things we do build are much more tightly aligned to real problems. It also changes how teams operate. Instead of debating opinions, we’re reacting to synthesized evidence. So for me, AI is less about speeding up execution and more about increasing the accuracy of what we choose to execute on.
How AI is condensing the entire signal-to-shipped workflow
Here’s an end-to-end AI-powered workflow I use to go from raw user signal to a shipped, validated product loop.
It starts with signal aggregation. I pull in qualitative and behavioral data, including interviews with couples, Reddit threads, venue reviews, drop-off points in the funnel, and inbound questions. Instead of reviewing these one by one, I use AI to synthesize across all sources and identify recurring problems, how often they show up, and where users are getting stuck in the decision process.
From there, I move into problem structuring. AI helps cluster those signals into clear problem statements tied to specific moments in the workflow. I then pressure-test those problems by asking, “Is this frequent, painful, and solvable by the product?”
Next is solution shaping. I use AI to rapidly explore different ways to solve the problem, not just features, but workflow changes. The key is generating multiple approaches quickly, then narrowing based on what best fits user behavior.
Then, we move into build and instrumentation. Using AI-assisted development tools, we go from concept to a working version quickly, but with instrumentation built in from the start. We track whether users engage with the new workflow, where they drop off, and whether it improves decision confidence or progression.
After that, it becomes a learning loop. AI analyzes usage patterns, qualitative feedback, and edge cases to identify what’s working and what isn’t. We look at whether the change actually altered behavior, not just whether users interacted with it.
Finally, it feeds back into iteration or removal. If the workflow improves outcomes, we expand it. If it doesn’t, we either refine or remove it quickly.
Claude, connected to my product data and user signals, handles most of this workflow.
How AI can create false confidence
The best result of AI that I’m seeing is a major increase in speed to clarity. AI has compressed work that used to take days into hours, especially in discovery, synthesis, and early product definition. I can review far more inputs, spot patterns faster, and pressure-test ideas before the team commits resources. Qualitatively, that has led to better initial framing, fewer weak ideas making it into roadmap conversations, and sharper alignment across product, design, and engineering.
It has also improved throughput in product creation itself. In the last year, I’ve used AI-assisted workflows to move from concept to working product dramatically faster than traditional cycles would allow. That includes getting from problem framing to architecture, PRDs, and usable software in a fraction of the usual time. The benefit is not just speed. It is the ability to test real workflows earlier, which improves learning velocity.
It isn’t all good, though. AI can create false confidence. Teams can mistake polished output for product quality. A prototype looks convincing, the spec sounds complete, and everyone feels like progress is happening, even when the underlying workflow, trust model, or user need is still unresolved. I’ve also seen AI increase noise when it is used without a strong product thesis. It can generate more ideas, more copy, more tickets, and more artifacts than a team can realistically evaluate, which can actually make prioritization worse.
Where AI falls short in product
AI has most clearly not delivered where I expected it to create step-function improvements in product judgment and sustained product impact.
I initially thought AI would significantly improve prioritization and roadmap quality by making patterns obvious. It does help surface patterns, but it doesn’t resolve what actually matters. The hard part is still interpreting tradeoffs, understanding second-order effects, and committing to a direction under uncertainty. AI informs that process, but it doesn’t replace it. I haven’t seen it consistently produce better product decisions on its own.
It has also fallen short in driving real adoption. AI features often demo extremely well, but that doesn’t translate into repeat usage unless they are deeply embedded in actual workflows. I’ve seen teams ship impressive AI capabilities that users try once but don’t come back to, because the product didn’t change behavior or become part of how work gets done.
Another gap is in reducing complexity. I expected AI to simplify how products are built and operated, but in many cases, it introduces new layers, including prompt logic, edge cases, evaluation challenges, and trust considerations. Instead of removing work, it shifts it into new areas that still require strong product and engineering discipline.
Why accountability must remain human
I use AI heavily anywhere scale and pattern recognition matter, and I keep humans in the loop anywhere judgment, risk, or taste determines the outcome.
On the AI side, I rely on it most in discovery and synthesis. I’ll feed in transcripts, support tickets, win-loss data, and behavioral signals to identify recurring problems, quantify frequency, and map those problems to workflows. It’s also useful in early prioritization, not to make decisions, but to pressure-test assumptions by showing tradeoffs, second-order effects, and alternative framings I may not have considered. In experimentation, AI helps generate hypotheses, draft variants, and analyze results quickly, especially when dealing with large volumes of qualitative feedback.
On the AI side, I rely on it most in discovery and synthesis. It’s also useful in early prioritization, not to make decisions, but to pressure-test assumptions by showing tradeoffs, second-order effects, and alternative framings I may not have considered.
Where I keep things explicitly human is in conviction and commitment. Final prioritization decisions, roadmap sequencing, and what we choose not to build still sit with the leadership team and me. The same goes for UX decisions that require taste, trust, and emotional context. Technical tradeoffs are also human-led, because they involve long-term system thinking, risk tolerance, and organizational constraints that AI can’t fully internalize.
The reason is simple: AI is excellent at compressing information and expanding the solution space, but it doesn’t own consequences. Product leadership ultimately comes down to making irreversible or high-cost decisions under uncertainty. That accountability has to remain human.
Why product leaders must watch for false trust at scale
Product leaders often underestimate the risk of false trust at scale.
AI systems are very good at producing outputs that feel correct, even when they’re not. The danger isn’t obvious failure. It’s plausible accuracy. Something that looks right, sounds confident, and is wrong in ways that aren’t immediately detectable.
At small scale, a user might catch it. At product scale, that same error gets repeated across thousands of interactions, quietly shaping decisions, workflows, and outcomes.
I’ve seen this show up in areas like document interpretation, recommendations, and workflow automation. The system performs well enough most of the time that users start to rely on it, but the edge cases are where the real risk lives. And those edge cases often carry the highest consequences.
What makes this especially dangerous is that traditional product instincts don’t catch it. You don’t see a drop-off or a crash. You see engagement. The product “works.” Until it doesn’t.
The mitigation isn’t just better models. It’s designing for trust and verification:
- Showing evidence, not just answers
- Exposing confidence and uncertainty
- Creating clear human-in-the-loop checkpoints
- Instrumenting for when the system is wrong, not just when it’s used
The risk is assuming accuracy scales linearly with usage. In reality, risk compounds faster than accuracy does.
How AI’s judgment can become weak
AI has struggled most where the product needs to understand human stakes, ambiguity, and the cost of being wrong — not just generate a plausible answer.
A good example is in compliance-oriented or high-trust workflows. I’ve worked on product concepts where AI can extract information from documents, flag issues, and recommend next actions. On paper, that looks like a perfect AI use case. In practice, the struggle is that the model can produce an answer that sounds highly confident while missing important context, misreading a clause, or failing to understand why one exception matters more than another.
That creates a trust problem immediately. The user is not asking, “Was this output impressive?” They’re asking, “Can I rely on this without creating downstream risk?”
What I learned is that AI is often weak at judgment when:
- The context is partial
- The consequences of error are asymmetric
- The user needs an explanation, not just output
How AI is restructuring teams
AI has changed the shape of my product teams from role-based silos to smaller, more integrated, system-oriented teams.
In the past, teams were structured around clear handoffs: product defines, design designs, engineering builds, and data analyzes. That model breaks down when AI compresses execution and introduces probabilistic systems that require tight feedback loops.
Now, I bias toward fewer people who can operate across boundaries. Product managers are expected to go deeper into data, prompt design, and workflow logic. Engineers are closer to the problem and user context, not just implementation. Design is less about static screens and more about interaction patterns, trust, and how the system behaves when it’s uncertain or wrong.
I’ve also seen the emergence of new responsibilities rather than entirely new roles. Things like:
- Owning the “system behavior” across edge cases, not just the happy path
- Defining confidence thresholds and human-in-the-loop moments
- Managing data quality and feedback loops as first-class product concerns
How product leaders should use AI
My advice is simple: Don’t use AI to move faster. Use it to get more right.
Right now, most teams are focused on speed, more features, faster cycles, quicker outputs. That’s the obvious benefit. But speed without clarity just scales mistakes.
The real shift is this: building is no longer the constraint. Judgment is.
So as a product leader, your role becomes less about driving execution and more about:
- Defining the right problems
- Sequencing decisions
- Ensuring what gets built actually changes user behavior
Use AI to expand your thinking, synthesize signal, and pressure-test ideas. But don’t outsource the hard decisions. That’s where the value is.
Also, redesign how your team works:
- Treat discovery as continuous, not a phase.
- Design for trust, not just functionality.
- Build systems, not features.
And most importantly, resist the temptation to skip the hard thinking.
Follow along
You can follow Adam Root on LinkedIn as he continues to build Sotia, VowVista, and the other SaaS products in his portfolio.
More expert interviews to come on The CPO Club!
