Transcript: Tom Mayblum | MIND | When Is a Customer Conversation Worth More Than Data?

Tom Mayblum and his career path

Eyal David: [00:00] What's up? Hi, how's it going, Eyal? Great. So glad you came, huh? Good to see you. With us is Tom, who is VP Product at MIND.

Tom Mayblum: [00:08] Before we talk about MIND and the topic of the episode, tell us a bit about yourself. Sure. OK, so I'm Tom, 40, originally from Haifa, today in Tel Aviv, married plus two kids and a dog. Today, as you said, I'm VP Product at MIND, a cybersecurity B2B SaaS company. Before that I spent about five years at Armis, also a cyber company, a bit more in the headlines lately following its acquisition by ServiceNow. There too I was in product roles throughout the years, and we went through growth from 100 employees to around 900. My cyber background, like most people in Israel probably, is 8200. I was there about six years. In between, in the ten years I haven't detailed, I made something of a personal pivot. I had a dream of developing something in the medical world. I went to study biomedical engineering at the Technion, I was there seven years, a bachelor's, a master's, academia. I founded a startup with two other partners in the field of ultrasound and computer vision, lots of challenges around clinical work, regulation, patents, hardware, algorithms. And unfortunately, around the start of COVID we had to shut the startup down. Everything kind of froze. So in a kind of shift back, I came back, I basically moved to Armis. There things came together, because my first role at Armis was actually product manager for the Armis product, but for customers in healthcare, hospitals, and that combined my background and knowledge in a pretty unique way, and that's how we closed the circle. That's how it connected, excellent. So OK, tell us for a second about MIND. Yes. MIND is an Israeli startup in cybersecurity, already past a Series A, two funding rounds. We deal with the world of data security, protecting information, and specifically the world called DLP, or Data Loss Prevention. Essentially, what we do in one line is help organizations prevent leakage or exposure of sensitive information to the outside. It's much more complex than that, of course, there are lots of threats, many of them external, you know, but usually the average case isn't actually an attack by some Iranian group or Handala or something like that, it usually actually happens from the inside. Often by mistake, an employee uploads some customer list from Salesforce to ChatGPT, asks it: do something with this, or summarize it for me, and it gets out, or uploads it to some private source, or exposes it externally with the wrong permissions. Or sometimes also maliciously, with some employee who's about to leave or is being fired, deliberately pulling and taking information out of the organization, and unfortunately we see that happen a lot. Unfortunately in the business sense for our customers, fortunately in the sense that we provide a lot of value in those incidents,

Eyal David: [03:16] and that's why we exist. Excellent. So just tell us, how many people are you on the product team? What does it look like?

Joining MIND and defining success

Tom Mayblum: [03:23] In product today we actually have two PMs on my team, besides that we have two designers, two female designers, sorry. A Head of Design and another designer under her, and we have a tech writer for copy and UX in the product. And tell me, at what stage did you join? Yes, so I joined a little over a year ago, it was right when MIND moved to... came out of stealth, as they say, and launched the product and the website and everything. The company had actually been running a bit before me, and they'd already built something, there were already design partners, there were also two or three paying customers, and there was no product function. There were founders, and there still are very, very strong founders, both technologically and business-wise. Very strong developers, a very strong sales team, but there still wasn't a product function making those connections, one that knows how to connect strategy and tactics, winning a specific deal with all the customers being happy, and really that's what MIND's founders felt was missing, and that's what I was looking for. After Armis I was looking to come in and be the first product function in a company the size of MIND, whose founders I believe in, whose problem I believe in, whose potential I believe in, and to build the product organization from scratch, from creating the processes and the organization all the way to the actual professional work itself. What did they define as success for you when you came in? Good question, what did they define as success? So they didn't give me sales targets or customer targets or retention targets, which of course are targets that matter to us as product, but we're never solely responsible for them, there's a whole organization that's also responsible for them, but it was really important to them to first create order. Meaning, in the end, a company especially at this stage, and my experience is mainly in cyber, but what I know is that there's a lot of action, lots of opportunities coming from potential customers, lots of deals on the table, and you need two things: first, to create order around, OK, do I need to jump on every request from every potential customer, and if so then what, and what don't I do, and second, focus. In the end there are lots of things I could do, lots of potential technology, lots of capabilities we have, but we can't build everything and we don't want to build everything. That's first of all what they wanted from me, they wanted the ability to create order, the ability to create an organization that knows what it's working on, both toward Engineering and toward go-to-market, to ultimately understand what we're working on, what the focus is, what's coming, what they're going to sell, and so on, the classic things product does but which simply didn't exist. What, in your eyes, are the biggest risks today for a company, a tech company, a startup? I may sound cynical, but I think most of the challenges aren't in the technology, and everyone's talking about vibe coding and prototyping and how fast I can already get something live. So the challenge, the barrier, isn't getting something live, and on the other hand it's also very hard to create some moat, a technological moat that says only I will know how to do this. In the end there are very few companies in the world whose claim to fame is that we do something technological deeper and better than anyone in the world. Most companies aren't in that place, and so they won't win on technology. The challenge is, in the end, first, how I move fast and fit myself best to the market, and second, how I actually solve a real problem and bring it to customers at the right time, in the right way, and most effectively. That's not technological per se, but it definitely requires a lot of product work in that direction and in understanding what I'm building and how and at what speed and for whom, and how I win, again, not by my technology being the best but by being the best for my customers. So if I wrap up for a second what you said, it's also precision

