My path into this work looks linear in hindsight, though it rarely felt that way while I was walking it.

I began as a data analyst, which is where you learn what raw data actually looks like. Messy, incomplete, and rarely structured the way the business assumes. From there I moved into data engineering, and that changed my thinking permanently. Once you've been accountable for pipelines, you stop treating reliability and governance as somebody else's concern. They become the precondition for anything worth building on top.

The move into product management came from noticing the same failure repeatedly. Technically excellent work would ship and quietly go unused, because nobody had been rigorous about the decision it was meant to serve. Product gave me the mandate to fix that at the source, starting from the business question rather than the dataset.

Somewhere during my consulting years I noticed something about myself that mattered more than any technical skill I had. What I was genuinely good at was reading a room. Understanding what each person actually needed, finding where their positions overlapped, and bringing a group that disagreed to a single decision they could all stand behind. Technical capability got me into those rooms. That was what made me useful once I was there, and it is what eventually pointed me toward product management.

So the journey reads as analyst, engineer, product leader. But the thread never changed. I've always been interested in the distance between what data can tell an organization and what that organization actually does with it, and in the people standing in that gap.

Frustration, initially. Early on I watched a genuine amount of skilled analytical effort go to waste, not because the work was poor but because it answered questions nobody had asked. Meanwhile the questions leadership actually needed answered went unaddressed, because the analytics team was buried under routine requests. That mismatch bothered me enough that I wanted to work on the system producing it rather than on individual outputs within it.

What drew me to the intersection specifically is that no single discipline resolves this alone. Data teams optimize for accuracy. Engineering optimizes for scale and stability. Business leaders optimize for speed of decision. All three are correct, and none is sufficient. Product is the discipline that holds that tension and forces a resolution. I found I enjoyed that far more than any of the individual crafts.

AI sharpened the appeal considerably. For most of my career the bottleneck in analytics was human capacity, a finite number of people answering an infinite queue of questions. Generative AI is the first credible answer to that constraint I've encountered. It moves analytics from something you request to something you have.

There's a human dimension too, and I'd argue it's the more important one. Technology is only interesting to me where it removes something that was making a person's work harder than it needed to be. That's what I responded to when I automated my first tedious report for a colleague, and it's what I respond to now at a considerably larger scale. Through @edubhav I speak with thousands of people trying to enter this field, and keeping close to their difficulties keeps me honest about which problems are worth solving.

Three environments shaped me, and each taught me something the others could not. Enterprise consulting first, then a high-growth fintech, and now enterprise technology. Together they account for most of how I operate.

The first taught me rigour and respect for foundations. Working across complex enterprise data landscapes, you learn quickly that ambition without data quality is a liability. If the underlying data isn't trustworthy, an AI layer doesn't create value. It industrializes the distribution of bad conclusions. That period also taught me to translate between technical and commercial language, and that the fastest way to understand a business is to help someone in it with something difficult.

The second taught me strategy under constraint. In a leaner organization there's nowhere to hide behind process, and the binding constraint is always prioritization. You cannot build everything, so you become genuinely ruthless about what moves the business. Establishing analytics as an enterprise capability there taught me that adoption is a product problem, not a training problem. If people must be persuaded to use something, the design is usually at fault.

Currently, both lessons converge, and I work most closely with the people who make this possible. My days are spent with analytics engineers, data scientists, and data analysts, and increasingly with the teams who work directly with customers every day, who understand how customers actually think in a way no dataset conveys on its own. The products we build are data products at their core, with AI layered on top of a foundation that has to be right first. An intelligent layer is only ever as good as the data models, pipelines, and definitions beneath it, and most of the hard work happens well before anything looks intelligent.

Building data products that reach customers also imposes a discipline around trust that internal analytics never demanded of me. Customers forgive a slow answer far more readily than a confident wrong one. So data quality boundaries, explainability, and knowing where a system should defer to a human become product requirements rather than technical afterthoughts. Nowhere is that clearer than in predictive customer work, where one confidently wrong signal costs an account team's trust faster than ten missing ones.

The synthesis is simple. Build on foundations you trust, prioritize against business outcomes rather than technical possibility, and design for adoption from day one rather than after launch.

The initiative that has defined my recent work is a unified customer data platform, built around a question most enterprises cannot answer. What is this customer actually telling us, across everything they have ever said to us?

