Rony Kubat, Tulip Interfaces

This week our guest is Rony Kubat, cofounder of Tulip Interfaces. Rony and I talk about what a manufacturing engineer's toolkit is like, and how Tulip's purpose-built hardware & software changes that.

Listen and subscribe on iTunesOvercastGoogle Play and Stitcher!

IMG_5548.jpg

Notes:

Thanks to Tulip for providing their tools to us!

SHOW TRANSCRIPT

Spencer Wright - 00:00:25 - Today, I have Rony Kubat. Rony is the cofounder of Tulip. And is somebody who I have referenced many, many times in The Prepared over the past couple of months. Rony, welcome.

Rony Kubat - 00:00:35 - Thank you.

Spencer Wright - 00:00:37 - So I am very familiar with what you guys do because I've been using Tulip for the past nine months or so, which makes asking you this question a little bit tricky, but what is Tulip?

Rony Kubat - 00:00:52 - If you are a manufacturing engineer, basically worldwide, the kinds of tools that you have to use are not made for you. You are typically using Office Suite stuff. You're doing a lot of work in Excel. You're using Word and presentation software just to get your job done, just to figure out what's happening on the floor—what are the problems? How am I fixing them? And fundamentally those tools are not made for manufacturing engineers. They're great, but they're not the right tools. So Tulip is a kind of software for manufacturing, which is meant to be this like first-class tool for a manufacturer engineer. It's the way that an engineer can create all sorts of applications on their own.

They take these applications, they can deploy them onto the factory floor and then use those applications both to understand what's happening on the floor to help guide the associates that are there and to optimize that process in a very sort of fluid way. Does that make sense for like how you’ve used it?

Spencer Wright - 00:02:12 - Yeah. Totally. And it may be useful to walk through how we have used it, I guess. I don’t know.

Rony Kubat - 00:02:22 - Yeah, we can turn this whole thing around. I can host you.

Spencer Wright - 00:02:26 - So we're using Tulip for a couple of things. One is work instructions and like you said—so for context, I’m using Tulip for The Public Radio, which is this single channel FM radio that this company that I co-founded with my friend, Zach Dunham. We make this thing and it is an electronic device that has be assembled by people.

Rony Kubat - 00:02:52 - Like so many things.

Spencer Wright - 00:02:53 - Exactly.

Rony Kubat - 00:02:54 - You forget in manufacturing that there’s an enormous, skilled workforce out there. They’re actually making and touching all the things that are around. You look around your room and everything’s been touched by a person.

Spencer Wright - 00:03:07 - Yeah. Yeah. This is getting off topic, but I think people think of manufacturing as like robots or big machines. And what I say, I say manufacturing is just people doing things over and over and again in a repeatable way. And our product is that way as well. Last year we shipped 3,500 units and every single one of them has four screws that have to be installed. And to somebody who hasn't done this, it might seem trivial. You might not even think about how will you communicate to the person installing screws, how those screws should be installed. But you do have to do that. And so—

Rony Kubat - 00:03:48 - —and the way that those screws are installed matter. If you do it in the wrong order, then you’re going to have some kind of failure out there in the field.

Spencer Wright - 00:03:57 - Yeah. So we have used Tulip to provide those work instructions to people on the floor. To the assembly line worker, Tulip appears like a slideshow essentially. You have a number of steps and on most of them, there's an image of a thing happening and then on the table in front of you, you do that thing and then you interact with Tulip in some way, either by scanning a barcode or pressing the foot pedal or a button or something like that.

Rony Kubat - 00:04:33 - So what’s important to say here is that this whole idea of communicating the instructions, that alone is not revolutionary because this is how you do manufacturing. You need to convey this in some way. So this kind of a build book or a set of instructions on how to do, it is typically just conveyed via paper. That’s the way that things are typically done.

Spencer Wright - 00:04:56 - It's printed out with images on it.

Rony Kubat - 00:04:58 - Yeah. It's like paper, physical paper or it's a paper on glass like you know, PDFs on screen and something like that. What’s lacking in those in that kind of conveying is any way to enforce some kind of check about what’s going on.

How do you say like, actually make sure that this thing happens before this next thing happens? Or how do I simultaneously record what's going on in here? Because you know, in your case, it’s based off of a particular customer order. You're changing what the product is. It's a mass customized product. You can't do that with paper.

If you start to think, what is the Tulip system? It’s a way for you, the engineer, to take what would have been on paper and now turn it to something interactive. Something which has error-checking baked into it. Or you have branching baked into it. So you could end up having a simplification of something that’d be very complex.

Spencer Wright - 00:06:07 - Yeah. So we have some of that “choose your own adventure” stuff happening in our process. We have error checking. Some of the times, the assembly line worker has to explicitly confirm that something happened, that they observed something happen. We also have a bunch of software checks going on so we know, in some cases, that the right outcome did not occur and we prevent the assembly line worker from moving forward in those cases, which, like you say, you have to rely a lot more on trust if you were doing it with paper. You’d have to go there and train people to a much higher degree and then supervise them and so on and so forth. And with Tulip, we can, to a large extent, train them and then observe them from afar using the built-in analytics that you guys have.

