Transcript: Spotting Bullshit in Product Management — Oded Hutzler (Evinced)

Eyal David: [00:00] Hi friends, this is Eyal. You've reached Product Builder, and here you can listen to the most interesting product conversations. My journey began in 2012 when I learned what product is at my own startup. Since then I've worked in the industry, and since 2017 my company has been consulting for a variety of companies. My drive is to help all of us improve as product people. And before we start, if you enjoy listening to Product Builder, please rate us five stars on Spotify. It'll give me great feedback that the podcast gives you value, and it would make me very happy. So come on, let's get started! Hey Oded, how's it going? Good, how about you? Great. Today Oded is joining us, he comes from Evinced, we work together, we've known each other for about three years now, probably. Okay Oded, so tell us a little — what does Evinced do? So, we're a startup in the accessibility domain,

Oded Hutzler: [00:53] broadly, helping people with disabilities use websites or apps like everyone else. And essentially what we do is help huge companies, large organizations, like Amazon, like Booking, like all kinds of big banks, to make their apps and their websites accessible. What does that mean in practice? We have a set of tools, really, for the entire development process, starting with tools for the graphic designer, to design with, so that in the end it can be made suitable for people who need accessibility, and for software people, essentially something that actually checks their code and finds all kinds of accessibility problems and bugs for them, and after that for QA people, and we even have all kinds of monitoring products, that constantly monitor your site and find accessibility problems for you, and of course also give you ways to solve all these problems, and that's essentially what the company does, and we have a set of products, for web of course, and also for mobile — an Israeli-American company, and when we talk, when I talk about accessibility problems, it might be a concept that not many people are familiar with, but broadly it means that every website, or every app — in order for people with all kinds of disabilities, like people with low vision, or people with all kinds of motor disabilities, to be able to use them, just like regular people, they need to be adapted to them. And to be honest, it's not just for people with disabilities, it's also for people like me and you, I don't know, around age 40 or so — for most people, our eyesight deteriorates a bit, suddenly we need a bigger font, suddenly we need bigger spacing in texts, so websites need to know how to function that way, a lot of websites don't know how, and essentially we help those organizations find problems as early as possible,

Eyal David: [02:52] in the development stage. So you talked about web products, because you're responsible for web products, several of them, and there are also mobile products, of course. You talked about disabilities, so it really can be even color blindness, or simply a better user experience, at the end of the day for everyone. Absolutely, user experience is part of accessibility. So Gild also came to us in one of the episodes, and you came here — we'll actually talk a bit about your path to product, and a bit about what you do, and what your day-to-day looks like, and we'll dive into your world, but really you came to talk about bullshit. How to spot it, how to communicate it, and how to get past it — it'll be an interesting episode. So really, tell us a little about your day-to-day, what does it look like?

Oded Hutzler: [03:36] To be honest, my day-to-day — maybe it's one of the things I love most about the role, because my day-to-day, broadly, never looks the same. It's always made up of lots and lots and lots of different things, small and large, so my day is probably, probably answering some support ticket, or dealing with all kinds of tickets that come from customers, answering customers, talking to customers, maybe some customer meeting could happen, probably there'll also be writing some spec document, some PRD, talking to the designer, talking to the development teams, there'll be meetings, of course, an integral part of the role, broadly, meetings, really, a bit of everything, mainly, mainly, mainly, people. People all the time. And you also do user interviews, you go on calls with customers too, right? Yes. And essentially most of the work is really around meetings, and Evinced is also a very technological company, and also around the accessibility domain which is really deep, so you need to gain that understanding, and essentially there are tons of discussions, because they're also carving out a lot of things, essentially the company is carving out for the first time, really. Because they don't exist, and essentially there are tons of conversations around these things. That's it, important to mention. Which products do you work on? So broadly, I work on, say, about three — you could say three products. How modest you are! Because really, the company, what we provide is products for the entire span of development stages. So essentially, I work on three products, essentially two products, two products for software developers and testers. What do they do? What does it look like? It's broadly some browser extension, two extensions, that essentially come up when you open them, it comes up on your web page for the software, or on the app — say you're on a bank app that you're currently on — and essentially runs some scan, finds all the problems, all the accessibility problems, suggests all kinds of solutions for you, how to fix them, and of course, we have integrations with all kinds of ticketing systems, like Jira and so on. Because really the goal is to find, essentially before going to production, that's usually the direction, essentially problems and to talk about them, right? Both before going to production and after, it's fine. Broadly, the orientation is always to improve. We know nothing will be perfect, that's fine. We want customers to always — or customers want to always be in the improvement arena.

