We Fixed Development. Oops.

The first wave of AI disruption inside most companies has been focused on Product and Engineering. That makes sense. The ability to generate working code in minutes instead of weeks is flashy. It gets attention. It creates momentum. It also creates a dangerous illusion that the bottleneck in software delivery has finally been eliminated.

It hasn’t. The bottleneck just moved.

Over the past several months, I’ve spent a lot of time thinking about what happens after an organization begins adopting an AI-assisted Product Development Lifecycle. Because while Product and Engineering may suddenly find themselves moving at a completely different speed, the rest of the organization often isn’t prepared for what happens next.

And that’s where things get interesting.

For decades, most software companies operated at roughly the same pace across departments. Product planned. Engineering built. QA tested. Product Marketing prepared launches. Documentation wrote release notes. Enablement trained internal teams. Customer Success figured out how to support it all. Everyone had enough time to stay relatively synchronized because development itself was the limiting factor.

AI changes that equation completely. When a team can move from concept to working software in days—or sometimes hours—the downstream functions don’t magically evolve overnight with it. In many organizations, Product and Engineering are now driving a Formula 1 car while the rest of the company is still trying to merge onto the highway in a 1987 Volkswagen van carrying a three-ring binder labeled “Q3 Launch Readiness Process.” That mismatch creates friction almost immediately. Features start arriving faster than Product Marketing can position them. Enablement teams struggle to keep internal teams informed. Documentation becomes outdated before it’s even published. Customer Success finds itself learning about changes at roughly the same time as the customer. And Support teams suddenly discover that “what changed?” has become their most commonly used internal phrase.

That’s the part of the AI PDLC conversation I don’t think enough people are talking about yet. Speed inside Product and Engineering is only valuable if the broader organization can absorb and operationalize that speed. Otherwise, you don’t really have acceleration. You have localized acceleration surrounded by organizational drag. And importantly, I don’t think the answer is simply “make every department move faster.” That’s probably the wrong framing.

The real shift is toward synchronized adaptability.

Different types of changes require different operational responses. Infrastructure improvements may be able to ship immediately with little visibility. Small workflow enhancements and paper-cut fixes can often move at extremely high speed. But larger workflow changes, navigation adjustments, reporting modifications, onboarding changes, or process redesigns may require more coordination, communication, and enablement. The goal isn’t universal speed. The goal is matching the operational response to the customer impact of the change itself. That’s a much more nuanced challenge than traditional release management.

One of the biggest mindset shifts organizations need to make is realizing that downstream teams are no longer really downstream. In a traditional PDLC, Product Marketing, Documentation, Enablement, Support, and Customer Success often engaged later in the process because there was time to do so. Development cycles were long enough that those teams could operate sequentially. That model breaks down quickly in an AI-assisted PDLC.

These teams now need to plug into the process much earlier and much more continuously. Product Marketing can’t wait for a finalized feature set because the feature set may still evolve during refinement cycles. Documentation can’t rely on large periodic updates because the product may change every week. Enablement can’t prepare static training material when workflows themselves are evolving in real time.

The old “throw it over the wall” approach simply doesn’t survive this kind of operating model. What replaces it is something much more collaborative and iterative.

The organizations that navigate this transition best will stop treating downstream functions as recipients of completed work and start treating them as active participants in the product delivery loop itself. That means involving Product Marketing earlier so messaging evolves alongside the product. It means giving Documentation teams access to prototypes and working builds instead of waiting until the end. It means Enablement teams becoming embedded partners rather than last-minute trainers trying to catch up before launch day.

And interestingly, involving these teams earlier doesn’t slow the process down. In many cases, it accelerates it.

When Product Marketing, Documentation, Enablement, Customer Success, and Support are integrated into the iterative loop itself, the supporting material becomes dramatically easier to prepare because those teams are evolving alongside the product instead of reacting after the fact. Messaging develops while features are still being refined. Documentation begins earlier because teams have access to prototypes and working builds. Enablement can shape rollout plans before the feature is technically “done.”

In other words, the AI PDLC doesn’t just accelerate Engineering throughput. It can accelerate organizational readiness too, if companies structure themselves correctly.

Most discussions around AI adoption focus heavily on developers, but some of the largest operational gains may actually come from functions surrounding development. Documentation teams can use AI to generate first drafts directly from demos, recordings, prompts, or working code. Product Marketing can rapidly create positioning variations, launch messaging, FAQs, internal battle cards, and customer communications. Enablement teams can generate role-specific training material, onboarding flows, and simulations far faster than traditional methods allowed.