Rony Kubat - 00:07:10 - The other thing here is about a speed of improvement, right? So “traditional” means you're working with a contract manufacturer. They're a amazingly well trained staff. You've created a great set of work instructions but you've sort of “thrown over the wall,” so to speak, and they're making stuff. But if something comes up that is a problem. Say you have a PCB that has a bad trace or something like that, the time that it takes to discover what that problem is, figure out the root cause what that problem is, and take some corrective measure on that—that time is dead time. Either you’re not making stuff or you’re making bad product that could end up in the hands of a consumer.

So, all the things we’ve built into Tulip to try to make things real time, to make the speed by which of communication between engineering and floor, floor and engineer, is about closing a feedback loop between what's happening right now and how could I improve it in whatever way.

Spencer Wright - 00:08:22 - Yeah. And there are totally times when I have, remotely, from thousands of miles away, logged on and changed, moved a button, or changed what the button does and I'm at the same time on the phone with somebody who was saying, “Oh, this thing is moving right now,” or “if I click it now, it does something different.” Whereas, like you say, that would be a process would take days at least, if you would even catch it in the first place.

Rony Kubat - 00:08:50 - The other thing is, at Tulip, we are primarily a software company. We make hardware too, to help enable the software platform. We make a gateway device that is basically a industrial hardened computer with a bunch of inputs and outputs to it that you can now connect into the Tulip software platform and use that to pull information off of machines, sensors, whatever—physical things that are on your factory floor. So we worked with a contract manufacturer to make this gateway and, of course, we dogfooded our own stuff. So our contract manufacturer was communicating using Tulip. We have that in their facilities so we know what our production yield is and stuff like that.

But the other kind of important thing is that this became the single source of truth for how we communicated a set of instructions or a process between the golden standard of what we built up in our lab and what is happening on the factory floor. So for the inevitable confusions or changes because you can't get this exact screw and there’s another vendor with a very similar one, how would this potentially impact that? It becomes a communications medium that we used with our contract manufacturer.

Spencer Wright - 00:10:22 - So one thing that I've been curious about is on the communications front. We communicate with our contract manufacturer about couple of different ways or about a couple of different things. We communicate work constructions to them, we communicate orders to them, and then they communicate billing to us. There's a couple of features built into Tulip that would, at least in theory, allow for a lot of that stuff to happen in your process or via the analytics that are built on top of it. We have done some of that ourselves. Our product is manufactured just in time. We get orders throughout the day, they are imported to our database overnight and then they are manufactured and shipped to our customers in the morning. We have some checks built into Tulip that let the operator know whether or not there are orders to be processed at any given time.

What we haven't done is link up the other side of it. The billing side. And basically, like you were describing, Tulip is the golden standard going one direction for sure, for “this is how you do it,” and at least in our case, “this is when you do it.” But we haven’t done the other side, which is “this is what we pay you for.”

I'm curious—when you're dealing with your contract manufacturer, have you gone that other direction too? It seems like something that, I guess we haven't approached it partly because our contract manufacturer has their own kind of tools and systems for that.

Rony Kubat - 00:12:10 - Yeah. I think that this industry, this manufacturing industry, it's full of three letter acronyms. It takes some time to like get to know them, whether it'd be the ERP, mes, DIA, whatever, whatever. What that is reflective of is that it's incredibly heterogeneous. Everybody has their own way of doing things. There is some notion of consolidation of formats and things like that, but even then, because they have to, on the one hand make a box of pasta and on the other hand make an MRI machine, the scope of these kinds of standards is enormous.

What ends up happening is that you either throw out like 95% of the standard or you have some kind of specialized system—whether helping running your business, whether it be how I manage orders, etc., etc.,—you build that yourself.

Whenever Tulip is gone in to work with a company, we always have to talk to them because we are never coming into a complete blank slate. It's infrequent when you have the opportunity to, from the ground up, build a thing, you know “build it right.” You’re always living within a context of something that's in operation. So for us, it's as important not just to have an ecosystem that is entirely living within Tulip, but to be able to communicate in and out from Tulip in an effective manner so that we can easily tie into these back-end systems that are preexisting.

So the other thing about these things, is it because the manufacturers rely on them and they’re are these behemoths, all of the sort of gigantic database players, and three letter of companies that are out there that are building these things. They have a high expense and they also, as a result, of the necessary complexity to run the business, they end up being kind of fragile and the fragility of them—So like say manufacturing execution system, so MES of the world, they're just insanely complicated—And so like understanding what the tables mean and what does this, what does this acronym fit into the thing and if I change, I want to make a query, how do I make that query into it or push data into it. That becomes really complicated. It becomes a specialized part of the business. You have the folks that are in I.T. that are running that and maintaining it and updating it, etc. But that rigidity makes it in complete conflict with a lean ideal of continuous improvement. So what we've tried to do in the kinds of ways that we make the connectors, which you know, you guys are using as well to connect to your own version of the Bespoke system—