Eyal David: [06:13] That's it. Let's maybe explain for a second why — what's so urgent for them, suddenly, to address accessibility problems. So yes, honestly...

Oded Hutzler: [06:20] First of all I'll just say, really, why an improvement arena, and why it can't all be perfect — one, because it's hard for everything to be perfect, and two, because accessibility is something that came into the world relatively, let's say, late. Like it came into the world in recent years, in the context of your question, so really, broadly, there are several reasons why to do accessibility. So maybe we'll start with the reason, with the good reason. Broadly, inclusivity — meaning, after all, at the end of the day, around 15-16 percent of the population have all kinds of disabilities, all of us, as I said, at age 40, when we age, will start to experience all kinds of difficulties, and essentially we want every site to be accessible to everyone, meaning that everyone can use the sites. That's the first reason. And the second reason is, let's say, it's the stick — essentially, in the world, governments; it already exists in the United States, it exists in Israel, Israel is very advanced in its standard, there are accessibility standards that companies have to meet. In Europe, for example, the standard was only just legislated, I think it's supposed to come into effect this year, essentially, something like that, and essentially whoever doesn't meet the standard, can get all kinds of fines, and very, very high fines, and essentially, and the third reason, let's say, is money — meaning at the end of the day, also, if the buy button on your site isn't accessible, essentially, to people who, for the sake of argument, can't use a mouse but do use a keyboard, then you lose market share.

Eyal David: [07:53] Amazing, so that was two products — we said one for development, the second for development and QA — and the third product?

Oded Hutzler: [07:59] So the third product, honestly, is a pretty groundbreaking product, it's some SDK, really for developers, sits inside their development environment, and essentially we help developers, essentially development groups, to really test, in Unit-Testing, which is a concept from the development world, to really test every design component, that they have on the page. Meaning, for example, if they have all — to test all their buttons, that they'll always be accessible, to test all the dropdowns, all the, I don't know, accordions, essentially every, how do we call it, essentially every component, we essentially allow you to test, and to get essentially 100% accessibility coverage. Like really already while writing the code,

Eyal David: [08:43] really, yes, and so on. And there's no bug at all. Right. Let's give some example, essentially, of a classic accessibility problem, let's shed some light on it, so it's clear what we're talking about. Okay. So let's take, for example,

Oded Hutzler: [08:57] an accessibility problem of keyboard operation. There are people who work only with a keyboard, for example people with low vision. They don't see the screen, for the sake of argument, or don't see the screen very well, and they'll usually work only with the keyboard. You and I, for the sake of argument, when we look, we can see there's something that looks like a button. For the sake of argument, we know that probably, if we hover over it and click on it, something will happen. And people who don't see, don't know that. They don't have this information. They rely essentially on information that comes to them, with something called a screen reader, it's essentially something that reads out to them what's happening on the screen, on the website, and then what happens is that there are sometimes all kinds of buttons, for the sake of argument, that aren't accessible to a screen reader, that a screen reader won't identify, won't read out, and those people essentially won't know, for the sake of argument, that there's a button there, that they can click on, that they can buy something, order a pizza.

Eyal David: [09:56] Cool, interesting. Actually, if we compare it to something from the real, non-digital world, then if there weren't those stripes right, before crossing, yes, then people would cross and it would probably end not well. So as an experienced product manager, you've seen it at several companies — can you say what are the most important product skills in your eyes?

