In this episode, I talk with Ilya Preston, co-founder and CEO of PAXAFE, a logistics orchestration and decision intelligence platform for temperature-controlled supply chains (aka “cold chain”). Ilya explains how PAXAFE helps companies shipping sensitive products, like pharmaceuticals, vaccines, food, and produce, by delivering end-to-end visibility and actionable insights powered by analytics and AI that reduce product loss, improve efficiency, and support smarter real-time decisions.

Ilya shares the challenges of building a configurable system that works for transportation, planning, and quality teams across industries. We also discuss their product development philosophy, team structure, and use of AI for document processing, diagnostics, and workflow automation.

Highlights/Skip to:

• Intro to Paxafe  (2:13)  
• How PAXAFE brings tons of cold chain data together in one user experience (2:33)
• Innovation in cold chain analytics is up, but so is cold chain product loss. (4:42)
• The product challenge of getting sufficient telemetry data at the right level of specificity to derive useful analytical insights (7:14) 
• Why and how PAXAFE pivoted away from providing IoT hardware to collect telemetry (10:23)
• How PAXAFE supports complex customer workflows, cold chain logistics, and complex supply chains (13:57)
• Who the end users of PAXAFE are, and how the product team designs for these users (20:00)
• Pharma loses around $40 billion a year relying on ‘Bob’s intuition’ in the warehouse. How Paxafe balances institutional user knowledge with the cold hard facts of analytics (42:43)
• Lessons learned when Ilya’s team fell in love with its own product and didn’t listen to the market  (23:57)

Quotes from Today’s Episode

"Our initial vision for what PAXAFE would become was 99.9% spot on. The only thing we misjudged was market readiness—we built a product that was a few years ahead of its time."
–IIya

"As an industry, pharma is losing $40 billion worth of product every year because decisions are still based on warehouse intuition about what works and what doesn’t. In production, the problem is even more extreme, with roughly $800 billion lost annually due to temperature issues and excursions."
-IIya

"With our own design, our initial hypothesis and vision for what Pacaf could be really shaped where we are today. Early on, we had a strong perspective on what our customers needed—and along the way, we fell in love with our own product and design.."
-IIya

"We spent months perfecting risk scores… only to hear from customers, ‘I don’t care about a 71 versus a 62—just tell me what to do.’ That single insight changed everything."
-IIya

"If you’re not talking to customers or building a product that supports those conversations, you’re literally wasting time. In the zero-to-product-market-fit phase, nothing else matters, you need to focus entirely on understanding your customers and iterating your product around their needs..”
- IIya

"Don’t build anything on day one, probably not on day two, three, or four either. Go out and talk to customers. Focus not on what they think they need, but on their real pain points. Understand their existing workflows and the constraints they face while trying to solve those problems."
-IIya

Links

PAXAFE: https://www.paxafe.com/
LinkedIn for Ilya Preston: https://www.linkedin.com/in/ilyapreston/
LinkedIn for company: https://www.linkedin.com/company/paxafe/

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today, I have a referral from a past guest. I had Natalia Andreyeva on the show, back in episode 167 and she had mentioned to me that I should talk to Ilya Preston, who I have on the show today. Welcome, Ilya. How are you?

Ilya: Brian, it’s great to be here. And—

Brian: Yes, yes.

Ilya: —I’m glad we’ve got some great mutual connections as well. Natalia is a good friend.

Brian: Cool, excellent. So, you’re a co-founder and CEO of PAXAFE. That’s, P-A-X-A-F-E. What is PAXAFE?

Ilya: Yeah, you’re definitely in the probably 20 to 30% of people that can actually pronounce that correctly.

Brian: [laugh]. Well, because you told me yesterday [laugh].

Ilya: Well, that’s—[laugh].

Brian: I did say pack-sahh-f—

Ilya: I was trying to build you up, but—

Brian: [laugh]. No, I failed. Total fail [laugh].

Ilya: We thought we were being a little cheeky, you know, when we started the company. We wanted it to be a play on words, obviously, with packing things safely. But at the end of the day, we get the French pronunciation, the pack-sah-fee more than anything else.

Brian: Okay [laugh].

Ilya: So, we are a logistics, orchestration, and decision intelligence platform for temperature-controlled logistics. So, if you think about all of the most important products that get shipped around the world at any given point in time, medicines, drugs, vaccines, food, produce, meat, dairy, even flowers, so basically anything that’s really susceptible to temperature or humidity, damage, environmental damage, time sensitivity, generally worth, you know, a lot of money, or is target for theft and counterfeiting, we help these products get delivered on time and safely with our software platform. In a nutshell.

Brian: The first thing I would wonder about is, wouldn’t you need telemetry coming from all these vehicles and/or checkpoints and, like, doesn’t that mean—that sounds like a nightmare [laugh]. Or do these truck—they all have this and they’re all on the they’re all on the grid, and, like, you can get access to all the data, or are you building, every time there’s a new client, it’s like, new connectors to, like, tap into all the telemetry. Like—

