Product Improv: Is Your Product Team Drifting to Failure?

You Don’t Have a Product Problem. You Have a Training Problem.

Most product managers have never been trained.

Not in any meaningful sense. They’ve picked up Agile. Maybe took a Scrum class. They’ve learned how to manage a backlog, run a standup, and perhaps facilitate a sprint review. Some have dabbled in DevOps. True, all of that is useful. None of it is the job.

They’ve learned development and design, and some aspects of delivery. They haven’t learned product management.

And yet, as a head of product—a director, VP, or CPO—you are expected to build a team that can consistently make good product decisions. Decisions about markets, problems, trade-offs, and priorities. Decisions that shape revenue, growth, and the long-term viability of the business.

So you assemble a team. You hire smart people. You look for domain expertise. You favor candidates who understand the technology or the industry. And then you put them to work.

What you don’t do—what almost no one does—is ensure they are actually trained to do product management.

Right now, budgets are tilting hard toward AI. Tools, pilots, integrations, “AI strategy” decks—everyone wants to show they’re in the game. And in the process, something quieter and far more important is getting squeezed out: the capability of the people making product decisions. The implicit assumption seems to be that AI will compensate for gaps in judgment. That if your product managers aren’t quite there yet, the tools will help them figure it out.

They won’t.

AI is extraordinarily good at accelerating execution. It can generate ideas, draft requirements, analyze patterns, and produce output at a speed that would have been unthinkable a few years ago. But it lacks a native understanding of your market, your customers’ actual problems, and the trade-offs that define your business. It works from prompts. And if those prompts are coming from product managers who don’t fully understand the job, then you’re not just making mediocre decisions faster—you’re scaling them.

I’ve already seen plenty of this. Teams using AI to generate roadmaps based on loosely defined inputs. Product managers asking for “top features for this segment” without ever validating whether the segment is worth pursuing. Requirements and stories written faster, but with less clarity about the underlying problem. It feels productive. But it’s disconnected from reality in exactly the same way—just at a much higher velocity.

This is where it gets dangerous.

Before AI, poor product management created waste. You built the wrong things, slowly. You could recover. You could course-correct. With AI, you can build the wrong things quickly, and with false confidence that you’re doing it right. The cost isn’t just wasted engineering time anymore. It’s strategic drift that compounds faster than your organization can recognize it.

At first, everything looks fine. The team is busy. Features are getting shipped. Stakeholders are engaged. Roadmaps are full and, in many cases, beautifully presented. If you’re not paying close attention, it feels like progress.

But over time, the cracks begin to show. Products become bloated. Features are added that don’t get used. Opportunities are missed because no one saw them, or they were ignored because the backlog already had more than could ever be done. Engineering time—your most expensive resource—is consumed by work that doesn’t move the business forward.

So yes, AI should absolutely be a focus—and not as a “when things settle down” initiative. AI is a “now” situation.

If you’re investing in AI without investing in the capability of your product managers, you are effectively handing a power tool to someone who hasn’t been trained to use it. The outcome is predictable. Not because AI is flawed, but because it will faithfully execute against whatever direction it’s given.

And that brings us back to the fundamental issue: the quality of your product decisions still depends on the people making them. AI doesn’t change that. It raises the stakes.

Chaos in process

Organizations love the idea of “learning on the job.” It sounds practical and efficient, and in some roles, I suppose it works reasonably well. In product management, it creates a subtle but persistent problem.

Everyone invents their own version of the job. Which means everyone is improvising.

Without a shared language, without standard methods, without clear expectations, product managers fall back on what they know—or what they’ve seen before. One leans heavily on engineering. Another behaves like a project manager. A third becomes a proxy for sales. Each is busy. Each is contributing. But they are not aligned, and they are not operating with a consistent definition of success.

I saw this play out at a mid-sized SaaS company that had grown quickly through acquisition. They had a dozen product managers, all experienced, all smart, all well-intentioned. When I asked them to walk me through how they defined a problem before building a solution, I got twelve different answers. Some started with customer requests. Others started with internal stakeholder ideas. A few admitted they weren’t sure they ever formally defined the problem at all.

The result was predictable. The portfolio looked like a collection of unrelated features rather than a coherent set of products. Each team was optimizing locally. No one was optimizing globally.

They didn’t have a talent problem. They had a training problem.

Product Managers Not Doing Product Work

Another pattern shows up once you look for it. Many product managers spend most of their time managing the delivery process. They run standups. They groom backlogs. They coordinate across teams. They keep things moving.

All of that is necessary. None of it is sufficient.