Spencer Wright - 00:15:14 - Our rigid, fragile thing.

Rony Kubat - 00:15:17 - But what you did, it solves your specific needs, right? It was built for the problem that you have and that’s not uncommon at all. I see it all the time. People are like, “yeah, that system doesn't really do the thing I need.” Let's just do our own thing and I know I know my own business, I know bubblegum manufacturing better than anybody else because I’m a bubblegum manufacturer, I'm going to make this thing that solves it, but now I have a system which is incompatible with the rest of the world. Right.

So what we tried to do is make that connection easier in a sense that you have a nice wall at which you have a flexibility on one side—so the manufacturer or engineer can create a single point of entry—then beyond that, they have complete flexibility to do whatever you need to do on the manufacturing floor, change the process, whatever. And then satisfy the necessary requirements of I.T., like let’s not mess too much with the system because of the risk that it could potentially entail to making those changes. Right.

Spencer Wright - 00:16:29 - So I'm curious how similar is our application to the other users that you guys have? I mean we are making this kind of weird product and we make it in a weird way, like you said, we are making a mass customized product just in time. How similar is our application to other ones you guys see?

Rony Kubat - 00:16:52 - I think that what you have in The Public Radio is a microcosm of the general set of problems that we see all the time. Right?

So there is a level of sophistication complexity in the product that you're doing. This is a conceptually incredibly simple product. It's like a radio with one knob and it plays one radio station. Right? But at the same time, because of the mass customization element, because of the just in time element of it—you could have one station, but the complexity of that one station matches what you might have in a 100 station facility, right?

The things that you care about are no different than what a Foxconn would care about. Like, how long does it take to make a thing because that’s impacting the cost of the labor that's put into the work. What is the quality of the output that I get out of this? Is that the end user going to receive the thing that they expect? And how long is the impacts of quality beyond just am I getting the right thing since mass customized, but also is it going to last me? So the overall quality of things—that is super typical. It's just small scale.

Spencer Wright - 00:18:19 - Yeah. So we are using a contract manufacturer to manufacture our product. We also have done a bunch of internal production, I mean a bunch. I've shipped 1,500 radios from the bench that we're currently sitting at.

Your typical users—are they mostly doing in-house production or using a contract manufacturer? And how are those two scenarios different for you?

Rony Kubat - 00:18:49 - Most of our customers are big enterprises. Fortune 500, Fortune 100 customers. So, effectively, some of them are contract manufacturers. For example, Jabil. They will work with other large, large customers that are out there and making networking equipment or toys, whatever, what have you.

I think that there's a sort of typical size, typical sets of problems, there is a similarity, as I mentioned in a class of problems that people are trying to approach here. But we have fewer instances of “we're producing a little bit in house,” “we’re using that now and transferring that out.”

I think that from our own experiences of working with RCM and the value that we got out of it as this communication platform, I hope to see more of that and more people being able to take advantage of that and now transferring that. When I go to talk to hardware startups, I inevitably hear the phase, “oh yeah, um, we just ended up buying a bunch of PCs and throwing them on the floor of RCM because they didn't have anything in-house that was going to do whatever custom testing requirements that I have out of my piece of equipment. So we had to build it for that line for, for them.”

And so that kind of transfer I see as a perfect use case. I think your experience as well as taking what you were doing, transferring that over to a CM and having that close connection between them. Here it's in a basement, there’s it's a beautiful sunlit environment, but there’s something that’s the sameness to it.

Spencer Wright - 00:20:47 - Yeah. So what was it like for you visiting your contract manufacturer? How were they at accepting this? Because in some way, this is very different from how contract manufacturer typically do business.

Rony Kubat - 00:21:05 - Yeah. We love our CM. They've been super supportive about us and they’ve been really excited about using Tulip. I think that there is, rather than a set of sort of chain-mail replies and replies and replies with version 7, version 8.1B, it ends up simplifying things for both sides. There's clearly a value on it that they're getting out of it as well, because I think that the overhead of the communication, making sure that you're sort of getting things right is still really high, especially when you're doing some kind of NPI. Sorry, three letter acronyms—new product introduction. Right.

There is obviously there's a kind of a challenge with working with a CM in the sense of on the one hand, the CM wants you to have full transparency of what's happening on the floor, but they also need to protect their own margins. Right? And so there’s a tension there that exists, but I think that on the whole, when you look at it from the relationship that we have now with our CM, it is stronger because of the transparency that we have with our own operations.