Bringing AI into product processes

Eyal David: [07:39] and mostly product precision, probably, and also avoiding waste, you talked a lot about time and such. Yes. How do you deal with that today? I assume that you, you mentioned AI, so I assume you're shipping a lot more things to production, like that's the expectation.

Tom Mayblum: [07:55] Yes. How do you manage to be precise across all the... Yes, so look, AI in the end is, you know, used in every area, from writing code or fixing code or improving code all the way to specs and design and analyzing customer sentiment. So yes, the output is higher, but that doesn't at all mean the outcome is better. Our focus as product is on the outcome. So for the outcome to be good, it doesn't matter how many lines of code get written and how much more or less AI gets done. The question is what it does

Eyal David: [08:30] and what the developers do and what they build. And that's where product comes into the picture, that's why it didn't use. So I'm asking, you're three people, how do you manage, with that same expectation, today a year after you joined, to handle many more initiatives? Yes. How do you manage to stay precise across all of them? We work hard, but first of all we also have tools

Tools and precision in product work

Tom Mayblum: [08:49] with which we can produce work faster, so that we also won't be the bottleneck. I never want the bottleneck to be the PM. For the bottleneck to be a missing spec, or no design, or it's still not clear exactly what the edge cases are, or a decision hasn't been made about doing X or Y, those are things that, as far as I'm concerned, must not be the bottleneck, it can't be, as far as I'm concerned, that developers or the engineering group are waiting for us

Eyal David: [09:17] in that sense. How do you get there in terms of processes, in terms of tools, how do you. So first of all in terms of mindset, again, and it comes back to focus.

Tom Mayblum: [09:28] I need to decide on a lot of things I don't do, and my team needs to decide on a lot of things they don't do and don't touch. You need to prioritize very aggressively all the time. How to know to address not only what's important but what's urgent, and to always make decisions on a daily basis about what we're dealing with. That way I can also narrow down the things I work on. Do they connect to my strategy or not, is this something that will get me lost, is this something that will solve a problem for this customer but also for more customers. So that's still true in the world of... in the AI era, in my view. And the second part is, yes, using tools. You know, many people talk again about AI in the worlds of prototyping and vibe coding, here, look how I make a mockup in a second, and by the way that's true and we all enjoy it and do things in a few hours that used to take a week. I think there's use of tools or AI in other places that help us a lot. Us too, and I think it's pretty standard for PMs and Israeli startups. In the end you work here in Israel, engineering is here in Israel, most customers are in the US, most salespeople are in the US. Time zone differences, cultural differences, we supposedly need to be everywhere all at once, which isn't very possible. Every PM will say I want to be in direct contact with the customer and in as many calls as possible, but you can't be in every call. At best you can be in a few calls a week, people might accommodate you on hours when you can join and not at midnight, but you still won't be in every call, and not all calls are necessarily led by you, it could be a sales call and so on. One of the things tools can help us with is really, for example, at our company, all customer calls are recorded, transcribed, and connected to a chat, Claude, GPT and so on. I can come and ask broad product questions in no time, I can ask which customers just talked about this thing, or what the customer's sentiment was in the call, or what the customer asked for, or how much urgency the customer expressed in this request, and we get all of that automatically.

