RSS

Tag Archives: #FutureOfWork

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

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.

 

Tags: , , , , , , , , , , , , , , , , , , ,

The Most Expensive Cost-Cutting Decision in Technology

The Most Expensive Cost-Cutting Decision in Technology

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.

 

Tags: , , , , , , , , , , , , , , , , , ,

Beyond the AI buzz: Delivering measurable results through real-world examples

Beyond the AI buzz: Delivering measurable results through real-world examples

I still remember working on an AI initiative 5-6 years ago for a healthcare company that wanted to transform the patient experience. At that time, AI wasn’t readily accessible to everyone. There were no consumer grade AI assistants generating content on demand. There were no established implementation playbooks. Organizations that pursued AI were often entering relatively uncharted territory.

We were building what felt like a first-of-its-kind platform designed to simplify interactions between patients and healthcare providers using AI. While the vision was exciting, the project was filled with uncertainty. Questions such as how to train the model, how frequently retraining should occur, what datasets should be used, what level of accuracy was acceptable, and what operational costs would look like remained largely unanswered. Every decision felt like an experiment.

Today, most of those technical barriers have been significantly reduced. Powerful AI models are available through cloud providers and APIs. Organizations can now build capabilities in weeks that previously would have taken years. But while many technical challenges have become easier, business challenges have become significantly harder.

The challenge today is no longer whether AI works. The challenge is whether companies understand the operational, financial, and governance implications of deploying AI at scale.

One of the most overlooked aspects of AI adoption is cost predictability. Historically, organizations planned budgets around relatively stable variables such as labor, infrastructure, licensing, and operational expenses. Financial forecasts could be created quarterly and adjusted annually with reasonable confidence.

AI is changing that equation. A company’s AI consumption could fluctuate dramatically based on customer adoption and usage patterns. An application might consume 100,000 tokens on one day and 10 Million tokens the next. A highly successful AI-powered feature can introduce operational costs that were never anticipated during planning.

For technology giants such as Microsoft, Apple, Google, Amazon, and Nvidia, these fluctuations can often be absorbed because of their scale and ability to invest heavily in AI infrastructure. For most organizations, however, especially those dependent on product revenue and operating within tighter margins, this new consumption driven model introduces uncertainty that many finance teams have never had to manage before. Thus, today’s companies should shift their focus from “Can we build it?” to “Can we sustainably support it?” That is where organizations need a different approach. 

So, let me provide you some pointers through which you can implement AI sustainably in your organization.

1. Use AI as a Tool, Not a Strategy: 

One of the most common mistakes organizations make is treating AI as a technology initiative instead of a business initiative. AI should never be implemented simply because it is available or because a competitor is using it. If you want to be successful in this AI race, then you need to  identify a specific business outcome and then determine whether AI is the right tool to achieve that outcome.

Instead of asking: “How can we use AI?”, you should ask: “What business problem are we trying to solve?”. The answers should be measurable and meaningful, not just some buzz words. For example, AI will reduce customer service costs by X%, or it will improve employee productivity by Y%, or it will increase customer retention by Z%, etc.

In one Fortune 500, I was called to coach the team in launching an AI chatbot because competitors had announced similar initiatives. But after several workshops, I identified the underlying problem. The real issue turned out to be the excessive amount of time employees spent searching for information across disconnected systems to help their customers. So, rather than building a flashy external facing solution, we implemented an AI-powered knowledge search platform for internal users. Adoption was immediate, employee productivity improved by 20%, and the ROI justified the costs of tokens. Thus, I recommend that you should also focus on outcomes first and technology second.

2. Start With High-Value Use Cases

Many Fortune 500 companies are attempting AI transformation through large, organization-wide initiatives. While it might work for 20% of the top tech companies, I believe that other Orgs should identify use cases that are easy to measure and relatively low risk, before heavily investing into AI transformation. In some of the companies where I have recently consulted, I often see AI augmentation opportunities within internal knowledge management, customer support automation, document summarization, meeting intelligence, workflow automation, and sales enablement.

For example, in one of the largest companies, we introduced AI-generated meeting summaries for their sales calls. While this initiative sounds relatively small compared to larger transformation, the productivity gains and lead conversion rates were transformational for the company. SDRs and BDRs had all the insights about their clients on their fingertips and they spent less time in refreshing their memories and more time in converting the lead into an actual sale. 

Thus, I believe that AI should be used in these targeted initiatives to provide immediate value and actual ROI. This approach isn’t flashy, but it works. Small wins create confidence, confidence creates momentum, and momentum enables scale.

