Fixing the Pilot‑to‑Production Gap in Enterprise AI - with Ronny Fehling of HTEC

Welcome everyone to the Emerj AI in Business Podcast. Today's guest is Ronny Fehling, Chief A I Transformation Officer at HTEC. HTEC is a global engineering firm focused on A I centric software and hardware development, working across financial services, med tech, automotive, telecom, and enterprise software from more than twenty engineering centers. In this conversation, Ronny examines why the transition from successful A I pilot to full production deployment stalls in enterprises, and why the root cause is almost always a sequencing problem rather than a technology or data failure.

He outlines the conditions that distinguish organizations that reach production from those that don't, including the use of narrow, bounded production slices built inside real workflows, decision gates with genuine kill switch authority, and executive commitment oriented towards learning rather than destination. He also addresses why large scale, top down A I mandates tend to reproduce the same failure patterns, regardless of the capital behind them, and what leaders should put in place before an initiative can realistically scale. Today's episode is sponsored by HTEC.

If you offer A I products or services into the enterprise, you need to find enterprise leaders with relevance. That means the right title at the right type of organization and readiness. Emerj attracts V P plus enterprise audiences who are already convinced that they need to move beyond traditional I T. To learn the exact strategies we use to help leading A I brands and startups connect with the ideal enterprise A I buyer, visit go dot Emerj dot com slash partner.

That's G o dot E M E R J dot com slash P A R T N E R. Now the conversation with Ronny. Ronny, welcome to our Emerj A I in Business podcast.

Thank you very much.

I'm excited about our conversation today. You've written about what you call the gap between conviction and execution reality, and I know that leadership is H plays a very big part in that for you. Um. We've seen them see say that, oh, the pilot has worked, but somehow things still get stalled. And there's nothing wrong that they can point out with the pilot or with the the A I itself, but for some reason, we're stalled. From where you sit, having lived this from different seats, what does that journey from a successful pilot to full production actually look like when you're inside of it?

Most of the enterprises that I work with, they don't actually have that journey. So they have a pilot, or they have had a pilot, or they want to go on a pilot. It goes well, you know, all things look good. And then it slum suddenly slows down and oftentimes this slowdown gets misdiagnosed. It is technology problem, it's a data problem, it's a change management problem. Recently heard also adoption problem, but I think it's usually neither. It's typically a sequencing problem.

Most of the time that I see is like the pilot was built next to reality, not inside reality. As soon as production hits, everything that wasn't in the pilot that you deliberately put out suddenly becomes the work integration, validation, certification, real users that have their real workflows using it differently than you planned, the governance, the monitoring, the accountability or ownership of that. And I think it's often that the team that was set up to build the pilot.

You know, was not structured really and was not thinking about that from day one and was n not planning to carry any of. And you know what what I find now interesting with the recent announcements from last week alone, Anthropic, uh, OpenA I, Blackstone and Helman Friedman. They all announced their own deployment company with the, you know, big private equity houses, roughly more than $5 billion of fresh capital, and it's all aimed at really closing this gap.

You know, even OpenAI, I think, was saying earlier this year that they see that the limiting factor for seeing the value of A I in enterprises is not the model inter intelligence. But it is how A I or how agents are built and designed to run inside these organizations. And that that's that's my thesis, you know, and and the models provide his own word. And I think the the scarcity of these implementation engineers I is one of the most significant bottlenecks to the adoption of A I in enterprises, as Blackstone, I think, uh, said themselves.

And that's, you know, a point three billion trillion dollar asset companies telling you, you know, that the constraint is delivery, not capability. So I think that gap is real. And now, you know, you can in invest in it. If I can give you a concrete example, I worked on a large telecom operator and there we found, we identified a bounded A I assisted configuration workflow. So it's a good starting point, very narrow, deliberately, it's a first production slice.

You, you, you hear me talk about these production slices a lot. It's real data, real systems, human in the loop, not completely automated, with explicit decision gate at the end. We wanna test it, this should work, and then we we can move forward. So not a platform program, um, you know, of of a horizontal data layer, not a full business case, a decision enabling step, de-risking, how I call it. Everybody agreed for a while. And then the decision logic shifted.

And I think that's very often, you know, problematic. M V P or this production slide started getting treated like a like a full investment case, you know, the business case being being put through. We had to put the R O I in there for first a six and then a twelve week program. Um, that that's a difficult R O I calculation. And these specifications that K kept on coming, they just looked like an R F P for some mature production software.

So I think the intent was good, the relationship was really good, but and and I think the organization wanted to be responsible, you know, acting on the investment, but the timing is wrong. And the result wasn't failure, mind you, it was just slowdown, but, you know, very harsh slowdown. More approvals, more specification, more governance, less room for iteration, less room for failure. And I think that is the actual failure mode in most enterprises. So what I've seen is the A I programs or these A I pilots, they never, they rarely fail loudly.