Spencer Wright - 00:22:36 - One thing that we've thought about is how much access we give our CM to the back end, right? As you were talking about harbor shops, that’s very similar to how we developed this. We have a number of custom tools that we engineered and that ultimately we maintain for the process. This is typical of any product, whether you're using some software or not. One thing that we’ve tried to do is pass off more of that systems maintenance to our contract manufacturer because, like you said, we trust them, we want them to be thinking about how to improve this process, and at the same time, they have other things on their plate, right?

How much have you passed over the baton on maintaining those tools to your contract manufacturer?

Rony Kubat - 00:23:46 - For us, because it is this new product introduction, we've kept a lot of that and we need that kind of visibility. We want to make the tweaks and changes as quickly as possible. But you know, we've experienced complete opposite sides of the spectrum. So on the one hand, we have situations like with The Public Radio where you started using Tulip, you built up the process, and you transferred it over to the contract manufacturer, so it’s like a new system for the contract manufacturer to start to use.

In the same way that if I've successfully hit my Kickstarter and now I have this fancy new piece of electronics that I'm trying to build, I might push all my testing equipment onto my CM and say, “these are the tests I want to put in my database, etc.”

We've also seen the complete opposite side of that where the Tulip system is owned by the contract manufacturer and their customers are saying, plop a box on their desk and say, “make me this, make my widget. You figure it out.” And the CM is building the work instructions for the customer side. I don't even know if they're giving the visibility of that to the customer, but they're still using it for their own continuous improvement efforts for thinking about how are we doing this on a flexible line where I might be making ten of these this week. I might be making a thousand of them this week. I need to be able to swap out these workstations from one thing to another. It’s both ways. The power of them in both cases, or the use cases, maybe a little bit different, right?

So, you want to have visibility into what's happening on the shop floor. That visibility becomes crucial so that you save a flight to go visit them. They want to improve their process and be able to use their time better or to compress the amount of square footage that they need for stuff.

Spencer Wright - 00:26:02 - You can imagine, it’s also the floor manager at some contract manufacturer, they want visibility into the floor, right? Like they want the same stuff that I want to know. They want to know,” hey, how long does Joe take to assemble this thing versus Dave?” There’s visibility required throughout the entire process.

Rony Kubat - 00:26:23 - Yeah, absolutely. And so, especially when you start to think about an optimization on the floor—say I've got some complex process, right? So I've got like ten stations where stuff is traveling through, and at each of those stations, a different part’s being added or some procedure’s taking place and stuff like that—this is classic manufacturing 101 stuff, like I’m doing line balancing and I want to figure out where is my bottle-necks in the system. I want to see how it’s varying—like who's working in there? What day of the week is it? Is it after lunch, first shift, second shift?

This is just information that, right now, because it's a human operation, it’s hard to gather. Right? How are you gathering that? Someone’s going out there—

Spencer Wright - 00:27:15 - With a stopwatch basically.

Rony Kubat - 00:27:16 - Someon’e going onto the floor with a clipboard and a stopwatch and they're sitting there, timing it. How often are you doing that? And then you're paying the person who's going out there with a stopwatch who’s like—

Spencer Wright - 00:27:24 - And you're affecting people's work habits because they're being observed.

Rony Kubat - 00:27:27 - Exactly. The other thing that happens by using a system like Tulip is that that's just data exhaust. It's just coming off of the system by virtue of using it. Now you have a very highly granular set of data that you can start to do interesting deep dives into an analysis of it to better understand what's happening for real on the floor. Not the kind of anecdotal stuff. Not very macroscopic views of my floors. I know I put this much material in, I know get this material, process goods out, but how’s the sausage made in detail?

Now I can start to have that kind of introspection. I can start to say, “oh, Jane is my best operator on the line. She’s been working on there for a couple of years. She has some kind of tribal knowledge and she’s going to retire.” How am I going to take that knowledge and how do I transfer that to the rest of the team? Now I've got some seasonal order and I'm hiring a whole bunch of people to come in and fulfill that and I need to get them up to speed quick. I want to make sure that they are going to be doing the same quality as my best person.

Spencer Wright - 00:28:50 - What is the physical device that you're making?

Rony Kubat - 00:28:57 - There are two physical devices that we make. The first one is what we call our iot gateway. You can think about this as a gateway, which in a sense is another buzzword, so industry 4.0. We have all the buzzwords but no blockchain. So what is it? It's a computer with some IO on it. And the IO for it is industrial spec, 24 full adopter, isolated, you know, IO plus standard classic computer connections, the serial USB and stuff like that. The point of this box is to connect whatever tools, physical things that you're using to make the things into the Tulip system so that you can now be data collecting. You can use that to impact what's happening in the application that you as an engineer are building within it.

So this could be everything from like super-duper simple things like a foot pedal or a brake beam light sensor or a tower light that I want to illuminate or whatever. Or very sophisticated systems like I've got a programmable torque driver that's going to give me a torque profile of how I'm screwing in this screw and ensuring that I'm hitting the right foot pounds for it. And if I have a binding data that's coming from that, it can now inform that and serialize that and store it. The gateway in that sense is a way to make that connection happen. And to do that in a way that doesn't involve any sort of coding per se.