Oded Hutzler: [10:20] Honestly, I thought about it a bit beforehand, and it kind of changed for me while — it's the kind of thing that keeps changing — but broadly I think first of all, accountability, because as a product manager you're kind of, let's call it, the CEO of your product, meaning you're responsible for it no matter what, for the bugs even though you didn't create them, you're responsible for them being fixed, you're responsible that they happen — well, that something is done about them, you're responsible that it manages to meet the KPI, no matter what, whatever the case, things like that — and that success is about making it happen, developers doing the work that in the end leads to it, it leads to stabilizing the work, it leads essentially to everyone giving their all, and to the product succeeding, against all the... races, that's the word — it's not necessarily the most accurate word. And the second thing is people — meaning, a skill of essentially interpersonal communication, emotional intelligence, to understand what drives people, what doesn't drive people, how to talk to people, what not to say. I think it's a profession where most of the work is done with people — like an army, you need to — do prioritization, do more of this, do whatever, on things, maybe the design and this and that, but always do it with people.

Eyal David: [11:41] And that's something you gave weight to before you came into product. Absolutely, it's one of the reasons I wanted to get into product. Tell us about it.

Oded Hutzler: [11:48] Broadly I was — I started as a developer, meaning I studied computer science and psychology, and I started as a software developer, I did frontend, I also worked at Microsoft, also at Kaltura, and also at AVG, which is an antivirus that no longer exists, and Microsoft was really the last place I developed at, and there I really understood that I really want to make a change, for two reasons: one, I wanted a role that's more human — I don't know if human is the right word, but more, like, social, really more communicative with people, and two, always — and also because I always saw that the product managers were the people I always got along with best, like it's really fun to talk to them, they're these fun people, and essentially the role was really, really, really at the center of things, like at the center of the action, they always kind of knew everything going on, meaning always kind of a big-picture mind, like you talk to them — let's say the product managers I remember fondly, they always knew what I was talking to them about, meaning it was always really fun to talk to them, and then I really made the shift, I moved to some friend's startup, which was a startup in a certain field — I was a very technical product manager there, there was very little UX there, and then after about a year, Maya from Evinced reached out to me, which was a role that I kind of just felt fit like a glove, meaning both the field I knew, the domain — meaning a lot of work with developers around frontend, a lot of UX, our UX is super super super super complex. Do you want to maybe expand on why? So as I maybe hinted earlier, one of the products I work on is essentially some extension, the add-on, which is essentially for software developers, also for QA people, sometimes used by all kinds of other personas, and it's a product that essentially serves a variety of personas, a variety of use cases, and provides an answer to essentially many things, which creates a very, very big challenge — meaning, how do we make the user who arrives and opens this product, for the first time, understand what they need to do, how do we essentially remove a lot of noise for them, meaning create some logical panel for them, like, within the product — and this is a product where, many times, accessibility is not something people want to do, they're developers, they don't get up in the morning wanting to do — whoa, I feel like just checking for a second that this feature, the feature I made, is accessible — they don't want to do that, kind of, usually — so how do you turn this experience into, let's say, something manageable, or less hard, how do you even explain these concepts to them, like, as a developer I didn't like accessibility, like I have to do it, it's this ancient thing imposed on me, and all these concepts, what is a screen reader, what is a screen reader, what are these things — I didn't understand. So how do you turn all these things,

Eyal David: [14:54] into something you can deal with — it's complex. There's another thing here, in a bit we'll also talk about your challenges, but the tools also need to be accessible — that's one of the significant challenges in the UX there.

