Episode Description

R&D for materials-based products can be expensive, because improving a product’s materials takes a lot of experimentation that historically has been slow to execute. In traditional labs, you might change one variable, re-run your experiment, and see if the data shows improvements in your desired attributes (e.g. strength, shininess, texture/feel, power retention, temperature, stability, etc.). However, today, there is a way to leverage machine learning and AI to reduce the number of experiments a material scientist needs to run to gain the improvements they seek. Materials scientists spend a lot of time in the lab—away from a computer screen—so how do you design a desirable informatics SAAS that actually works, and fits into the workflow of these end users?

As the Chief Product Officer at MaterialsZone, Ori Yudilevich came on Experiencing Data with me to talk about this challenge and how his PM, UX, and data science teams work together to produce a SAAS product that makes the benefits of materials informatics so valuable that materials scientists depend on their solution to be time and cost-efficient with their R&D efforts.

We covered:

• (0:45) Explaining what Ori does at MaterialZone and who their product serves
• (2:28) How Ori and his team help make material science testing more efficient through their SAAS product
• (9:37) How they design a UX that can work across various scientific domains
• (14:08) How “doing product” at MaterialsZone matured over the past five years
• (17:01) Explaining the "Wizard of Oz" product development technique
• (21:09) The importance of integrating UX designers into the "Wizard of Oz"
• (23:52) The challenges MaterialZone faces when trying to get users to adopt to their product
• (32:42) Advice Ori would've given himself five years ago
• (33:53) Where you can find more from MaterialsZone and Ori

Quotes from Today’s Episode

• “The fascinating thing about materials science is that you have this variety of domains, but all of these things follow the same process. One of the problems [consumer goods companies] face is that they have to do lengthy testing of their products. This is something you can use machine learning to shorten. [Product research] is an iterative process that typically takes a long time. Using your data effectively and using machine learning to predict what can happen, what’s better to try out, and what will reduce costs can accelerate time to market.” - Ori Yudilevich (3:47)
• “The difference [in time spent testing a product] can be up to 70% [i.e. you can run 70% fewer experiments using ML.]  That [also] means 70% less resources you’re using. Under the ‘old system’ of trial and error, you were just trying out a lot of things. The human mind cannot process a large number of parameters at once, so [a materials scientist] would just start playing only with [one parameter at a time]. You’ll have many experiments where you just try to optimize [for] one parameter, but then you might have 20, 30, or 100 more [to test]. Using machine learning, you can change a lot of parameters at once. The model can learn what has the most effect, what has a positive effect, and what has a negative effect. The differences can be really huge.” - Ori Yudilevich (5:50)
• “Once you go deeper into a use case, you see that there are a lot of differences. The types of raw materials, the data structure, the quantity of data, etc. For example, with batteries, you have lots of data because you can test hundreds all at once. Whereas with something like ceramics, you don’t try so many [experiments]. You just can’t. It’s much slower. You can’t do so many [experiments] in parallel. You have much less data. Your models are different, and your data structure is different. But there’s also quite a lot of commonality because you’re storing the data. In the end, you have each domain, some raw materials, formulations, tests that you’re doing, and different statistical plots that are very common.” - Ori Yudilvech (11:24)
• “We’ll typically do what we call the ‘Wizard of Oz’ technique. You simulate as if you have a feature, but you’re actually working for your client behind the scenes. You tell them [the simulated feature] is what you’re doing, but then measure [the client’s response] to understand if there’s any point in further developing that feature. Once you validate it, have enough data, and know where the feature is going, then you’ll start designing it and releasing it in incremental stages. We’ve made a lot of progress in how we discover opportunities and how we build something iteratively to make sure that we’re always going in the right direction” - Ori Yudilevich (15:56)
• “The main problem we’re encountering is changing the mindset of users. Our users are not people who sit in front of a computer. These are researchers who work in [a materials science] lab. The challenge [we have] is getting people to use the platform more. To see it’s worth [their time] to look at some insights, and run the machine learning models. We’re always looking for ways to make that transition faster… and I think the key is making [the user experience] just fun, easy, and intuitive.” - Ori Yudilevich (24:17)
• “Even if you make [the user experience] extremely smooth, if [users] don’t see what they get out of it, they’re still not going to [adopt your product] just for the sake of doing it. What we find is if this [product] can actually make them work faster or develop better products– that gets them interested. If you’re adopting these advanced tools, it makes you a better researcher and worker. People who [adopt those tools] grow faster. They become leaders in their team, and they slowly drag the others in.” - Ori Yudilevich (26:55)
• “Some of [MaterialsZone’s] most valuable employees are the people who have been users. Our product manager is a materials scientist. I’m not a material scientist, and it’s hard to imagine being that person in the lab. What I think is correct turns out to be completely wrong because I just don’t know what it’s like. Having [material scientists] who’ve made the transition to software and data science? You can’t replace that.” - Ori Yudilevich (31:32)