What they are not doing is spending time in the market. They are not having direct conversations with customers. They are not exploring problems deeply enough to understand their context or their impact. Instead, they rely on secondhand input—sales requests, support tickets, internal opinions. And rely on AI to filter through this noise to come up with a prioritized list of requirements.

I had a conversation with a team not long ago where the product manager proudly showed me a roadmap built from a list of “top customer requests.” It was organized, prioritized, and already partially in development. When I asked how those requests were validated, the answer was simple: “Sales told us these were important.”

We spoke to a handful of customers together over the next two weeks. What emerged was not a list of features but a set of underlying problems—some of which had nothing to do with the customer requests. In one case, a requested feature would have made the customer’s situation worse.

When customers describe a solution, they are almost always wrong. When customers describe a problem, they are almost always right.

The product manager wasn’t careless. He was untrained.

Hiring Doesn’t Fix This

When leaders seek new product management candidates, they double down on domain expertise or technical background, assuming that deeper knowledge of the space will lead to better decisions.

It helps, but it doesn’t solve the problem.

You can have someone who knows the industry inside and out, who understands the technology at a deep level, and who still struggles to frame problems, evaluate trade-offs, or connect product decisions to business outcomes.

I’ve seen this repeatedly with former engineers transitioning into product roles. They are exceptionally capable, but they default to solutioning. They jump to how rather than starting with why. Without training, they do what they’ve always done—solve the problem in front of them—rather than ensuring it’s the right problem to solve.

So the organization continues to rely on “figuring it out,” and the cycle repeats.

What Real Training Looks Like

The most effective product organizations take a different approach. They treat product management as a discipline that must be learned, practiced, and reinforced over time.

I know a product leader who assigns a mentor to every new hire. Not for a week or two, but for months. The mentor walks them through how the organization works, where to find data, how decisions are made, and what good looks like in practice. They review work together. They challenge assumptions. They provide context that no onboarding document could capture.

It’s not fast, and it’s not particularly glamorous. But it works.

It mirrors the way other professions build capability. Watch one, do one, teach one. Guided experience, not passive exposure.

Which brings us to training itself.

From time to time, a company will ask for a two- or three-day seminar. The expectation is understandable: gather the team, deliver the content, and watch performance improve.

It almost never happens.

Lecture-style training creates awareness, not capability. People leave energized, maybe even inspired, but they return to the same environment, the same pressures, and the same habits. Within days, the new ideas fade.

Real learning is active, applied, and reinforced. It requires working on real problems, making real decisions, and receiving real feedback. It requires coaching. It requires peer review. It requires repetition.

In other words, it requires a commitment to building capability, not just delivering content. Professional development, not just information transfer.

The Job No One Teaches

At its core, product management is about making trade-offs. It is about balancing the needs of the market with the needs of the business. It is about deciding what not to build as much as what to build.

If you follow every customer request, you create a bloated, unmanageable product. If you ignore customers, you lose relevance. If you focus only on short-term revenue, you undermine long-term value. If you focus only on vision, you risk never delivering anything meaningful.

This balancing act requires judgment. It requires context. It requires the ability to say “no” in a way that aligns teams rather than alienates them.

And yet, very few product managers are ever taught how to develop that judgment.

They are expected to absorb it through experience, which is another way of saying they are expected to make mistakes until they learn.

The Cost of Not Training

There’s a quote often attributed to Zig Ziglar:

When you don’t train product managers, the cost is not theoretical. It shows up in your products, your teams, and your results.

You see features that no one uses, products that try to do too much, and roadmaps that reflect internal opinions more than market reality. You see engineering teams working hard on things that don’t matter, and product teams that are constantly busy but rarely effective.

Perhaps that is the reason that 80% of features in the typical software product are rarely or never used, according to research by Pendo, the software analytics firm.

Over time, other parts of the organization begin to question the value of product management. If the function is not clearly driving better decisions, it begins to look like overhead.

In product management, that’s not just clever—it’s painfully accurate. Because untrained product managers don’t simply maintain the status quo. They accumulate bad decisions, one small compromise at a time.

The Bottom Line

Great product managers represent the interests of both the customers and the business. They work ON the product, not just IN the product.

If your product managers are not actively learning—and applying what they learn—you don’t have a product organization. You have a guessing organization.

And guessing works, for a while. It can even look like success. But eventually, the market catches up, the mistakes compound, and the cost becomes impossible to ignore. By then, the problem is much harder to fix.

Want to know what works? The best way to build a strong product management team is to offer learning opportunities, foster team discussions, sharing, and retrospectives, and provide ongoing mentoring.

Learn it, do it, teach it.