Transcript: Cracking the Root of a Problem — with Eyal Pinko (Taboola)

Eyal David: [00:00] Hey everyone, this is Eyal. This time I spoke with Eyal Pinko from Taboola. I've known Eyal for a long time, and he's an incredibly sharp and smart person. We focused mainly on how to crack the root of a problem — a super interesting episode. Alright, let's get started. Hey Eyal, how's it going? Great — how are you, Eyal? Wonderful. Eyal, it's so great that you're here with us — Eyal Pinko, who comes to us from Taboola, where he serves as a VP. Eyal, let me tell a bit — we know each other. You actually worked with me at my first job in tech, or my second, and you really came from a big R&D background.

Eyal Pinko: [00:46] Absolutely right. A classic product manager — first half of the career in development, second half in product.

Eyal David: [00:53] Really classic. So maybe you could tell us a bit about what you do day to day at Taboola.

Eyal Pinko: [00:59] So today I manage the advertisers' side at Taboola. The advertisers' side is pretty large — my group alone numbers something like 40 product managers and analysts. And the company itself, I'd say, is not small — it's not huge, it's not Google or Facebook, but we have 2,000 employees, with a large part of them on the media side, on the advertisers' side. So yeah, I have tons and tons of areas. Under the advertisers' side we basically have a solution for the full funnel of the advertisers. The advertisers' funnel, let's say, starts from awareness for the brand, then continues to consideration — understanding what this product even does, and then finally to conversion, meaning a purchase, or capturing a lead, or whatever it may be. We have this whole funnel, while our focus is basically from the middle part downward. What does the middle part mean? I mean from consideration — got it — down to conversion; that's where we shine. Where things happen, where the real things happen, where you can measure everything with data — that's our strong zone. That's it — it's a field that isn't based on data... actually everything, everything is data. It's so much data that many times, on the flip side, you have to be very careful of analysis paralysis. Because you have so much data and you can go in so many directions — it's easy to drown. Exactly. You can drown, but yes — everything is data. 'In data we trust' — that's what's written on our wall. Really? Yes.

Eyal David: [02:34] And basically today we'll mainly talk about taking problems and finding their essence.

Eyal Pinko: [02:41] Yes, yes, I'd be happy to talk about that, it's a topic close to my heart, and after, really, I don't know, ten years of experience in product already. How many years have you been at Taboola? At Taboola, seven and a half; in total, let's say net product roles, ten, and I think, from my impression at least, 90–95% of the failures come from a not-good-enough definition of the root cause of the problem. Exactly. Not from the problem definition, but the root cause of what causes the problem. Exactly. And it's a muscle you have to keep training in order to really get all the way to it. It has implications for so much afterward, because the moment you don't start from a correct and scoped problem, the right focus, in the end everything gets translated into work and money and things that might be meaningless. Right, right. And you — I have many examples of cases where we burned a lot of resources, and time of course, and there were resources of very talented people there, and in the end it's because the initial work we did wasn't good enough.

Eyal David: [03:47] Which is basically the PM's responsibility. Yes. So maybe, really, Eyal, tell us — what do you look for in a product manager

Eyal Pinko: [03:54] who comes to you? Excellent question. So look, first of all, since we're already an established and large company, we've gone through many iterations in this area, so we have a set of values, an official one that we made, I heard that in one of the episodes you talked about 'strong opinion loosely held' — that's really a value with us, and of course all kinds of technical checks, but in the end, if I distill down to what I really look for, then I'd say two things. One is first of all around creating value for others. What happens in product management is that in the end you're not responsible for your resources, meaning, you don't manage them day to day, and in order to harness them to the mission, what you need to do, in my view, is create value for them. With every interaction, with every party in the company — PS, development, customers, teams, management, whoever it may be — I come with the approach that I need to create value for them in this meeting. If I create value for them, then it's very easy to harness them. So maybe give an example of that?

Eyal David: [05:12] When you come, say, to really write a ticket, okay, or at some stage where you present it to development and you talk,