Oded Hutzler: [15:06] Yes, we don't want to be the barefoot shoemaker — like a cyber company doesn't want some security breach suddenly found in it, so an accessibility company also doesn't want people suddenly saying its products aren't accessible. So I think actually, one, it's a very, very, very, very big challenge, to be accessible, especially in products like these, these are products that have tons of kinds of interactions, and a lot, a lot of difficulties, which I won't start getting into, but this challenge is a lovely challenge, because I think a lot of people are familiar with the concept of mobile-first, for the sake of argument, first doing design or planning for mobile, and after that for web — so there's something too, it's not necessarily what we always do, but kind of always some accessibility-first, meaning always thinking about the person, about some, for the sake of argument, the user flow of that person with low vision, meaning how they dealt with our system, and take it from there, many times, not always, but many times we see that essentially things that are done and benefit people who have some disability, also benefit regular people, like me and you.

Eyal David: [16:22] There's also, it's important to say, business value to this — meaning retaining the customer, there's essentially significance to the tools being accessible.

Oded Hutzler: [16:30] Absolutely, and accessibility is also kind of a community, meaning it's a community, and the moment you're there, like suddenly they'll find out about you that you're not accessible, or they'll say about you that you're not accessible, it can also be a problem, meaning you have to meet a certain standard. Amazing, I'm sitting on two questions,

Eyal David: [16:44] and I have to ask you, before we continue. The first question, as someone not young,

Oded Hutzler: [16:50] AVG — were they remembered because it was always free? Wow wow wow, you're taking me back, AVG, remembered, no, AVG was bought by a competitor, called Avast. Right, they were the second one that always popped up for me. Right, right, right, really, those are two veteran companies, Avast bought them, and AVG was a distributed company around the world, it had tons of sites, it had one in Israel, I think in Australia, in America, lots of places. Avast is a centralized company, it had broadly just one site, I think, in Czechia, not in Prague, or yes in Prague, I don't remember. Okay, so they didn't die. Anyway, they closed. But maybe you can expand. So yes, as I said, really, UX is quite a challenge, also essentially, as we said, the accessibility, and also UX itself. A second challenge — our products, I won't say they're unique, but we don't have that many to learn from, meaning we do, many times we go to all kinds of parallel fields, and try to learn and understand, how to actually make our products better, or what exactly to do. But it's very hard, we don't have that many to learn from. And the third challenge is people, as usual, it's always, I think, always a challenge in every role, no matter what, even just — it's a challenge in living, but certainly, certainly in this role, meaning, you're essentially kind of a manager without authority, like, for the sake of argument, and you need people to love you, or it's advisable that they like you, and sometimes it doesn't go well, meaning, you don't always do things that people will like, because sometimes you have to tell people no, sometimes you have to call on people to do things they don't want to do. And sometimes you have to spot bullshit.

Eyal David: [18:39] And sometimes you also have to spot a bit of bullshit, yes. So let's take the topic of bullshit, focus on it, let's start simply, essentially, so how do you spot bullshit? Or let's first define what bullshit is, essentially.

Oded Hutzler: [18:52] So what is bullshit? One can be — there are tons of kinds of bullshit. One is that you get an inflated one-time estimate from some developer — a developer or any person, not necessarily a developer, maybe from the designer, suddenly it could be, no, this'll take me a month of work. So how do you spot such a thing? So with developers, honestly, since I'm a developer, then with the frontend it's pretty easy for me overall to understand when they're pulling one over on me and when not, and honestly, precisely because I have this advantage I sometimes prefer, not to use it, meaning not to come and say it seems to me you're exaggerating, unless it's really excessive, and in other places, when the estimate is exaggerated, you simply have to start talking to people and understand what the story is, and sometimes break it down, get them to understand that they're exaggerating.

Eyal David: [19:48] Because what's the cost of it — of spotting it?

Oded Hutzler: [19:54] There can be all kinds of costs, but I think for starters, your planning can change as a result of an under-estimate or an over-estimate. Suddenly they tell you some feature is really really important, it's huge, for the sake of argument — it could be you'll decide not to do it, and it could be that some very very important feature you would have done if it were a bit smaller, more compact. Suddenly breaking features, bringing forward your MVP even though you don't want to bring forward your MVP, all kinds of things, tons of costs.