So in the same way that in Tulip you build an interactive application without coding because you're using a rule-based systems, like “if this, then that” kind of thing. You now have that kind of flexibility and power but now applied to physical hardware.

Spencer Wright - 00:31:08 - So it is a Linux-based computer being run headless all the time? And it just allows information to get in and out of the back end, basically?

Rony Kubat - 00:31:24 - Exactly.

Spencer Wright - 00:31:24 - Gotcha.

Rony Kubat - 00:31:25 - Yeah, so the gateway is one thing. The second part of what we make is what we call it a light kit. This is a driver for LED strips that, in a sense, is a very simple product. But the idea here is that it’s a way to give indicators for associates on the factory floor about anything from like where to pick a certain part or illuminate a tool or things. It's a communications medium with the person on the floor.

So, to give you an example of a simple case—pick-to-light type systems like this, we’re not actually inventing something completely new here. These things have existed for awhile. I've seen factories where people have a pick-to-light system is made out of a Christmas ornament lights. It’s amazing. It's because they've cobbled together the solution for the problem that they've had, right? So this is making that solution much more accessible because nobody has to go out and shop for Christmas lights or whatever in order to do that and to do that inexpensively.

One of our customers that makes medical devices, so dental implants devices. In some ways, this is like in the same way that The Public Radio is this microcosm, so here’s an example. This is a mass-customized product. So, you go to the dentist, you need a root canal. Hopefully you never have to experience this. But the dentist, is going to scan your teeth. Now you come back for your next appointment and when that next appointment happens, there’s a 3D printed jig that fits onto your particular teeth. It comes with the titanium screws that are just the right length, just the right size, and the screwdrivers are required for that and all the abutments.

So in that kit that you're a dentist has received that—that kit is made by our customer. So you have a standard set of components, like the titanium screws and stuff like that, and you have a bunch of custom-made stuff. Now the combination of what goes into that box is made for a particular patient. You have billions of potential combinations of what can be in there. And the cost of poor qualIty, you get the wrong thing, is like some patient is in the dentist chair and like, “oh, your mouth is open. It doesn't fit right.” That’s bad.

The quality is of paramount importance here. And because of all this combination of different things, you have a person who's fulfIlling this who has tens or hundreds of bins of parts that they need to pick from for a particular order. So here you can apply these strips, illuminate a bin based off of the logic that's baked into Tulip and then remove or minimize any potential for human error that is resulting from this.

Spencer Wright - 00:34:37 - So I’m the assembly person on the line. I pick up an order slip, I scan a barcode on it or something like that, Tulip recognizes that order. And then lights illuminate below the bin for the tiny screws—like m00000 or something.

Rony Kubat - 00:34:55 - Right, right, right, exactly.

Spencer Wright - 00:34:56 - But the light shows up under that thing. I'd pick one out of there, light shifts on something else. I pick one out of there.

Rony Kubat - 00:35:01 - Exactly, exactly, exactly.

Spencer Wright - 00:35:02 - Okay. So we are not using this product, we are just using a gateway. I imagine these things are used in concert.

Rony Kubat - 00:35:14 - Yes. Yes, they are.

Spencer Wright - 00:35:14 - Gotcha. Okay. What is it like having a company that does both of these different things? The service that you're providing to your customers is primarily software, right? But it relies on these pieces of hardware that are specific to your service, right? How is managing that division? How does that work for you?

Rony Kubat - 00:35:47 - So I think that the connection to the real world is absolutely critical to what we're doing here because in manufacturing, you're making a physical thing, right? And you're making a physical thing using physical tools. And so if you want to get beyond a fancy slideshow, which is like what the Powerpoint is effectively being used today and you have to make that kind of connection.

Now, whether you use our gateway or you're connecting over a MT connector, OPCA, or some other program, for me, it doesn't matter. The important thing is about that connection to the physical world. That connection to the physical world has typically been a challenge because of the huge number of protocols that people are talking. Not only just like you can rattle off the list of industrial protocols but it’s like I don't have enough hands to have fingers for them.

Beyond that sort of proprietary stuff, there’s accustomed protocol for a particular piece of equipment. If you wanted to do this before, we're talking about someone who has got a sit down where the manual and read it and then write some custom piece of software for it and then connect it to another custom piece of software. And that's how you end up with these enormously fragile, complex systems that you can't upgrade it because if you do the person that wrote that code has retired or left the company and now what are you going to do?

So for us, putting these, the hardware together with the software is, fundamental. We try to build it, obviously internally, we try to build it with nice points of separation. For example, we have to make physical hardware in the world. It's harder to update that. Of course, we do, but it's definitely harder than if you're have a cloud service that it’s like updating out from under you. So we have nice clean separations that we're building our own internal APIs for that. But at the same time, we can’t escape the connection to the physical world. That's fundamental to what we're doing.

