Dileepan Narayanan

So I'm the chief product and technology officer of a company called Afiniti. Afiniti is a company that builds state-of-the-art predictive and agentic AI, enabling enterprise contact centers to amplify their internal investments through additional sales and retention opportunities.

So contact call centers. So you call customer support. Somebody, an agent, picks a call at the other end of the line. Today, it's a human agent. It's increasingly transitioning to an AI picking up your call at the other end of the line and escalating to a human as the need may be. So that's where we've linked overall.

That's right. And it's very interesting because there are workarounds for those latencies. So when an agent is looking up information, you could say something like, give me a moment. There are ways to mitigate the latency through the customer experience. We're getting to a point where the underlying technology is largely robust right now. Where customer support organizations are falling short is in the CX. It's ensuring the right customer experience, where an agent can actually earn trust with the customer. It's the agent being able to think like a human. It's the agent being able to have the context to figure out which of its decisions will actually lead to the resolution of the issue or a successful confirmation.

It's a data, context, and decisioning issue. Ultimately, when you talk to a human, a human knows where to go look up the data that's needed across all of these different siloed data elements. A human also has the context on what you are, what your persona is, what your demographics are, what you're likely to say, what your frame of mind is likely to be when you call about an issue. And most importantly, a human knows what to do to close a conversation, to retain you as a customer, to upsell you. These are the things that an AI is not yet good at. And it's not because the agentic capabilities are lacking. The underlying technology is actually getting to a point where it's becoming increasingly robust. It's just the fact that the underlying data systems are so siloed that the data systems don't talk to each other. And it puts a lot of burden on implementing the AI right. So the application layer and the user experience layer becomes of parallel importance.

That's a big part of the problem. So some of the data is on prem. Some of the data are spread across CRM databases to contact center platforms to interactive voice response and voice agent systems. So there are multiple systems that don't talk to each other. And it's these silos that break the cameras apart.

So a big part of what Afiniti does and does really well is it's able to connect the customer engagement work streams, the customer engagement data, with the outcomes data. So we have state-of-the-art predictive AI models, which are able to connect customer engagement patterns to outcomes, both short-term, like on-the-call outcomes, to longer-term outcomes, in terms of what customers do after they hang up. Do they survive as a customer, or do they go find somebody else? So Afiniti has the through-line that is able to connect across this journey. And it's this canonical through-line that helps us build a very robust predictive model, where a model is able to make decisions and predict the outcomes of those decisions very robustly.

That's right, for customer implementation. But the data conversation is so nuanced. You look at large enterprises, they do not want data to leave their premises. They want total control over their data. So what we've gotten really good at is building models and model workflows that can quickly learn the setup within a customer, within a client setup, on the fly. And while safeguarding a client's data, we're able to very quickly train these models to predict very accurately in terms of what engagements would lead to what outcomes.

In real time.

That's a great question. So our primary customer, the people that derive the most economic benefit from our solutions, are the call center business owners. They pay the bills, basically. But it's so hard to decouple the client from the end customer, because the client succeeds when they offer a bar-raising customer experience. So the conversations all, they're two pieces apart, as far as we're concerned. So we look to amplify a client's ROI while ensuring a bar-raising CX, which enables them to go approach their customers better, improve the quality of their interactions, improve sales, retention. It all starts with the experience being trust-earning and bar-raising.

Way before. So we've been building world-class machine learning models for the last 20 years. And the way Afiniti built its market leadership is by building what we're calling agent-to-customer pairing, whereby we optimize for the agent that we have fronting a customer call or a customer contact. So we ensure that the best agent is put on to handle every customer, to improve the outcomes for the greatest number of customers calling in. And that's how we improve the ROA of the business overall.

That's a great question. So Infosec and legal priorities are at the top of the technology. The reason we've been so successful in building this end-to-end view of the data is that we've figured out a way to address Infosec from the ground up, information security from the ground up. So as we think about bringing in AI tools like Claude Code, we're very deliberate in instituting organization-wide policies where any of the data that we use to improve productivity cannot be sent out of Afiniti service. They cannot be used for model training, for example. And so anything we develop is primarily data but Afiniti-deed-dense. It's just like an engineer developing code, and nothing leaves our code repositories, for example. And the other part of it is just the productivity, and all the code that's built ships in the same manner as human-built code. So there's nothing different about AI-generated code that we ship out today.