Ilya: Yeah, that’s a great question. So, if you look at this industry, the cold cha—it’s often referred to as cold chain in general, but basically shipping things that are temperature sensitive. You know, there have been technologies, to your point, that have been around for decades. There have been, you know, passive temperature data loggers, which are required from a regulatory perspective. You can think of these as, you know, thermometers that are dropped in at the product level, with each and every product to essentially be able to go back after the fact and see if a product stayed in the proper temperature range.

There are, more recently, over the last 15 years, real-time IoT devices that are now being dropped in at the pallet level, sometimes at the product level, sometimes at the shipment level, at the truck level, to be able to communicate in real time, right, throughout the lifespan of the shipment, so that you can actually do something about something that’s going wrong throughout the course of the shipment. And then, over the past decade, there have been, you know, everything in between, from real-time IoT visibility solutions to aggregation software platforms that basically try to aggregate all this data together. There’s risk management platforms that help model risk. Here, more recently over the last five or six years, something called decision intelligence, so effectively software platforms that help humans make more intelligent decisions, that’s been a popular thing. But at the end of the day, what we found is that despite all of these solutions that are out there, all these technologies that are out there, nothing has moved the needle when it comes to temperature-controlled logistics, meaning product loss keeps getting worse, year after year. More and more losses happen in the transportation value chain. Operational inefficiencies continue to get worse.

Brian: Wait, percentage of shipped goods? Or—because, like, if we’re shipping more stuff, there’s going to be more loss. But like, the percentage is going up?

Ilya: The percentage of dv—it depends on kind of which leg of the supply chain, but generally speaking, even if you account for the increase in shipped goods, the amount of product loss from a product loss and product value perspective is rising, and as such, insurance claims keep going up accordingly as well. So, you know, those things keep getting worse. Operational inefficiencies aren’t getting any better. Most importantly, I think what we’re finding is that companies just lack the ability to effectively make real-time trade-off decisions that are backed by data from their network because all this data that they have, all the telemetry data, all the IoT data, it’s siloed and it’s not contextual. It doesn’t fit within the confines of existing workflows. People have to do a lot with it in order to try and make sense of it, and then by the time that they do make sense of it, it’s already too late, right?

Brian: Right, [laugh] yeah.

Ilya: So, that’s kind of the issue that we’re solving for is, you know, we see all of these data silos that exist, we see that the, you know, the data itself is not overly actionable, and we try to piece all of that together and enable really quality planning and transportation leaders to be able to make the best decisions in real time in order to do one of those three things: reduce product loss, improve operational efficiencies, or make smarter decisions that will reduce cost within their transportation networks.

Brian: It sounds like, so the raw data is present. There’s enough IoT and telemetry that’s already being captured. That’s kind of old school, old news. Is that correct? So, from the, I don’t know, the warehouse layer to the truck to the train to the final destination, there is already data being collected, but it’s like, well, maybe the transporter has their systems, the store has its own system, the hospital has its own system, each of those is collecting telemetry independently, and so are you sitting above that, trying to consume all that, and then—am I in the ballpark?

Ilya: Yeah, so yes and no, I think to your point, yes, each of those legs does have telemetry data. The problem with telemetry data, if you’re talking about, for example, ELDs or passive loggers, those are not well, specifically, ELDs—

Brian: What’s ELD? What is that, ELD?

Ilya: So ELD, Electronic Logging Devices that are embedded within their trailers.

Brian: Okay, got it.

Ilya: Or carrier milestones, for example, like UPS or FedEx or DHL, the stuff that you see when you order a shipment, that says it reached Indianapolis—

Brian: Oh, okay.

Ilya: —and now it’s reached my house. Those data sets, they’re not at the product level, so you’re typically looking at a trailer level. So, the trailer has no real understanding or mapping to the product, so you can get a sense for where your stuff is likely, but you’re not going to understand what condition it’s in, and you’re not going to understand if something gets left behind, if it went to the wrong destination, if there’s something else that’s wrong with the pallet. So, you typically need pallet-level or product-level visibility for when you’re shipping sensitive goods like this, right? Because these are goods that at the end of the day, are consumed by humans and by people, and if they turn out to be ineffective, or even worse, if they turn out to be spoiled and then cause a human to get sick or die or whatever else, that’s not a good scenario for anybody.

So, with the telemetry data, you have, kind of, the built in sensors that enable you to track different legs at the trailer level. But now, over the last decade, what’s gotten more pronounced is this product-level tracking with IoT that is now attached to pallets or attached to products, and now you get that more granular visibility. To your question, is that widespread, the answer is, kind of. Everybody is moving towards that adoption very quickly, however, everybody has also drastically underestimated the change management that is required when you’re rolling out even just basic IoT solutions.