Eyal Pinko: [05:22] I don't like to come with a completely closed ticket, certainly not in the early stages — I mainly want to create a dialogue, to show them the perspective, also to get their insight from them, but in the end I'm not coming to decide, 'here, this is how it's done,' it's a joint decision where I try to extract value from everyone who's there. If I meet with customers, say, then I try very, very hard before every meeting to do deep work, so that there are always things you can improve for them. Because you're behind the scenes and they don't know, so there's always some optimization they didn't do, or some expansion — there's no reason to come to the meeting empty, because they always have to leave the meeting with a feeling of, okay, I can now improve performance by, say, 5%, 10%, or I have poten... and then you... you harness them — that's basically what you're saying. Yes, you create a reason for them to invite you again, to talk with you again, to open up, because there's value in it. I can think of more examples. This seems like a really good example to me.

Eyal David: [06:24] It's like a kind of model where everyone is a customer, all the time. Are they all partners or customers? They're customers, and they're partners, both and both.

Eyal Pinko: [06:33] But I want to come to them with the feeling that, for me, they're first of all customers, and I need to serve them. So that's the first thing. And what's the second thing? The second thing is the ability to simplify a complex problem. I've noticed that this is a very common problem among a lot of product managers, meaning, they know all the literature, they're very technical, they know everything, but in the end, most of our work is around finding the problems, defining them properly, and then solving them. Now, to solve them, you have to, honestly, also in the specification process itself, explain them in a simple way. It's part of the service you provide, basically. And I've noticed that it's very hard, it's really hard to find people who do this well, and if you don't do it, then you — it's exactly the opposite of value, right? Because then you create more work for everyone who works with you. They have to figure out what you even want, and why you're doing it. So that ability to take a complex problem and simplify it is critical, critical, critical in my view. And it's really like you say, it's hard to harness people with complex messages.

Eyal David: [07:45] Right, right, right, you didn't do the service. So I have to ask, how do you — you say this is what you actually look for. Those two things. How do you know how to assess a person who knows how to harness others?

Eyal Pinko: [07:58] The problem matter, apparently, you can... The problem matter, yes, you usually start focusing on, you know, either you invent a problem, or you focus on previous problems, and see how he'll deal with it. In the value area, you see it in ideas, it's pretty easy. You see his approach, the work with the other stakeholders, you see his approach, in the idea — meaning, already in the idea, I want to feel that he's giving me value in the idea. You skimped on value in the idea for me. Exactly. I'm less interested in hearing about, you know, his whole résumé — I can read that on LinkedIn. That's not a problem, and I see summaries of previous meetings, and I want to feel like, here comes someone who now gives me value, and I, as a manager, say, of the development department, I see, here, I'll get immediate value from him. So that's amazing — you can even connect it to me arriving at an idea, I solve the problem, and if I solve the problem or present the problem and I've already shown you something you didn't think of because I'm looking from the outside, then you already can.

Eyal David: [08:55] Totally, totally, you can contribute this value from all kinds of directions, but it's an interesting matter of approach. And it's maybe even something not necessarily related to product management — like, it could be that I come with it as a trait or as a...

Eyal Pinko: [09:07] Right, right, I think it's critical in product management, because in the end, again, you don't hierarchically manage any of your resources, and so it's critical, critical, critical.

Eyal David: [09:18] I also remember you, from the work we did together back then — I remember you as this, even back then, offering customers at the time, on behalf of a development company, 'come, I'll look at your analytics and I'll give you value already in the meeting, how you can improve conversions' — I don't remember it.

Eyal Pinko: [09:31] Exactly, that's one example — I always try to make an effort to end those meetings, or also during the meetings, with added value that they have.

Eyal David: [09:41] Wow, what a great life tip, really. Okay, so Eyal basically, like we said, started from R&D — we met together at In-Manage, you were CTO, right? Yes. I remembered, right. And basically before that, before that there was the Animbo story — do you want to tell about it for a moment?

