RSS

Tag Archives: #TechnicalProgramManagement

Why Most AI POCs Stall and How to Build an AI Operating Model That Works

A few months ago, I was speaking with a leadership team that had invested heavily in Generative AI. They had done everything right, at least on paper. They hosted hackathons, launched AI innovation days, encouraged teams to experiment with tools like ChatGPT, Cursor, Claude, and Gemini, and generated dozens of exciting proof of concepts (POCs). The demos were impressive. The excitement was real. Then I asked a simple question: “How many of these solutions are actually running in production and creating measurable business value?” The room went quiet.

If you have been involved in AI initiatives, you have probably seen the same pattern. Teams produce innovative AI prototypes, leadership gets excited, and everyone talks about transformation. Yet months later, very few of those ideas become dependable, secure, and widely adopted business solutions.

The problem isn’t the technology. Today’s AI models are incredibly capable. The problem is that most organizations are trying to scale AI without building the operational framework needed to support it. In my experience, the companies that successfully scale AI don’t necessarily have the best models. They have the best operating model.

One of the first challenges organizations encounter is what I call the “happy path” problem. Most AI POCs are built using clean data, predictable scenarios, and carefully controlled environments. Real-world systems rarely behave that way. Customers enter incomplete information, business rules change, systems fail, and unexpected edge cases appear. Many teams react by trying to perfect the solution before launch, spending months solving hypothetical problems. However, I believe that the smarter approach is the simpler one: release a focused solution to a targeted audience, gather feedback, learn from real-world usage, and improve iteratively. The fastest way to build a production ready AI product is to get real users into the loop as early as possible, not to spend months and years to perfect a solution.

Even when organizations overcome that hurdle, they often run into a second challenge: data and integration issues. Most AI failures are not actually AI failures. They are data failures, process failures, or integration failures. A POC can operate on a carefully curated dataset, but production systems need secure data pipelines, governance controls, monitoring, observability, auditability, and integration with existing business workflows. I have seen organizations spend months debating which model to use while completely overlooking the fact that their underlying data ecosystem wasn’t ready. Thus, companies should invest in building a stronger data pipeline, improving their integration testing capabilities, and creating an operational framework that can accelerate pace of innovation. After all, the AI isn’t the problem, the foundation is.

Another common trap is measuring activity rather than outcomes. These days, organizations proudly report the number of tokens used, experiments conducted, prompts executed, or AI tools adopted. Those metrics may indicate engagement, but they don’t necessarily indicate value. The questions leaders should be asking are much simpler: Did customer satisfaction improve? Did operational costs decrease? Did revenue increase? Did employee productivity improve? AI creates value only when it is connected to measurable business outcomes. Everything else is experimentation. That’s why I recommend that organizations regularly review AI adoption, engagement, and ROI through existing governance forums such as Monthly Product Reviews (MPRs), Monthly Business Reviews (MBRs), Engineering Operations Reviews, and Level 10 (L10) meetings. These forums help connect AI initiatives to measurable business outcomes, making it easier to understand what’s creating value, what’s falling short, and where organizations should focus their next investments.

As organizations mature, AI governance becomes increasingly important. Unfortunately, AI governance has developed a bad reputation and is often viewed as the enemy of innovation, since AI models are evolving at an unprecedented pace, heavyweight governance processes often struggle to keep up. In reality, governance is what allows innovation to scale safely. Whether it’s privacy, security, compliance, responsible AI, or human oversight, organizations need clear and repeatable processes that help teams move quickly while managing risk responsibly. The Air Canada chatbot incident serves as a reminder that companies remain accountable for what their AI systems do, regardless of how autonomous those systems may appear. Thus, I recommend that organizations rethink their decade-old governance models. Since AI is evolving rapidly, innovators should not have to navigate multiple approvals and disconnected stakeholders just to get an AI use case reviewed. Instead, organizations should establish a centralized governance forum where teams can bring ideas, ask questions, receive timely guidance, and understand the rationale behind governance decisions. The goal is not to reduce oversight, but to streamline it. By creating a transparent, well-socialized, and operationalized governance framework with regular follow-ups and clear communication, organizations can strengthen governance while simultaneously accelerating the pace of innovation.