And as a result, I think the adoption of the actual IoT devices at a product level has been slower than what was originally projected, you know, six, seven, eight years ago. So, everybody’s moving in that direction. If you ask any major pharmaceutical company, really, I would say any pharma company north of $5 billion in revenue, even a lot of the mid-sized ones kind of in that billion to $5 billion range, most of them are moving towards real-time visibility and tracking at the product level, so IoT. But how quickly they think they’re going to get there versus how quickly they actually get there is a different question.

Brian: Sure. I guess the spirit of my question was more trying to understand, yes, do they even have the data collection happening at the right level, let alone the analytics or the insights about it? And if they don’t, then how does PAX—because it sounds like your product would be great if only this infrastructure existed.

Ilya: Yes.

Brian: Are you only primarily working with fairly advanced companies that have already, like, have the telemetry in place at product and pallet level?

Ilya: Yeah. That’s an excellent question, and that, I think, speaks to the spirit of how we started and how we’ve since pivoted. When we started, the answer was, no. We felt that the infrastructure was not strong enough, so we actually came into the market with our own hardware, with our own IoT device that we had for the first few years because we felt that, number one, there wasn’t enough IoT that was adopted in our particular industries, within pharma, within food and beverage, et cetera, and number two, a lot of this more advanced functionality, which really gets to the value of having visibility in the first place, workflow automation, operational efficiencies, cost reduction, reduction of product loss, that’s really why people end up adopting visibility in the first place. But in order to unlock that, you need to have that infrastructure there.

Our sense was, if we start talking about these things, about reducing product loss, about automating workflows, nobody’s going to quite understand what that means yet. So, we came out with our own hardware, and then eventually, I think in 2022 we recognized there was an inflection point in the market, meaning IoT adoption had started to accelerate, and that was a byproduct of things like hardware getting cheaper, cellular infrastructure getting better, data quality, data consistency, improving drastically. And when we saw those signals, and we started to see companies routinely start to ask for the things that we were actually building on the back-end, all this intelligence, all this predictive capability, that’s when we decided to go hardware agnostic. We dropped the hardware, and we became a fully agnostic platform. So, to answer your question, yeah, today, no, you don’t have to be the, you know, the most advanced company. You don’t even have to have real-time IoT deployed. We can add value from other data that you have, in terms of passive temperature data loggers, carrier milestones, ELD data. So, we kind of service the full gamut of transportation data, and we can add value regardless of where you are in your visibility maturity journey.

Brian: Got it. So, this sounds like it maps very closely to some other products that I’ve worked on, that are in the, you know, decision support space, insights monitoring, and one of the challenges that I’ve seen a few times now this pattern, is this idea of, like, the logical model, the way, like a customer user, thinks about, like, in your case, a shipment, or maybe they think about a product, and a product is a collection of, like, a train, a truck, and some other thing, but logically, these three ingredients have to be shipped differently, but they’re like one product to the customer, so they want to think of that as a group, whereas someone else is, like, no, it’s just everything in the truck is my shipment. I don’t—like it—that’s all—that’s just beans. We’re shipping beans, you know? It’s not complicated.

But for the drug, it has to be three separate components, three different, like, temperature levels, and one needs to be there tomorrow, and the other ones can be there whenever they want, but that first one’s important. But when I track it as a product, it’s one thing. And then everyone has their own versions of this, and so the product gets really complicated because it doesn’t necessarily mat—like, your sensor might be at, like, the pallet level, but in some cases, someone doesn’t want to look at pallet level; they need an aggregate of pallets to think of that as the logical thing. Did you run into this challenge in your design and product, like, journey?

Ilya: So, our customers run into this challenge all the time, and I think that’s why—there have been, to your point, aggregation and visibility platforms around for over a decade in our space, and that’s exactly why they haven’t been successful in cold chain. There are so many nuanced intricacies and specialized workflows around temperature management, around the tracking of product stability budgets, right? To your point, there’s, you know, there are products that could literally be out of temperature range for no more than 30 minutes before you have to scrap them before you can’t use them anymore. And then there are products that have, like, ten different temperature ranges, and each range they have a set amount of time that they could be outside of range for. Sometimes it’s cumulative. Sometimes it’s continuous. Sometimes you need to piece it together from different parts of the value chain, so from raw materials or distribution to final mile. So, there’s a lot of complexity around dealing with temperature sensitive products, and it’s not a one-size-fits-all model.

I think that’s where our platform has kind of stood out from the rest of the pack. First and foremost, we’ve looked at everything when we’ve designed and built our platform, we looked at it from the standpoint of the product transportation cycle, effectively. So, if I’m a product, if I’m a brand new product, what needs to happen to get me from point A to point Z? And typically, there’s five steps involved: there’s a planning stage where you have to qualify a lane and basically do validation and say that, you know, I’ve done the proper risk assessment with this vendor mix with this routing, with the use of this IoT device, this carrier, this kind of packaging, this is how much thermal life I’ve engineered for my package, all of that has to be done before I ship my first shipment.