3. Build Guardrails Before Scaling

Once organizations begin seeing success, there is a natural temptation to expand AI rapidly. After all, C-Suites are pushed by their stakeholders to show big wins through AI quickly. 

However, I believe that AI adoption without governance can quickly become expensive, inconsistent, and difficult to manage. I strongly believe that all the Orgs should establish guardrails before broad deployment. This includes monitoring usage trends, creating cost management controls, setting spending thresholds, defining approval processes, implementing security standards, and establishing performance monitoring frameworks.

Recently, I was coaching this S&P 500 company that had seen situations where individual departments adopted multiple AI solutions independently. Marketing purchased one platform, operations implemented another, and customer support selected a third. While each decision appeared reasonable in isolation, the organization eventually found itself managing overlapping vendors, inconsistent security controls, and rapidly increasing costs. Thus, I strongly recommend you to think through your AI strategy and implement internal support systems for building guardrails and governance before everything goes out of hand.

In the end, the organizations that succeed with AI over the next decade will not necessarily be those spending the most money or tokens. They will be the companies that approach AI with discipline. They will understand the difference between experimentation and strategy. They will balance innovation with governance, ambition with financial accountability, and opportunity with measurable outcomes. Most importantly, they will stop asking: “How can we say we are using AI?” And instead ask: “Where can AI create sustainable business value?” That distinction may seem small, but it changes everything.

The future will not belong to companies that can simply claim they use AI. It will belong to companies that can clearly demonstrate why they use AI, how they govern it, and the value it delivers. Because in the end, AI should be more than a buzzword. It should be an impact multiplier.  

 

Tags: , , , , , , , , , , , , , , , , , , ,

New Operating Model for Product & Engineering Ops in the World of AI

New Operating Model for Product & Engineering Ops in the World of AI

When I first saw teams experimenting with AI before it became cool, the behavior felt really familiar. It reminded me of how teams treated Agile in the early days, something you “use/follow” rather than something that fundamentally reshapes how work flows. Teams were excited, curious, and well intentioned, but almost everyone was underestimating the change in front of them.

At larger enterprises like GE and Schneider, operations always lived a layer below the visible product surface. Customers never see the spreadsheets, the JIRA workflows, the dependency maps, or executive readouts, but those invisible systems determined whether strategy delivered the outcomes that we were looking for. AI is now inserting itself directly into that invisible layer.

Most teams today are using AI as a chatbot. They paste in meeting notes, ask for summaries, maybe generate a PRD draft or clean up status language. That’s fine, but it’s also like using a high performance engine only to power the radio. The real power shows up when AI becomes part of how decisions get made, not just how words get written.

I saw a version of this contrast clearly when working with startups versus large enterprises. Startups rarely debate whether a process is “ready.” They automate thinking early because speed leaves no alternative. In contrast, large organizations often wait for certainty, governance, and sign‑off, which delays leverage. AI flips this dynamic. For the first time, large companies can gain a startup‑like operational awareness without burning people out.

The biggest mental shift is this: AI is not just another productivity tool, it is an operating layer that sits between data and action. Every organization already has raw inputs: roadmaps, sprint plans, incident logs, metrics, emails, Slack threads. What most lack is synthesis at scale. Humans do this manually, inconsistently, and too late. AI changes that.

One of the most effective early experiments I have seen is when we stop asking AI to “do work” and start asking it to “explain the system.” Thus, I often ask questions like: What changed this week that mattered? Where are we accumulating hidden risk? What assumptions are we acting as if they are true, but haven’t validated recently? These questions help me sharpen my approach and provide insights that I can quickly review and validate with my organization’s strategy.

Another practical way to begin is to deliberately wire AI into your operating cadence. For example, before every weekly program review, I feed my model JIRA updates, dependency map, and roadmap changes. After that I ask it for a narrative and compare it against my overall understanding of the program. This approach has helped me cut down my manual tasks by almost 40%. Recently, I have started providing some additional context to my model and started asking it what tradeoffs it will make based on the information and using that to improve program’s execution. If you follow this approach, then overtime AI will become your partner and help you expedite decision making. 

I believe that the teams that win with AI won’t be the ones who generate content faster. They will be the ones who design systems where insight appears earlier, decisions happen cleaner, and surprises shrink. This isn’t a tooling upgrade, it is an operating model shift.

 

Tags: , , , , , , , , , , , , ,