Another common mistake organizations make is failing to invest in their people. Like any major transformation, AI augmentation is ultimately a transformation of how people work. Simply providing access to AI models or GenAI tools does not guarantee success. Organizations need to invest heavily in AI literacy, change management, coaching, upskilling, and adoption strategies, just as they would for any other enterprise-wide transformation. Leaders cannot assume that because AI tools are available, employees will automatically use them effectively or that productivity will magically improve. Without the right training, guidance, and support, most employees will either underutilize AI or use it only for basic tasks. Employees need to understand where AI can help, where it cannot, and how to integrate it into their daily workflows responsibly and effectively. After all, if people continue to view AI as nothing more than a chatbot, the vision of building AI-powered assistants, autonomous workflows, and agentic AI solutions will remain out of reach. This is why leaders must build an operating model that reinforces the right behaviors, creates opportunities for learning, and encourages adoption through the right incentives. Ultimately, AI transformation is not a technology transformation. It is a people transformation.

Finally, organizations need to answer one critical question: When AI fails, who is accountable? As tools like Claude, Gemini, Cursor, and GitHub Copilot become part of everyday software development, accountability can quickly become blurred. My view is straightforward. AI can generate content, code, and recommendations, but it cannot own responsibility. The engineer who deploys the code remains accountable for its quality. The product manager who launches the feature remains accountable for its business impact. Human ownership must remain intact, regardless of how much AI contributed to the solution.

The biggest obstacle preventing companies from realizing value from AI isn’t model performance or innovation. It’s the absence of an AI operating system that connects governance, measurement, accountability, data readiness, and talent development into a repeatable framework. AI doesn’t reduce our need for leadership, governance, operational excellence, or execution discipline. It increases it.

3 Comments

Posted by Bhavin Gandhi on August 26, 2026 in 21st Century, AI Leadership, Leadership, Management, technology

Tags: #AgenticAI, #AIAdoption, #AIGovernance, #AILeadership, #AIOperatingModel, #AIStrategy, #AITransformation, #BusinessTransformation, #ChangeManagement, #DigitalTransformation, #EngineeringLeadership, #EnterpriseAI, #FutureOfWork, #GenerativeAI, #InnovationManagement, #OperationalExcellence, #ProductManagement, #programmanagement, #ResponsibleAI, #TechnicalProgramManagement

The Most Expensive Cost-Cutting Decision in Technology

13 Aug

Over the last two decades, I have had the opportunity to work with startups, growth-stage companies, and some of the world’s largest enterprises. Across these organizations, I have helped product, engineering, design, and quality teams improve the way they operate. Sometimes the challenge was a lack of strategic alignment. Sometimes teams were working hard but prioritizing the wrong things. Other times the problem was execution, where ownership, planning, and delivery were disconnected from one another. Regardless of the company or industry, one lesson has remained surprisingly consistent: success is rarely determined by great ideas alone. It is usually determined by the operating system that helps teams turn those ideas into reality.

Unfortunately, that operating system is often the first thing leaders cut when revenue falls short and budgets need to be reduced. I have seen this happen more times than I can count. A company misses its financial goals and leadership begins reviewing costs. Product teams are viewed as essential because they drive innovation and define the future roadmap. Engineering teams are viewed as essential because they build the product and deliver features. Design teams are viewed as critical because they shape the customer experience. Then attention turns toward Technical Program Managers (TPMs), Project Managers, Delivery Managers, and PMO organizations. Since these teams are not directly writing code or defining product features, they are often perceived as overhead. The conclusion becomes simple: remove the program management layer and allow product and engineering leaders to absorb the responsibilities.

On paper, the decision sounds reasonable. However, it often creates far more problems than it solves. I have personally witnessed this firsthand in multiple startups I supported throughout my career. In two of the companies I worked at, leadership reduced a significant portion of the TPM and program management function during periods of financial pressure. The assumption was that product managers and engineering leaders could take over the coordination work while continuing to execute their existing responsibilities. Leaders hoped this would reduce costs without affecting delivery speed or business outcomes.