So that leads us into the whole discussion about how we're implementing AI. So a couple of points. One, when coding gets commoditized, when the operationalization of coding and even the thought process of building products has gotten commoditized, all of the conversations are around, how do you build the right product? How do you have the right checks and balances? And how do you ship with velocity yet preserving the CX in a trust-earning model? So we have a bunch of guardrails right from ideation through shipment to ensure that what we're building and shipping is far from the AI slop. And so we're very intentional about the process. So right now our organizational structures are a lot more multifunctional and a lot flatter as well. So just the process from ideating from a customer feature request or an idea to getting through to a prototype happens in a cross-functional pod which has a product manager, a UX designer, an architect, an AI modeling architect, and QA and an evals expert as such. So the whole thought process is multifunctional.

And there's also been a horizontal collapse across the roles where everybody's a builder now. The differentiation between who's a product manager versus who's a UX designer versus who's an architect is kind of collapsing down the horizontal. But at the same time, it's a fallacy to assume that the functional expertise is going away. And these are realizations that people come to as they build, right? Where right now the role of the UX designer, for example, has changed from actually doing the design, implementing the design, to actually telling the tool what a good design looks like. And the same with a product manager.

You have machine-readable specs that are getting put out by these AI tools. You have machine-readable business requirement documents. You have machine-readable design documents, design artifacts. But the real differentiations are going to be around, where's the intentionality in the product? What product are you building and why? And how intentional are you about the process? And how do you ensure that the process itself is good enough where you ask for a product and you get exactly that, to the specifications you asked for, without a drift in scope, without a drift in specifications or a drift in the customer experience. So it's that end-to-end process and the checks and balances around them that would differentiate a good product from a bad product. And a simple example is today, when organizations write documents and they communicate, you're now moving to a world where you ask the AI a question and it spits out a 60-page requirements document. And the way people end up reading it is they are unable to deal with the cognitive overload. So they end up sticking it back in AI and getting it summarized. So there are two AIs talking and the humans in the middle, right? So when this happens, the conversation's not about how complex a product you can build. It's about what product will actually serve its purpose in the simplest manner with the least cognitive load to humans with the right pace. So the conversation's very quickly evolved from what looks great on paper to what's actually useful.

So our processes are heavily guarded. So I've quickly come to the realization, I think in today's world, CTOs cannot afford to be hands-off at all. Everybody needs to be a builder. And I can clearly see a difference in the industry. You're clearly seeing a demarcation between people that actually use the tool, get their hands dirty and build, versus people who are a step removed. And to me, that is gonna make all the difference tomorrow. As I'm building, I'm coming to very profound realizations on what looks good on paper but doesn't work. For example, something as simple as what a business requirements document is or what a product requirement document is, it's just changing immensely.

If you tell AI to build a thing, unless you're very specific and intentional in the definition, and until the definition is shared across the product spec, the UX spec, the architectural spec and the AI spec, AI is gonna build whatever it thinks is right. And it sometimes takes the agency to simplify things and make decisions on its own. And some of these decisions are honestly latent and transparent to the user of the tool. And so the BRD as a contract just changes. The requirements document, the contract, needs to have the right through lines between what a product manager thinks, what a UX designer thinks, what an architect thinks, what an AI modeling architect thinks, what a QA person thinks. And what defines good or bad, like the QA around it, the unit tests, the evals, the acceptance criteria. So as you define multiple aspects of a product, this granularity needs to come through, this through line needs to come through with every aspect of the product. If it doesn't, AI is going to end up making its own assumptions and simplifications. And then you end up spending a lot more time undoing what you've done.

So the amazing thing about today is the agency to build anything is there. And so what would make a product really bother me is the ability to go simplify, where the AI is going to build just a whole lot, which is too much cognitive load for humans. So a lot of my focus these days is in building the right principles, it's in building the right reviews or charters that guardrail the AI, that tell the AI what is a simple UX, what's a bar-raising, easy-to-use UX versus what's complicated. And the amazing thing about AI today is not everybody's version of the AI tool is going to be the same. I'm finding as I'm building that these tools are adapting to how you want to build. So every time you go ask it questions, every time you tell it to fix something, it's adapting, it's prophylactically applying those fixes the second time it does it. So I see a world where the real A-team builders are also going to build versions of these tools that are going to increasingly think like that.

So as people build more and more, as their habits, as their best practices get codified into how the agent actually functions, how the agent actually makes a very logistical decision as it's building products, as it's building code, then the emphasis is all about how do you teach it the right practices? How do you keep it from straying? How do you impart your first principles whereby it's thinking simply, like you? That's where a lot of emphasis needs to go in terms of the building.