Eyal David: [20:24] There's also an issue of time and money here, right? It's all money in the end. Definitely, yes, a lot. Tell me, and why in product specifically is it such a thing that keeps recurring — the topic of bullshit and spotting it — compared to other professions? Why isn't it like in every profession?

Oded Hutzler: [20:40] I think here you simply work with tons and tons and tons of stakeholders, and you don't have — and ostensibly the knowledge you have, meaning you know a little or don't know a lot, like you don't have, how to say this, expertise in all the things. You're not — now, you're not a designer yourself, like maybe yes, but you're not, you're not a developer, and you're not, I don't know — say, in our domain I'm not an accessibility person, meaning for the sake of argument, although I learn and I absorb, and I specifically know a bit of development, but I'm not an expert and I can't come and tell them, like, listen, you're wrong.

Eyal David: [21:17] Because you also mentioned earlier the topic of staying likable — so how do you stay likable while also spotting bullshit, right?

Oded Hutzler: [21:26] So one, I think, by the way, unlike many — let's say, also friends of mine and acquaintances in the field who know how to see fast — I usually need time to process, meaning someone who suddenly tells me this'll take me a month, I won't tell them right away, it didn't come to me automatically, like, what, what are you talking about, there's no way it'll take a month. I'll need, like, after the meeting ends, then suddenly I'll start thinking and reading and understanding what I do with this month. And many times there are all kinds of reasons for why a month, and you need to break it down, you need to understand — like maybe he thought, maybe he didn't understand our task correctly, maybe talk to his manager, maybe he doesn't know everything well — I won't say everything, but he doesn't know — maybe it can be done differently and he's not thinking about it at that moment, and there are all kinds of ways to break it down, essentially. After all, I also come from a development background, and at first I really was calling the bullshit, and I learned over time that it really doesn't contribute and doesn't help. Because, as mentioned, everyone comes in good faith — I brought it up to be really practical, so, well, right, on the other hand it's also not my job to come and offer solutions or start and say — so this thing of really breaking the thing down and thinking together jointly, that's really also what works best for me.

Eyal David: [22:44] So do you have some story you can tell where you actually spotted bullshit and thereby saved the organization from wasting time?

Oded Hutzler: [22:51] Honestly, it's a waste of time and maybe also a headache. So yes, honestly, there arrived some, let's say, this case is pretty painful, it's essentially some false positive. Again, especially in our domain, in any domain probably, certainly say in medicine, because in the end in our case, a developer will come, he'll sit on it, he'll waste his time, and he'll be frustrated, he won't find anything, everything will be fine, he'll come back to us, there'll be some ping-pong, and it'll also lower our credibility, it'll also frustrate the developer, and in the end it can cause, bottom line, it can cause people to not use our product anymore. So really some such problem arrived, I raised it, we found that it really — like, we really did verification, we found that it's really the situation, and the developer broadly sat and told me, unsolvable. Meaning, he told me, unsolvable, maybe I can solve it partially, but it'll take me roughly something like half a year, and even then you'll have all kinds of problems, and that's it, somehow he wriggled out of the story a bit, I was left with doubt, because I didn't know — one, this is a very senior developer, meaning, I took his word, he says it's unsolvable, but then I started to think a bit, and I started to search, and I started to look at other tools, why other tools don't find it, and it's fine when there are other tools that don't find it, there are all kinds of reasons, but I said, I don't know, something still didn't feel good enough in this story, and it took me a bit of time, but at some point I said, okay, we need to sit down, we'll take a few people, each in their field, all kinds of specific people, and I managed to kind of bring them to a meeting, even though there was resistance from that developer, meaning, that developer said, I don't want, meaning, I know what I'm talking about, and not willing — in the end, somehow, I managed to gather them all into a meeting that in my view was solved within fifteen minutes — one of the people there said some line of code, said, sure, it's a small thing, like two minutes; two days after that, this thing was solved, shipped of course to that customer, and the bug was fixed.