Eyal David: [11:47] So tell me, there are several types of user interviews, and I meant to break them down, but say now you want to bring in someone from R&D, or you want to bring in a product person who joins you, and you want to guide them on how to do user interviews, how would you start that?

Tom Mayblum: [12:02] Nice, so really, as you said, there's an oral tradition, maybe, of how to do interviews. There are also good people more senior than me who wrote books about it, you mentioned Teresa Torres and product discovery and how you do that whole journey. I think it's a bit like in sports, to succeed you have some combination of talent, preparation, experience, and just seniority, how many times you've done it. I talk with them a lot about preparation, which also depends on the type of interview, and experience is just experience. I bring them into calls. In the first two or three calls they probably won't say a word. Maybe in the first call I'll even say, like, your role is to listen. Sit and hear the call, see how I respond, how I ask questions, hear the customer. Sometimes they also won't want to talk themselves because, you know, they're shy, hesitant and so on, but really the goal first of all is to learn and see how a call is run, and to bring people into calls and see what a customer call is. Because it's very easy to get some feature request and say, oh, he said that and he doesn't understand, and then when you're in the line of fire facing the customer and you realize there's also a human element and frustration and human needs, believe me the interaction is different. So first of all, listen. And then I'll try to bring that developer or product manager to a place where they've been through a few of these and also done the preparation, which we can talk about, so they can join and be a bit more active, and later lead

Eyal David: [13:45] such calls themselves. Come on, let's get into it. So basically you start from the end, where do you, like, I, say, start from: OK, what do I want to achieve from the call.

Defining the goal of an interview

Tom Mayblum: [13:52] Totally right. So first of all there's, you know, framing of what the call is even about. Meaning, we said interview, but an interview isn't a single animal. There's very general product discovery of: now I'm coming to build something from scratch, I'm an early startup, I'm opening some new module. To build or not to build, you might decide not to build. Yes, maybe more at the level of validation, for a second, and to go all in. I have a thesis, and I want, sorry, but I have a thesis and in the end I want to validate it. And here I really come to learn, I want to understand how things work, I want to understand things very broadly and deeply, and that's one type of interview. Versus a more specific interview about some use case, about some need, a customer feature request, say. It reached me as: add X to the product, and I want to understand for a moment why, or what you're trying to achieve, and what I really need to build, or whether I need to build at all, whether there's a way to do it today that you're not yet trained on or don't know the product well enough, unfortunately, or the product isn't intuitive enough. Maybe I already came with suggested solutions and in the call I want to see the alternatives and see what the customer thinks in as unbiased a way as possible, and maybe I'm just coming because I shipped something, some feature, and I want to get feedback after use. So there are all kinds of interviews, and the preparation is first of all to understand what type of interview it is and, as you say, what I want to achieve in the end, what the final result is that I'll come out of satisfied. In the end this call is a bit selfish, in the end I'm trying to get something out of it, of course I also want to provide value to the customer, even if it's an interview where he needs to talk more than me, in the end I want to make him feel heard, make him feel important, that his feedback matters

Eyal David: [15:39] and that I also understand what he's talking about. Basically you're building context here, right? You're kind of mapping the role of the other side? What they're trying to achieve in life, and not just to extract it for our insights but actually their sense of fulfillment, and basically there's another dimension, also after you, I think after you talk with people or you get to know the persona on the other side a bit, there are also constraints. Say, Sarah, I know she's going to talk a lot, and I know I need to take that as part of the event, and I don't interrupt needlessly. Totally, there's also style, yes, and there's a relationship now.