You know, they slow down, they become more and more complicated, they lose the momentum. And then by the time that anybody calls that out, twelve or eighteen months are gone. And so I think, yes, the adoption gap is real, but it's further downstream of this. It's I I. If the first production slice lives inside a real workflow and removes a real pain, I strongly believe adoption is not a problem. And, you know, there I can tell we had a manufacturing case in discrete manufacturing, uh, quite tough, highly regulated.

We built this very small system that helps these operators, blue collars, handle non quality events faster. And, you know, they they came to us before saying these causes a lot of problem, we get a lot of blame on that. And it worked inside their existing system. It didn't require any change management, it didn't require them to learn anything new. It was sitting slightly and very lightly integrated into their existing system, and the adoption was instantaneous. We didn't have to run a change management program.

Their work just got easier. And I think that is the goal that we want to see in order for these pilots, and not even the pilots, right, that you immediately are in production. So it's not really moving pilots from the pilot mode into, uh, into production, but starting with production in mind and a very narrow slice. And then the idea what pilots are before, you know, uh, tested out and then scale it out. For me, it's like, no, you see the actual result, it's been adopted, it's being used by real users that feel pain if you take it away from them, you know, that's the pull that they then generate.

And now you can expand the functionality across different, uh, operations of that or different, uh, business parts. Now you can, you, you have a real scale factor that you can. SL. Slowly put the value case and the R O I.

And it's interesting because, as you as you're explaining this, it makes it makes a lot of sense, but it also sounds so familiar because it's very similar to our traditional coding, S D L C, the software development life cycle. It's it's very similar to having certain slices, basically having an M V P and having rolling out, uh, a beta and alpha and and those kind of things before we're all flat out in. Okay, this is now being integrated.

Is is it the same idea? Am I getting? Is the picture that I'm seeing right?

Yes, it's so the M V P, and I think it's used in different terms sometimes. The production slice idea, um, that, you know, can be substituted with M V P is is this idea that the th this slice by itself brings the value already. So it's not a proof point for the value itself. Proof point, this actually works, and from there I can scale.

And then we build, so foundation, basically. We we start off with a foundation and we make sure that foundation is perfect before we start building on top of it.

E exactly it. It is really the it's a decision enabling stuff at that time, you know, and you might have a gate even before when you have the value case. Um, uh, roughly, but after this, you should have a gate. And this is how we think, we think in production gates, um, that are typical. And this gate, the I think the most important feature of this gate is the kill switch. So you get together and you know, it's like, if if the numbers don't match to where we think it should be, we kill it, or we have to further narrow it down.

And that's where I think some of the problems are. If you have big numbers in in mind, you know, at first, and you said, well, instead of narrowing, let's widen the scope. And that's, I think, where the failure, which then starts.

And I think at the same time, an executive having to make that decision also has to keep a board happy and explain decisions. And and there's a lot. That's there's a lot for them to think of. And you've been pretty direct about this that the enterprises that do get A I to production aren't necessarily the ones with the biggest budgets or the most sophisticated technology, but they're the ones that figured out something internally, something organizational. So moving beyond proof of concept, like you just said, what is actually true inside of the organizations that actually make it, and what is lacking in the ones that don't?

So I think when it works, it's almost, as I mentioned before, like, because the organizational respected that sequence. Start with a value ambition, not a precise R O I. Pick that bounded slice that actually matters, build it inside a real workflow, not not on the side, not, you know, in the would have, could have, should have situation, you know, of historical data on this. And I think the ones that that are successful, they use these decision gates to reduce uncertainty, to reduce risk rather than kill momentum.

You know, I think you have to let the operating model that might be there or might might want to evolve, evolve through delivery, not to design it on a whiteboard before, not first create all the governance structure. Because even if it works, or just, you know, as it works, it will evolve as well. It goes often from a centralized to a more distributed model. And I think on the use case discipline, to trying to see, you know, where I'm going to start first.

I think it's important not to pick the easiest thing, you know, the low-hanging fruit. It means to pick a use case where the value is real, the workflow is real, and you can actually finish it into production, meaning that the execution friction, that might be data, that might be the technology, but most often is also the process and the business reality that you're in allows allows that. I think these are the bounding steps, and then it's not always that important to know which one is the biggest, the second biggest, etcetera, because these need to go quick, very fast.

You know, we're talking here six to twelve weeks, um, to them. And you, you just said it before, and I like it. Most of the companies, they pick these use cases that just look very impressive. And um, I had a C E O say, you know, that have this wow factor. Uh, that's literally what he said in front of, you know, a a steering committee. The ones that scale, you know, are use cases where someone is going to use this every day.