Then comes the visibility. How do I keep track of my products while they’re moving? The exceptions management or the monitoring, which is, okay, great, I can track two shipments or ten shipments. What do I do when I get 10,000 shipments? How do I know what to prioritize and what to look at?

Then there’s—critical—the quality release, or you can think of it as quality approval piece, which today is incredibly manual, being able to effectively do those calculations of how much time did my product spend out of range relative to the product stability ranges, and should I approve quarantine or reject this product? And then finally, how can I make use of all this data? How can I aggregate this data in a way that makes sense to me, and in a way that would make sense to my planning team, to make tomorrow’s shipments better, to optimize performance, to take out cost from my network, to reduce risk?

Those five things, those five pillars, are how we’ve what we’ve designed our product to be around, and effectively, I think we’ve developed the most seamless platform that allows for both that breadth of being able to do planning all the way through to aggregation and analytics, and then also provides that complexity or the configuration ability to configure to specific use cases—as you were asking—so that it’s not a one-size-fits-all model. It can truly be configured to whether you’re shipping last mile, if you’re shipping first mile, if you’re shipping middle mile, if you’re shipping air, ocean, you know, rail, whatever it is, it’s a fully agnostic platform. It’s agnostic to devices, it’s agnostic to data types, and it’s agnostic to modes of transport.

Brian: Got it. The buyer of your solution is typically the, I’ll call it this, the sender of the goods, not the receiver? Is that correct? Or is it the receiver that wants to monitor this?

Ilya: So, that’s a good question. In pharma, yes, it’s typically the pharmaceutical manufacturer. So, the manufacturer of the goods, they’re the ones with their brands and their necks on the line to deliver a quality product. It is also a service provider that sells into that pharmaceutical manufacturer, so it could be an IoT device provider, it could be a logistics service provider, like, a 3PL, 4PL shipper.

And then on the produce side, it could actually be any and all of the above. It could be the original, kind of, manufacturer that has farms all over and ships product from the farms to various distribution centers in the US. It could be the retailer that’s looking at that product and looking at it inbound and basically wanting to make sure that product gets there on time in the right delivery windows and has a quality product to offer to consumers. And it could even be the brokers that effectively act as the intermediaries between the carriers and the retailers, or the manufacturers. So, I guess from a persona standpoint, it’s typically always one of three functions, regardless of which industry you’re looking at.

It’s either transportation slash logistics, which focus on the operations and the live shipments. It’s planning, which focuses on improving and optimizing shipments for tomorrow, for next month, for next year, or it’s quality, which focuses on that product quality aspect, making sure everything is buttoned up, making sure that we have the full audit trail that you can show to regulators if anything were to come up, making sure everything’s GxP compliant. So, those are the three functions, and then it kind of varies by, you know, industry, where our entry points or sell points are. But I’d say those are the three functions that overlap, regardless of which industry.

Brian: Who’s the end-user of this solution, then? Is there someone that usually owns this responsibility for, like, end-to-end delivery quality, like, goods quality, you know, managing loss or trying to reduce it? Is it typical, or do you have a bunch of different types of users and they’re all, like, kind of have different workflows across, you know, grocery versus pharma? I’m sure there’s some differences here. How do you keep the product simple when I’m assuming you have multiple different types of users that need different levels of granularity, maybe? Like, I don’t care about one truck, I care about how, like, you know, [March’s 00:20:28]10,000 trucks did with their goods. Like, you know, they’re looking at different visib—you know, altitudes, et cetera.

Ilya: Yeah, that’s a good question. I think so first to answer your first question, the users are actually the ones that I mentioned. The transportation, planning, and quality. I would say the buyer is more so always the CIO or whoever sits as a part of the CIO team within an organization. Those are the buyers. But yeah, the users always kind of fall within those three functions.

How do we keep the product simple with so many different use cases? I mean, there’s no good answer for that. I think the easiest way to think about it is we try to meet the users where they are, meaning we, especially now over these last two years, we’ve really tried to dig deep into their existing workflows and to build or to be able to configure our product around those existing workflows. If they have APIs, or if they’re 3PLs, if their partners in their ecosystem have three APIs, great. We’ve got—you know, we’re fully—we’ve got a full suite of APIs. We’re quick. We’ve got one of the best, I think, the best, pre-processing engine and ETL layer in the industry, which allows, basically, for very quick and seamless plug-and-play integration. We can handle integrations very quickly.