Eyal Pinko: [09:58] Right, yes. Animbo was probably the coolest project I was ever on. So we're talking about 2005, okay? The beginning of Facebook, or damn? Before, yes, really. Really the days when YouTube was also starting. So Animbo was founded by Mori Shner, who was CEO of Keshet, left Keshet, was looking for something else, and then basically connected with a few guys from Bezalel and me, and we founded an animation community. which at the time was the largest animator community in the world, so there was also a very, very large collection of... of animations. We're talking many years ago, there were almost no communities — setting up a community server was quite an effort — and we also built there many tools for creating stop-motion animation, with a webcam, and also more advanced tools, real stop-motion studios, and we did very cool things that were ahead of their time, like for example we did a contest with Radiohead, the 'In Rainbows' album, I don't know if you remember, I remember the video. Yes, so there was a real contest of creating animations for all the songs there, and in the end Radiohead themselves chose the winners, and it was great. It faded the moment that what happened is that YouTube also grew phenomenally, and what it gave you was basically the option to be a channel within YouTube, and Facebook also completely took over the communities, so in the end it... it faded, we probably made a few wrong decisions along the way, but it was two very, very exciting years, and I was the VP R&D there. It was of course a very small startup, we started with five people, when I left we were, I don't know, fifty, sixty, but it was very, very cool.

Eyal David: [11:48] Amazing, and here basically your thing with video began, which continued onward too. So basically afterward in your career you went to work at Convert Media?

Eyal Pinko: [11:57] Right. Was that a technical role there or a product role? First product role. What happened is that over the years, as the years passed, I understood that I'm more interested — like, I really love building things, but I'm less interested in the code quality, or whether the architecture is... You weren't in love with code? No, but I had a lot of fun building things, and honestly a bit before Convert I also did an MBA at the Interdisciplinary Center, which started throwing me toward product — that's, I don't know, 2014, something like that? Yes. And Convert... Convert Media was basically my first product role. They actually didn't work in video, they were some very large ad exchange that gave services to all kinds of parties, and when I arrived they really did a pivot toward video, and it was great, because also what happened is that I arrived with the status of a product manager, but this pivot did require doing very quick POCs, and then great, like, you know, I started raising them on my own. That's exactly your sweet spot. Exactly, yes, I landed exactly on the sweet spot. On one hand, I can raise it on my own, and it needs very quick-and-dirty things, and on the other hand, it was also video that I knew, and it grew very, very fast. And what happened afterward? That's it, so about a year and a half, two years after that, Taboola bought us, and basically we became Taboola's video arm, and then the next role was to basically build Taboola's video product. How convenient. Yes, now Taboola, honestly it's a bit of a full circle, because Taboola actually started as a video recommendation engine, and back at Animbo, I think we were the second customer ever, yes, of Taboola. They started as, you know, you see some organic video now, and then like, what's the next video you'd be interested in watching. Over the years Taboola did a pivot to content recommendations in general, and not necessarily video, and today, by the way, it's the content recommendation platform. The largest in the world — because I can throw out some numbers, it's crazy scale: 50 billion recommendations a day, 600 million daily active users, 220 billion ad impressions a month, it's crazy scale. Daily users — is that considered someone who's exposed to ads, or users within the platform? It's within our network of sites, which is very large today — it's Microsoft, Yahoo, all the big news sites in every.

Eyal David: [14:23] The whole world, so it's a very, very large network. Yes, mmm, and I'm trying to understand, so basically you were in an MBA, you decided you want to be in product, or you learned about product — basically you were magnetized to it, did you plan this path?

Eyal Pinko: [14:38] Yes, I planned. The MBA helped me sharpen it, it was in the innovation track, and honestly a lot of the people who studied with me became product people, or arrived already as product people beforehand, and yes, it was great. So you're aware that the moment I finish this, I'm looking for a pure product role, and it helped, because I had the background in development, together with a bit of an MBA, you know, more general — the combination of the two pretty much opened it up for me. So basically you recommend this path? Yes, yes, yes, I recommend it, especially if you come from development. I think you have, broadly, a few options, but you can try to advance to product roles within your company, if it's a company that's large enough, and... if not, then you need something a bit business-y — like, add some other element beyond development, and say do some MBA, that's a great solution, you also meet a lot of people from the industry, that usually helped a lot, yes.

Eyal David: [15:36] So maybe let's really touch on this for another moment, for people in dev who want — the moment came and they understand, like you, like me, that building is actually less their thing.