Eyal David: [25:21] That's first of all cool that you shared, and cool that you caught it. Essentially what worked for you, if I understand correctly, was first of all creating that meeting, and essentially talking about the thing in a wider forum. Always. And you also beat his ego, right? That's also something that happened here. It's hard for me to say I beat his ego. No, in a good way — like, he came with some ego. Right. You said he didn't want to come to this meeting. Right. Yeah, like, just,

Oded Hutzler: [25:48] I don't know if I won there, yeah, but at the end of the day, yes, I managed there, let's say, to get him to understand that it's worth it for him to meet, to sit with other people — by the way, it worked, after that it actually contributed, because actually after that, suddenly on other topics, problematic ones, we didn't get to — like, we didn't so much get to situations of this can't be solved anymore, and we actually got to situations of faster, well, I already talked to, and so on. Amazing, so essentially you managed to raise his accountability. Absolutely, and also I think his productivity in the end,

Eyal David: [26:21] like. That's for sure, and you kept the customer happy, and so on. Are there more things like this, because we're talking a lot about developers, and, you know, there are stories of developers, that essentially you arrive, like you said, some feature, and then you need to stop it, essentially, like, thinking together. So how would you manage such a process now, if now, you know, I'm a developer, you come to me, and you present me essentially your feature, and like — so it's not a bug this time, but like, I tell you, I don't know, it'll take two months, and two months doesn't sound right to you, so how would you approach it?

Oded Hutzler: [26:51] Usually, again, it'll always probably be usually — one, the conversation, it'll be a conversation. Let's go to a place, say, where the meeting happened,

Eyal David: [26:58] the meeting ended, you're ready now to go at me. To go at, that's it,

Oded Hutzler: [27:04] yeah, no, no, to go at — never, ever. It'll always be a conversation, and it'll always probably, probably we'll involve another person, like, just from the domain, we'll try to come out in a pleasant, cool way, like, let's hear more, to see how we actually break down this problem, and also we'll listen to other suggestions, like, usually the developers will come and give some, let's say, a counter-suggestion, but they'll give all kinds of these, no, you can't do this, but you can do other things, and then to see, maybe actually you can approach from the middle direction, and see how from the middle direction, maybe, to reach the solution I wanted in the first place, or not, maybe I'm wrong, it could be that a solution I'm proposing is not a good solution, like, I don't have — honestly it's not up to me.

Eyal David: [27:47] You know what I've noticed they do in the development world in such a case? If a manager simply hears out their employee, or something in that style, yeah. So they'll propose some idea, and then say, okay, go do a POC, come back, and usually that solves the matter, because then they discover the thing is much smaller, right? Yeah. So that's also something you can do. Tell me, and what do you think about self-bullshit?

Oded Hutzler: [28:10] We as product managers. So yes, when we talked earlier about bullshit — so many times it's to attack, like, right, everyone has bullshit, but many times it's your own bullshit. I think that's actually the place that's hardest to attack, many times. Like, a lot, I don't know how — all this, preconceptions, or all kinds of assumptions you carry with you, that you need to shatter, and it's uncomfortable for you to shatter, it's you against your own ego, it's you against some product, or some, something you built in your head, you said, this works, this is how it should be, and you suddenly understand that no, it shouldn't be this way. Like, probably not, maybe you're wrong, and it's hard. And what are your ways of dealing with it? Like, how can you — I think that, a, over time, you improve at it. You tell yourself less the bullshit, especially if you work in the same domain, or the same product. So I think an iterative process, usually, like, it'll come, and maybe will minimize the amount of bullshit there is, meaning, that from the start, you'll do some thing, you share it with people, with a developer, with your manager, with your colleague, with you, Eyal, or with someone else, you'll show them, you'll get feedback, you'll already from the start cut off all kinds of assumptions you have, that you might have, and that might develop for you in the process. And you'll refine yourself, essentially in this process. So essentially you're saying, features,