But if they don’t, you know, we’ve got other functionality that’s more conducive to, you know, other ways of ingesting data. We can parse data in and basically have them upload CSVs or PDFs, and we can extract the critical information from those documents, and it ingests it into our configuration tables. And basically it still allows for that workflow automation, but it’s done a different way. And we do this across the platform in many, many different ways. I think the other way that, you know, we’ve made it quite simple is we’re very modularized. We’ve got five distinct modules.

Two of the modules are focused on operations, two of the modules are focused on planning, and one is focused on quality. So typically, if we’re selling to an individual function, we don’t even talk about, look at, mention the other modules; we hyperfocus on their world, and those modules that we have that are focused to each specific function or ICP user type go very deep into their world. I would say it’s simplified in the way that we’ve kind of split out the platform. Instead of having one massive control tower, we’ve got five individual modules, and they can use as little or as much of it as needed, depending on where they are in their journey.

Brian: Let’s kind of shift over to your team. Who decides, like, what gets prioritized in the product, what gets made? Engineers are going to make it, but someone had to decide, like, you know, we really need to make our setup easier because there’s more and more, you know, data vendors out there that are collecting telemetry, and so we want to be able to onboard those partners, versus no, no, no, the analytics and insights, we should be predicting when trucks are going to be delayed and not waiting until they are and then sending alert out after it’s already too late. We should do that. Like, tell me about the product, like, who does that work? How do you prioritize it? How do they work with UX?

Ilya: Yeah. So, we’ve basically gone through a couple of different philosophies at PAXAFE. One of my favorite quotes, even to this day, and when I started PAXAFE, it was especially true, is the Henry Ford quote, “If you would have asked the customer if they wanted, they would have said a faster horse,” so very much so in our, you know, initial years of building PAXAFE, we had, I would say, a very strong perspective on what the customer wanted and needed. And we, I mean, to some extent, we fell in love with our own product, with our own design. And, you know, it’s funny because at the end of the day, our initial hypothesis and our initial vision for what PAXAFE turned out to be today was 99.9% spot on. Like, nothing had changed. What where we were wrong was in the market readiness in terms of we built a product and a solution that was a few years early for the market, in our earlier years, right, back in 2020, 2021.

Brian: Is that when you started?

Ilya: We started in 2018. We started—

Brian: Okay, seven years. Okay.

Ilya: Yeah, that’s right. And so, we had to wait for the market to catch up. And in that period of time, we started to lean more and more on customer feedback and basically understanding why the customers felt like they were early, what real value that they needed to be delivered today, and this whole concept that you mentioned earlier, how can I realize the value from something if I don’t have the infrastructure that’s, kind of, laid out right? And so, you know, I would say, over time, we have this hybrid approach where we heavily partner with and rely on our customers for directional feedback. We collect that feedback through QBRs, through our knowledgebase, through our customer success team.

I go out, and my co-founder Ashok, our CTO, goes out and we routinely talk to our customers, both existing customers, customers that you know are relatively far along in the sales pipeline, but along the similar line, we still very much adhere to our initial vision. We don’t blindly just do anything and everything that a customer is asking for. We have this vision of putting the cold chain on autopilot and effectively becoming the intelligence infrastructure and back-end for each and every temperature-sensitive shipment that gets shipped around the world, ever. And so, it needs to kind of support that overall vision. Any product decisions that we do have to get us closer to that vision.

And so, you know, the way that we kind of build products today and prioritize products again, I think heavily reliant on customers, still adhering to our vision. We have a lot of internal debates and disagreements and alignment between product teams, between data science teams, development teams, even sales and marketing, customer success, basically all of our functions. We routinely meet cross-functionally, and the heads of each function meet routinely on a monthly basis to talk about roadmap, any changes to the roadmap, prioritization. I think to a large extent, it is driven by—at least short term roadmap is driven by customer demand, meaning, if there’s an opportunity to capture value immediately for especially existing customers that we’re already working with and help them achieve value, that gets prioritized first and foremost above anything that you know prospective customer or a new customer is asking of us. So, we want to be good partners to our existing customer base, but at the same time again, it has to fit within the broader roadmap of what we’re building it.

You know, we recently got asked to build, for example, almost like a billing management part of the platform for freight billing. And that is something we can, you know, potentially bring in through an integration, that is something that you know, most of the TMS providers, Transportation Management Systems have. It’s not a module that’s going to necessarily fit or live within our platform. Would it be something that we could bring in, like, the, at least, bring in the data and show it and kind of incorporate it into our analytics, et cetera, yeah, it could be, but it’s not going to add value to 90% of our customers, so, you know, it’s not something that we’re going to kind of stop everything else and prioritize.

Brian: Sure. And so, maybe you could tell us, just like, in terms of when we talk about the product, like, this application, do you have a product management function? Do you have a design function, engineering? Or is engineering effectively your product management function? Or data science? Like, I’m kind of curious about how the teams are made up, what kinds of resources you guys use to decide these things.