Tom Mayblum: [16:16] The preparation I'm talking about is also the preparation of really what the goal of the call is and what the context is, but also preparation on a more personal level, meaning who am I going to talk to? At the customer level, first of all, what is this company, if I've never talked to them, what do they do? What does their status currently look like in terms of the relationship, are they in a place where they're happy with the product, have they finished onboarding, are they at the very beginning, are they getting value, do they have all kinds of complaints or feature requests we haven't addressed yet, or some escalations or commitments we gave them once before I even got to the role. So I need to understand that whole relationship for a few reasons: first, to come prepared and really ask the right questions. Not to show that I know nothing and suddenly ask something I'm supposed to already know, actually, from the history, from the previously-on recap. Second, I don't want to be caught unprepared. Meaning, suddenly I'll join a call to talk with him about something very general and he says to me: wait, what's happening with that thing you promised two months ago? I'm not interested in talking about this now. First let that be ready and then I'll talk. So if I didn't do the preparation, there's a bigger chance something like that will happen to me. So first of all I need to understand what I'm walking into. I'm not coming in at the beginning, I'm coming in in the middle of something. In the middle of our relationship as MIND with the customer and with the company and with the person themselves. Also regarding the person themselves, I need preparation to understand who I'm talking to. First of all at the level of whether it's the buyer or the user. For us, say, and in many startups in cyber, the buyer can be the CISO or the CIO, the user can be the security team, and even then, is it the team lead or the operator who goes into the product day to day. And of course that completely changes the conversation. Is the conversation more technical, more high-level? Is he going to complain about things that are hard for him to do day to day, or is he, you know, at the executive level, buying the product, his considerations are different. They're less interested in whether it's hard or not for the security team to work with the product.

Eyal David: [18:20] So all that preparation is pretty critical in my view for the call to be successful. Let's say one more thing, so really the next practical part would be preparing the questions. We, for example, prepare the questions in advance. Even if I'm going into a discovery process, I'll probably prepare the same questions or very similar questions, which I'll also tighten between calls. I'll basically come more prepared. Here you could bring in AI, for that matter, it's still not perfect, but it's already cool.

The right questions for each type of interview

Tom Mayblum: [18:46] So how do you prepare in terms of the questions? What does it look like? Excellent. So really, as you say, in the end I need to take all my preparation, all that input, and translate it into a script or into something I intend to ask, and what I think the flow of that call will be. I say "think," because the flow won't necessarily end up like that, and we can talk about that too, but obviously, you go into a call with a customer, you have a certain goal, the customer can take it in another direction along the way. You usually need to be dynamic, meaning, or flexible, you know. You came to talk about X, it's very important to the customer to push to talk about Y, you'll probably let him talk about Y. After that you'll try, with some relatively elegant segue, to get back to X, which you wanted to talk about, but you won't tell him, no, no, we're not talking about Y today, I want to talk about X, that's why I came to the call. So you need to be as prepared as possible, and have a plan in your head of how it's going to look, but also be ready for changes. In terms of the call itself and the questions I prepare with, then really, as you said, it depends on my goal. If it's a discovery call, then you want, it's a bit tricky, because on the one hand you want them to describe their world to you, describe for me the daily workflow of what your work looks like. Better than that is usually to ask for examples, of: tell me, if you can, about the last incident that happened, the last data security incident you had, what did you do, how did you deal with it, what was the problem. If they're not my customer yet, then why doesn't the current product or the current solution address it? What were you missing, what hurt, things of that kind. I think it's tricky, because on the one hand you absolutely want to ask as many questions as possible, and as basic as possible even, on the other hand you don't want to be caught as too much of a novice, a noob who has no idea what I'm talking about, and I'm asking you the most basic questions in your world, and you'll say wait, why am I even talking to you? You have no idea about my world, why would you give me a solution, I don't trust you. He probably won't say it, but he'll think it. He'll think it, and there's another thing here too, I think you might miss really important details because you didn't account for them in the script you built. That's the muscle you basically need to train, knowing when, I say it in a bad way, knowing when to shut up. And when to actually amplify. Yes, yes, and you know, like, at least examples where things like that happened to me too personally, not necessarily at MIND but also, say, at Armis, the previous company I worked at, there was a case where, not a case, but there was an event where we wanted to develop some product, a product line with a new module for existing customers to also buy. On the other hand we didn't know the field well enough, and there are many competitors in that field, so you can go and have friendly calls with an existing customer, who loves Armis, knows the company, uses it, but on the other hand he understands that field much better than you and you need to come and have him teach you about the field. So you can't come with zero knowledge, and you come to a team I've never talked to, and it's not necessarily using your product, because you're talking to large organizations with several teams, one team uses your product, a second team never heard of you, they dropped you on them, the CISO dropped you on them and told them, talk to him. They're like, why? You need not to annoy them, they're technical people in the end, people whose time is valuable, but on the other hand in the end you need to validate, so there's a very delicate balance in how I ask questions in a way that's not too basic. I don't say describe to me how, what is vulnerability management, which is, say, a module they need to set up, but rather, explain to me what it looks like at your company. Who works on it? In what setup? What tools do you use? Can you tell me, you know, what happened, something that happened in the last week that was some incident? What's not good about how you do things today? So you need to kind of walk between the raindrops and ask the questions in a way that on the one hand is relatively open, that you want to learn, and you really are coming to learn, and on the other hand, with some foundation that you did learn beforehand, otherwise they really say, like, why are you asking this? Don't you know the answer?

