RSS

Tag Archives: #TechLeadership

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: , , , , , , , , , , , , , , , , , , ,

Dependency Management with AI: From Tracking to Forecasting

Dependency Management with AI: From Tracking to Forecasting

A few years ago, I was in a Roadmap Planning Onsite in a room full of incredibly smart, driven people, the kind of team any company would be proud of. Product leaders, engineers, designers, program managers, everyone aligned, everyone motivated. The roadmap looked solid, the timelines felt achievable, and there was real excitement in the air. If you had walked in at that moment, you would have confidently predicted a couple of successful launches. And yet… these launches slipped.

It didn’t happen all at once. First, a small delay in a review. Then a meeting got pushed out. A dependency that seemed “almost ready” turned out not to be ready at all. One team was waiting on another, and that team, in turn, was waiting on someone else. Before long, what had started as well planned initiatives turned into a series of urgent follow-ups, escalations, and frustration.

What struck me most was this: no one lacked talent, and no one wasn’t working hard. The failure wasn’t about capability. It was about something much quieter and far more dangerous…….unmanaged dependencies.

In smaller companies, this problem is easier to avoid. Decisions happen quickly, often made by a single founder or a small group of leaders. Teams are lean, and the same people who define the problem often see it through to completion. Dependencies still exist, but they are visible, human, and manageable. If something is blocked, everyone knows about it almost immediately, and adjustments happen quickly. The feedback loop is tight, and the risk is contained.

But as organizations grow, so does complexity. What used to be a simple flow, from idea to execution, turns into a chain of handoffs. Product defines the “what,” design shapes the experience, engineering builds it, QA tests it, DevOps deploys it, and along the way, legal, finance, content, and other teams may also get involved. No single person owns the entire journey anymore. Instead, execution depends on how well these teams coordinate with each other. And that’s where things start to break down.

Without a clear operating model and a strong way to track and manage dependencies, teams begin to work in silos. Each team focuses on its own deliverables, assuming that everything else will fall into place. Progress is reported optimistically, but risks remain hidden until it’s too late. Eventually, you start hearing the same familiar line: “We have done everything on our end, but we are blocked by another team.”

On the surface, that sounds reasonable. But when every team is saying it, it points to a deeper issue. It means the system itself is not working.

One of the most challenging aspects of dependencies is that they rarely fail loudly. They fail quietly, almost politely. A review gets postponed. A requirement remains unclear. A deliverable is “in progress” just a little longer than expected. Nothing feels urgent in the moment, so it doesn’t get escalated. But over time, these small slips compound. By the time the impact becomes visible, the situation is already critical. Deadlines are missed, launch dates shift, and trust between teams begins to erode.

I have seen this play out in both small and large organizations. In smaller teams, you might lose a few weeks before the issue becomes visible. In larger enterprises, the problem becomes even harder to detect. Dependencies spread across teams, tools, systems, and time zones. They get buried in JIRA, Asana or Trello tickets, scattered across calendars, and diluted across layers of communication. They don’t become less severe, they just become harder to see.

Take a simple example. Your team is ready to launch an A/B test. Everything is built, tested, and ready to go. You assumed that the experimentation platform team would support your test when you needed it. But it turns out that team is already running multiple experiments and doesn’t have the capacity to take yours on. No one flagged it early, no one anticipated it, and now your launch is blocked. What seemed like a minor assumption quietly becomes a major delay, impacting not just one feature, but potentially a significant portion of your roadmap.

This is why, in my experience, unmanaged dependencies are the single most consistent reason why even the best companies struggle to execute. It’s not technical difficulty. It’s not lack of talent. It’s the invisible gaps between teams.

What is encouraging, though, is that this is starting to change. One of the most powerful shifts I have seen with GenAI is the move from simply tracking dependencies to actively forecasting them. Instead of asking AI, “What are our dependencies?” teams are beginning to ask better questions like “Which dependency is most likely to surprise us?” “Which team is likely to become a bottleneck based on past data?” “What should we be watching closely in the next few weeks?”

This shift changes the entire tone of planning. Conversations move away from debating optimistic timelines and toward understanding risk and building resilience.

This is where AI plays a transformative role. AI is uniquely good at something humans struggle with at scale, it can reason across both time and structure. It can look at historical patterns and identify where delays typically occur. It can spot patterns in scheduling mismatches, highlight recurring bottlenecks, and even identify situations where one team consistently absorbs the impact of another team’s delays. Traditional tools (like JIRA, Asana, Planview PPM) show you connections between Features, Epics, and their relevant User Stories/Tasks. However, AI takes this further and it helps you understand the consequences of those connections.

And when teams start working this way, something interesting happens. Conversations become calmer and happen earlier. Risks feel less like surprises. Escalations decrease. Instead of reacting to problems at the last minute, teams begin to anticipate them and adjust ahead of time. The culture shifts from blame to problem-solving, from urgency to clarity.

In the end, execution doesn’t fail because people aren’t capable or committed. It fails because the space between teams is left unmanaged. When that space is made visible, when dependencies are not just tracked but understood and anticipated, everything changes. Teams move faster, with more confidence, and with far less friction. And that’s the real unlock: not just building great things, but building the systems that allow great teams to deliver them, consistently and predictably.

 

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

How AI is Redefining Product Management: From Writing PRDs to Rasing the Bar

How AI is Redefining Product Management: From Writing PRDs to Rasing the Bar

During my second week at Facebook, mid-pandemic, onboarding remotely into the VR org, I joined a product review where a PM spent more time challenging their own proposal than defending it. Before anyone else could question it, they walked through what might break, where adoption could fail, and what risks Legal or Infra would raise. By the time feedback started, most of the obvious objections had already been addressed. 