Eyal Pinko: [15:49] Yes. How did you reach this understanding? Like, how long did it take? How long did it brew? I'm not a good example, it took me a long time, it took me like 4–5 years, where at first I went into simple management roles, in development, and also honestly, at first I didn't even know there was such a role, product manager — that only started to develop over the years, so it took a long time, but then at some stage the penny dropped that I do a lot more product, I deal a lot more with UX, and with the problems there, and not necessarily with the code, For those, you know, for those who are now in development and thinking of coming over, it's relatively easy, because you can always just take a more product-oriented perspective, try to help more in other areas, bring broader thinking — it's challenging, because it's hard to do that together with your daily tasks, but it's completely possible.

Eyal David: [16:46] And you can also express yourself more during meetings you're in anyway. Right, exactly. And tell me, did you take on...

Eyal Pinko: [16:53] a side project during your period in development? There always was one, but it was usually my own projects. Meaning, I think, up until Taboola, up until the last five years at Taboola, I simply don't have time to breathe anymore, but up until then, always, always, always, I had other things in parallel. Everyone — whatever excites him — I usually did aim it also at projects that in the end bring revenue, because otherwise, if it's general projects, I wouldn't complete them all the way, but I had tons, you know, websites along the way, volunteering, this, all kinds of those, that were in areas a bit different from where I'm at, and that helps me very, very, very much. And that always connected you, basically, the business side, like you say, all the time. Yes, and it also meets you afterward, even if you now know some project, I don't know, I had some comparison of all kinds — well, this is really early, okay, but a comparison of sports lines, or all kinds of... plugins for Chrome — in the end, afterward, this knowledge serves you. Always. Yes, now it's crazy, yes, with...

Eyal David: [18:01] with ChatGPT and all those, it's just crazy the things you can do in your free time. So if I ask you, basically, what's the skill that helped you throughout your career, that you want to mark as the main driver — then it's?

Eyal Pinko: [18:16] I'd say... two. One, the technical background helped very, very much. And that I was broad — even when I was a developer, I don't think I was a particularly good developer, but I was broad, because I knew a whole lot of languages, I knew a whole lot of things. Depth was less my strong point, but that helped me very, very much, because that way I could enter different domains, and always bring value — again — to whoever I worked with. That's the first thing. Second thing, I was simply interested in the broader perspective. Thanks — what, I'll add one more thing. Over the years, it may also be because I come from the value area, I think my working relations with the stakeholders were always very, very good. And it's not always simple, there are a lot of clashes, but I think in the long term it helps very, very much, that you can work with different people, with different skills, and try to solve things and not necessarily keep getting into frictions. Yes, so it's, you know, it's a kind of soft skill that people don't attribute. Yes, so it's, you know, it's a kind of soft skill that people don't attribute. They don't give it enough value, in my opinion, and over the years, you see that many times people advance and reach higher goals, or you can achieve your goals more — actually more than the brilliant geniuses who get stuck and dig in, you know, and don't let go of certain points.

Eyal David: [19:42] That's the efficient way, that's also what I live by, and I really remember you like that too, and I think there's, really — you talked about curiosity — I really remember you like that. Yes. Hit the target. That's also something I think is worth mentioning. Yes. Do you want to tell about your entry into Taboola in a few words, what it looked like?

Eyal Pinko: [20:01] Yes, sure. So really, up until Taboola I was in quite a few places, say 4–5 different places, and I also had tons of side projects, but they were all in pretty small companies, say 60–70 employees. And were you always looking, you bigger, you more... No, actually I really liked that it was small, and you can run fast, and make decisions on your own. Great, so the entry into Taboola was a bit of a shock at first, because we entered a company — although Taboola was much smaller then, but still 600–700 people. It was a shock at first, and also we came to build a product that didn't exist at Taboola, video advertising. So it was a bit of a shock, but I came out fired up, because I did see it as an opportunity. And it was challenging, because first of all, you know, at startups you run really fast, there aren't many processes, there are no QBRs, you know, every couple of days, and we entered a company, we have so many processes — how to plan the next quarter, how to plan the next year, there are QBRs for product, for PS, for all the regions, for all those. Now, you need to know how to work with that, and you also need to understand how to even operate this whole system, meaning, you come to now put out a product. You do ideation, who you need to talk to, how you get something to the field — like, the go-to-market of a company of 20–30 people is so different from the go-to-market of a company of 700 people, I won't even talk about much larger companies. So I had about half a year that was very, very hard for me, but again, the moment people understood that this actually contributes value to them — if this video product gets embedded in more places, then they'll make more money, they'll reach their goals, they'll reach those goals — then things started to open up, and usually, this video product is one of the biggest successes there were at Taboola. I think within two years it grew to 100 million dollars, mostly.