Links Referenced

• Website: https://www.materials.zone
• LinkedIn: https://www.linkedin.com/in/oriyudilevich/
• Email: ori@materials.zone

Transcript

Brian: Welcome back to Experiencing Data. This is Brian T. O’Neill. Today I have Ori Yudilevich on the line. How are you, Ori?

Ori: Hi, Brian. I’m doing great. Really looking forward to this episode.

Brian: One of the things I love about, like, the data space and, like, the career that I chose to specialize in as a designer is, like, all these different domain spaces where there’s just interesting things to get into around data and insights. So, you’re Chief Product Officer at MaterialsZone, so you’re helping, largely, materials scientists, bench scientists, run experiments to figure out what are the better materials I can use in my products to get different parameters out of them, better performance, better longevity, whatever the qualities that they’re looking for. Did I basically summarize MaterialsZone correctly there?

Ori: That’s perfect. I mean, we like to say that we accelerate innovation in R&D for materials scientists.

Brian: Yeah. This is a digital software delivered through web interface. It’s really targeted at scientific users. Is that correct?

Ori: Yeah, exactly. We’re a SaaS platform completely on the cloud, browser-based, and we’re targeting researchers in the lab, helping them [do 00:01:41] their experiments faster.

Brian: Got it. And just curious, like, who buys this, like, at a company? I’m assuming it’s not the individual bench scientists or whatever that are buying this. Is it, like, Head of R&D, or like, what makes them feel like, “Oh, I have a need for something like this in the first place?”

Ori: Yeah, no, that’s a really good question. So, usually we go through the Head of R&D, or Head of Innovation. Sometimes it’s the CEO, if it’s a small company. So, just somebody, usually higher up, that wants to improve efficiency, get into this whole AI business, start using their data properly. Sometimes it comes from below. So, sometimes you’ll have a researcher that will hear about us, and then, you know, give us a call or talk to his boss, and—

Brian: Right—

Ori: —get interested? Yeah.

Brian: Right. So, during our screening call, you’ll correct me if I’m wrong here, but like, I think I told you, it might be fun to, like, maybe use a real example. You don’t have to, obviously, give us a client name or anything like that, but to pick a real product or something, whether it’s lipstick or, you know, home batteries, or something like this. But my understanding is, like, in the old world, or maybe the world a lot of people are still living in, if say you’re, I don’t know, you’re Amazon or whatever, and you’re trying to make a longer-lasting battery than Duracell, and you want to sell it more cheaply, or whatever, you might have your scientists trying to figure out, like, how can we change the chemistry of a battery so that we can get longer performance without overheating, or whatever other, you know, parameters, they’re—maybe keeping cost—the materials have to be cheap, et cetera. In the old way, you basically, like, played around in the kitchen, in an actual wet lab, and you’re running experiments which are lengthy and costly, and so the alternative is to use either digital twins or to have more insights about, like, you know, hypothetically, if you ran this combination of, you know, this kind of bread with this much water and this much flour, and you substitute this kind of salt, you might see these parameters in the future. Am I getting this mostly correct so far [laugh]?

Ori: Yeah, no, that’s perfect. And actually, I think that’s the fascinating thing about materials science, is that you have all these variety of domains. So, you gave an example of batteries, and I think you mentioned lipstick, but all these things, and even if you go to concrete or plastic, they follow the same process, right? So, they all—we like to say—resemble cooking, right? And you also gave an example of baking bread and flour.