And, as I said before, if the business notice if it goes away. And I think there's another part where I also think some of the the push that we might see now with some of the announcements is, you know, this pushing for the foundation or the engineering foundation. And let's say we talk about, you know, big data layers. We had this ten years ago around data lakes, and uh, that's also where I would push against, you know, the the perhaps the conventional answer, you know, and I think the the the trap is that I see a lot of enterprises, once again, investing heavily in these foundation.

Modernization, data platform, governance frameworks, and they assume that the value will follow once the architecture is clean. It doesn't. You know, we see that now very often. Uh, we we worked with a company that serious money into data modernization. They expected the the transparency and the data clarity, um, on on some of the products that they were distributing. And out of that, the ability to increase, let's say, the margin or or et cetera. This transparency was supposed to come out of this big foundation.

Uh, modeling. So what did get cleaner over over two years, you know, the the data got cleaner, the decision didn't, definitely didn't. So the standardization is not a value by itself or TR or transparency. And I think this is also where I'm a little bit contrarian or I'm a little bit, let's say, pushing back on some of the announcements, you know, that that we have with billions of dollars of new capital flowing into these P E portfolio, A I services, both with Anthropic and OpenAI.

I think we're going to see a wave of top down mandated A I rollouts into these portfolio companies over the next, you know, twelve, eighteen months. Top down, vendor locked, governance heavy, you know, because it comes from from outside. Some would work, you know, but I think many will fail exactly the way that I just described because it's it's late state logic applied to early stage problems, standardization, transparency before the value signal, platform commitment before the workflow proof.

This is what we've seen. We we often deploy small production slices and through that we built possibly the platform. It it it gets better all the time. You know, if you demand R O I before the the production is there, it it will ha be hard. I think the, you know, the capital will will be there, but the sequence will be wrong in in many cases. So let let's check on that in in eighteen months, um.

I'm excited, I'm excited to to monitor this. And I think we have listeners thinking now, hearing what you're saying, following the picture that you're painting and seeing, okay, yes, uh, Ronny, I agree with you. I can. I can see why you're saying we're headed into this top down problem with vendor locks and and all of that. How do we prevent that? What is what decisions should we be making now to prevent that?

I think there there are a couple of things that, you know, when we, when we design it, uh, when we're in the use case. What you actually need, I think, is usefulness from day one. The adoption is actually a symptom of a useful first slice, not a condition that you can engineer separately outside or that you put on top of that. And, you know, choose that the work that you do removes the pain from the people doing it.

You don't need the change program. If it doesn't, no change program will save you. And I think it's the these measurable milestones that, but the sequence still still does. I think on the on the C suite side, there are probably things that that need to be put into place. That that that helps make it true before you you can guarantee that something can scale. I think there are there are a couple of things, you know, on one side, commitment from the executive level to learn before we scale.

No commitment, you know, to, hey, let's do A I, you know, let's let's have this abstract thing, you know, we need to have A I in there. Although they get that pressure, you know, a lot from the investors. And I think their commitment to running real production proofs and then change the plan if necessary, based on what they see. Most of the executive commitment that I see is set up for the destination of A I, but not for the journey.

Which means that if at the first decision gate, you know, that I mentioned before, we come in and say the data says we need to narrow further, or we need to pivot, or we need to kill. They really wanna push through anyway. Um, you know, let's, you know, go bigger. And and often that's where the programs go sideways. Another point, I think, is this this narrow entry point that's within a real workflow. I think this is the single most underrated decision.

It needs to be bounded from the side enough so that we can finish something in six to twelve weeks. But it needs to be important enough that somebody cares if it works. And it needs to be, I don't know, embedded enough in the organization that it does touch a real system of record, you know, which at the end shows up in the P. And if the first A I initiative is built next to that reality, it will likely survive the trip into production.

But M most pilots are purposefully. And I think probably the most important, well, I don't know if most important, but the one that I I I miss the most is the that that most leaders skip. They they need to prove before you scale, but actually prove it, you know, not not on a slide deck. And know where I'm coming from. But you know, you need to you need to prove that this thing works in the inside production.

It it needs to have real users, real data, real validation, uh, of this, uh, and real operational constraints, you know, especially if you go in regulatory or compliance kind of environment, you know, uh, these these engineering, complex engineering environments, as we just love. I think this is, you know, that gap between the proof of the value or the pilot and the proof of production, where most A I proof of value shows that something looks promising in in principle.

It's at at worst, it's showmanship, at best, it's, you know, historical. But a proof in production shows that it can survive inside the system that that has to carry it at the end. And and especially in regulated, or, you know, where we work a lot in these core operational environments, that bar is much higher than most people expect.