The opposite happened. Within a few months, product managers found themselves spending less time talking to customers and more time tracking dependencies across teams. Instead of validating market opportunities, refining roadmaps, and measuring customer outcomes, they were coordinating schedules, chasing updates, preparing reports, and managing delivery risks. At the same time, engineering leaders became consumed with sprint planning, program reviews, portfolio reporting, PI planning sessions, and other operational activities. Rather than focusing on architectural improvements, engineering productivity, DevOps optimization, developer experience, and technical mentorship, they were forced to fill an operational gap that nobody had anticipated. The work itself did not disappear. It simply moved to people who were hired to do something else.

As a result, execution slowed down, planning became less predictable, dependencies fell through the cracks, and leadership visibility decreased. While the company saved money on a spreadsheet, it lost efficiency across the organization.

One reason this happens is because great program management is often invisible. When TPMs and PMO teams are performing well, most people do not notice the work they are doing. They see smooth planning cycles. They see aligned roadmaps. They see risks identified early. They see stakeholders staying informed. They see teams moving together toward common objectives. Because the outcomes appear seamless, it becomes easy to underestimate the effort required to create and maintain that alignment.

The best way I can describe it is this: program management is the operating system of an organization. Just as Windows/Mac operating system allows hardware and software to work together efficiently, TPMs and PMO leaders create the frameworks, governance, communication channels, and execution mechanisms that allow product, engineering, design, and QA teams to work effectively together. When you remove the operating system, the individual components still exist, but they stop functioning together at the same level of efficiency.

This becomes particularly important as organizations scale. In small teams, coordination can happen organically. People can walk across the room, have a quick conversation, and resolve issues immediately. However, as organizations grow, dependencies increase. More stakeholders become involved. Priorities compete for attention. Teams become distributed across locations and time zones. Without strong operational frameworks and cross-functional governance, execution naturally becomes more difficult.

Many leaders today argue that Artificial Intelligence (AI) will eliminate the need for large PMO organizations. There is certainly some truth to that argument. AI is already helping organizations automate reporting, generate dashboards, summarize meetings, identify risks, and track work more effectively than ever before. I personally believe these innovations will continue to transform how TPMs and PMOs operate over the next several years.

However, automating tasks is not the same as replacing a function. AI can generate a status report. It cannot always drive organizational alignment. AI can identify a delivery risk. It cannot negotiate priorities across competing stakeholders. AI can provide project insights. It cannot build trust among leaders, challenge assumptions, facilitate difficult decisions, or create accountability across teams. The most valuable work performed by modern TPMs is not administrative. It is strategic. It is helping organizations make better decisions, focus on the highest-value work, resolve complex dependencies, and improve how teams operate together.

The irony is that companies often spend enormous amounts of money trying to improve engineering productivity, accelerate software delivery, improve customer outcomes, and increase organizational effectiveness, while simultaneously reducing the very teams responsible for enabling those outcomes. They invest heavily in building products but underinvest in the systems that make product development successful.

In my experience, the highest-performing organizations understand that operational excellence is not a luxury. It is a competitive advantage. They recognize that product managers should spend most of their time understanding customers, validating roadmaps, and measuring business outcomes. They recognize that engineering leaders should spend their time improving architecture, strengthening DevOps capabilities, mentoring engineers, and increasing delivery efficiency. They also recognize that somebody needs to own cross-functional execution, strategic prioritization, governance, dependency management, and organizational effectiveness. That “somebody” is often your TPM and PMO organization.

Are there program managers who simply act as messengers between teams? Absolutely. Every profession has people who contribute more value than others. But judging the importance of an entire function based on its weakest examples is a mistake. The best TPMs create leverage across the entire organization. They help companies prioritize strategic bets, improve product development processes, streamline software delivery, increase engineering productivity, strengthen Agile execution, and drive better business outcomes.

As technology continues to evolve and AI becomes increasingly capable, I believe the TPM role will evolve as well. Routine administrative work will continue to be automated. Reporting will become easier. Data collection will become smarter. But the need for leaders who can align strategy with execution, drive cross-functional collaboration, optimize operating models, and help teams deliver value faster is not going away anytime soon. If anything, it is becoming more important.

The next time an organization considers reducing its TPM, Project Management, or PMO function as a cost-saving measure, I would encourage leaders to pause and ask a simple question: Who will own the operating system that makes execution possible? Because building great products is only half the challenge. Building an organization that can repeatedly deliver those products at scale is what separates companies that survive from those that truly win.