So, all of these are use cases, and I can mention a couple of them. So, for example, we work with companies that make consumer goods, right? So, it can be shampoos or cosmetics, and one of the problems that they face is that they have to do very long testing, lengthy testing of their products because they have to see, does the product go bad after it sits on the shelf for three, six, nine months, right? And this is something you can use machine learning and digital twin, as you mentioned, to shorten these times because you can sometimes predict after only one or two months that something’s going to go wrong seven months later, right?

And the example of the batteries you gave is perfect, right? So, sometimes you want to introduce a new technology. We have a project in the solid state battery business, right, where you just want to really substitute the very basic components of your batteries with something which is maybe easier to get or maybe cheaper, maybe more sustainable, and try to make good batteries, right, that last longer, that are more powerful. And all of these processes are pretty similar. It’s an iterative process that takes, typically, a long time. It can take years even to develop such a product, and using your data in a smart way, and using machine learning to predict what can happen and what’s better to try out can really reduce costs, can accelerate time to market.

Brian: Got it. What kind of change are you looking at? Is this something—like, if I’m making my new battery here, we’re talking about what might take a year’s worth of experiments, and you know, $10,000 per experiment. Maybe I run 25 of them, and now you’re doing it in a month? Or, like, just give me an order of magnitude: like, what’s the difference between doing this analog, or whatever the old-fashioned way was versus now?

Ori: Yeah, so the difference can be really up to 70% less experiments, which can mean 70%, like, shorter time, and 70% less resources that you’re using. Maybe your researchers can do more projects in the same time, so it’s really significant. The old way, as you called it, that’s what we call, like, trial and error, right, where you’re just trying out a lot of things. The human mind cannot process a large number of parameters at once, so typically, what you’ll do is you’ll just choose one thing, for example, the temperature of the oven, right, if you’re making, maybe, ceramic tiles, right? And then you’ll just start playing only with that single parameter.

So, you’ll just have, like, many, many experiments where you just try to optimize this one parameter, and then you might have 20, 30, or 100 more. And using machine learning, you can just do much—you can change a lot of parameters at once, and the model can really learn much faster what has the most effect, what has a positive effect, what has a negative effect. So, the differences can be really huge.

Brian: From a UX standpoint, am I getting a prediction of what the parameters might be, and then I can decide, do I want to actually go run it in the real world with those settings to see if it actually matches? Is that kind of the way it works?

Ori: Yeah. I mean, sort of. You will get a prediction. The problem with materials science, what makes it very different—from the data perspective—from other fields, for example, if you’re doing usage analytics, right, of a website, right, you’ll have hundreds of thousands, millions of data points, and you can get very accurate models. In materials science, typically, what you have is very few experiments because they’re so costly, and you have a very large parameter space because you can try out thousands, tens of thousands of different materials, and play around with different parameters.

So, the models are not extremely accurate, but the nice thing is that you can test everything, right? So, you can test everything in the lab. So, the model is more, it gives you a direction, what you can try, and what you shouldn’t try, it will help you maybe explore spaces that you wouldn’t even think of trying because your intuition doesn’t take you there. And as you go, the model, of course, becomes better, right, and it becomes better from project to project, right? So, in your 10th project, your model becomes stronger, it’ll give you more accurate predictions. So, it’s a combination of prediction and recommendation, right, [recommending 00:08:09] what you should do in the lab.

Brian: And is it only my company’s data? Like, I don’t get to learn from what Energizer did when they tried putting water in the battery? Like [laugh], is that correct? It’s all isolated, or are you building, like, larger models? It’s like, we know a lot about sand or silica and how that… our models know something about silica when that’s an ingredient. Like, how does that work?

Ori: Yeah, no, that’s a great question. We don’t share data or even learnings that we have from different companies because that’s not allowed. I mean—

Brian: Yeah, I figured not.

Ori: You have two competitors that work for us, one doesn’t want the other to learn from their experience. So, part of it is your own data, right? So, your own data stays with you, but then there’s also the public data. So, it’s a bit like how ChatGPT works, right? I mean, we want to believe OpenAI that they’re not using our data—if we have the pro account—to train their models, but the model is trained on a lot of public data, right, and then our data kind of is added for our specific use.