Eyal David: [22:02] That's amazing, and you also sat exactly on the pipe at the best time, like, on video. Right, right, that was — video then... You didn't sit on a pipe, but... yes, grew on... right. And tell me, how was it for you actually, because you said you used to work very not-in-depth, and suddenly you're now a crazy domain expert in the field.

Eyal Pinko: [22:24] Yes, but not-in-depth was mainly in development, let's say. In product it's different. Because it's development, because it's less of an interest. Yes, yes, in product it's different, you do need to go there much, much deeper, but it wasn't... it wasn't a hassle. Yes. Apparently if you're interested in something, then it moves you more.

Eyal David: [22:46] Okay, so let's move on to really talk about the topic. The main topic, which you also mentioned earlier — how do you approach a problem?

Eyal Pinko: [22:53] Yes, so look, again, from my experience, most products fail because the root cause isn't defined well enough. I can give a few examples. For example, we now have — there's some product we launched, I don't know, in August, it's called Maximize Conversions, it's a product that basically allows advertisers to automatically achieve as many conversions as possible. Okay. This product, we launched it in August as mentioned, and it's the fastest adoption growing product in Taboola ever. As many conversions as possible, under the budget we defined. Yes, we're already at 40–50 percent adoption among our advertisers, it's 2 million dollars a day, that's a lot. But, if we go back a bit, we worked on this product for two or three years, and we were really stuck there. What happened, this product basically has two parts, it has, achieving as many conversions as possible, within a certain budget, and it has some other subset — now this is a subset, yes. of how much you're willing to pay for that conversion. Okay, that's target CPA. What happened is, we started, we started from okay, what, what do you want to reach, what, why, how much you're willing to pay for a conversion. And in hindsight, that was a serious mistake. Because, what happens is that the moment you — there are two reasons for this. One, we didn't understand well enough what the advertisers really. What they really want. Meaning, it's true, everyone says, listen, I'm not willing to pay more than $10 for a conversion. But, the question is how much they're willing to compromise at scale. Meaning, if you now bring them 100 conversions at $13, or, alternatively, you bring them 10 conversions at $10, which is worth more? So it turns out that the 100 conversions at $13 are worth much, much more than 10 conversions at $12.

Eyal David: [24:44] I want to elaborate on this in a word, for those who don't know. Why is it preferable? Yes. Because in the end, they, first of all, they don't,