Spencer Wright - 00:38:23 - And how do those two teams interact? That’s an incredible opportunity to be able to dog-food on your own product and use the back end, all the software to make this physical thing that you need. But I imagine it adds additional complexity to your organization. How do you manage that interface?

Rony Kubat - 00:38:47 - So I think that, you know, we're still a pretty small startup in the land of startups.

Spencer Wright - 00:38:56 - How big is your total company?

Rony Kubat - 00:38:57 - So we're in the tens of people right now. Still very engineering focused and still very much looking for new people. so if you know anyone… But the way that we try to do that is to have a good amount of cross-pollination between the teams, right? So we have a customer team and the people on the customer, these are engineers coming from mostly an industrial engineering background. They deeply understand the manufacturing world. And now have a Tulip perspective on it. So they are the team that is helping our customers get the most out of Tulip.

So whenever we have, say an engineer whose focus is going to be on some web technology for it or whatever, if they're a salesperson or a hardware engineer, whatever—they spend time in the customer team immediately so they understand what are the problems that customers are having. How are we trying to solve those problems?

We also tried to maintain the cross pollination between the software team. So the software team which is responsible for a connection to the physical world, sort of the software that's running on that gateway. They spend time on the platform team which is responsible for the core web product and vice versa. We're all in the same room also, so it makes it a little bit easier.

Spencer Wright - 00:40:26 - What is your background? How'd you get to this?

Rony Kubat - 00:40:32 - So MIT is where we're born out of. We are a startup that came out of the media lab. My co-founder and I were both graduate students there. My background is in computer science, machine learning. My cofounder, Natan, also is an engineer by training before he came to the media lab. And the media lab is a weird academic lab compared to many other ones in the sense that there’s a huge industry connection at the lab. The lab is still largely funded by companies that come in and give money to a big pool that is then distributed to research labs that are going from everything to biology to machine learning to education. And from the research work that we were doing, which was primarily on new kinds of user experiences and user interfaces, we kept getting connected to these large companies that make things. And they’d say, why don’t you try stuff out in the manufacturing domain?

So we started spending a lot more time on factory floors and this, between myself and Natan, we had some experience being on factory floors. For myself, also a mechanical engineer, for Natan who spent time in the consumer electronics, cell phone industry, so slept on factory floors as stuff was being made. We started seeing more and more of this from the lens of a user experience designer, what are the user experiences that people on the factory floor have? And they're not great. They are user interfaces that are designed for machines. They're not designed for people. And we thought that we have, through our perspective as designers of user experiences, something pretty unique that could change the way that manufacturing is done.

So that is of the origin story for us. It was like three and a half years ago or around then when we set out to try to change the way that the shop floor experiences is like.

Spencer Wright - 00:42:55 - Gotcha. Okay. So what are the typical improvements that your customers see?

Rony Kubat - 00:43:01 - There's two classes I'd say. So there's like in terms of what is measurable and the immeasurable stuff, right? So, measurable things are things like “I had no data before, now I have data.” In a sense, it's a gap, it's measurable, it's binary, it's nothing to something.

Then there's the straight up measurable things. Like I had a number before, now I have a number after and the difference between those two numbers is my ROI. Ah, another three letter acronym. My return-on-investment. Right?

What we see as our three big categories for impact, right? So impact number one is improvements in training processes. Being able to train someone up faster, taking someone who is maybe a lower skilled operator and putting them into a higher skilled operation, and reduction in cost of trading someone up because now you don't have a senior person who is observing and ensuring the work that someone is doing. And so that's one major impact. That's like factors of 10 in improvement in training time.

The second big impact is in throughput. Making stuff faster. We’re in a whole variety of different industries from marine to pharmaceuticals to electronics assembly to apparel. And across multiple industries, we've seen double digit improvements for different kinds of assembly type process. And this is from better guidance for lower cognitive load when you're doing something.

I think the third big bucket is in improvements in quality. So you were able to have a higher yield out of your stuff. Again, through error checking and this built-in process effectively, we see now as elimination of manual-caused errors at workstations. 99%, 100% percent reduction in these kinds of problems.

The other facet to improvements in quality for a lot of the non-manual root-cause stuff is coming out of being able to more quickly get to a root cause of what an issue is. If you’re, say New Balance. They’re an interesting manufacturing problem because they are high volume, high mix. You've got differences in style, gender, size, color. We have width. We also have the actual processes that are being used because some soles are injectable, right? So which mold was used for this particular shoe, and if you have an issue that you need to try to nail down, like “what is the cause”? Is the cause because the chemicals were slightly mixed differently? Is the cause because the oven that’s baking the shoe—did you know shoes were baked?—is the oven not set to the right temperature? Did the adhesive not have enough time to set?

There’s so many different factors that will impact the quality of the shoe. That being able to collect data and be able to dive into that data and investigate the correlations between these different factors means that you can shorten the time that you are able to do some kind of new product introduction and achieve a yield which is where you want it to be. We've seen a number of times now being able to do that NPI much, much faster. And so that's another major sort of impact on the quality side.