And that’s more or less what happens in our case. So, we have data which is public. You know, there’s a lot of knowledge on raw materials, what are their properties, different chemicals, there’s scientific data out there, right, experiments that are made public through scientific articles, so those can be used in the model, plus the data of the company. And of course, our technology builds upon all this knowledge, right? So, the data itself we don’t use, but the algorithms become better.

Brian: So, part of what I wanted to talk about is, like, how does one go about designing an experience here for these kinds of users. And the first thing that came to mind is, some clients I’ve worked with in these kinds of capacities, the engineering mindset and the technical mindset, if I’m working with a technical stakeholder, is like, “We can do it for lipsticks, so we can do it for batteries.” And the assumption is, like, basically, your experiments are all the same thing; you can just swap out the nouns, and it’s the same thing. And the designer in me is going, “Yeah, until you actually go out and talk to a battery scientist and/or pick something where there’s, like, heavy regulation or, like, you can’t even get access to that material, let alone run experiment on it without going through, like, 25 tiers of, like, government policy, regulated, blah, blah, blah. It’s not the same.”

Or is it? So, maybe you could tell me a little bit about, like, do you have to onboard a new domain? Like, now we’re going to go into liquids, or now we’re going to go into gasses. Like, you know, products that involve gasses. Or do you have to, kind of, like, bring on a new domain space? And are the scientists working the same way, and how do your designers or product team account for these differences? Or are there not differences [laugh]?

Ori: No, no, definitely there are differences. So, in the ideal world, or in the naive world, maybe the world we were in a few years ago—

Brian: [laugh].

Ori: —we thought, you know, everything is the same, right? Everything is like cooking. I mean, that’s what I might say in a podcast, then when you actually go and work on a use case with a client, then you see the differences. There’s a lot of differences, and there’s a lot of commonality as well. So, as I said, the core is pretty much the same, right?

You’re doing experiments, you’re trying out different formulations, different what we call processing parameters, right, like, the temperature and pressure, et cetera, but you know, the devil is in the details. So, once you go deeper into a use case, you see that there is a lot of differences. And we do try to specialize in domains, right? So, we have a few domains that we’re more specialized in. We’re open to trying out new domains, but there are some domains that we’re just better at just because we have the experience.

And I’ll give, you know, a few examples of what they could differ in. So, first of all, you know, these are scientific domains. Each one of them is a full science. You know, there’s a people writing PhDs on each one of them, so the data itself—for example, the types of raw materials people use—is different, the data structure is different, the quantity of data differs quite a lot, right? When you do, like, experiments with batteries, you have lots of data because batteries you have these machines, they’re called cyclers, where you put on shelves hundreds of batteries, and you test them all at once, right? You charge-discharge them for a long time, and then you gather lots and lots of data.

Whereas where you do something, for example, in the domain of ceramics, you don’t try so many. You just can’t. It’s much slower, you can’t do so many in parallel, you have much less data, that’s one difference. And then your models are different, your data structure is different, complexity of data can vary, tools that you’re using, like, analytic tools, really scientific equations that you use, so we have them embedded in our system where you can actually do very specific calculations or analyze certain graphs, those are very different from one domain to another. So yeah, there’s quite a lot of difference.

But there’s also quite a lot of commonality because you’re storing the data, we have a data structure which is common, right? So, the interface, the UI, is the same for everyone. In the end, you have each domain, you have some raw materials, you have some formulations, you have some tests that you’re doing, you have different statistical plots that are very common. Yeah, so the overall experience is very similar, but then when you go into the details, we really have kind of a special domain or a special environment that is different for each other.

Brian: Oh, so it does—the experience or the interface is different based on the domain that you’re working in, to a degree?

Ori: Yeah, not the UI itself.

Brian: Ah.

Ori: So, the UI looks the same. What I meant is that the kind of the workspace you’re in is different, right? So, you’ll have, maybe the language will be different, right? In batteries, you’ll have kind of an area where you’ll collect your anodes and your cathodes and your electrolytes, whereas when you work in ceramics, you’ll have an area where you collect the different ovens you’re using, and so it looks different, but [unintelligible 00:14:04] customizable per domain.