Uh, it, it sounds like it's as simple as you need to slow down to move fast. Like you, you just take it back a bit, slow down a bit, and then, is a cliche to say slow and steady wins the race, especially the A I race. But is that the idea that our executive should have in? Instead of making the focus R O I, and instead of making the focus impress the board, it's make sure this works, and the R O I will basically come by D.

Yes, I think it's, it's, yeah, you can, you can skin the cat that that way, um, you know, depending on what you mean by slow down. I think when I say production in six to twelve weeks, that's incredibly

That's fast, that that's, that's super fast, but but slowing it down and and taking that narrow slice, instead of saying, oh, we're going Don't copy, to fully convert, take. Yes, let's, yes,

let's not start to transform the company. You know, it is not transformed by the A I, it is really transformed by these in production slices where you see, aha, there's value in there. Organization absorbs this, this works, this doesn't. I think, we, we don't have a top of the funnel problem. We have a problem of making sure that we do the things that we need to do, and most importantly, we kill the things that we don't need to do, or we say no to it.

yes, uh, and and and that should. The practical thing that you also mentioned was that we should miss it if it goes away. So if we think, oh, this is really working, let's take it away for a week and see what happens. Let's see if it, if it changes operations, obviously not in high stakes areas, but just to make sure that, oh, this is not just, uh, another piece of technology or another tool that we've integrated.

This is actually something essential and crucial, and we can build from this.

Uh, that that's exactly right. There are different ways, right, to encourage, um, or to to realize adoption. And it can be A B testing, there can be incentives, there can be, you know, most of the time, the best thing is to take the pain away. And if other people see that you have taken pain away, or you say, let's try it again without it and then see, oh, no, the pain increases immediately. You know, those, I think, are are very good ways.

Organizational structures are different on it and you, you might adopt it to it. But I think in general, you know, it's the governance should become operational, not not conceptual. The. And I always say the structure, and you might need a restructuring because it changes the way that we do think, but the structure should follow the signal, not the other way around.

The the biggest messages that our executive audience can take away from today is that the first thing you said, I think that was probably the first sentence, is that, uh, the pilot runs need to run with, or or next to the reality, not, uh, apart from it or in it, or it, it has to be a parallel, uh, relationship. I like the the respect the sequence part as well. Start with where there is value, start with a small slice that actually matters for the business.

If you notice that it's gone, it, it was valuable. And I like that you said six to twelve weeks. Like we said, that's fast, but it shouldn't take longer. If it takes you longer than that, then we've obviously already have seen new technology. And what we've been working on in the last three months might probably, uh, be outdated already. Anything else, Ronny, that you want to leave our audience with today?

Well, you know, uh, I think I was kind of excited, you know, seeing last week's announcements of it because it does validate a lot. What operators have been seeing for two years, you know, that the bottleneck was never the model. But I think at the same time, the mistake going forward now will be that we confuse more capital with better sequencing. And I think this quincing idea that says, you know, start in these slices, you know, have those decision gates, then go further on that.

And to adhere to it and to stick with it and prove it, then go and make.

Ronny, uh, this has been a a genuinely valuable conversation, the kind of conversation that I think our audience will be able to walk away with something that they can actually bring up in their leadership meeting next week. Thank you for being so direct, thank you for for keeping it real here. We've seen this now from your point of view, and you've basically had a bird's eye view of the problem and the problems. Uh, it's been great having you on.

Thank you so much for sharing your insights.

Thank you so much.

Wrapping up today's episode, let's look at the three key takeaways from our conversation with Ronny. First, the gap between a successful pilot and full production is almost never a technology problem. It's a sequencing problem. Pilots built next to reality rather than inside it will encounter integration, governance, and adoption friction the moment they move to production. And no amount of capital or change management will substitute for having started in the right place. Second, the single most underrated decision in any A I initiative is the choice of the first production slice.

It needs to be narrow enough to finish in six to twelve weeks, important enough that the business notices if it disappears, and embedded deeply enough in a real system of record that the result shows up in operations. That pull users who feel the pain when it's taken away is the only reliable foundation for scaling. Finally, executive commitment to A I must be oriented toward the journey, not the destination. Leaders who set up governance and approval structures for a mature program before a single production proof exists will constantly push through decision gates that should have been kill switches, and that is where most A I programs go sideways.

Position your brand alongside the Fortune 500 leaders defining the enterprise A I roadmap for the opportunity to showcase your solution to the executives currently funding and scaling global initiatives. Partner with Emerj to reach the decision makers holding the strategic mandate. Secure your partnership at go dot Emerj dot com slash partner. That's G o dot E M E R J dot com slash P A R T N E R. For further executive level analysis and to join our network of leaders delivering workflow impact with A I, visit Emerj dot com.

On behalf of the team at Emerj, we'll see you on the next episode.