Spencer Wright - 00:47:02 - Mmm. What are those actual users like? And I guess maybe I should back up. So in our implementation of Tulip, I'm the guy doing a vast, a lot of the work, right? Like I make the physical jig that puts the thing together, I organize, I actually make the Tulip presentation, I make all the connectors to our outside services. I make many of those outside services as well. And then, like I said, like I personally shipped 1,500 or something radios last year. Right. That's a really unusual scenario, right? Like having one person who's doing all that different stuff I imagine is, I mean, it almost never happens, right?

Rony Kubat - 00:47:54 - Well, no. I've definitely seen it. I mean, that's the thing. So what I love about talking to people in manufacturing is zero bullshit, right? And what I love about it is that there is on the one hand, you have an operations research perspective on things. Like how do I optimize this thing? On the flip side of that, you also have, like you said, how do I build a thing? It’s not just the product, but build the process which is putting together that process. So there’s both a static and dynamic parts of the manufacturing world. So, sure—you’ll have factories that have people that are just focused on quality or those that are just focused on optimization.

But what I've seen in the world is that a lot of times the backgrounds that people are coming through are incredibly varied. And as a result of that, what I see over and over again is a very multifaceted perspective on the problems of manufacturing.

Spencer Wright - 00:49:12 - And so these are the people who are using, let's say just the back end side of the software platform, is that just like any manufacturing engineer? I imagine like you’re going from a scenario where no data is coming off of the line or data is only coming off the line when we specifically decide that we are going to try to observe some data. And you’re moving a scenario where data is just flowing off this thing every single day and I have the ability to make updates on the fly. Do you need a specific kind of manufacturing engineer? By kind, I mean someone who is young or who has a weird background or something like that. What is working with those people like?

Rony Kubat - 00:50:05 - I don't think there's a correlation in terms of age or anything like that. I think that what you more see is those manufacturing engineers that I think have always impressed me the most are the ones that have an innate curiosity about stuff. There is a transition that’s happening for sure from the old school way of doing things. It’s like writing ladder logic for your PLCS and there’s like three or four different languages you can write your software for that and that’s it.

And then you have the what’s coming out of maker movement and the democratization of hardware in a lot of ways that now is trickling into the factory floor. Right? So I've seen people building multimillion dollar pieces of equipment with arduinos that they've cobbled together to do something.

So I think that more so there’s this bleed over from the sparkfunds of the world and the people that with kind of curiosity, they’re like the hobbyists in their everyday. They go home and they do cool stuff and then they bring that attitude with them to the factory.

Spencer Wright - 00:51:27 - What's next for you? What are you working on?

Rony Kubat - 00:51:30 - So the challenge with a lot of the software in the manufacturing world is—in general—super high cost, a lot of challenges to get started with it. And we want to make that a lot easier for anybody to very quickly get started to build system, basically like what you did, without effectively making a big deal about it. We are launching a starter kit, or as we call it, a factory kit. This is like Tulip in a box. It has a gateway, it has our light kit, it has a couple of sensors that are part of it, it has a subscription to the software side of the house, the cloud-based part of it, that allows you to build a very simple Tulip process and actually deploy it onto your floor, whether your factory floor is your basement or within your CM or within your OAM, within your facilities. And to do that very, very quickly at a low cost.

So that has been a big push for us recently is creating this experience of Tulip in a box in a way that allows you to, at your own pace, build up the Tulip system with a variety of learning resources and medias to do that. And the set of typical sample apps that cover a lot of different cases to allow you to get some kind of value out of the system immediately within half an hour of opening the box, basically.

Spencer Wright - 00:53:25 - It's, it's funny because my experience using Tulip has been so incredibly self-service. Like I can jump in and start messing with stuff very quickly. How much do you see that being the case for your larger customers? And maybe specifically, I would imagine that the Tulip kit in a box, the goal would be to have this engineer jump in and immediately be working on it themselves. Do you see that translating over to the more enterprise customers as well?

Rony Kubat - 00:54:00 - Yeah, absolutely. I think that's the case. I think what I’ve been trying to say is that Tulip is a new type of software. It doesn’t fit into a nice three-letter acronym in the manufacturing software world. And as a result of that, there is, in a sense, a new way of thinking about what it is that you're trying to do. It’s like what is the art of the possible? So you can, nowadays everybody is using some kind of presentation software. You can build a presentation, anybody can do it, it’s self-serve, you can create a presentation very quickly. No doubt, you’ve sat through terrible presentations. So there is, on the one hand, you want to build a tool which is sophisticated enough to solve all the problems that you have.