Brian: You told me that, like, you’ve had some stumblings over the years. You’ve been there about five years at MaterialsZone, is that right? And felt like you had kind of landed at a fairly mature product and design user experience process there. Tell me about the before and after, like, in your version of whatever mature means, or—and I think that’s something where it doesn’t need to be measured externally; it can just be measured internally, like, “I feel like we’re making good progress,” or, “We’re repeatedly shipping value out the door”—what was it like before? What’s changed over the five years about how your teams are working together to make this product?

Ori: Yeah, no, so the change is huge. I mean, when I arrived, it wasn’t that mature yet. I mean, we had some good processes in, but we were very small, first of all. We were a team of about five people, five technical people. Some of them were abroad, there was very little communication between us.

You know, we had sort of like, kind of a Jira-like process, but we didn’t have, like, good product techniques, right? We weren’t doing experiments with users, we weren’t listening enough to our users, following a lot of intuition, being very sales-driven, right? So, every opportunity kind of takes you in a different direction, so you know, I think the things that a lot of early, early stage companies suffer from. As we grew, we went through our financing round, hired some more people, and we started growing in the product sense. We actually, I think when I arrived, we didn’t even have the notion of product, right? It was more like the management level was telling the developer directly what to do, you know?

And then we just went and learned. We went and talked to some external consultants, we read some books, we tried out some things, and today we have, I think, a much more mature process. We do a lot of experiments. Our experiments are—some companies have experiments that are very short. You can just try, like, ten different things a week. We can’t do that typically.

You know, some UI things we can, but a lot of our experiments, because the actual use cases take a long time, then what we’ll typically do is we’ll do what we call the Wizard of Oz technique, right, where you kind of simulate as if you have a feature, but you’re actually working for your client behind the scenes, of course, telling them that that’s what you’re doing, but then measuring the value, understanding if there’s any point in developing a feature, of doing that. And then while, you know, once you validate it, and you have enough data, and you also know where the feature is going to, then you’ll start designing it and releasing it in very, you know, incremental stages. Yeah, so I think we, you know, we’ve made a lot of progress in how we discover opportunities and how we build something iteratively in an agile way, and you know, making sure that we’re always kind of going the right direction.

Brian: Can you unpack, for people that don’t know what that Wizard of Oz technique is, can you use a real example, or a realistic example of one of these experiments that you’ve done just so someone can see it in their head?

Ori: Yeah, sure. So, you know, I mentioned this machine-learning technique, right, where we create a model of the client’s data, and then we start recommending experiments, right? So initially, like, we didn’t have this feature available, and we just had data scientists sitting in the background running scripts. And then we had a customer success guy talking to the client, and pretending as if, you know, he is the UI, right? So, the customer would send him the data, he would measure, the guy in the background would run the machine learning models, send it back to the customer success representative, who would then recommend the experiments the client of you know, doing everything we can, via the UI, so, for example, just manually inserting the recommendations.

So, creating this kind of iterative cycle as if the client is actually just doing it via our UI. And then, you know, once we understood, for example, what the problems are, what kind of information we need from the client, what they understand better, what is more difficult for them to understand, then we could really come up with a design that, you know, that is based on actual work of a user, and not our guess as how to that user will want to use such a feature. And then we started building it and building it, you know, in stages. So, in the first stage, the user, you know, can still not configure it on his own, but he can already use it, right? So, we’ll configure it for him in the background, and then he’ll start using it. And then after we see that it works, then we’ll start adding more customization options for the user and so forth, as you know, as the feature grows, that’s what I would call, like, a Wizard of Oz technique.

Brian: It almost sounds like there’s a level of, like, consulting services going on, and then you’re eventually productizing that over time once you see the repeatability of it, consistent feedback. Is that essentially what was happening?

Ori: Yeah. For sure, for sure. The early stages, there’s a lot of service, there’s a lot of help from us, we meet the clients on a regular basis in the initial stages. You know, and the more we progressed, the more we could kind of let them go faster. But initially, yeah, it was like, was, I would say, a very large chunk of services consulting and, you know, and then eventually you want to build a product that can just grow on its own.