Eyal David: [29:31] and iterations, iterations, iterations. Yes. By the way, it's something you can also do with GenAI, because you don't feel like going out at all to...

Oded Hutzler: [29:39] Right, right, you can do it with GenAI — I'm crazy about GPT, I still think GPT is great at all kinds of things, I don't know how critical it is. And when you catch bullshit, probably it's also advisable to get off it as fast as possible, again, from my experience. Bullshit with myself. Yes, yes, even if I already, you know, went and marketed it in all the courts, it's really advisable, because otherwise it bites you, and you regret it. How do you base this thing? Absolutely. And also data is probably something you can hold on to, like this, to minimize bullshit. You can also look at data in all kinds of ways, right? And produce bullshit. That's also true. Data can mislead.

Eyal David: [30:24] And let's talk about bullshit versus design, for example. Yes, honestly here I think,

Oded Hutzler: [30:30] when I think about bullshit versus design — actually there, design or UX, all kinds, this whole world — actually there it seems to me one of the places that contributed to me spotting bullshit,

Eyal David: [30:40] is, I did a master's degree actually in human-computer interaction. Whoa, dive into that a bit. We ran through your bio really fast. Dive into that a bit. Where did you do it?

Oded Hutzler: [30:48] I did it at the Interdisciplinary Center, at Reichman University. Was that when you were a developer or before? That was already when I was a PM. Cool. Essentially in my first year as a PM. It's essentially a degree that combines psychology, UX, and also a bit of programming, and essentially talks about how you create good products for humans, not necessarily digital ones, also really physical products, like some toy for a kid, how you make it — also cool, also so the kid immediately understands what they need to do with it, and also that the whole shipping process, from the factory for the sake of argument, until it reaches the kid, will be, let's say, as short as possible, as easy as possible, as efficient, economical. Overall it's very very interesting, and it's multidisciplinary, meaning, really like the role, and I learned a lot there, tons, a lot of the world of design and such, and actually there I understood, many times designers can talk to you in theory, meaning, the moment they start talking theory to me that's not connected to reality, or say things not based on theory, saying, this is how it should be, this button should be red, because red, because whatever, and whatever, doesn't matter, or you can't do this, this is what, say, I want to do — so actually there, the degree gave me all kinds of tools to base my decisions, meaning, yeah, but actually with, maybe also on theory, maybe with data, all kinds of things like that, and essentially to understand when they're just telling me something, and how to attack it too. Because it can be very time consuming, right?

Eyal David: [32:17] Essentially all the processes, no matter who you do it with — so essentially with design, unlike development, do you also create such a meeting?

Oded Hutzler: [32:25] One, like you described with that developer? So there, again, it's slightly different stakeholders, but there, you know, design is, let's say, people much more love to give an opinion on design, or everyone has an opinion on how the design looks, so there you try to, you know, move it in the direction you want, steer the ship, if you think you're right, and sometimes you're not sure if you're right or not. And it's also really, say, a world I'm a bit less — like, I didn't come from design, for the sake of argument.

