From Enterprise Consulting to Product: Translating Client Pain into Gen-AI Solutions

From Enterprise Consulting to Product: Translating Client Pain into Gen-AI Solutions | Devangshu MitraCareer & Craft 12 min read

From Enterprise Consulting to Product: Translating Client Pain into Gen-AI Solutions

How three years of watching clients struggle with the same broken workflows taught me more about product-market fit than any PM framework ever could.

By Devangshu Mitra | Life Sciences & Healthcare AI Product Manager

The Consulting Background

I spent the early part of my career doing what most analytically-minded people in tech gravitated toward in the mid-2010s: enterprise consulting. My clients were BioPharma and MedTech companies - big ones, the names you see on hospital walls and research publications. The work was intense, intellectually demanding, and built a set of skills I still reach for every single day.

In practice, consulting in Life Sciences meant a rotating diet of deeply specific problems. One quarter you were helping a mid-size clinical research organization redesign its site selection process for Phase II oncology trials. The next, you were elbow-deep in a global pharmaceutical company's adverse event reporting workflow, trying to understand why pharmacovigilance teams were spending 60% of their hours doing manual data reconciliation that felt like it should have been automated years ago.

What I did not fully appreciate at the time was what those engagements were actually teaching me: a map of pain. Across dozens of clients, the same problems kept surfacing in different clothes. The vocabulary changed - "signal detection" at one company was "safety surveillance" at another - but the underlying frustration was identical. Clinical data was fragmented across incompatible systems. Regulatory submissions were authored in Word documents passed around by email. Trial patient matching was done by a coordinator manually cross-referencing spreadsheets against protocol eligibility criteria.

The consulting playbook for these problems was always the same: you built a bespoke solution, wrote a 60-slide deck, handed it off, and moved on. Occasionally you came back six months later for a "Phase 2" engagement. The client was satisfied. The engagement was profitable. The problem was still there.

It took me longer than it should have to name the discomfort I was feeling. Every recommendation we delivered was solving the same problem for a different person. We were not building anything. We were describing what should be built, delivering the recommendation, and moving on.

The Pivot Point

The moment that changed my trajectory was not a dramatic one. It was a debrief call with a client's VP of Clinical Operations, maybe eight months into an engagement that had gone well by every measurable standard. We had delivered a framework for intelligent patient cohort identification - a structured process for layering EHR data against protocol inclusion/exclusion criteria in a way that cut their manual screening burden by roughly half.

She said something I have thought about hundreds of times since: "This is great. But three other companies have asked us about this exact problem in the last year. When someone builds the product version of what you just described, it's going to be enormous."

She was right. I had been so close to the work that I had stopped seeing the pattern. The same problem, the same broken workflows, the same frustrated operations teams - across every client we touched. That was not a consulting engagement. That was a product brief.

I made the transition the following year. The move from a large enterprise consulting practice to a product role at a Life Sciences AI company was not smooth or immediate. There was a real credibility gap to close. I did not have an engineering degree or a traditional PM pedigree from a Big Tech internship pipeline. What I had was several hundred hours of watching enterprise teams try to operate around inadequate tooling, and a very clear picture of what those teams actually needed.

That turned out to be enough to get in the door. What happened next was harder.

Building the First AI Product

My first PM role was on a team building an NLP-powered adverse event detection product. The core idea was straightforward: Life Sciences companies receive a continuous stream of unstructured signals - physician notes, patient support calls, field reports - that may contain reportable adverse events. The traditional process was almost entirely manual. A pharmacovigilance analyst would read incoming documents, apply clinical judgment to determine whether a reportable event was present, and then manually format that event for submission to the FDA using the MedWatch schema.

This process was slow, expensive, and inconsistently applied. Analysts were scarce. Training took months. The regulatory exposure of a missed adverse event was severe.

The consulting version of me would have documented this problem extensively, recommended a set of workflow changes, and proposed three vendor options. The product version of me had to actually build something. That distinction sounds simple, but it reshapes every decision you make.

The hardest adjustment in those first six months was learning what "done" actually meant in product work. In consulting, done means the deck is delivered. In product, done means nothing - because the thing you shipped needs adoption, iteration, and maintenance indefinitely. You own the consequences of every decision you made during development, not just through launch but for years afterward.

The second hard lesson was understanding the difference between a client requirement and a product requirement. In consulting, when a client says "we need this feature," you build it. In product, when a customer says "we need this feature," you ask why three times before touching the roadmap. One customer's urgent need might be an edge case that scales to 2% of your user base. Getting that wrong early is how you end up with a product that is perfectly customized for three clients and useless to everyone else.

For a more systematic way of thinking about this distinction, I wrote about it in detail when working through defining what MVP means for AI products - it is a different calculus than traditional software because the model itself is part of the product, and its behavior changes with data.

Despite the growing pains, the first version of the adverse event detection product shipped. It was not elegant. It covered roughly 70% of the use cases we had designed for. It missed edge cases we had not anticipated. But it worked, and more importantly, it worked in a way that we could measure. Clients were triaging AE reports 40% faster in the first month. Analyst hours spent on manual document review dropped by more than a third within two quarters. We had baseline numbers. We had something to build against.

Scaling from One Client to Platform

The adversarial event product started as a solution configured specifically for one large pharmaceutical client. Their data lived in a particular system, formatted in particular ways, with particular submission workflows tied to particular regulatory bodies. We knew their setup intimately, having spent nearly four months integrating with their infrastructure.

When the second client came, we did what any team would do in that situation: we tried to adapt the existing solution. What we discovered was that about 30% of what we had built was specific to the first client's systems and processes, and would never apply to anyone else. Another 30% was genuinely generalizable with some abstraction work. And the remaining 40% was core product functionality that should have been modular from day one but was not, because we had optimized for speed to the first client rather than designing for the second, third, and tenth.