Brian: Right, right. How does the user experience piece fit into this? Like, when do your designers get involved with that? And like, is this a fairly complex experience for somebody, especially if they haven’t had access to these kinds of tools before? How do they get involved, and where do they fit in with this kind of product discovery, iteration process?

Ori: So, you’re referring to the designers you said, right?

Brian: Yeah, mm-hm.

Ori: Okay, so that’s another thing we learned and progressed with quite a bit with the years. So, we learned that the designers have to be involved in a project, in an idea, from the very beginning, right?

Brian: Yeah.

Ori: So, already the stage of the Wizard of Oz, we’ll just, you know, get them involved in the idea, right? There’s still no UI, but they’ll start learning what the process, what are the users going through? Maybe we record a call with a user, and they’ll watch it, and we’ll start making mock-ups, mock-ups where we can really show the user some interfaces. Because, you know, when you have a mock-up, and you have something visual you can look at, you can have a much deeper discussion over, you know, is this good, is this not good? So, the designers will be involved already from at that stage, right?

And at that stage, we’ll start making some mock-ups, start running ideas, having internal discussions, then having maybe some user testing of these mock-ups, showing the users some pictures, getting their opinion, starting to

you know, do you even understand what this thing means? And then they’ll be involved throughout the process. They’ll work very closely with our product team, they’ll work very closely with the developers, and sometimes they’ll even join, you know, a call or two with a user, just to get, like, kind of, the first-hand experience.

Brian: So, right at the beginning of this response you just gave me, you said something like, we figured out that they need to be there from the beginning. That sounds like it wasn’t like that in the past, and then it became like [laugh] that at some point. What happened there? What made you feel like, oh, this is better when they’re involved from the start?

Ori: Yeah. They were definitely not there from the start. So, you know, in the start, we actually didn’t really have so much of—[laugh] so many designers, and we had—

Brian: That’s common.

Ori: Somebody internal, who was just really good at designing stuff, who would make mock-ups. You know, and then we hired a designer externally, so somebody that would work a few hours with us a month, so we couldn’t get them involved as much. And I mean, there’s another problem which is inherent in our domain, which is the, as you said, it’s the technicality of the problem, right? So, it’s not like you can bring a designer in, you know, sit with them an hour or two, show them the platform, and they’ll get it, right? It’s very technical, you know, very scientific in nature, and you really have to get somebody to be there for half a year, a year before you really see that they’re starting to understand.

So, yeah, so it wasn’t like the instinctive thing to get the designers involved. They would sit there and not understand. You know, and as we learned, we also saw—and I think this is kind of goes all around, not only about designers—that you really want to get people to see things firsthand, right? You want to get developers to even watch a call with a user sometimes. You know, even if they don’t interact on a daily basis with a user, when they see somebody using the platform, there’s nothing like that, right? There’s nothing. I mean, I can show the developer, “Oh, look, I saw a user do this.” It’s not the same thing when they just see somebody do it—

Brian: Firsthand, yeah. I completely agree. Yeah. What got you to the point, though, that you felt like involving them early was important to do, as opposed to just keeping it the way it was?

Ori: Yeah. I think just the inefficiency of it, right, just the number of iterations we would have to go through until we got something good, right? And sometimes you would just say, you know, if they were just there in that meeting, I wouldn’t need to explain that. And they were also asking for it. They wanted to be more involved, right?

And you want to avoid having… calls with customers where you have, like, ten people there, right? So, you have to be but, you know, you can sample it. You can bring a designer there once a month, for example, or show them a recording. Yeah. So, it was really just the efficiency, and the quality as well because they would just get it much more. They would get the problem, they would be much more creative with their solutions, and they would get much more engaged. They’d be more motivated.

Brian: How is that changing to now in terms of, like, it sounds like you have a fairly mature set of designers on the team or something like this, but how has the product evolved to the point where it is now? Are there still challenges? Is it like bringing on a new domain, a new scientific domain that’s difficult? What’s hard about the product, and how has that changed over time? About using the product, I should say.

Ori: The main problem that we’re encountering is change management, right? Like, changing the mindset of users, right? I mean, we go into a company, and the time it takes to get users engaged, to get users to want to do this, each domain is very, very different. And our users are not people that sit in front of a computer. These are researchers that work in the lab, they have gloves on, they can’t really use the computer all day, right?