The problem is fragmentation, not scarcity. Every organization holds an enormous volume of customer data, sitting in disconnected systems. Service records live in one platform, conversational data in another, feedback and behavioural signals somewhere else again. Each of those is a dataset in its own right, with its own structure, its own quality issues, and its own definition of what a customer even is. Individually each is a fragment. Collectively they are a fairly complete account of the relationship.

So the first and largest phase of this work was not AI at all. It was data work. Establishing a single customer identity across systems that had never agreed on one. Building the pipelines to bring hundreds of touchpoint types into a common model. Resolving conflicting definitions, handling the gaps, and getting the quality to a standard where an analytical output could actually be trusted. That phase absorbed the bulk of the effort, and it is the reason everything after it works. Every organization that skips this stage and jumps to the modelling ends up with a sophisticated system producing unreliable conclusions.

With that foundation in place, we applied an AI layer that reads across the unified dataset alongside everything else we know about a customer. Getting that layer to produce something believable took close partnership with the teams who work directly with customers, because they know which signals genuinely precede a customer disengaging and which ones look alarming but mean very little. A model can find correlation. It takes people who sit with customers every day to tell you which correlations are worth acting on. The output works in two directions. It surfaces early indicators of churn risk, so teams can intervene while intervention still matters. And it identifies where behaviour points to genuine unmet need, which is where credible expansion conversations begin. 

The outcome I find most meaningful is the change in posture. Conversations that used to begin with a customer already frustrated now begin earlier, with context, and with a clearer sense of what they actually need. The durable gain is that account teams stopped operating on instinct and started operating on evidence.

I want to be precise about the scale, because that is where AI changed what was possible. Every conversation a customer has had with us, accumulated across years, much of it unstructured text. Traditional analytics could aggregate the structured portion, but nobody could read across the whole of it and form a coherent view of how a customer feels. Analysts sampled, or relied on an account manager's memory, and both are lossy. This is a category of insight that did not previously exist.

As product manager I set the problem definition, drove the prioritization, and made the calls on how insight reached the people who act on it. Analytics engineering, data science, and the teams closest to the customer each brought expertise I do not have, and my job was to keep those disciplines pointed at one outcome. That is what made the programme work. 

The clearest way I can put it is this. A dashboard answers the questions you had on the day it was built.

That is the constraint we have all quietly accepted for a decade. Requirements are gathered, a dashboard is built, and it serves those questions well. But business questions do not hold still. The moment someone asks why a number moved in this region, for this segment, last quarter, the dashboard is finished and a request enters a queue. Days pass. By the time the answer arrives, the decision has often been made without it.

Generative AI removes that constraint. Instead of a static view built for anticipated questions, you have a conversational layer where people ask what they actually want to know, including questions nobody could have predicted at build time. The answer arrives inside the moment of thinking rather than a week later. That is not a better dashboard. It is a different relationship between people and their data.

What this actually demands, though, is a stronger data layer than most organizations have ever needed. A dashboard is a curated path through data, and an analyst quietly compensates for whatever is inconsistent underneath. An AI agent has no such filter. It will traverse whatever you give it, so the semantic model, the definitions, and the pipeline reliability have to be genuinely sound. The interface gets easier and the engineering underneath gets harder.

The second shift is scale, and I find it more significant. An entire category of analysis was previously out of reach, not because the data was missing but because most of it was unstructured and nobody could process it at volume. That is now tractable, and it changes what a customer relationship can be.

For product management specifically, the job changes. When production is no longer the bottleneck, judgement becomes the differentiator. Value moves to asking the right question, framing the problem correctly, and being rigorous about trust. A system that answers instantly and confidently is persuasive whether or not it is correct, so knowing where a model should defer, and making its reasoning visible, becomes a core product requirement.

My expectation is that the winners will not be the organizations with the best models. Those are increasingly commoditized. It will be those with the best data foundations, and those who redesigned how decisions get made around the new capability instead of layering it on top of the old process.

The gap is rarely one of goodwill. Everyone wants the product to succeed. The gap is that each function carries a different definition of done, and left unexamined, three capable teams work hard in slightly divergent directions for months before anyone notices.

Four things have worked consistently.