That realization forced a painful but necessary conversation about platform architecture. We needed to rebuild several foundational pieces to support configuration rather than customization - so that a new client could map their data schema to our intake pipeline without requiring us to rewrite ingestion logic every time.

The effort took most of a quarter. It delayed two features the first client had been expecting. Those were uncomfortable conversations. But what came out the other side was a product that could onboard a new enterprise customer in three weeks, down from the six months the first implementation had taken. That is not an incremental improvement. That is a business model change. Three weeks versus six months is the difference between a consulting engagement and a scalable product.

Over the next 18 months, the platform grew from serving that first client to more than 40 enterprise customers across BioPharma, MedTech, and contract research organizations. Each new customer accelerated the next - not because the sales cycle shortened dramatically, but because each implementation surfaced edge cases and configuration patterns that we built back into the platform. By client 20, the implementation playbook was tight enough that a customer's own IT team could handle the integration with minimal involvement from us.

That shift - from requiring our engineers in every deployment to enabling self-service configuration - is the moment I think of when someone asks me what "platform thinking" actually means. It is not an architectural pattern. It is a cultural commitment to solving the general problem rather than the specific one, even when the specific one is right in front of you and easier to reach.

What Consulting Taught Me That PM School Did Not

I want to be careful here not to be romantic about consulting. The model has real limitations. The incentives are misaligned in ways that matter. The billable-hour structure means you are rewarded for complexity, not simplicity - which is the exact opposite of what makes a good product. The work is episodic in a way that makes it difficult to develop the longitudinal intuition about a problem space that good product management requires.

But there are things consulting built in me that I have not seen developed as reliably by other paths into product work.

The first is pattern recognition across organizations. When you have sat across the table from clinical operations teams at 15 different pharmaceutical companies, you develop a clear sense of which problems are universal and which are idiosyncratic. That distinction is enormously valuable in product work. It tells you, with reasonable confidence, whether a customer request reflects a market need or a one-off preference. It is the difference between building a feature and building a solution.

The second is structured thinking under ambiguity. Consulting drills you relentlessly in the practice of breaking an undefined problem into its components, forming hypotheses about root causes, and testing those hypotheses against available evidence before recommending a course of action. This is exactly how good AI product development works - you form a hypothesis about what the model needs to do, you define what evidence would confirm or disconfirm that hypothesis, and you build the data collection and evaluation infrastructure to find out. Most PM training skips this and jumps to frameworks for prioritization without addressing how to think through what to build in the first place.

The third is stakeholder fluency. In Life Sciences, the people who use your product and the people who buy your product are almost never the same people. The Chief Medical Officer approves the budget. The pharmacovigilance analyst opens the application every morning. The IT security team controls whether the integration gets approved. The regulatory affairs director decides whether to expand from adverse event detection to label management. Each of these people has a completely different frame for evaluating value. In consulting, you learn early that the person in the room is not always the person whose problem you are solving, and that is a lesson that transfers directly.

The fourth is the discipline of going to the source. The consulting habit I am most grateful for is the instinct to talk to the person actually doing the work before drawing any conclusions. Not the director, not the VP - the analyst at the bench or the coordinator managing trial documentation. In product, this translates to rigorous user research grounded in observation rather than surveys. It means watching someone try to use your product rather than asking them what they think of it. Those two activities surface entirely different information.

For a fuller discussion of how these principles connect to go-to-market strategy in enterprise AI, I go into the specifics in my piece on building a go-to-market strategy for AI products in regulated industries - the dynamics are meaningfully different from standard SaaS.

Results and What They Actually Mean

There are numbers I could lead with here. Forty-plus enterprise customers. Implementation time reduced from six months to three weeks. Detection accuracy for adverse event signals above 91% in production. Annual recurring revenue growing 3x over two years. Customer retention above 94%. These are real outcomes and they matter.

But I am more interested in what those numbers represent, because the numbers themselves are downstream of decisions that are harder to quantify.

The decision to rebuild the platform architecture rather than continue customizing is what made the 40-customer number possible. If we had stayed in bespoke-solution mode, we might have five very satisfied clients and a services business that looked profitable in year two but had no path to scale. The three-week implementation time was not an engineering achievement - it was a product architecture decision made 18 months earlier, when it was not obvious that it was the right call.

The 91% detection accuracy is meaningful, but what I am prouder of is the human-in-the-loop review design that makes that accuracy trustworthy in a regulated context. The model does not auto-submit adverse events. It surfaces candidates with confidence scores and evidence citations for a trained analyst to review. That design decision - to augment the analyst rather than replace the workflow - is why pharmacovigilance teams actually adopted the product rather than treating it as a compliance liability. Accuracy without trust is a number in a demo. Trust with accuracy is a product in production.

The consulting-to-product transition is sometimes described as going from advising to doing. That framing is too simple. The more honest version is that it is going from solving one instance of a problem to solving the class of problems it belongs to. It is a different cognitive task. It requires a different relationship to uncertainty, a different time horizon, and a different definition of what it means to succeed.

What I did not expect is how much the consulting years made me better at it. Not because consulting and product management are the same - they are not - but because the years of sitting with client pain, mapping it, categorizing it, and trying to explain it to people who had not seen it firsthand built a kind of intuitive catalog that I have not found a substitute for. The catalog says: this problem is structural, that one is a workflow issue, this one is a people problem in disguise, and that one - that one is a product opportunity.

That last recognition is what I was trained to hand off to someone else. Learning to keep it, and do something with it, was the whole transition.

Consulting to Product Management Enterprise AI Product Life Sciences AI GenAI Client Pain to Product

Related reading:

Further Reading