Eyal Pinko: [24:51] the estimate of how much per conversion they're really willing to pay is something very flexible. They're not completely straightforward. And they always have more margin too. And also many times there are elements you're not aware of. Meaning, how did they calculate this thing? Like, if you, say, reach 100 conversions, then they can basically also buy their products much more cheaply. And they also always give you harsher terms than they really are. That's the first element. The second element is also from a development standpoint, when you come to build a product, okay? And you tell it, look, this is all, these are all the options that exist in the world. Now start choosing among them. That's one approach. A second approach is, okay, I'm now narrowing all the options down by a third for you, okay? because these are the only options that even fit this price. Now start choosing for me. So, that's a much, much less good approach. Because you're basically bringing much less data to the models, and you're limiting them in terms of the options. So even when we eventually came to implement, after we implemented Maximize Conversions, which basically tries to get you as many conversions as possible, and we came to implement afterward the target CPA, that target that you're willing to — it was much easier for us. Because when you come from that direction, it's much, much easier. So that's one example. Say another example I can bring, it's — within this product there's some sub-product, that basically tries to help advertisers who don't have enough data. Say you're a new advertiser, you started working with us, and there isn't enough data. And then we, okay, let's find other data — not the data you defined that you want to convert on, in the meantime, in order to accumulate the data. What, an industry benchmark or something like that? No, even from what you report to us, you declared that you want to achieve this, but say you want to achieve purchases, but in the meantime there isn't enough data. Let's look at add-to-cart. We'll have enough data, we'll move to purchases. Great, we defined the problem, we understood, like, how we need to solve it — what's the problem now? We need to collect data, right? These are the two teams — they did work very closely, but they're different. So great, we went out to collect data, and we went to our 200–300 largest advertisers, we collected excellent data, okay? And this process of course took time, and then we came back with this data to the models. And then we said, wait, but the 200–300 largest advertisers, they actually have data. They have a lot of campaigns running with us. They don't have this problem. Exactly, they don't behave that way. Now, this sounds like a mistake, it sounds like something very, very trivial. Of course the real use case was a bit more complex, but here — we didn't catch it. And it stems, in the end, from the fact that we didn't fully define the problem we wanted to solve. Now I sort of said, I defined it already in a more granular way, because I said, it's new advertisers. But we didn't define it fully then, because we said, okay, new campaigns, but no — basically it, the problem is only for new advertisers, who never worked with us. And we have no other data about them. If we had defined it more precisely, then of course we would have saved a lot of work, and probably some frustration too. So what do you suggest? So look, there are tons and tons of methods. I want to suggest some super simple and intuitive framework to deal with this. This framework is called Five Whys. It was invented at Toyota, I think even by the founder of Toyota, some Toyoda, back in the previous century. And broadly, it's an iterative method, of five questions, where each time you ask, Why? Why? Why? Why? I'll give a very, very simple example, okay? Say, the site or some service crashed. So why did it crash? Probably some new version was pushed, because we see from the logs that this crashed it. Okay, why did the new version crash the product? Look, a new feature was released, and probably this feature doesn't use the API correctly. Okay, why did we actually do that? Why did we release a new feature that doesn't use the API? Because there's a new engineer, and he doesn't know the API well. Okay, why do we have an engineer who doesn't know the API well? Why is he new? Yes, this comes back a bit to the curiosity matter. Because we didn't give him good enough training. Why do we have engineers we don't give good enough training? Because the team lead's approach is that we want to onboard people as fast as possible. But there are two things here — one, we need to fix this feature, but the deeper problem is that we don't do good enough training for the engineers. So that's a lot that goes outside the boundaries of the product in this case. Yes, and probably until we fix the root cause — that we don't do good enough training — the problem will recur, and it'll happen more and more. So to work with this method — it's admittedly very, very simple, but there are a few things you need to do. First of all, you need an understanding of the problem. You can't just say, how you do — define it properly. After that, it's worth setting up some group that's cross-functional, so that you can do this 'why' process with it. Preferably they're in the same room. Because say if there were someone missing from dev, then no one can answer. Exactly, so you can't answer the questions properly. During the questions, first of all you need open questions — now I only said 'why,' but it's better for you to phrase the 'why' a bit more precisely, you need to hang onto one of the elements from the answers. You need to listen as much as possible, talk as little as possible, let them. You need to try to constantly challenge the assumptions. Every time they give you an answer, you need to try to challenge it. The answers must be based on facts, not guesses. Because if it's guesses, then you'll get stuck in the same place. That's it, and it's an iterative process. You need to do it several times. And when do you do it? Say, just — now I go out, I understand there's a request from a customer, for the sake of argument. And now I basically start kicking off this process, in order to better define the customer's problem, and maybe I'll also find problems of additional customers — that's something we didn't talk about, parallelizing problems, which is already for advanced people.

Eyal David: [31:10] Totally. If I don't manage to reach the fifth question, I get stuck on the fourth or third question,

