Litmus CEO Vatsal Shah on Unified Industrial Data, Scale, and Cutting Through the Noise
Manufacturing Happy Hour
In this episode of Manufacturing Happy Hour, host Chris talks with Vatsal Shah, founder and CEO of Litmus, which describes itself as a unified platform for industrial IoT. The conversation covers why Shah thinks fragmented industrial data needs one end-to-end platform instead of a patchwork of point solutions, and what Shah learned on a recent round of customer site visits. Shah's main argument is that manufacturers now arrive with real, quantified problems. They increasingly treat scale, central management, and the cloud as requirements, not options.
What "unified platform" means in plain terms
Chris asked Shah to explain Litmus as they would over drinks. Shah started with what they see as the core challenge in manufacturing and industry: a fragmented data landscape. Plants run legacy systems, and control systems, automation systems, and robotic systems all hold large amounts of data. The work is to collect that data, normalize it, contextualize it, and make it available to "smarter systems" that can consume it.
Shah argued that this whole journey has to be unified. If one vendor solves one piece and another vendor solves the next, customers are left to work out everything in between. Shah compared that to "playing giant Jenga." Litmus's pitch is a single platform that covers the full journey for industrial customers. For a less technical version, Shah used a simple picture: there is a boiler, you want to know what it is doing, and the unified platform is how you understand, analyze, and use that boiler's data.
From ladder logic to a connectivity problem
Before Litmus, Shah worked at Rockwell Automation in industrial design, business development, and strategy, according to the host's introduction. Shah described their career as starting right after a bachelor's degree, as an instrumentation and control engineer. In the first week on the job, Shah was handed P&ID diagrams and asked to develop SCADA screens and business logic. Shah said they were "fascinated" by ladder logic and kept building it, first for power plants and later for oil and gas, pulp and paper, and food and beverage.
As a junior engineer, Shah initially stayed at a desk rather than going out for field acceptance testing. Later they commissioned some facilities, which gave them experience with panel logic, HMI, and SCADA work on both the design and field sides.
The problem that led to Litmus came from one project that required working with four vendors, including large oil and gas automation suppliers such as Emerson and Fisher-Rosemount, as well as Siemens systems. By Shah's account, it took about three and a half months just to establish connectivity across all of them. The team used OPC and everything else available, and they still ended up writing Visual Basic scripts to pull data from one system and push it into another. The original idea for Litmus was a platform that could talk to every control system and output the data "in a way that humans can understand."
"49 out of 50 customers said you're naive"
Shah said the idea took shape around 2012–2013. It came mostly from their own and their co-founders' experience rather than from customer requests. The team then took the idea to customers quickly, and Shah recalled that 49 out of 50 told them it was naive, that it would never work, and that even if it did, nobody would buy it from them. The team kept asking why not. Over the following years they built a more compelling story in which connectivity was only one part, and how the data gets used became the larger part. Litmus was founded after that.
Chris asked what kept them going when roughly 98% of people were discouraging. Shah gave two reasons. First, the objections were never that the problem didn't exist. People said nobody had solved it before, and that if anyone did, it would be one of the large automation companies, not an independent vendor building a common data layer for industry. Shah took that to mean the problem was real. Second, Shah said the founders were "a bunch of young kids" out of university with nothing to lose and nothing to unlearn. Everything was new to them, which made them bullheaded. Shah admitted with some humor that the skeptics "of course knew what they were talking about."
Shah's advice to manufacturing leaders in a similar spot was to persevere. As Shah put it, if the problem statement exists, "you might be the best one to solve it because you identified it." Shah added that for Litmus the key ongoing challenge was to keep reaching product-market fit with a broader customer base.
Back on the plant floor after COVID
Chris mentioned a recent LinkedIn post in which Shah described visiting about six customers to see Litmus in use. Shah said visits like this were routine before the pandemic. The two or three COVID years went by in a blur of video calls. Being back on site reminded Shah how much ingenuity is built into manufacturing operations, which is easy to lose sight of while writing code on a laptop.
Shah gave an example. A developer might casually say "we're going to connect a million tags." Once you understand what those million tags represent in a facility worth a hundred million or a billion dollars, you stop using the phrase lightly. Shah described seeing their product influence a billion-dollar manufacturing operation as "mind-blowing."
On the question of what kind of manufacturer adopts this technology, Shah said these customers are not only early adopters but mass adopters, and that the market is ready. In Shah's view, the questions have become concrete: here are my assets, here are my processes, here is my problem, can data help solve it? Shah said "it's not fluff anymore." It is no longer about digitizing and seeing what happens.
Two concrete problems: yield loss and scrap
Shah described two customer problems from the trip.
The first was at what Shah called one of the largest food and beverage companies. The issue was in the packaging machines: why yield was below expectations and why downtime was higher than it should be. The company's KPI was manufacturing loss per hour. They compared the machines' specifications with actual performance and multiplied the gap by the value of the finished product. The result, as Shah relayed it, was about a billion dollars a year in lost manufacturing capacity. The company then asked whether data could help close that gap. Shah framed it as specification versus reality. Data could show where downtime happens and help prevent it, which directly increases yield.
The second was a metallurgy company with a scrap problem. When a product doesn't meet the quality they want, it is scrapped and made again. That wastes manufacturing resources, production resources, and human effort. The company wanted to reduce it. Shah called both of these "very genuine" problems.
Two kinds of customers, and a rough split
Chris asked whether customers arrive already knowing what a problem costs them, or whether Litmus helps them find out. Shah said both kinds exist.
The first kind starts with discovering the data. Shah's example was a pistachio factory that relied heavily on pen and paper, with handwritten logs for cleaning and other processes. Without digital records, the company couldn't see where to optimize. Companies like this build a baseline digital infrastructure: they collect the data, push it into a simple cloud data warehouse, and visualize it with tools like Power BI or Tableau. Once they can see things like a 100-kilogram loss on one run, or what a golden batch looks like, they start to identify which use case to pursue.
The second kind, like the food and beverage company, already knows the problem and the gap between spec and reality, and wants data to help solve it.
When asked for a rough split, Shah estimated 35–40% in the discovery group and about 60% in the group that already knows its problem. Shah immediately called this a possibly "very biased" figure. Litmus tends to engage companies that already have an industrial IoT or Industry 4.0 strategy, with an officer and a budget attached, so Litmus may enter late in the journey. Some of those companies may have been in the discovery group a year earlier. Chris saw the numbers as a positive trend compared with five or ten years ago, when many companies didn't know what their data was or where it lived.
Shah added that customers also understand the problem "one step deeper," as a technology problem. They know their environment is heterogeneous. No single vendor can solve everything, and they often can't even get one system integrator to connect everything or help design an architecture that will scale. Shah said some vendors had "borderline conned" these customers by selling solutions presented as scalable that weren't. As a result, customers now say they will only work with vendors that scale well, model their data, and put security first.
Technology-first experimentation: encouraged, but not on production
Chris raised a common problem in manufacturing digitization: people find an interesting technology and apply it before defining the problem. Shah said the response is mixed. Doers often start with technology, whether something from GitHub, an open-source project, or something they saw on LinkedIn. Shah said they should not be discouraged. They should experiment, play with low-code environments, build applications, and visualize data.
Shah drew a clear line at production systems, though. Hooking experiments up to production, or connecting them to a real boiler that could have serious consequences if it were hacked, is "probably not" something people should do. Shah's position: learn the technology and pick up new skills, but know enough to understand that it can be dangerous on the plant floor.
Who actually drives digitization: a "fusion" of teams
Chris noted that digital transformation is often seen as a C-level initiative and asked how plant-floor staff are driving innovation. Shah agreed with Chris's framing. By Shah's estimate, about 75% of the people they met on the trip began as industrial automation or automation engineers and now lead manufacturing digitization strategies, because they know what exists on the plant floor.
Across Litmus's customer base, Shah described CIOs or data officers bringing together three kinds of people: those who know the plant floor and have done PLC programming, data scientists who can interpret the data, and application builders. Shah called the combination a "fusion that you can't replicate anywhere else." Funding usually comes from the center, because rolling out data initiatives across 50, 100, or 200 plants requires a real budget. A single plant owner can drive the effort, but that person guides the central team on how to deploy, distribute, scale, and manage it, and on what the data means.
Chris said that in their own interviews, the companies that succeed at digital transformation have cross-functional teams of executives, IT, OT, and plant-floor staff. Shah said this applies to "100%" of Litmus's large customers. These teams sit under an umbrella program, such as a data initiative, a manufacturing DataOps initiative, or a CIO-led asset program, and include practitioners, data scientists, and application builders.
The surprise: scale is not optional
Asked what surprised them on the trip, Shah pointed to Litmus Edge Manager, the company's central management product. Litmus had positioned it for later, when customers were ready to scale. Customers and system integrator partners told Shah that scale matters much earlier than Litmus had assumed.
Shah relayed their reasoning. Plants already have legacy OPC servers, legacy SCADA systems, and home-grown aggregators built on custom code. These work, but they can't be replicated from one line to another or one site to another. If one site uses Node-RED and another uses something else, the central team has no practical way to manage it all. In Shah's summary, customers said scale and central management are "not optional" for any of their industrial IoT initiatives. Shah said this was not entirely surprising, but the way customers described it was.
Chris asked whether the "fusion" teams explain this. Shah said yes, at least partly: one part of those teams is cloud-native IT staff who are used to scripting everything and managing laptops, networks, and data warehouses centrally. They couldn't understand why OT tools were built to run on a single line and never designed for scale. One customer told Shah that a major reason for choosing Litmus was that Edge Manager lets them make one API call and update all of their nodes across every plant. As Shah recounted it, the customer said this was not a feature but a mandate, and that without it they would never use the product.
Cloud: fear has shifted from security to cost
Chris asked whether manufacturers are past their fear of the cloud. Shah said the fear used to be about attack surface: enabling cloud services might open up cybersecurity and management problems. Shah's view now is that "cloud is not optional anymore." The customers Litmus works with already have cloud initiatives on the financial, supply chain, ERP, and MES side, and have spent several years moving local SQL servers, MySQL databases, and ERP systems to the cloud. They have built trust and relationships with cloud providers. Now they are bringing operational data into the same environment.
Shah said a fear remains, but mostly among midsize companies, and it is about cost rather than security. They worry that turning things on could cost a million dollars once per-message charges and warehousing costs add up.
Feedback-driven development
Chris asked how to bring customer feedback to market quickly. Shah said "feedback-driven development" has always been a core principle at Litmus, and told a story from six or seven years ago. A large automotive tier-one supplier issuing an RFI asked whether Litmus had a particular connectivity capability, and said Litmus would be disqualified without it. The capability was already on Litmus's roadmap and existed in their lab, so they said yes. They arranged a call within two days and demoed it. Someone had worked 24 hours straight to build the connectivity overnight.
Shah believes feedback-driven development is "the only way to survive" as an industrial data platform, and called the company's accumulated feedback one of its biggest assets. Litmus holds quarterly business reviews with customers. Shah personally joins significant customer support calls to learn where customers hit the platform's limits or where ROI is being constrained. Internally, Litmus has a process for segmenting feedback from customers and channel partners and turning it into a product that meets many requirements at once. Shah called feature development "more like art rather than science": you take all the input, "create a gumbo out of it," and launch a feature that addresses about 80% of the issues from the start. Shah said the company has run this cycle for about six years and credits it for the company's success, describing the team as engineers first, close to the ground, who let customers tell them what to solve.
Closing thought: filtering the noise
Asked what they wanted to leave the audience with, Shah returned to the earlier topic of doers experimenting on their own. Shah said there is more noise in the market than people realize. Every problem has many proposed answers, some that mainly benefit a particular vendor, some that benefit the customer, and some that benefit the ecosystem. Shah thinks filtering that noise is critical. Sometimes you have to try things yourself. Otherwise, find a trusted partner who puts your interests first, whether a system integrator, technology partner, cloud partner, or value-added reseller. Shah said Litmus tries to answer in the customer's favor rather than in favor of its own architecture. Shah's answer to how to cut through the noise: try it, understand it, and find a trusted partner to help you get there.
[Music]
Vatsal, it's awesome to have you here. It was great being part of your virtual event just a few months ago, and I have to start off in Manufacturing Happy Hour fashion with this question. Litmus is described as a unified platform for industrial IoT. So if we're having beverages with one another, how do you describe what you do?
First of all, thanks Chris for having me. I really appreciate you hosting me here. So if we are having beverages with each other, if we talk about unified platform for industrial world, I would say there are some foundational challenges in the manufacturing or industry world right now. They do start from all the fragmented data landscapes that we are seeing. There might be legacy systems at play. They have amazing amount of data right inside those control systems, automation system, robotic system. How do we make that available to broader world, collect out of it, normalize it, contextualize it and make it available to the smarter system that can consume that data? That whole journey, it has to be unified.
We cannot give a point solution that somebody's going to solve this challenge, somebody's going to solve this challenge, and let customers figure out everything else that they require. It's like playing giant Jenga. Rather than that, we are proposing unified platform. It takes care of complete journey for manufacturing or industrial customers. And that's what, again, it still goes in a little bit technical way, but if I'm explaining like it's five: there is a boiler, you want to understand what the boiler is doing, that's when you use the unified platform. Correct. Understand, analyze, utilize that data.
Yeah, and you touch on a big point that we face in manufacturing all the time: fragmented systems. How do you create something that's unified, that brings all that information together, and how do you take action on that? We're going to get into all of that as we get into today's conversation. Yep, looking forward to it.
So before we get there though, you've got a cool background and I have to ask you, you know, what were you doing before Litmus? If I saw it right, you were like an industrial design engineer at Rockwell Automation, you were in business development and strategy. Like, what were you up to? Give us the background.
Right after bachelor's, I started my career as an instrumentation and control engineer. So at first day of the job I was given, let's say, these are P&ID diagrams, go develop SCADA screens and business logic out of it. So within first week I started developing ladder logic and SCADA screens, mainly for power plant use cases. And like, I was fascinated by ladder logic at the time and I was like, just keep on developing it. So my real career started from automation engineer, and started from power plant, went into oil and gas, some pulp and paper and food and beverages, towards data.
Mainly, once again, as a new engineer you're not supposed to go on a field acceptance test or UAT. We were not supposed to do that. So I was still on the desk in the initial times, and then did commission some of the facilities towards the end of it. So I have experience from manufacturing side, on the field side, on how to create anywhere from panel logic and HMI and SCADA screens.
And I saw the problem statement there though, where on one of the projects we were forced to work with four different vendors. They were large oil and gas vendors like Emerson or Fisher Rosemount, and there were some Siemens systems there. It took us like three and a half months to develop connectivity across all of them. Even if we were using OPC, even if we were using everything else, we were literally writing scripts on VB and trying to collect data from one and integrate into another one. To solve that, the first idea was to create a platform that talks with every control system out there and gives the data out in a way that humans can understand. That was the idea, the whole idea for starting Litmus.
So I have to ask, what year was it that that idea really hit you? Because I mean, I've been in this industry since 2009, 2010 really is when I got my start, and I don't think we were there yet. Like, when did this moment hit you? Was there a moment, I should say?
I would say in 2012, 2013 time frame this moment really, really hit me. Once again, it was more about my own personal experience or our co-founders' experience rather than getting feedback from the customers itself. That was the first thing. But we went into customers and meetings very fast. We went out there; 49 out of 50 customers, they said, you're naive, this will never work. Even if it works, nobody's going to buy it from you. But we kept on asking why, why not? How can we figure it out? And then over years we developed a more compelling story where connectivity is just one part of it; how you utilize that data is a bigger story of it. And then Litmus was founded. But yes, that was the moment, 2012, 2013 time frame, it's when it really hit us.
I have to ask you this question then, because I think your story, there's some similarities I hear from other stories, right? You experienced the pain in your role that inspired you to start Litmus, but you also followed that up with 49 out of 50 people told you it wasn't going to work. So what made you persevere and keep going forward to say, I think there's something here, versus being like, well, almost, you know, 98% of people said this was not going to work, we should give up? What kept you going?
I think the responses were interesting. The responses were not that the problem does not exist. "It's naive that you think you're going to solve it" was the response. Nobody has done it before doesn't mean that it's not required. Yeah, sure. Like, this is the problem and then somebody's going to solve it, but it's going to be one of the large automation companies solving it rather than independent vendor who's going to figure out common data layer for the industrial world. So that was one. And the second thing, we were a bunch of young kids out of university; we had nothing to lose. We first out of it, we were like, okay, you're going to reject, you don't know what you're doing. That was our, at the end of the day, like, these guys don't know what they're talking about, right? Of course they knew what they were talking about. And we had nothing to unlearn, I would say. We were learning everything for the first time, and that helped us being bullheaded that we were before.
So that's a fun answer, right? You were young, you had that ambition to keep going forward. You also highlighted how it's not that the people you spoke with didn't say there wasn't a problem; they agreed with you that there was a problem. They were just saying, ah, we just don't think you're going to be able to solve it. So what advice would you have to the manufacturing leaders that listen to this, whether they work for a big company, whether they're starting their own thing? What advice would you have to them when they're in a situation like that where there's, let's say, some doubt, but there is a problem that needs to be solved?
I would say you have to persevere out of it. That's the only thing that matters. Like for us, it was more or less we were ahead in the market, we were ahead in our journey in the industrial data innovation itself. But like, how do you make sure that we keep on hitting the product-market fit for a broader customer base is critical. So the only advice that I would give is persevere. If the problem statement exists, you might be the best one to solve it because you identified it.
Excellent advice. And I think this actually ties into what we're going to talk about next based on some of your recent experiences at Litmus, because I literally just saw this on LinkedIn as I was preparing for this interview, but you had made a post saying, hey, I just traveled to six or so of our customers to see Litmus in action, to see how our solution works on the plant floor. Like, I'm curious right off the bat, what are these plant floor environments like? Are these similar environments? Are they more advanced than other manufacturers? I'm just curious what type of manufacturer is, let's say, a bit of an early adopter for something like this.
Yeah, it was just fantastic because pre-COVID we used to do this like it was casual. We used to just fly to customer site and they used to show us, here is what's going on, here is how it's working, and everything was good. The last two, three years in COVID, they went by a blur. We were connected with our customers, we were always there on video, but the thing that we don't realize is these manufacturing operations, they have so much ingenuity built into it that we can't even comprehend. It's like we are sitting on our laptop and we are developing a code: yeah, we are going to connect a million tags, right? That's a story that we say, oh, a million tags is fine. But if you really understand what those million tags represent, then you won't just casually use the words "we are going to collect a million sensor inputs in our system," because they are running hundred-million, billion-dollar facilities there, where you have to understand what you're doing.
And my experience was just, yeah, it's mind-blowing when you see how your product is influencing a billion dollars' worth of manufacturing facility out there.
And to answer your second question, like how do we think about, like, are they early adopters? They are just mass adopters itself. I think the market is ready. Market is more asking the question: here are my assets, here are my processes, I have this problem statement, can data help me solve it? That's what they are really working towards. And their questions, they are as genuine as you can imagine. It's not fluff anymore. It's not like, oh, let's just go and do digitization and we'll see what we get.
It's really... I visited one of the largest food and beverage companies out there, and that problem statement was really in the packaging machines itself: why we are not getting the yield that we are supposed to be getting, or why our downtime is higher. Their KPI was amount of manufacturing loss per hour. These are the specifications of our machine, this is the result that we are getting right now. If you calculate the difference between both of them, multiply by cost of your end result, you will get a billion-dollar number right there, that at the end of the year we have a billion dollars in manufacturing capacity loss. Now can you help us with solving it with the data? And you find yourself dumbfounded there. You are literally solving a manufacturing problem, which is spec versus reality. Data can help you solve it, understand the downtimes, prevent those downtimes. It has a direct impact on getting more yield. That's one.
Another one was a metallurgy company, and that metallurgy company was always about: we have a scrap reduction issue that we want to address. We manufacture something, it's not at the best quality that we want it to be; that means we have to scrap it and we have to go through that process again. That means we are wasting resources, manufacturing resources, we are wasting, like, let's say, production resources that we have and human resources that we have. How can we reduce it? So very genuine problem.
So I have a couple questions because these are two great concrete examples. In the case of the metals company, we were talking about quality. In the case of the food and beverage company, you're talking about a billion dollars in lost production a year. Are these problems they've already calculated, they know it's costing them this much and they're bringing you in, or is this something you're helping them realize, that hey, this is the extent of your issue, and by the way, we can help as well?
Some food and beverage companies, they start with discovering data itself because they do not know the problem statement. This is, let's say, a pistachio factory. They have a lot of pen and paper. They're writing down every log of: this is the cleaning process, this is some specific Bing process and other process. There are a lot of manual logs that exist, so they can't understand where they can optimize. So companies like that, they create a baseline digital infrastructure where they collect all the data and they push it into a simple data warehouse in the cloud, start doing Power BI, start doing Tableau, start visualizing the data: okay, we had one turn of this here, we had 100 kilograms of loss here, and this is the manufacturing operations or golden batch here. Then they start understanding this might be the use case that we should address. That's customer type number one.
The customer that I was just visiting, they already knew the problem statement. They already knew that there is a spec versus reality issue. When we visited them, it was: well, this is the specification of machine, this is the reality of the machine right now, here is the gap, multiplied by our cost, done. They already knew that. It's like, okay, now data is going to help us solve it. So again, both problems exist, both types of customers exist.
I'm really excited about that answer, 'cause it begs the question, and this doesn't need to be an exact science, but I'm curious your perspective: are more companies in column A, where they haven't even been able to contextualize the data but understand they have an issue, or are more companies at this point in the position where they have contextualized some of the issue and they can tell you, this is my problem statement? What is the rough distribution these days?
Rough distribution, I would say 35, 40% companies on the first column and close to 60% companies on the second column. That might be just a very biased answer because we engage with companies who already have industrial IoT or Industry 4.0 strategy defined. Sure. So again, that's just from Litmus perspective. When we engage with them, they already have an officer associated with that, with the budget, so we might be a little bit late in the journey. They might have the exact... they were in column A a year back, but we were not engaged with them at that time.
And that makes sense, right. But what I do love about your answer, and no one needs to quote this specifically, but I like the optimism that's there. It's like, hey, at least for the companies we're engaging with, more people are familiar with their problem statement; they've already contextualized at least enough of the data to get there. I just think that's a good trend in the right direction, whereas maybe 5, 10 years ago people were just like, I don't know what's going on, I don't know what my data is, where it's sitting. So I love the direction you went with that.
Yeah, and I think if you go one step deeper, their use cases are one, but they are also aware of this data landscape that they have. It's a heterogeneous environment. No one vendor can solve all of the problems. They can't even get a system integrator to connect with everything, or they can't even get one vendor to help them create this blueprint of their architecture that's going to scale. So they know a problem one step deeper, which is technology problem. They have legacy systems. A bunch of these vendors, they borderline conned them in giving them a solution which was not scalable. They pretended that it was scalable, and now they are coming back as, like, we are only going to work with vendors that scale very well, that model, that are security-first, to address this data landscape problem that we have.
Well, another great point you made there is that taking it a step deeper, that's when you start looking at the technology behind it, which is the right order people should be going in. But all too often, and I think this is one of those challenges around manufacturing digitization, is people like, okay, there's this cool tech, let's
slap it on what we have, they haven't done the due diligence to say, hey, this is the problem that we need to solve first. So are you starting to see more of that, then? People are understanding it's like, okay, problem statement first, and then we'll worry about what technology goes next?
Like, there's a mixed response here, and it's a very good question. So should doers be discouraged from doing anything that they want to do? So doers, they start with technology. They start with something that they found on GitHub or open-source domain, or somebody that was talking on LinkedIn. Should they try it? By all means, go ahead and try it. You want to play around with some low-code environment, you want to build some application, you want to visualize it, by all means, strike.
Should you be hooking up to the production system? Probably not. Should you be connecting that to a real boiler, which might have implications if it gets hacked? Probably not. You should not do that. So yes, they should be encouraged to try the technology. They should be careful and they should know what they're doing before they hook it up to production. So yes, there is a technology, shall learn it, acquire new skill sets, but know enough that it's going to be dangerous if you put it on your plant floor.
That's a nice segue into the next question I'm going to ask, because when I think of, I'd put you in the category of digital transformation with what Litmus does, and when I think of that, I usually think of that as an enterprise, a C-level initiative. But I want to go back to your recent visits to your customers. How are you seeing people on the plant floor drive innovation? Because I think that's a new part of the recipe that we're starting to see, that it's not just an executive driving a decision like this, it's the people that are out there actually using this technology that are really finding the problems that need to be solved and finding solutions to them. What are you seeing from your recent trip, if you will?
Yeah, you're 100% right. My trip was like, let's say 75% of people that I met, they were industrial automation or automation engineers at first. Now they are driving manufacturing digitization strategies because they know what exists on the plant floor. So they are there.
With the amount of customers that we work with, we have a large portfolio of customers all across the world, so now we're seeing a mix, which is, this mix is very evident, where somebody who is aware of what exists on a plant floor, somebody who has done it before, somebody who has done PLC programming, or somebody who knows those environments before, they are merged into a common team by CIOs' or data officers' requirement. They merge it with data science and application builders.
So there is somebody who knows how to build applications, there's somebody who knows how to understand that data, and there's somebody who knows what that data represents. You combine them, you've got a fusion that you can't replicate anywhere else. That's why there is a convergence of it.
So yes, it's driven by a budget from central, because you require a good budget to drive a data initiative across all of your plant floors, like 50, 100, 200 plant floors. You need a budget for it. One single plant owner can drive it, but that plant owner is going to guide the central unit how to deploy it, how to distribute it, how to scale it, how to manage it, what that represents. All of those things, they are there. So it's again fusion. My answer would be this: fusion.
Yeah, and it's a true team effort. And in interviews I've done where digital transformation has been the focus, the companies that I've seen succeed the most are companies that have those cross-functional teams of executives, the doers, the folks out on the plant floor, IT, operations technology. If you can get those people working together, that's when you see successes. At least that's my experience. Is that what you're seeing too?
100% of it. 100% of large customers that we are working with, they have these teams. They put them under the umbrella of either a data initiative, manufacturing DataOps initiative, or some CIO's initiative for understanding all the assets and what they represent. So there is an umbrella initiative. Under that umbrella initiative, there are practitioners who have done it before, there are innovators, which are data scientists, and there are, again, innovators on an application builders side as well. So put them together, they are going to understand the problem statement and solve that problem statement.
Excellent. Well, I have one last question from your recent trip, and that's: was there anything that surprised you from your visits to some of your customers? Anything that was something new you learned, or something you didn't expect going into it?
One of the biggest factors, or let's say eye-opening things, was we have a product which is a central product called Litmus Edge Manager that is used when customers are scaling it up. One thing that I realized after talking with all of the customers, all of the system integrators, partners, is scale is becoming a more important factor at an initial stage than we ever assumed. This was a big surprise for me. We were always selling that central management and scalability aspect of the product when you're ready to scale.
So the thing that they told us is, there are legacy products out there, there are legacy OPC servers, some legacy SCADA systems, and then there are aggregators that they have designed, some shell code that they have written. It exists, it works. You can't scale them. You can't replicate it from one line to another line. You can't replicate that from one site to another site. How are you going to scale all of that initiative that you did? You can use Node-RED on one site, you can use something else on another site. How is that central team supposed to manage it?
And that was really eye-opening, and again, not entirely surprising, but surprising in the way that they described it, that scale is not optional. Central management is not optional for any of the industrial IoT initiatives for them. I was like, okay, very nice.
I'm interested to know, then, is it because of the fusion, as you called it, you have on those teams? Is that why they're recognizing scalability is so important?
Because one component of that fusion is cloud native. Somebody who knows how to script the complete automation in an IT environment. How do they manage everybody's laptop? How do they manage every network? How do they manage data warehouses? Everything is scripted, everything is centrally managed from an environment that allows them to have this distributed layer. Why can't they get that in OT? They can't understand that. Why all solutions that they were evaluating were suboptimal, why they were just created to run on one line. They were never created for scale.
And that's what they were explaining, like really explaining to us, that you don't realize this, but one of the biggest factors in selecting you was because you have Litmus Edge Manager that allows us to make one API call and update 100% of our nodes across all of the plant floor. It's not a feature, that's a mandate. If we don't have it, we will never use your product. I was like, okay, wow.
Yeah, well, what strikes me about that is now having a solution that's cloud native is a requirement. So would you say manufacturers are over their, quote unquote, fear of the cloud, if you will? Because I feel like five years ago there were people that were still skeptical about it. What are you seeing?
Yeah, there was always a fear of cloud, or there was always a fear that the attack surface that it might open up would be too large for them if they enable cloud services, which is cybersecurity issues will pop up, their management problems and other things, they will pop up. So it was always there, but cloud is not optional anymore.
Every customer that we are working with, they have either financial side, supply chain side, ERP side, MES side, they already have those cloud-based initiatives. They already started migrating local SQL servers to cloud SQL servers, or local MySQL to cloud MySQL, local ERP to cloud ERP. They have been doing it for the last few years. They have enough trust built out there, they have enough relationship built out there. All they are doing is bringing now operational data into the same environment so they can digitize those aspects as well.
I don't think the fear is there anymore. Fear is there for midsize corporations, because of not the attack surface, but because of cost. The fear still exists that by just enabling this, is it going to cost me a million dollars or what? Because I'm counting the number of messages I'm going to send, per-message cost, and this is warehousing cost. It's going to cost me a million or what? That's a fear for them.
Oh, okay. So, well, my biggest takeaway from that statement was cloud is not optional anymore. People understand that it's secure, there's this necessity of scalability, and you need cloud for that. So for the manufacturing leaders out there, I think you've given a lot of really good down-to-earth advice around digital transformation today, with some great specific examples.
As we get to the end of our conversation, this is more of like a young company, kind of a startup-y type question, right? But how do you bring customer feedback to market quickly? I think this is something startups and especially large manufacturers are wondering: how do I do that? I think this is something that Litmus excels at, so I'd love to get your advice for the leaders out there on this one.
Yeah, again, one of the core principles on us creating the product was always feedback-driven development. If I tell you a story, one of the large automotive tier ones, we were bidding for an RFI. This is like seven years ago now, six, seven years ago. And they asked, do you have this connectivity established? Otherwise you'll be disqualified. That was a simple thing. And we already knew, we already had that on the roadmap, we already had a system available in our lab. We were like, yeah, sure, we have it. And next day, like, we arranged a call in two days and we actually demoed it to them right then and there, that this connectivity exists. We developed it overnight. Somebody worked 24 hours straight to develop that connectivity.
Now the story is, feedback-driven development is the only way to survive in an industrial innovation platform, in an industrial DataOps platform. The feedback that we have is probably one of the biggest assets that we have as of this moment. We go on quarterly business reviews with customers. I personally go on customer support calls if they are significant enough, just to understand where we are hitting limits of our platform, or where are we hitting, let's say, possible ROI restrictions for them. So understanding that is critical.
Then we created a process internally: how do we segment that feedback across all of the customers, all of our channel partners that we have? We get a large amount of feedback. How do we segment it? How do we craft a product which fulfills everybody's requirements all at once? So developing a feature is more like art rather than science, where we input all of this, create a gumbo out of it, and then launch a feature which is addressing 80% of those issues right off the bat. And that's that cycle. We have been doing it over the last six years, and that's how we are successful. It's like we are really, really close to the ground. We are engineers at first. We know how to solve it; what to solve, we let our customers tell us.
I like the gumbo analogy. I also like what you just said: feedback-driven development is necessary for survival. So I think you guys are a great example of that. As we get to the end of our conversation, last question's up to you. Is there anything you wish I would have asked you that we didn't cover today? Right, we've covered some good examples, we've talked about Litmus, digital transformation. Anything else on your mind that you want to leave the audience with?
One of the, let's say if I'm asking myself, an extension to your earlier question where there were, like, doers trying to do everything by themselves: how much noise there is in the market is something that we can't really, really understand. Every problem statement has a lot of different proposed answers. Some answers, they are good for a specific vendor, some answers, they are good for customers, some answers, they are good for the ecosystem. How do you filter this noise is extremely critical. You can't do it without sometimes trying, or find a trusted partner who has your interest first.
We actually, as Litmus, we always give responses in favor of customers rather than our own core architecture. So finding a partner who is going to give you that feedback is critical. How do you cut through the noise is the question. Try it, understand, find a trusted partner. It might be a system integrator, it might be a technology partner, it might be a cloud partner, it might be a value-added reseller partner. Find a trusted partner who's going to help you cut through this noise and help you achieve success out of it. That would be the answer to the question of how do you cut through the noise.
It's funny, we talk about cutting through the noise in terms of what's on social media, what you're getting hit with from a marketing standpoint. Same thing goes for technology as well. I think you summed things up very well today, Vatsal. I'm going to have links on the show notes page, manufacturinghappyhour.com, to connect with you, to connect with Litmus, to see all the cool things that you and your team continue to do. In the meantime, I just wanted to thank you for taking the time to jump on today's show.
Absolutely. Thank you for having me, and it was great chatting with you. Thank you. Cheers.
Cheers.
Article published