Eyal David: [32:55] So you need to understand if you're — whether the design is simple, and also at the end of the day, like also versus development, you always choose your battles. Absolutely — maybe it's also something worth talking about in the context of product, but I'll tell you what works for me, two things: of course experience, and — I'll touch on it, but one is to stick to working patterns, I saw a product I know, and it's good, and that works in a certain way — that's a great argument, and usually they'll also be similar to it, so you can argue with that, and two, producing a POC here is really easy, right, compared to development. So producing two variations now, and going to sample them on people, like you described, that's simply gold. Right. And you can also, you know, if you have some design partner, then you can totally involve them, and get real feedback. Absolutely. There are even platforms today, right. Like, user testing and all those, where you can upload, and really give a scenario, and you can get essentially opinions of users, that's really gold. And also, GPT. Right, you can upload — that's true, that I also tried. Right, we started doing that recently. Where you essentially upload a file, and it'll give an opinion? Both it gives an opinion, and you also ask, you describe to it what you want to do, it proposes what's the most correct way in its view, and sometimes you agree with it, or sometimes not. Yeah, you didn't manage to get any good enough feedback? What, from GPT? I think its feedback is general. And you use — it depends which model you use too, right? That can also be, yeah. Using four, but, I don't know, sometimes I just feel it's a bit too nice. It's obvious though that this field is naturally improving. What other uses do you make of GenAI tools? I think the tool, or essentially one, of course, of course, copy, microcopy, or English in general, you know, like to fix up English with it, if we want it to be something, a customer, I don't know, an announcement, all kinds of things like that, I pass it through GPT. And two, brainstorming. I think it's amazing, amazing, amazing, amazing, at giving you all kinds of ideas, connecting things for you that you didn't think of, opening the mind a bit. Amazing. I want to go back a moment, today you work at a startup, of a certain size, before that you worked at Microsoft. How different is the bullshit that you were exposed to at the two organizations — again, Microsoft, just for context, an organization that size, how different is it? Wow. Okay, there I worked as a developer. You supplied the bullshit. I supplied the bullshit. That's true. I think there, really, if I look at it, also there, we gave bullshit. Meaning, we were — there are reasons, yeah? But yeah, totally, it exists everywhere. How did they deal with it there? How, say, did they break down your bullshit, when you came with it? Do you remember? Yeah, so also there, again, I think it's the same method of conversation, of talking — suddenly talking with someone else, who gives you a counter, to the point — I'd suddenly get to manage with, talk with the team lead, there the team lead would suddenly say, what's this, and they try to find some solution in the middle, or a workaround, or all kinds of things like that. Although sometimes you, after they did a mitigation to your bullshit the first time, you already learn that... you get wary. Exactly. Yeah. Interesting, cool, I hope we'll all be better now at spotting bullshit and maintaining relationships. So it was a great episode, Oded, I really enjoyed it. I want to ask — usually, when we wrap up the episode, I ask, essentially, where are you — what do you wish for yourself in ten years? So first of all, to be happy, I think, that's the most important thing, certainly in a time like this, and certainly when work takes up such a big place in life, there's nothing to do in the end, I don't know, nine hours, ten hours, I don't know, depends, depends on the day, maybe more sometimes, so definitely, to keep working with great managers, because that's super important, an expert environment, and that I'll keep getting up overall pretty happy to work. I wish you that too, and I have one more small question. Sure. Why is it worth — this is already less personal — why is it worth coming to work at Evinced? I think Evinced is the first place that I — one of the people — sure, great, everyone says that, but I really think we have great people, but really, it's to get up — when people ask you, where do you work, and you say, I work here, I work there, I work at this — and everyone looks, thinks with you, what do you do in life, and this, I don't understand, no one understands, people always ask, you don't understand what they want from you. And that you work — and there aren't many places where you can come and say, I ultimately help — right, we do it for money, but I help people with disabilities, I help people with low vision, I ultimately help everyone use all the products, that's not something you can say at many companies, so — and also, overall it's a company in a very good state, we even have great people, we have very very very very interesting challenges in all the fields, whatever you want, mobile, web, even at the design stage, right, also in Figma and also AI, important to say of course, we also do AI, and quite a bit. That's essentially the metric you're measured by — it's to improve the world, so maybe in ten years it'll be perfect, but it definitely contributes, it definitely contributes, no doubt. Amazing, what fun that you came, Oded, thanks for inviting me, with pleasure, it was interesting, come on, bye for now, bye. Hey friends, thanks for listening. If you found this podcast valuable, you can subscribe and follow us, of course, for more episodes on Spotify, Apple Podcasts, or any other app. Of course, if you didn't find us on some app, I'd be glad if you write to us, we'd be very happy for five stars on any platform, and that you follow us so more listeners can discover us and find the podcast. You can also find the previous episodes on any app or on the YouTube channel, we have links in the description. Until next time, come on, be efficient, and bye bye.