That was my first real glimpse into how the strongest product managers operate. They don’t just present ideas, they argue with them. I have seen similar behavior in startups, but there it usually comes from necessity, limited resources force sharper thinking. In Fortune 500 companies, this kind of rigor comes from discipline.

That’s where AI changes the game today. AI gives every PM a first-pass sparring partner, but only if you use it the right way. Today, most teams use AI to generate PRDs, architecture docs, epics, and user stories. That’s useful, but it misses the point.

The real leverage shows up when AI becomes the voice that challenges you: “Here’s what you might be wrong about.” It’s particularly effective at surfacing blind spots like downstream dependencies, operational risks, users you overlooked, or costs that don’t show up in feature narratives.

Over the past few years, I have coached many PMs to use AI differently. Instead of asking it to generate output, we trained AI to think like stakeholders. At Amazon, for example, we created detailed personas for 3rd party sellers, engineering leaders, legal, finance, marketing, and operations teams. PMs would then prompt AI to respond from those perspectives:

  • What would Legal push back on?
  • How would Finance evaluate this investment?
  • What risks would Operations flag?
  • What architectural dependencies could delay the launch?

Early on, the outputs had rough edges. But as models improved, this approach became increasingly powerful, because product decisions rarely live in isolation.

One PM I worked with used this exact approach while planning a new seller facing feature. On the surface, it looked straightforward, improving onboarding flows to increase seller activation. The PRD was clean, the metrics were strong, and engineering had already sized it.

Before finalizing, we ran the idea through stakeholder based AI prompts. When prompted as “Legal,” AI flagged a potential compliance issue with how seller data was being surfaced across regions. When prompted as “Finance,” it highlighted an unaccounted cost in supporting international payment reconciliation. And from an “Operations” lens, it exposed a spike in expected support tickets due to onboarding ambiguity in edge cases.

None of these were obvious in the original proposal. Catching them early avoided what would have likely been a delayed launch and a much more expensive fix post-release. That’s the real value.

Over time, PMs who use AI this way will produce sharper, clearer proposals, not because AI wrote them, but because weak thinking was exposed earlier, grounded in data and organizational context. Thus, AI becomes a forcing function for rigor. And that leads to a broader implication: Product excellence has never been about output volume. It has always been about decision quality and the outcomes those decisions drive.

AI is now raising the bar for decision hygiene and quietly exposing teams that rely on intuition without validation.

 

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: , , , , , , , , , , , , ,

Navigating A/B Testing Challenges: A Journey Through Real-world Solutions

Navigating A/B Testing Challenges: A Journey Through Real-world Solutions

As a technology leader over two decades of experience, I’ve witnessed firsthand the transformative power of A/B testing in driving revenue growth and customer-centric innovation. However, this journey is not without its challenges. In this blog, I share my insights and practical tips to help you and your team master the art of A/B testing without sacrificing quality or speed.

Establish Clear Experimentation Guidelines: Overlooking experimentation guidelines can lead to unforeseen consequences, as I learned the hard way when we mistakenly mixed up test and control cohorts, resulting in inaccurate experiment results and a costly rollout. To prevent such mishaps, invest time in creating clear experimentation guidelines and educating your team on their proper implementation.

Utilize the Staging Environment: Never offload testing responsibilities onto your customers. Always test your experiments in a staging environment before launching them to a subset of users. In one instance, a company failed to test a payment integration in staging, resulting in a $30,000 loss. By adopting a rigorous staging environment testing process, you can identify and address issues before they impact your users.

Implement Feature Flags: Rushing experiments without a proper feature flag framework can lead to chaos. In one project, we had to revert to an older code version after launching an experiment due to the lack of feature flags. Establish a standardized practice for using feature flags to enable smoother experimentation and rollouts.

Enhance User Acceptance Testing (UAT): Relying solely on shift-left testing can introduce bugs into production. To address this, implement Sprint Demos, a practice that allows for early identification and resolution of issues. This agile approach ensures that your features are thoroughly tested before reaching users.

Maintain JIRA Hygiene: A well-structured JIRA framework can streamline experiment tracking and prevent delays. In one company, inconsistent JIRA usage led to a backlog of experiments exceeding their timelines, resulting in revenue loss. Regularly update and track experiments in JIRA to maintain a smooth workflow and identify experiments requiring attention.

Conduct Regular Product Reviews: If you’re running multiple experiments, consider implementing product reviews to collaboratively assess experiment results. This approach not only enhances team learning but also helps identify and eliminate underperforming experiments. Collaborative cleanups are crucial, especially when reviewing legacy solutions.

Implement Continuous Monitoring and Rollback Plans: Even with the best intentions, experiments can go awry. Always have a comprehensive rollback plan in place and continuously monitor experiment progress. Minor anomalies can escalate without proper monitoring. Establishing a regular monitoring cadence ensures swift resolution in case of unexpected challenges.

A/B testing is a delicate balance between innovation and stability. Each challenge we face presents an opportunity to refine our approach. By embracing these insights, you can navigate the world of A/B testing with confidence, delivering impactful features while maintaining velocity. Remember, A/B testing is an ongoing journey of learning and improvement. Embrace the challenges and continuously strive to optimize your experimentation process.


Relevant Hashtags: #ABTestingJourney, #SoftwareDevelopment, #InnovationStories, #TechSolutions, #CodingWisdom, #AgileDevelopment, #ExperimentationSuccess, #ProductReviewFramework, #SoftwareCrafting, #ContinuousMonitoring, #TechLeadership, #UATefficiency, #JIRAHygiene, #DevelopmentChallenges, #RollbackStrategies

 
 

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