Ilya: Yeah, so my co-founder and CTO oversees product today. We’ve got a product management function. We’ve got several product managers that are responsible for various products or modules within our platform. We’ve got a data science team that it’s about a seven… I think, seven or eight person data science, machine-learning engineering team that focuses on building in a lot of the intelligence into our products. We’ve got a software development team, you know, includes everything from front-end, back-end developers, site reliability engineers, so we’ve got a pretty broad software team as well.

And then we do have two UX/UI designers as a part of the team as well, which focus on the design, which basically focus on putting the best possible product that fits within the confines of customer workflows, in front of the customer. And so, that’s how our team is structured. But it’s all predominantly led by my co-founder Ashok Seetharam.

Brian: Got it. What are some things that you’ve learned and changed, like, literally, in the products, you know, around either planning or on the delivery side, like, maybe assumptions you made or you, you know, designed the dashboard this way, and we found out, no, no, no, they really want it this way, which we thought didn’t make sense, but that’s what people were willing to pay for. I’m always curious about, like, especially with data products and analytics tools, what are we learning along the way, and can listeners possibly steal some of that insight and apply it to their own domain? Any just recent insights you can think about, or changes you’ve made?

Ilya: Yeah, absolutely. So, there’s a lot of things. I think, first and foremost, it really depends on who you’re talking to, you can have the same customer have three different people within the organization tell you three different things about three different right ways to do something, and three different preferences, right? So, you have to take everything that you hear with a grain of salt. But when, for example, we were building, you know, and delivered our first iteration of our, we call it our aggregate analytics, our aggregate insights tool, which basically takes all of that data that’s being collected from transportation and quality, aggregates it on a lane, route, and individual waypoint basis, and then provides prescriptive recommendations on which things to improve.

Our first iteration of that was effectively a risk-scoring algorithm that came out and provided a risk score on a lane-by-lane basis. And then you can drill down in each lane and you can understand things like which routes were the riskiest, how did the carriers perform? How much did temperature or weather or various events contribute to the risk score? And we thought that everybody would absolutely love this ability to understand what’s actually contributing to the risk score, right? And literally, like, you know, for the first six months of—or twelve months of use, users would come back to us and be, like, “I don’t understand what the difference between, like, a 71 is versus a 62 or a 43?” Right?

Brian: Right.

Ilya: Like, and then, “I don’t care about the risk factors. Like, I just need to know what to do.” Right? So, like, “Tell me what to do.” And that’s where we kind of abstracted the risk moving forward, we made it much more actionable, so we bucketed into, like, needs immediate action, monitor closely, ignore completely, right? So these, kind of, abstract definitions of what to do, and then we would make a recommendation—not we, our platform would assess and make recommendations to say, you know, change this variable, or don’t ship on Tuesdays.

You know, so basically, they didn’t like the, you know, the—so they wanted recommendations on which variables to change and how to change them. So, we started abstracting the risk scoring, and the platform started making these recommendations and root cause analysis, and then the next wave of feedback came six months later that was like, “Well, how do I know if I can trust that recommendation? Like, can you send me the raw data? Can you send me how you’re calculating this risk? Like, how do I know that I, as an end-user, or I can empower my team to go take action on your recommendation? I don’t know that.”

And then we had this big, kind of like, epiphany that was, like, it went full circle because that’s essentially going back to the starting point of labeling and qualifying and quantifying all the risk and telling you what’s contributing to it. So, we came to this conclusion that, like, okay, the end-users oftentimes, either they may not know exactly what they want, at the end of the day, they want you to put forth the best solution after you deeply and intricately understand what they’re trying to solve for. And we didn’t do that at the beginning. We focused more on delivering what we thought they wanted and needed without truly understanding deeply the nuances of their issues and their [unintelligible 00:34:39] and their problems. So, that’s one example where we kind of came out with, you can call it an over-engineered solution. Not over engineered. We didn’t really change much to the algorithms and to the intelligence; we changed how that information is consumed on the front-end. So, we simplified it, we made it less clicks. We abstracted some of the risk scoring, and that’s worked really, really well for us.

Another example would be, you know, the recommendations themselves. Well, these recommendations are great, but you know, they’re too broad. They’re not specific enough. And so, we started ingesting standard operating procedures from the organizations on the front-end. So, we would ingest these really elaborate documents that talk about approved vendors, approved routes, you know, packaging that’s been qualified so we can then make really—our AI—can make really accurate diagnoses of the problem and recommend what to do about issues that these recommendations become hyper-contextual and they’re based on existing workflows and existing SOPs that the company has in place.