But there's also the best practices that are surrounding that. The key thing for us as to how do we take the discovery of the ways that Tulip has been used in the field, distill out the general principles that are part of that. What makes a good user experience? Not in the sense, you know, these are experience of creating a presentation, but the user experience of experiencing the tool of application from the perspective of the operator or associate that's on the factory floor. Distill those set of best practices into a set of default applications, you could say, that shows the art of the possible, makes it so that you don't start with a blank canvas and have to build the world from scratch. But it can show you how, like “oh, this is how a serialization based process that is talking to a backend that has a branch out to a defect reporting form that has the analytics that are tied into it.” So you know, “show me how I can get out a root cause to whatever that problem is.”

Spencer Wright - 00:56:23 - That's really interesting to think about. So I happened to be making a presentation, a regular old slide show last night, right? And I, for whatever reason, chose to use Google Slides because it's going to be collaborated on with a bunch of other people and it’s easy to use this platform. And Google Slides, whatever they call it, has a bunch of default presentations. Some of them I actually kind of appreciate because some of them are silly, like they have funny default slides that say like, “this is where your main point goes” or something like that. And most of them are geared towards like investor pitches because, of course, it’s Google.

It must be absolutely fascinating to see what the tomes as were of the manufacturing processes? Like what do those top ten kind of standard templates look like? That must be a really interesting thing to see.

Rony Kubat - 00:57:29 - Yeah. I love discovering what our customers have done with Tulip. I can give you an example of a tome, as you say. I’d say, to summarize it in a pithy phrase, it would be like “make it visual.”

So, say you’re making a sweater. And there’s a class of different kinds of defects that you're wanting to inspect for, right? So there's like a bad stitch or like a yarn got pulled or there's a hole or discoloration in the dye, right? The old way of doing it that you'd see in a factory is there's a clipboard or something with check-boxes and it’s written out, like “loose yarn,” and you go in there and write a tally or something like that.

But now you have a way of making a visual. So what do you do? You show a picture of a sweater and you just press the part of the sweater where there's the defect, right? And then when you pressed that part of the defect, you show three images of the types of defects that you'd have at that location as exemplary ones and you’d touch that. And then that's it. So that becomes the data entry recording mechanism that the human on the line, the skilled person, the craftsman, they’re making that assessment in a way that a computer can’t really do. I have a workforce that speaks like seven different languages and I no longer have to worry about translating my paper form and I don’t have to look up on this piece of graph paper, like “which row does this go on? Where do I put my tally?”

Simple things like that reduce the friction to collect some kind of data is one example of a user interface tome. And again, this is nothing new. People know these kinds of things from the design of computer interface and stuff like that, but having the right examples of this makes it a lot easier. Take the classic five paragraph essay that you learn in high school English class. What’s the result of that? You have a lot of five paragraph essays out in the world that are all the same form. But there is a kind of truth as to why a five paragraph essay is good at conveying an argument or an idea. So, sensible defaults really matter.

Spencer Wright - 01:00:21 - Yeah, yeah, yeah. One thing that I hadn't realized when I first started with this was the number of things that people can mess up while they're assembling a product. And figuring out, “well, what is the default behavior that I want to encourage?” Building that inexplicitly has been a real learning experience for me and understanding that it isn't necessarily a binary thing on the factory floor. There’s a bunch of things that can happen that are difficult to categorize. And your sweater example, where it's like, “hey, maybe your common defect is the stitch right under the underarm where you have multiple pieces of fabric coming together, that's the one that usually gets torn or something like that.” But then if you enforce that binary check, then you don't allow for other kinds of errors to propagate and to be identified. Which has been a really kind of interesting realization on our part.

Rony Kubat - 01:01:27 - You're just confronted by your own assumptions that you're making that you don't realize. Like, “the screw goes in clockwise.” It’s an assumption that that’s the case, but it’s not always true.

Spencer Wright - 01:01:51 - Yeah. Yeah. It's funny. It's an interesting challenge to force yourself to trust the assembly line worker more as well and find ways to get their, it’s not so much feedback, but to capture their input in some way. With paper, it’s difficult to do. It’s a lot of paperwork.

Rony Kubat - 01:02:20 - In that communications path, typically it's always downstream, right? You go, “I'm telling you what to do and do it the way I say.” Having a nice mechanism to make it easy for someone on the floor to stop the line and give their input. This is one of the pillars of Lean Manufacturing to their production system. You want anyone on the floor to be able to provide their input very quickly. Sometimes having a technology that helps make that easier, lower friction for someone, really matters.

Spencer Wright - 01:03:10 - Yeah. Well, Rony, where can people find you and Tulip?

Rony Kubat - 01:03:16 - You can find us online very easily at tulip.co. You can find us in Somerville, Mass.

Spencer Wright - 01:03:27 - Yeah. Cool. Well, thanks so much for coming on.

Rony Kubat - 01:03:31 - Yeah, pleasure being here.

Spencer Wright - 01:03:33 - For links to the things we talked about in this episode, visit theprepared.org/podcast. As always, thanks to theprepared.org supporters for making this show possible. My name is Spencer Wright. See you next week.