Eyal David: [23:04] Yes, there's another thing here, I think, especially with non-Israelis it comes up, that's the matter of basically staying politically correct. Here too it's a delicate range of basically asking the question, like, really digging into it without actually annoying the other side, or without actually getting answers, you'll say, OK, fine, I'm moving on, basically, and I put a check for myself, but actually it's not a check. So what do you suggest doing in situations like that? Yes, that's a good point, because really there are,

Tom Mayblum: [23:35] there's no way around it, there are cultural gaps. I talked a bit earlier about experience and repetition, so repetition helps with that a bit, because in the end you understand the culture more, and it's not necessarily a matter of language, you know, whether you're a native speaker or not, and you understand English, in the end there are differences of culture and approach, and he tells you one thing, but he actually means something else, or doesn't mean it, so experience helps, and what I, in the end, you know, in the end you see that he's giving you laconic answers, and he tells you something general that doesn't really move you forward, so you can't be, you know, direct like us Israelis, and tell him, you didn't answer my question, or that's not what I'm looking for. You do need to acknowledge what he told you, give some positive feedback, and maybe bring him into the conversation a bit from your side, and also give your own example. For example, to say,

Eyal David: [24:23] that's interesting, other customers I've talked to described something like this and that. Have you run into something like that too? Exactly, that's an excellent example. I use it a lot, and sometimes I even note it on the side, and I'll come back to it later in the call. So yes, that's a very nice trick, but you must not leave these things untapped, I really agree. You also need to watch the time when preparing for calls like this. Again, if we talked about a script and questions, in the end there's half an hour to an hour, subtract from that the hellos and stuff, it's really significant to account for that. OK, we've done an interview, say, good, not good, we've done it, how do you look at the interview afterwards? Do you basically summarize things for yourself, do you watch it again, what does it look like?

The long way that pays off: small change, big impact

Tom Mayblum: [25:07] Yes. Good point, so there are a few things here. First, really, during the interview I'll also try to repeat each point, to make sure I understood what he or she said, kind of echo, to echo what was said, and make sure it's correct, and otherwise I'll get a correction, and note it on the side and document it. Second, in the end I want to end a call with some action items. Starting from a summary of: these are the things I understand, do you understand the same thing too, or did I miss something, come help me. Second, if it's a call that's not just discovery, but really their questions, or things about a specific feature or a request, then of course also if I need to get back to them with answers, then to state action items of: I need to get back to you on A, B, C, and to propose some follow-up touch point. For example, I'd be happy to schedule for another week, two weeks, a month, depending on what the call is, but if the call is about a feature then we're working on it and we'd be happy to show you a mockup in another week. You had the example with Deploying, I remember you told me at the start of the prep. Yes, yes, I have two examples like that, or even three, of customer requests. Usually these are also tactical things, they don't have to be the biggest things in the world. It can be a case where part of our product is API integrations, we connect to the customer's SaaS environments and check, scan what sensitive information potentially exists there. And the installation process is pretty simple, but in the end there are stages to the installation, you connect, grant permissions, and then hopefully the integration, everything works as it should, the integration moves to a state where it's Active or Online. The path there can be all kinds of things, there can be a failure, or we're still at some sync stage. In the end I got some claim or something that came from the field, from our Go-To-Market, that a customer says, the integration status says Deploying, change it, it looks like you're installing something in my environment. I know we're not installing anything in his environment. But I understand the status is confusing. I'm still trying to understand what's going on. And the instinct of the team, of sales, was: change it now, within five minutes, we'll look responsive and fast, no matter what, no matter to what value. What we did in the end, after I asked, is that a day later, after they raised it, I got on a call with the customer, and I said, this is what I understood from our team, that you raised. I'd be happy if you described it in your own words. He explained, and then only really he explained to me what I later described and understood, that it confused him. It confused him because he thought that what we do, because a certain word was written there, is that we install something in his environment, and he thought we were completely passive. So first of all, really, he's right. Second, I described to him what it actually does, and what the process we do looks like, and then I asked him, after what I described to you, how do you think you would call it, or how would you describe it. He gives a few options. So you basically got copy. Yes, he gives a few options for copy. By the way, speaking of preparation, I had already come with three copy options in advance, and I could have chosen one of them, but I wanted to do two things. First, I wanted it to come from him, second, I wanted him to feel he has impact. After he gave a few more suggestions, I told him, OK, like, those sound like good suggestions. We also thought of a few more options, what do you think of them, and in the end he actually chose one of them that looked very good to him. That same day, or a few hours later, that thing went in. And it went in after the call, and we also showed him, we sent him, like, and showed him, here, look at it inside. And we achieved a few things here. First, we achieved that of course we fixed something that was confusing in the product, and that helps all customers. Second, we achieved some trust with this customer. That says, even about the smallest thing, you get on a call with me, you listen to me, and in the end you also do something in the product according to my feedback. And he really, even though he's American, a different culture and so on, he wrote almost in those words, he said that he was really, really impressed by the fact that we, both by the speed, and by the fact that we took his feedback on something that was supposedly minor, and made that change. And again, it's a very small example, but we took the slightly longer path, which cost us another day, in order to do something that gave us more value.