That’s another thing that, you know, we kind of started off with these broad-based recommendations, and then we realized that nobody’s going to get value from—if your recommendation engine is telling you don’t ship on Tuesday, but, you know, it doesn’t account for the information that’s in the SOP that’s telling you you can only ship on Tuesday and Thursday, those are the only two days you can ship out on, you know, it doesn’t add as much value if you’re not able to add that full context in. And so, that’s another example. And I can, you know, I can go through a number of these, but we’ve effectively learned how to front-load that customer, understanding the existing customer process, workflows, technologies, which ecosystem partners they work with, where the data needs to flow through, both within the organization and outside of the organization. We understand that now all up front, so that we can put forth a solution, you know, that, from day one, adds value and doesn’t necessarily need to change their behavior a tremendous amount.

Brian: Talk to me a little about, you mentioned the AI piece here. Obviously, there’s a lot of people talking about this, like, for example, this SOP, is this something where your algorithm makes a high-level recommendation to monitor closely, and then you go and look at the SOPs, and it tries to build a little bit more context into, like, oh, wait, I shouldn’t recommend that because this is, like, a cheap product, and it’s okay if there’s a little bit of loss, so I’m going to change my recommendation, and here’s why I did it. Like, you know, is this the space I’m—I’m wondering if, when we talk about AI here, are we talking about traditional machine-learning forecasting. Are we talking about leveraging language models? I could imagine it gets complicated quickly, with all these companies having different SOPs and trying to model every single organization into, you know, an agnostic platform, it could be challenging. So, talk to me a little bit about what’s happening with AI and how you’re seeing that in PAXAFE.

Ilya: Yeah, so there’s a couple of ways that we leverage AI in our platform. I mean, I’d say at the most basic level, you know, document ingestion, we started with OCR, but as you know, OCR will probably get you 70 or 80% of the way there. It doesn’t account for edge cases. It doesn’t, you know, support things like handwriting very well, unstructured data. And so, yes, we had to, you know, in order to be able to basically meet 99.9% of document types with, you know, a hundred percent accuracy, or near a hundred percent accuracy, we have to rely on LLMs as a part of that.

So, document ingestion is the most basic version. Next you have more of these call it LLM-enabled diagnoses and recommendations. So, think of it as an AI that sits within each product that we have, within each module, whether it’s dealing with live shipments or after-the-fact aggregate analysis, and it’s basically telling you, number one, it’s diagnosing and providing context with any issue that comes up. So, if it’s live shipments, it’s on an exceptions management basis. It’s telling you, this is what’s wrong. This is the root cause. If it’s after the fact, it’s also telling you, here’s the root cause, here’s the historical trend analysis, right.

And then it’s actually putting forth that recommendation. And it’s first referring to those SOPs, so it makes a call to see kind of what’s in the SOP, is it relevant? And then second, it formulates its own recommendations based on a number of factors, scenarios, et cetera. Now, the cool thing about it is it’s LLM agnostic, and what we’ve actually found is that different models handle different types of queries requests, you know, whether it’s inferential questions or—basically different types of questions get routed to different models that best support that particular response type. And then there’s, you know, the actual agentic kind of workflows, where you can tell the platform what to do, and it will set up an agent to kind of do that. That is more so in its infancy.

So, that’s something that we’ve just started working on not too long ago, but that is, I believe, [sigh] you know, in [sigh] I do believe that is the future of our platform. I think in industries like pharma and produce, where things are a bit more conservative, and, you know, there’s a heavy regulatory focus, there is a fundamental kind of lack of trust in having an AI do something for you or even make a quality decision for you, like, very much. So, a lot of those—there’s a lot that can be automated today where a human is still massively in the loop just because the implications of making a wrong decision or wrong output could be drastic. And so, I think even though agentic workflows are very much the future, I think the areas where they’ll be applied will be very selective. And so, we’ve started focusing on those areas within our own platform, but yeah, that’s kind of—does that answer your question of how we’re leveraging AI?

Brian: Yeah. I wanted to a—you mentioned the trust thing and this obviously comes up a lot, and, you know, just so you know, as we wind it down here, I’m curious, like, when you’re using machine learning and AI to solve an aspect of the problem, does your product team generally have this sense of, like, there’s inherently going to be a trust issue here that we need to make sure that we address in the experience because there’s a—like you mentioned, you know, pharma is conservative, are you designing for this idea that the trust has to be designed into the solution because there’s going to be a bias to be not trustworthy of it, or does that not really exist in your customer’s sphere? Like, they don’t really know, they don’t care, like, we’re not really thinking about it, and we only deal with it when it comes up. If they say they don’t, like, “How did you come up with this answer?” Or, like, “Oh, it made a mistake. I can’t trust it.” Is it after the fact or are you thinking about it actively? Are you thinking about it at all?

Ilya: I think there’s my personal feeling on this, and then there’s kind of the position that we take as a part of the company [unintelligible 00:42:30]. My personal position on this is, like, look, as an industry, pharma is losing $40 billion worth of product today because they’re relying on, quote-unquote, Bob’s intuition from the warehouse of, like, what works and what doesn’t. In produce, it’s like 50x worse, or 20x worse. I think they’re losing, it’s like $800 billion worth of product each and every year, specifically due to temperature issues and excursions. And by the way, that pharma number $40 billion is drastically under reported.