Yeah. So I have a dual role in terms of being the CPO and the CTO of the company. So I manage product engineering, applied AI, technical program management, and then I have a customer success, product success org as well. So that org is close to 300 people right now overall.

That is a great question. So through my own journey, I found that at this point, more people does not directly translate to scale in terms of what you build, what you ship. And in fact, when coding's become commoditized, if you're able to elucidate your idea very clearly, and you're able to build products, and you're able to turn out prototypes in, say, a week, and you're able to take products to production in, say, four to six weeks, at that point the code generation, the building, the operationalization of the software development lifecycle is no longer the bottleneck. The bottleneck occurs amidst all the coordination that happens, all of the reviews that happen, when people need to pick up the phone and call each other, or set up meetings, set up review boards. It is all the coordination that's actually taking more time.

And if you have larger than ideal engineering teams, you're in a situation where engineers are aligning with engineers on architecture and the sessions, trade-offs, and that's potentially going to take a lot more time, versus the time they would actually take to iterate and build the final product. So I think the size of the pod becomes the most deterministic quantum at this point. And ideally, it's going to be a right-sized pod where you have functional experts who are able to view every part of what the tools are providing. If you have a product pod with product managers, engineers, architects, AI architects, and a UX designer, once you have the functional expertise, the ideal size of the pod, that's going to be, to my mind, if you're looking at a portfolio with some legacy products as well as new products that you're building from scratch with AI, I think a pod of eight to 10 should be able to build the product ground up with optimal coordination, where people coordinate when it's necessary, but they're not wasting time aligning on decisions. And there's this healthy balance between moving fast and moving with clarity. So when that happens, and when companies can build products in a matter of weeks and months, then ultimately, a lot of the investment is about how do you build a channel with your customer base.

No, it's not. I mean, you can think of these AI tools. These AI tools are pretty smart and doing really well out of their tasks. And so it's almost like everybody has a junior engineer at their disposal right now. If you tell a junior engineer exactly what to do, that person will do a great job of it. And today you have AI doing the same thing. So the single quality that becomes the most critical is judgment. You need to be able to look at what the AI is doing. Sometimes the AI is too eager to please. And when you tell it something, it automatically assumes your point of view and it tells you that it's complying with your request. But there are parts of your request that it's actually not complying with. It's simplifying, it's building initial prototypes when it's telling you it's done a full audit. So the conversation sometimes falls through the cracks. And so it's critical for somebody to show the judgment at every point of the conversation to make sure that nothing gets lost in translation. So it's almost exactly like working with a junior engineer with whom the jury's still out for you. You're still forming an opinion of whether they're a trusted person, how often do I need to inspect the work? And so you need somebody with high judgment. And to your point, you need somebody who can absorb the cognitive load. Because there's so much code that's being generated right now, to an earlier point, no human's gonna be able to view thousands and tens of thousands and hundreds of thousands of lines of code. So you need somebody with the judgment, increasingly, to figure out where to go look, where the AI might most likely be right, and where do you need to go inspect.

I think to say that we won't need junior engineers is not the right framing. As we've hit the agentic AI age, already information access is at your doorstep. And right now, with these AI systems, you have curated information that's been delivered right as you type a prompt for it. And so learning cycles are also getting immensely accelerated, even as the tooling to go produce artifacts or to produce information is available. So the way I think the world will evolve is that college graduates who come out, their learning curves will be infinitely accelerated. I think we'll see a lot more high-judgment people coming through the ranks a lot quicker. People will start using these AI tools earlier, which means there'll also be the familiarity with using these tools. These college graduates now understand the way to use these tools much better than anybody who started using the tools later in the game. So I think the availability of expertise is gonna shift, the profile is gonna shift, I think we're going through the shift right now. I see college graduates around me, and they're just so much more proficient and so much less resistant to using these tools versus people who've been in the industry for a while. So the skill of acquiring judgment is still a skill that's up for grabs. And your own equity as a person is being evaluated every day.

I mean, the world's been through multiple cycles like these. At some point we did not have physical help. And then machines were invented. And people became smarter in terms of learning how to use these machines and how to become an order of magnitude more productive. And the same thing's happening where mental work is getting outsourced, right? And at some level, people are going to adapt and figure out how to use these tools to turbocharge their capabilities. I think we're selling people short if we think people will not adapt and find new pathways to get on top of what they need to do.