Eyal Pinko: [31:16] what do you suggest? So look, it depends. It could be that the problem itself wasn't defined well enough, but sometimes you can stop before that. The question — okay, there's a question of when you even stop. So you stop in the following cases. You can, first of all, if the problem is systematic, meaning, you understand there's something here that will recur, and not, okay, oh, I need to fix this feature. Then you probably haven't reached the root cause yet. Many times when you reach the root cause, there's a feeling of satisfaction, you're like a kind of eureka, like, okay, I understand now. If this problem gets solved, it comes back a bit to systematic — if this problem gets solved, other problems too — so if solving the problem will solve other problems, then that's also a good sign. And also, also, listen, if you reach a dead end, like all the answers become similar, no, there's no additional information, then you've probably arrived. Or you've reached a dead end, or again, it's not defined well enough, or there aren't enough people in the room.

Eyal David: [32:12] Exactly, exactly. Now look, it's not, it's not a perfect formula, right? You need to practice it,

Eyal Pinko: [32:18] sometimes it can also not work. But it's a relatively easy method to penetrate a bit deeper, and you need to come with a lot of curiosity. That's, that's the key. We can take another example, if you want. Sure. Say, we have a problem, that customers abandon the shopping cart. Okay? So okay, why do they abandon the shopping cart? Because the checkout process needs to be shorter. Okay. Why is the checkout process long? Long. Exactly. Because customers need to fill out a very, very long form. Why is it long? Exactly, why is it long? Because our system requires a lot of information about the shipping, in order to do shipping properly. Classic Shopify, right? Classic, yes. Alright, ask the question. The next question — why do we need to ask for all this data? Do we even need to ask for this data? Is there shipping at all? No, there is shipping. That's a good question, there is shipping. But I'll tell you, it's just not... we're in an integration with a very outdated system, that asks for a lot of details, and it's because we didn't prioritize more advanced systems. Okay, so you can ask, okay, so why didn't we prioritize? Why didn't we do an update? Because in the feature prioritization process, we didn't think about user experience, say. Yes. So that's also — you have a bigger problem here, like, you have two problems, one problem is... So let's basically bring user experience into the measurement? Exactly. Okay, so you can solve the billing problem now, but you probably have a more general problem, that you don't think at all about user experience when you prioritize things. Yes. Wow, it's a great tool for management too, it must be said.

Eyal David: [33:58] And I so hate those sites that ask for a zip code. That's what it made me think of. Ooh, totally, totally, yes. Do you put in a real zip code? Yes. Really? Wow, I can't believe I do that. Yes, I go and copy-paste. I never put in a real zip code. I was always afraid it wouldn't reach me. It's two rules. I don't put in a real zip code, and I never give my real email on the Wi-Fi at airports and hotels.

Eyal Pinko: [34:22] Whoa. Ah, at airports especially, they can't, after all it has no meaning, whatever. No, that's true, I got value.

Eyal David: [34:28] You're not on Apple, right? Where? Do you have an Apple device? No, no, Pixel. That's it, now there's continuity, and then you don't give the email anymore, but yeah. No, no, I'm a Pixel person. Cool. I took the value. Okay, we're approaching the end of the episode in giant steps. It was very interesting. Eyal, how does one get in touch with you? If someone wants to solve problems, wants to reach the essence of problems? On LinkedIn, Eyal Pinko. Should we put a link? Right, to reach me. Yes, sure. Cool, and we'll also put a link in the show notes, of course, to Five Whys. Yes. Do you have another suggestion for young PMs? You gave a lot of advice. You also gave advice for developers, but maybe you have advice for young PMs who are just starting?

Eyal Pinko: [35:11] Yes, I think you need to do a lot. Meaning, I see this a lot, say, when I interview or talk with young PMs. I'm interested in seeing things they actually do. Meaning, things they raise on their own. This brings us back to the side project. Totally, totally. I want to see curious people who want to do things all the time. And it's very impressive when you see it. And it's a very, very good signal, and you also learn from it, right? So it seems to me a win-win for both sides. So that's what I'd recommend — recommend, but through doing. You can also read and understand more about how to be a better product manager. But in the end, you have to experiment and do things. And not wait until some company recruits you, and then you'll start doing things. So like, start from the doing and then the theory, basically. Yes, or in parallel. Yes, you can do the doing and the theory in parallel. What do you mean, time?

Eyal David: [36:04] Cool, Eyal. Thank you so much for coming. And until next time, bye for now.

Eyal Pinko: [36:10] Thanks, Eyal. Bye bye.