I mean, pharma does not like to publicly share their loss data, and so, you know, they try to minimize kind of the—it doesn’t account for a lot of the, I would say, the ancillary actions that come from having temperature issues, things like root-cause analysis, corrective action reporting, replacement product, you know? So, that there’s a lot of hidden costs there that adds to that number. So, either way, kind of the status quo is, like, well, it’s not working, so okay, you might have initial kind of challenges with AI, but it’s probably not going to make things worse than it is today, than the status quo. It’s only going to get better. So, that’s my personal take on it.

Yeah, of course, from a company standpoint, basically, we try to provide each customer with the ability to drill into their own data and make sense of it, like, at a most granular level, at a shipment level, and with a full audit trail so that they can go in any specific—like, on an exception by exception basis, if they need to go to that level of detail, if there’s an audit, if they need to provide something to the FDA or to any other regulatory agency, they have the ability to do that. And I would say the level of support that we provide there is better than what other providers will provide today. Other providers, if a customer is asking for, hey, show me the raw data, show me where this went wrong, other providers will literally send them a CSV file with, like, 100,000 rows, and it’s like, “They’ll figure it out. Like, here’s the raw data. Go analyze it,” you know?

We have the ability to do that, but we also provide shipment-level details where they can actually go through on a shipment-by-shipment basis in data that’s still contextual, so that they can understand and easily consume, where they don’t have to do all this analysis and basically get to the conclusion, or get to the root cause of what actually happened to get that confidence around here’s why the recommendation was what it was; here’s what actually happened. So, we support them through this, you know, GxP validated audit trail and shipment-level detail that is still easily consumed by the end-user to where they have to have, like, minimal analytics or ability to interpret data skills.

Brian: Ilya, this has been great. Thanks for talking to us about PAXAFE. Do you have any final thoughts you want to share with our audience about building useful and profitable businesses around decision science, decision intelligence, and analytics, and just your experience so far?

Ilya: Yeah, I mean, if I’m thinking of advice to anybody that’s just starting out, I’d say the biggest thing is don’t build anything on day one, and probably not on day two or three or four either. Go out and talk to customers and go out and understand, not so much what they think they need, but what their actual pain points are, and on what their problems are, what they’re trying to solve for. And understand their existing workflows and confines within which they’re trying to solve for those problems. I think getting to that and getting as deep as you can in that discovery will allow you to put forth a version zero, a version one of a product that is much stickier than trying to go at it alone and force-feed it into their existing workflows. I’d say that’s the biggest thing, and that’s one of the biggest things we didn’t do right from day one, is we tried to get everybody to kind of conform to our standard, and that’s not feasible in this space.

Brian: It’s not true in a lot of spaces, and you’re definitely singing a song that is sung on this show quite a bit, to try to get out, go with the current, don’t try to swim upstream. Most people don’t want to change what they’re doing, so if you can kind of slide into the way they want to do the work and just make it easier for them to do the work the way they think they need to do it, it’s generally easier. But the trick is you have to know what the work is, [laugh] which you can only get through customer exposure. You can imagine how it could be better, but it’s not the same thing as actually doing that job every day. And I have seen your journey happen before, especially with data science, when we think, “Oh, we could predict this, we could get ahead of this. Look at all the things we could do with the technology,” and then you realize that they’re not ready to take that. They’re not ready to change how they do that work right now. So, it doesn’t matter. You have, “Technically right, effectively wrong solutions,” end-quote, at that point. So, thank you for sharing [laugh] that and advocating for this, so I appreciate it. I did not pay you to say that—

Ilya: [laugh].

Brian: Just for the record [laugh].

Ilya: No, no, no, you’re spot on there. So, I think that’s the biggest thing. The only other thing I’d say is, especially in the early stages—call it zero to one—if you’re not talking to customers, or you’re not building product, or you’re not doing something that is supporting one of those two things, I.e., you know, potentially fundraising or something like that, you’re literally wasting time. So, nothing else in the zero to pre-product-market fit phase, nothing else matters. Talk to customers, build product, iterate, shorten those iteration cycles. Everything else is a waste of time.

Brian: Thank you, Ilya. Where can people follow you and stay in touch if they would like to get in touch?

Ilya: Yeah, they can find me on LinkedIn, Ilya Preston, and then they can find our company PAXAFE, www.paxafe.com—that’s pack-safe, not pack-sahfee—and they can also look at us up on LinkedIn and shoot us a follow on LinkedIn as well.

Brian: Cool. Thank you so much for sharing your journey with us. It’s been great to chat.

Ilya: Thank you for having me.