Eyal David: [29:55] More value, more of a breathing test, more customer satisfaction. OK, how do you know at the end of a call,

Tom Mayblum: [30:02] how can you tell yourself whether it was a good call or not a good call? Good question. I think that... first of all, did we even manage to reach the topic for which I convened, or we convened, because it can absolutely derail and go in other directions. Second, if we talked earlier about preparation, I have some goal for the call. So can I measure whether I got that goal? Meaning, did I meet the target, did I get an answer to something, or did I get a direction, or some input that helps me with the decision I need to make? Whether to build or not to build, or A or B, or what the problem is that really needs solving? So if I got some answer, I feel I succeeded in the call. And there's also the softer side of, you know, how do I feel in terms of our relationship with the customer? Did it strengthen it or not? And also whether there's a need to give some value here, in terms of the customer feeling that we want what's best for him,

Eyal David: [31:01] hear him, understand his difficulties, and that strengthens the trust. And now I'm trying for a second to take this to the end result. So basically I've done a few calls like this, I came out and summarized them, and I already understand better which way the wind is blowing. And now I'm basically taking this and putting it in as a data point, and I also have the quantitative data, if I have it. Industry trends, or my usage in the product. How do you look at this and at that, and know how to say, OK, this is correct. Like, which would you trust more?

Qualitative learning vs. quantitative data

Tom Mayblum: [31:32] Yes, good point, and I think it's a bit annoying, but you know, it depends. The annoying answer is that it depends, and I think in the end it's some mix. My personal experience is in B2B, SaaS, cyber, not B2C. So the world is a bit different in terms of metrics, statistics, data volumes and analytics, and how much you can rely on them. In the end, in the worlds I live in, you don't have millions of users, you don't have much statistically significant value for all kinds of decisions. You have very specific value. One call, or a few calls with five big customers, is much more significant, or much more meaningful, than something in some usage graph we have, in our world. The second thing is that again, in the context of a specific customer, of course his usage data interests me. Speaking of preparing for a call, I'll try to understand whether he uses the product, which feature, how often he logs in, which use case if he tried to use it, but at a very granular level, not at the level of the aggregate. Meaning, yes, there are things we make decisions about, or micro-decisions, based on analytics of how many clicked on something,

Eyal David: [32:46] or how many got confused creating a policy, as I said, and so on. Totally, I also took that to the place of discovery, that if, say, we're examining a new idea, and there are the trends, there are some trends, and I'm now hearing the opposite of that, or different from that, basically, in the ideas, maybe I'll just want now to really have a deeper discussion around that difference, and maybe go on another journey of interviews, short follow-up interviews, to basically nail this down. I too, like you, prefer, I prefer qualitative information, especially in today's world. Excellent, I think it was an excellent episode, I'm glad you came. If people want to get in touch with you, ask questions and such?

Tom Mayblum: [33:24] You can find me on LinkedIn, Tom Mayblum, you can find me by email, tom@mind.io.

Eyal David: [33:31] Excellent. In every possible medium, probably. Great, so glad you came, Tom. My pleasure. Come on, thanks a lot, bye bye. Bye bye.