The point isn’t replacing these teams. It’s removing the mechanical work that slows them down so they can focus on judgment, clarity, customer understanding, and refinement. Because just like AI-generated code still requires human review, AI-generated messaging and enablement still require human expertise. Nobody wants hallucinated release notes confidently explaining a feature that doesn’t exist yet. That’s how you accidentally create roadmap commitments during a webinar and suddenly find yourself in a meeting that starts with the phrase, “So… a customer has some questions.”

This also changes the role of Product Management in ways I don’t think the industry fully appreciates yet.

Historically, Product Managers spent enormous amounts of time managing engineering scarcity. Prioritization, roadmap sequencing, stakeholder negotiations, and tradeoff discussions were often driven by the reality that building software itself was expensive and slow. AI changes that equation.

As engineering constraints become less dominant, Product Management increasingly becomes an exercise in judgment. Understanding customer workflows. Understanding operational impact. Understanding change management. Understanding where speed creates value versus where speed creates disruption. That’s a very different discipline than simply managing a backlog.

I’m actually writing this section on a plane ride home from speaking at our customer conference, and one thing became incredibly clear over the course of the event: customers are excited about AI. Not cautiously interested. Genuinely energized. The conversations weren’t centered around whether AI matters anymore. That question has already been answered. The conversations were about how quickly organizations can benefit from it and how deeply it can improve the way work gets done.

What was equally interesting was that the excitement wasn’t limited to the capabilities themselves. Customers were energized by the speed of iteration and responsiveness they were seeing from teams adopting AI-assisted development practices.

In one session, a customer shared a request on the first day of the conference. By the end of the second day, the change was already in QA and being discussed publicly as an upcoming enhancement. A few years ago, that kind of turnaround would have sounded completely unrealistic. Today, it’s becoming increasingly achievable.

Moments like that fundamentally change the customer relationship in a positive way. Customers feel heard differently when the feedback loop tightens from quarters to days. Their ideas no longer disappear into a roadmap slide titled “Future Consideration” where features quietly age beside a collection of optimistic target dates and at least one dependency nobody fully understands.

After sharing some of my thoughts internally around customer fatigue and release pacing, I also had a really thoughtful discussion with our CEO that helped sharpen my thinking on this topic. His perspective was simple and honestly hard to argue with: the industry overall is still nowhere near the point where customers are asking product teams to slow down meaningful improvements. Most software still contains enough friction, inefficiencies, and quality-of-life opportunities that customers are thrilled to see rapid progress.

And I think he’s absolutely right. The more I thought about it, the more I realized the issue probably isn’t release speed itself. The issue is understanding the difference between customer value and customer disruption.

Some changes are low-disruption, high-value improvements. Papercut fixes, workflow accelerators, performance improvements, and highly validated customer requests should absolutely move at AI speed. The conference example is a perfect illustration of that. Clear customer pain. Obvious value. Minimal disruption. Ship it immediately.

Other changes carry a very different operational footprint.

Altering navigation, changing terminology, restructuring workflows, modifying permissions, redesigning reporting outputs, or shifting established user habits may still absolutely be the right decisions, but they often require a different level of communication, onboarding, enablement, or rollout planning. Not because customers dislike innovation, but because customers operate businesses on top of your software. Every visible change creates some level of cognitive and operational overhead.

That’s why I don’t think the future state of Product Management is about slowing down releases or reintroducing heavyweight launch bureaucracy. If anything, AI is finally allowing teams to move at the speed customers have wanted for years. But it absolutely raises the bar on judgment.

What should ship immediately? What should be grouped intentionally? What requires enablement? What requires communication? What should customers barely notice at all? That feels like a much more sophisticated discipline than traditional roadmap management.

And honestly, I appreciated the discussion because it reinforced something important for me: this transition is still evolving, and the best thinking is going to come from leaders challenging each other’s assumptions in real time while we all figure out what great looks like in an AI-assisted PDLC.

The organizations that navigate this balance successfully will have a significant advantage. They’ll move quickly without creating chaos. They’ll accelerate innovation without overwhelming customers. And they’ll recognize that customer experience is shaped not just by the quality of features, but by how manageable the pace of change feels over time.

Because ultimately, the real advantage of an AI-assisted PDLC isn’t just faster shipping. It’s faster learning.

Sometimes that means releasing faster. Sometimes it means validating ideas faster. Sometimes it means realizing a feature should never exist in the first place before spending six months building it.

That may end up being the biggest shift of all and the code generation part might actually be the easy part.

In my next blog, I'll begin to tease apart some of the "how" behind this evolution.

Wishing you all the best

Mike