Define the decision before defining the solution. Not the metric, not the model. The decision. Who will do something differently because this exists, and what will they do? If that cannot be answered in a sentence, the project is not ready, however compelling the data. This single question resolves more disagreement than any amount of alignment meeting, because it gives three teams one shared object to argue about instead of three separate ones.

Agree what good enough means, early and explicitly. Data science is trained to pursue accuracy, rightly. Engineering is accountable for behaviour at scale. The business needs an answer this quarter. All three positions are legitimate, and left unresolved they surface as friction near a deadline. Naming the threshold at the start converts a late conflict into an early decision.

Translate in both directions, and treat it as real work. A meaningful part of my job is ensuring the business understands what a confidence interval means for their decision, and that technical teams understand the commercial cost of a false positive. Neither side is obliged to learn the other's language. Someone has to carry it.

Show something real, early. Written specifications create the illusion of agreement. People read the same document and picture different products. A rough working version, even a poor one, exposes the misunderstanding in an hour rather than a quarter.

Underneath all four is a posture rather than a process. My job is to ensure that expertise is aimed at something the business genuinely needs, and to remove whatever is in its way. When it works, nobody feels managed. They feel unblocked. In my experience that is also how you earn the right to lead people who are more technical than you are.

Most failed AI programmes I have observed did not fail technically. They worked in a pilot, impressed a leadership audience, and never entered how the organization actually operates. Four obstacles account for most of it.

The data foundation is weaker than anyone admits. Enterprises consistently underestimate the state of their own data. Ownership is unclear, definitions differ between departments, quality is inconsistent. AI does not forgive any of this. It amplifies it at speed. Leaders should treat analytics engineering and governance as part of the AI investment, not as a prerequisite to be skipped for the sake of momentum.

Pilots are optimized for approval rather than adoption. A proof of concept succeeds with curated data and an enthusiastic team. Production involves messy inputs, sceptical users, and people who already have a way of doing their job. Design for the workflow from day one. Where does the insight surface, who receives it, and what are they expected to do next? If nobody's routine changes, nothing has been delivered.

Trust is treated as a communications problem when it is a design problem. People do not reject AI because they fear technology. They reject it because they were once given a confident answer that was wrong and had no way of knowing. Explainability and clear boundaries are product requirements. Rebuilding lost credibility takes far longer than earning it once.

The technology gets funded and the change does not. Organizations invest readily in models and infrastructure, and very little in helping people work differently. That imbalance is the single most common reason capable systems go unused.

The way through is to resist starting with the technology. Start with a decision that genuinely matters and is currently made badly, slowly, or on intuition. Improve that one visibly. Credibility earned on a real problem funds the next ten. Enterprise-wide AI strategies announced before a single decision has been improved tend to age poorly.

Most answers to this question predict what AI will do next. I am more interested in why so little of it gets used.

AI Capability will keep getting better. Models will keep improving, agents will move from advising to acting, and an AI system deciding something matters and acting on it will soon be ordinary. That is a baseline, not a vision.

My vision sits underneath. The organizations that pull ahead will not have the most advanced AI. They will have made their AI usable, which comes down to three problems, none of them technical.

• Accountability: When an AI system acts on a customer rather than advising a human, someone has to own it when it goes wrong. Few companies can say who.

• Meaning: Most companies have never written down what their own terms actually mean, so an AI model has nothing reliable to reason from. Getting that out of people's heads is unglamorous, and it is the highest-value work in data today.

• Control: We know how to review and roll back code. We have no real practice reviewing a decision a model made alone.

Solve those three and capability takes care of itself. Skip them and you have impressive AI nobody is allowed to use. This is also why fundamentals matter more now, not less. A human reading a result catches what looks wrong. When AI acts alone, that check disappears and everything rests on the data underneath it. The visible work moves up. The critical work moves down.

On impact, two things, and they are really one bet.

• I want to build AI products that remove real friction rather than show off capability. The best work I have done made someone's job easier and then stopped being noticed.

• And I want to change who gets to do this work. Through @edubhav, I teach data analytics to people entering the field without a network or a brand-name degree. Every meaningful step in my own career came from taking someone else's problem seriously and fixing it properly. Teaching is that same instinct, just at scale.

AI is only the instrument. Understanding the person on the other side of the problem is the actual skill.