So, it’s very different if you cater to, I don’t know, to developers or product managers. If you’re building a tool like that, then you know your users are computer geeks [laugh] in a way, right? And our users are not. They look at their phone once in a while, but they’re not behind their computers. And the main challenge is getting people to use the platform more, to want to be there, to see, you know, it’s worth it for me to go there maybe once an hour, or even twice a, day and put in my data, look at some insights, run the machine learning models.

We’re always looking for ways to make that transition faster. Yeah, and I think for us, that’s probably… you know, one of the main challenges. And I think the key is really user experience, making it just fun and easy and intuitive to use this platform. Because, you know, if you ask me what we do, then we make—I mean, we accelerate innovation. That was the [laugh] introduction, but we also make data science accessible to non-technical people, to chemists and materials scientists, and that’s not easy [laugh].

Brian: Yeah, yeah, no, I understand that. The low adoption problem, it’s in a lot of places, and it sounds like it’s in materials science as well here, and you do have this extra challenge of, like, their work environment is not necessarily in front of a screen all the time. So, how do you incentivize them to want to—I’m guessing maybe they’re running experiments, and every week they need to log some data back into the tool so that it can learn something about whether it worked and make the models better. Is this something where they’re kind of like, “Yeah, I get paid the same whether I do that or not. Like, maybe this battery will be better. I’ll just run another experiment because that’s what I do. I run experiments.”

Is that the mindset a little bit there? Or is it more that it’s difficult, where it’s challenging to go, I got to, like, read the numbers off of this, like, physical oven that my ceramics are in, and then type them into your interface. I don’t really get anything immediately out of that. Is it more that it’s hard or annoying, or is it more that, like, they’re just apathy?

Ori: Yeah, I think there’s the hard and annoying part, which we try to make that experience smoother. But even if you make it extremely smooth, if they don’t see what they get out of it, as you said, they’re still not going to want to do that, right? Because even if something is very easy, you’re not going to do it if you’re just doing it for the sake of doing it. We also went through a lot of that, like, trying out different features that we thought, “Oh, this is awesome. They’re going to want to see these really cool plots,” right? And you know, often that’s not enough.

What we find is that if this can really make them work faster, or, you know, develop better products, that gets them interested, right? Because, you know, there’s this kind of saying today about ChatGPT and all that, that if you’re—you know, there’s going to be the people that are using it and the people that are not using it, and the people using it are going to win, right? They’re going to be the ones staying. But ChatGPT is not going to replace us, but the people using it will replace the people not using it just because they’re working faster, right? Of course, this is a bit of a cliché, and we’re in the middle of a hype, right, but in the end, I think it’s true. Like, if you’re adopting these advanced tools, in the end, it makes you a better researcher, a better worker. And I think we really see differences within a team. You can see some people are better at adopting it, and they grow faster. They become leaders in their team, and they slowly drag the others in.

Brian: Mm-hm. Is this because, like, the buyer is the Head of R&D, and they see, like, the potential value in reducing expensive experiments in the lab, et cetera, but the lab scientists are like, “What’s in it for me?” [laugh].

Ori: Yeah, yeah.

Brian: Is it like that, or there’s not a lot of incentive for them to necessarily, on their individual level, projects or products, there’s not as much incentive. It that the challenge?

Ori: Yeah, that’s a challenge. But also, I mean, that usually doesn’t work. Like, when the boss comes and says, “Okay, you have to use it,” that’s not strong enough.

Brian: Yeah [laugh].

Ori: But you really see within a team, right? The people, the let’s say, lower level that are doing the actual work, you see people that just adopt it really fast. They just look at it and there’s like, “Oh, cool. I want to use this.” And with them, it’s super easy. It’s so fun to just work with them and see them get it and enjoy it.

And then you’ll see people that are kind of like, “No, I’m, you know, I’m happy with the way I’m working now. I don’t want to be bothered with learning a new tool.” Or you just kind of need to find the ones that are easier to attract, create momentum there, and they will slowly bring in the others, right, because the others will see them working. And that’s the—so, yeah, so I think it’s not enough to go only at the higher level and expect that the bosses are going to get it in. Because the bosses, they have a lot of stuff to do, right? They’re not going to be there making sure that people are taking in measurements. So yeah, you have to get the actual people on the ground interested, and engaged, and working.

Brian: Yeah. It was one of the things that I didn’t learn till much older—later in my career, was that this, especially with design and these adoption challenges is, there has to be a real incentive for the worker. Even if the product, in theory, like, if you were to explain this to someone, it’s like, “Of course. Why would you not want to do it this way? It sounds totally obvious.”

But then you have to think about the user experience outcome piece, which is what’s in it for the individual scientist? It’s got to be way better than something they’re doing today. It’s got to take away some kind of pain or something they don’t like doing. It’s got to increase their status somehow, whether they’re getting promoted, or it’s like, everybody wants to work with this scientist because they’re just cranking out winners all day long, and then they find out, “Oh, it’s because I’m doing ten times less experiments than you are. I’m not guessing. Like, I’m using this product.”

But if we’re not dialed into, like you know, at that line level, the person who’s actually hands on computer, or hands on the interface, if we don’t know what it’s like to be that person, it’s really hard because you just have this theoretical value. You have this tool that theoretically should be really obvious, and of course they’d want to use it, but they’re not the ones paying for it. There’s always those two sides of the coin to me. If they’re not using it, eventually that’s going to get back to the buyer, which is, we’re paying all this money, and no one’s using this tool. We’re not getting any value out of it, right? Do you see it that way as well?

Ori: Definitely. It’s very, very tough to also, I think some of our most valuable employees are the people who are the users, or who could have been users. Our product manager today is a materials scientist, and we have a team of materials scientists, and these people are really the ones that they kind of imagine. So, I’m not a material scientist myself, right? So, for me, it’s harder to imagine being that person in the lab, right?

And sometimes, kind of, what I think is correct just turns out to be completely wrong because, you know, I just don’t know what it’s like. And I think having these people within your product team, and within your customer success team—and even within your development team, we also have materials scientists in the development team, people that made the transition to the software and data science—you can’t replace that. And of course, you can’t replace talking to the users and to potential customers all the time. And yeah, it’s really this search for the product-market fit. That’s a very tough search, you know? Because you start with a with an idea, but then when you actually get it, you know, start building it, you realize that half your idea doesn’t really work or is not really valuable, and you have to keep refining it. And we see that very, very strongly.

Brian: Yeah, yeah. Ori this has been a great chat. Do you have any, like, closing thoughts, particularly, any advice you might give yourself of five years less age, you know, or someone in your space here, something you’ve changed about how you’re leading product, about how you’re working with design, anything like that you might want to share with our audience?

Ori: Yeah, sure. I mean, I think we kind of said a lot of it. Listening to your user. Don’t think you know better, right? Don’t come and say, you know, “I know the answer. Let’s just follow, you know, what I think or what my boss thinks.” Just be very modest, and just listen to your users, listen to your customers. You know, look at your competition, what they’re doing, look outside and see what you can learn.

And always keep learning, right? Always keep learning because there’s always ways to, you know, keep learning from the outside. Don’t say, “Okay, now I know. Now, I’ll go and build.” Right? And I think, you know, Agile is kind of based on that, and I think that’s so true, right? And there’s a lot of content in that, right? A lot of things, details to learn of how to do that. And I’m still learning all the time, but I think that’s a big thing. Yeah.

Brian: Cool. Ori, thank you so much. Ori is the Chief Product Officer at MaterialsZone. Can people get in touch with you somewhere? LinkedIn? Are you on social media, anything like that?

Ori: Sure, I’m on LinkedIn. You can email me ori@materials.zone, very easy to access. My name is very unique. Ori Yudilevich. You won’t find [laugh] another one.

Brian: Nice, nice [laugh].

Ori: [crosstalk 00:34:15] find my LinkedIn account.

Brian: I didn’t even know there was a dot zone top-level domain. That’s—you guys got that one lucky.

Ori: [laugh].

Brian: [laugh]. Excellent. Well, Ori, it was really nice to talk to you, and thanks for coming on Experiencing Data.

Ori: Thank you, Brian.