Transcript: Ronny Maate Keller | Vertice | How to Avoid Getting Stuck as a Feature Factory and Stay Strategic as a PM

Host: Eyal David · Guest: Ronny Maate Keller · Back to episode

· Updated:

Ronny Maate Keller has spent 20 years in product: a developer who moved into product management at 888 (Random Logic), Payoneer's first VP Product, Cybereason, third hire at Mesh Payments, and today CPO at London-based Vertice, a startup that helps organizations manage their SaaS stack and vendor negotiations. In this episode she talks about the gap between why we got into product, to move the needle, and the day-to-day of maintenance, regulation, integrations and edge cases. She details the skills that matter most to her (openness and flexibility, deeply defining the problem and the customer, understanding go-to-market, and enough grasp of the architecture), how to challenge founders without becoming "the douche in the room", how to measure yourself during audit and compliance periods, and why to ask before any move what the day-to-day will look like. She closes with Payoneer's IDC project, incremental KYC data collection that shortened customer approval time.

In this episode

  • Even a "tactical" feature is a strategic opportunity: if you understand why it was requested, you can challenge the approach, find a shorter, smarter version and tell the story. And if there's no product you're building strategy for, you are the product.
  • The four skills Ronny looks for: open-mindedness and flexibility, deeply defining the problem and the customer (in B2B there's the decision maker, users and sales), understanding go-to-market, and enough grasp of the architecture to be pragmatic.
  • Challenge without being "the douche in the room": don't challenge everything, only what you understand deeply. At Mesh the team built a light version of expense reimbursement instead of a by-the-book one, because the goal was not getting disqualified in RFPs.
  • The feature-factory feeling recurs at every seniority level: a CPO too spends months on SOC 2, audits, shutting down a country or a key customer's edge cases. It's part of a mature product's life cycle.
  • In 0/1 periods like an audit, personal success lies in efficiency and engineering: distill the minimum, make the team a partner, and build genericity or feature flags so you respond faster next time.
  • Before a job move, do due diligence on the day-to-day: which team, B2B or B2C, regulation, real time, company stage, and whether there's any methodology at all. The same PM title looks completely different in every company.

Intro

Eyal David: [00:00] Hi, Ronny, how's it going? Hi, all good, how's it going? So today we have Ronny with us, the woman from London. How long ago did you move? A little over a year ago, in August 24, yes. Which is basically the time you've been CPO at Vertice, right? Right, literally two days ago I hit one year at Vertice. Excellent, so you'll tell us about Vertice and we'll get to know it a bit more, but let's talk about you for a second so we know who we're talking to. So Ronny, I'm kind of debating how to introduce you, because the list here is really very long, but do you want to give a brief, run through it and tell us?

Ronny Maate Keller: [00:37] Yes, I'll try to keep it focused. So I've been in product for 20 years, give or take, and I've been lucky to work at successful companies. I started at the very beginning of my path, I was a developer for not very long, and early on I decided I don't want to compile another line of code in my life, and that what interests me is talking about the what and the why, and less about the how, maybe. At the start I began working at a company that was then called Random Logic, many know it later as 888, as a product manager, that was my first product management role, actually on 888's back-office systems that dealt with risk, customer service, promotions and payments, and that's basically where I grew up, and it was the best online school in Israel at the time, everything was measured, every breath of a player and every bit of theirs, and I basically grew up there, I grew up there in highly regulated worlds, in worlds with tons of data. From there I joined Payoneer when it was already a successful company, which has since raised more than 50 million, and I joined as Payoneer's first VP Product, that was in 2013, and I basically grew with the company for almost 5 years, through a very very fundamental change, from a company that was financial services to a company that became product-led, global, that moved from B2B to B2B2C. I learned a ton, I built the whole product group there, and after that I moved on to the cyber world, at Cybereason, because being an Israeli in technology and product without doing cyber, I guess I felt that can't be, and I really really wanted to, and they approached me then after Cybereason was at its peak, after a 100 million raise from SoftBank, and I joined. I was there a relatively short time, because the person who later founded the company I moved to, Mesh Payments, convinced me to move back to the fintech world. And at Mesh Payments, after more than 10 years of career already, I moved to an early-stage startup, third hire at Mesh Payments, to lead product, with no customers, no product, building everything from scratch. I went through three funding rounds with Mesh Payments, over a hundred and five million, and from there I moved to Vertice, where I've been for the last year. Vertice is a company in the procurement-tech world. So for those who don't know, Mesh Payments does what's called P2P, procure-to-pay, and Vertice does the earlier part, the negotiation part, it helps companies manage their SaaS stack. Each of you uses SaaS, from Figma to, you name it, basically everything we use, OpenAI of course, and companies, every year SaaS spend and tech spend gets added, and if you don't manage it, don't manage renewals, and don't negotiate efficiently with the vendor, it just keeps getting more expensive and going up, and lots of tools or modules we buy and pay for without anyone using them. So Vertice comes to put things in order, and to help companies manage their whole SaaS stack much more efficiently, to run an organizational approval process, because many products of course have exposure to data today, so in their procurement process you need to embed all kinds of security processes, legal of course, and also start renewing on time, because just imagine, if you go to Salesforce and the renewal is tomorrow, you have no leverage to negotiate. Maybe Salesforce isn't a perfect example, because Salesforce today is kind of a monopoly, but there are lots of companies where it's very very significant when you even start the negotiation. Vertice helps with that, and also with managing all of this orchestration, and beyond that also with doing the negotiation itself.

Ronny's career path

What Vertice does

Eyal David: [05:33] Excellent, wow, we ran through that really fast, I hope you have some air left, I jumped in so you could breathe. So basically, really, a long list, as we said, you mentioned it too, you've worked in different industries, in different roles, and at different company sizes. You said it, I was once alone, and I started hiring, and in the end I was in charge of 25 people, right, you said, or I read it, and then?

Ronny Maate Keller: [05:57] Yes, at Payoneer it grew from zero to a group of over 25. So I'm fine.

Eyal David: [06:03] Oh, over. Okay, excellent. And then basically, we talked, okay, there's something you see recurring again and again among product managers, and we want to talk about it, but just a second before that, it's nice first to say about Vertice, what I really liked about the business is that it's about as AI-resilient as it gets, no matter how much AI improves and so on, the business model holds and the need exists, I really liked that. So do you want to tell us, for a second, what we're going to talk about today? Yes,

The feature-factory feeling and frustration in product

Ronny Maate Keller: [06:35] absolutely. So I shared with you that along the way, over the years, I hire a lot of product managers, I talk, I mentor a lot of product managers, and one of the things I feel doesn't change, and here, AI-resilient, it's totally AI-resilient, is a certain level of, let's call it, frustration or gap that product managers experience. Because a lot of product managers, a question I ask in every interview by the way, why do you love being a product manager, or why do you want to be a product manager, and there are tons of answers, but the answer that repeats itself is that people feel that as product managers they'll be able to contribute, to move the needle, to contribute to the company's strategy, and to make it more successful of course, more selective. And basically a lot of product managers, day to day, feel this gap, or this frustration, that they don't feel they're really contributing to the company's strategy, or they're not strategic enough, or don't have enough impact, and then they experience a kind of frustration of becoming a feature factory machine, that actually sounds a bit nicer, but it's a feature machine, and sometimes they don't even fully feel connected to the company's bigger vision. Especially product managers who, say, work more on the back end, or on the company's back-office systems, or things related to integrations, things that maybe aren't at the cutting edge, aren't the sexiest things that turn the company into one with a very big differentiator, not some feature now that knocks everyone off their chair, but something that might even be more of the same, that other companies and other products already have. And suddenly I find myself required to do that, and then, is this really why I became a product manager, to do this thing now? It's something I experience personally too, sometimes I even look at it this way: okay, I'm really really focused now on succeeding together with my group in delivering something that's very important, and many times holding that gap, and being able to focus and deliver the value, it's not always that you wake up in the morning and it's clear to you that this is really what creates impact.

Eyal David: [09:18] Right, that's basically how to manage it. Let's put a notch on that for a second, and I'll ask you, what in your eyes are the most important product skills in product people, product managers? So that's a great question,

Core skills: openness, problem, customer and go-to-market

Ronny Maate Keller: [09:33] I think for me the most important is first of all open people, open-minded, sorry for switching to English like this, but I think it's really important, especially in our era, the ability to adapt, to other opinions too. Meaning even if I thought I came with an idea that I think is truly the height of perfection, to be able to contain other opinions too, to understand, to think outside the box, to change all the time. So I think flexibility is really really important. Second, the ability to define the problem and understand it, and no less our customer, and in B2B worlds our customer is always more than one customer, because there's the decision maker and there's the user, and often there are also different types of users. So for everything I do, it's really really important for whom. And truly many times there are lots of things we do that are actually to help the sales process, and in the end no one is going to use them, and that's totally fine, but as long as I understand that. So understanding go-to-market is really really really important. I think understanding in general how it's going to be built, even if in the end I don't understand, you know, exactly all the technology nuances, but roughly what the architecture is going to look like, I find that very important for product managers, in order to walk the talk with the people who will eventually build it. And also many times you need to be really pragmatic, because you think of some idea, it's excellent, it's amazing, but in the end building it might be really expensive, and for that maybe it's worth making lots of compromises, and without having that dialogue and some degree of understanding of the architecture,

Eyal David: [11:41] sorry, it's hard to manage. In the end you need to translate the business needs into product, in the end it goes through technology, what can you do? You need to understand what costs how much and how to approach it. So without really those details, that context, you can't manage that kind of dialogue, you can't represent it, you can't challenge it, argue about it or whatever, in order to reach the most fitting solution. And I really agree with you, tell me, on pragmatism, of course as product managers you strive toward the goal, the goal of why we gathered, and there's always the why. But you can be pragmatic up to a certain point, right? There are places where in the end, at the end of the day, you also want to express yourself, right? And then the issue comes up of, you gave a really good example in our prep call, we talked about someone who works at a startup, and now the founders already have the whole vision in their heads, and they know what they want to do, and then okay, I'll be pragmatic, and I'll go with their vision, and then as you called it, I'll be an executor, a feature factory, but what do I get out of it? Because where am I headed? How can you look at a situation like that? So I think, one,

Ronny Maate Keller: [13:07] whoever works in product needs to look, on the one hand of course at the product they're delivering, but also a bit at the product that is themselves, right? Because as a product manager, how am I developing, how do I think about the problem, what do I need to solve, beyond of course what value I'm going to create, also what's my value, or what am I learning, or how am I going to do things more efficiently, or how do I learn new things. So I think all these things, again, don't contradict pragmatism, but live together with it in a very complete way. So yes, I think it's really, and I said it too, what's important in a product manager, maybe as the first thing, is open-mindedness and flexibility. So I think even if they told you now, and I'll give you a real-life example, for that matter at Mesh, one of the two, it was really clear that we write to the ERP, and we sync transactions to the ERP and so on, and part of this month-end thing, you need to create some memo, a memo for each transaction, and there was a feature that needed to add that ability for users. But there were many ways to maybe get there even before doing that, and maybe to create more value in other places. So for example, if I can actually hold a conversation about a transaction, and part of it, one of the fronts of that conversation, will be a memo, and not just the memo touch, maybe it will serve other things, maybe I can do it in a more creative way, but without literally doing add memo, and maybe do it in a shorter way in terms of delivery. I'm just giving it as an example, because with every such thing, almost every feature, if we think about it we'll manage to think of several ways, and in the way I choose to do it, even if you can't call it strategy, in the end there is a strategy about what I do, how I get there, what I'm gaining in it, how I tell it and how I persuade, the whole topic of storytelling, entire paradigms in product management, and truly there are better lecturers than me on storytelling, but in the end if I have some idea of how to handle some capability I need to create, in a way that isn't by rote, and I can explain it and bring people along, then I think I've already gained something for myself, that I managed to lead something, I have an idea. And it may be, by the way, that I brought it, and they tell me it's not good enough, and you know, they take me off it, and that's also totally fine. I think that also comes with experience, and with age sometimes. It's great if I brought an idea and someone else managed to challenge me, whether a developer or of course my manager, and told me it either doesn't meet the need, or it's too broad, or too narrow, that's totally fine, it doesn't hold you back. Really, I also noticed something else here, that you basically said,

Eyal David: [16:51] you added here, like this, first of all, you go here, and basically you understood, in the example you gave, you understood a problem more deeply, right? And then basically you also spread out the unique space that went around the thing, because it's also a matter of, I think I'm pragmatic, but I actually want to bring it down to earth, according to how I understand the matter, and give my personal touch. Again, it meets us, I probably have a higher strategy, maybe I want to prove myself, maybe I want to show I know how to solve, to parallelize things and show them, to show my abilities basically. So I really connect to that. I wanted to ask about the matter of challenging too, that's also excellent advice, you know? Like, fine, obviously we need to be people who adapt, take feedback, improve ourselves, pragmatic all the way, but we can also challenge them back.

Challenging founders and managers without being "that douche"

Ronny Maate Keller: [17:39] Absolutely. I think it's a place that maybe in smaller startups is a more challenging place, because as we already said at the start, often founders, C-level etc. know where they want to get to, or know what they told the board, really, and they have a very very detailed way to get there, because in the end the breadth of the product is still limited, and the team is still relatively limited, so they can be very very much in the details. And that makes product managers, as we said, feel like deliverers and executors, and not owners of the things, or the ideas, or the roadmap at most. Here, at this point of challenging, I think it's especially, I encourage product managers all the way, both the founders and the managers and so on, that even if we said now that we need to do this or that feature, for example, I'll go back to the example at Mesh, where we thought we needed to do expense reimbursements for customers, and it was really something that had tons and tons of questions around it, because in the end it cannibalizes the spend on our card and so on, we don't want people paying out of pocket, it's truly against every company policy too, nobody wants people to pay out of pocket for all kinds of things, and then come and claim it back. But in the end we understood that we must, we must have this feature, to fit the market, and to be able not to get disqualified, for example, in RFPs and so on. And then the question was, and it really needed to be challenged, so what is reimbursement? Is it by-the-book reimbursement, and you go to products in the market that help with expense management, very very structured, and we chose, for that matter, to do it in a way that's much, much more, say, light, much easier for the end user too, and much easier. Meaning, there was a lot of room to challenge in those places too. Maybe the essence is to really understand why I was required to build this feature. Meaning, within the feature factory, if I understand why, it's much easier for me to challenge and come up with new ideas, because if I'm just doing it mechanically, like, they told me to go add a button here, I added a button. Yes, let's really formalize this for a second, so like, understanding the goal,

Eyal David: [20:46] or the business goal, is the basis of everything. Maybe I'll give a tip about that afterwards, but really, from there you can start deriving, and also hold a more substantive dialogue. You also don't want to challenge everything, you don't want to be that douche in the room who jumps on everything and has something to say, but it isn't grounded in anything. So it's really important to understand why things are done. I was thinking about it, I remember that when I was a young PM, I too was a feature factory in the end. Today it's much easier to bring all kinds of things down to earth, things I used to do, I'd do and write stories, and today it's much shorter, so you save time. A lot has also moved to the point that you sometimes feel like a babysitter, because you're also a project manager on the way, so maybe there too you can save time, and then suddenly there's a block of time you can use, because PMs are really busy, meetings all the time and so on. Maybe that's a window you can use to really get to the bottom of the problem, to understand a few things, how it looks, to know the market you operate in, to understand who your competitors are, to do some discovery, even if no one asked. That way you can hold a substantive discussion. And also, tell me, you as a manager, is this something that... this is what you dream about,

Ronny Maate Keller: [21:53] no? Today it's also really so easy. In the past, especially in worlds like fintech, many times, putting yourself in the shoes of your user wasn't so trivial, because you couldn't really, or you had never been a finance manager. So how would you know upfront whether a question you're asking is even relevant or not? Today, because you truly can, one, do market research in seconds, if you just ask the right questions, you can truly simulate, or even, [unclear] and another one, and another one, and another one, and another one, and another one. Do market research in seconds, if you just ask the right questions, you can truly simulate or even build products, again, just to get some idea and a few sets of usability, really within an hour you have a few directions. So from the outset, if you understood the problem, as we said, or sometimes when you don't yet understand the problem but you understand what they asked you to execute, it's much easier for you to get the background, understand, and be able to ask the questions. I think the problem maybe starts sometimes if you really just joined a company, and there are already products and things that happened long before you, and lots of legacy, and now you enter some place where you need to add some feature, or some capability in a world that already exists and also has lots of constraints, whether regulatory, or the way it was built and the legacy written before. And now you say, but it sounds really simple to you, and suddenly you discover it's not so, because whether in the permissions structure or in the integrations structure, with lots of things, that's where it gets complicated because the devil is in the details. And many times I think I experience maybe difficulty, or not difficulty, a challenge really, that you ask questions and they tell you, but that's how it is, because that's how we built it, because that's how it is, and then you can't now refactor the last three years. So those are the areas I think are especially hard. Interesting, right, but there's also the other side,

Working with legacy, regulation and technical constraints

Eyal David: [24:23] exactly, we've had this kind of force of axioms, because you arrive and everyone tells you yes, because that's how this type of user behaves, and sometimes you can get pulled along and say yes, like you said before, you can just go with it, or alternatively, you can do your own discovery, you can do the challenge because it's possible. And also in the technical worlds, I don't know, it happened that I challenged, even when I was young, I also came from development by the way, which sometimes helps you when you lead technical discussions, that's what I discovered over time, but there too I found myself fighting, not fighting, but somewhat challenging technical axioms, and yes, sometimes, wow, I was right. Even if they tell you or give you that answer, it's worth understanding the depth, the why,

Ronny Maate Keller: [25:11] it's not enough to hear "because that's how it is," in my opinion. I think a lot of it is also related to the evolutionary stage of the company you're in, because there are many things in one company that is more established, for example, or... and serves many more customers, or already enterprise customers and so on, and there, for many things there's no choice, you need to build some foundation that has to hold what the company does, or there are things where we can't make compromises, because it's real time, because it's transactions, because it's truly things where any error would be fateful. Versus things where I'll say, and certainly in younger startups, where many times we're just, you know, testing the water or looking for signs of a niche, and so let's do something that can really sort of work, let's put it that way, or work only, you know, for certain use cases, and there's no need now to support genericity and make it scalable, but just to check whether the direction is right. Whether it's something that even if, like you said, even if they told me, because I came and worked with systems where, in the end, those who work with them are finance managers or bookkeepers or procurement people, and they're used to ERP or legacy systems, and they love lots of tables. No, not true. In their daily lives they have a mobile app, and they have online banking, and they already use much much more modern tools, and the fact that their experience used to be in all kinds of Excel tables doesn't mean I can't disrupt that. And I think that's actually really important, those are the places where you can buy and win points. Really, we're playing ping pong.

Eyal David: [27:18] I'm also going back to what you said, that one of the important skills is really understanding the technical field you're playing on. So if you get an answer like "it's impossible," it's really good to dig into the details and understand. I remember some case at a client where they told us basically it's impossible, we looked, my team and I, what, why is it impossible, let's understand, and in the end it turned out okay, it's possible, if we hide this risk properly, then you can spend another 200 dollars a month, and this whole event is like completely behind us. So I think there too it's not good to go in and be a pain and go to places where it's really just being stubborn, but there are many places where, if you understand them deeply, you understand what you're trying to achieve, and you're pleasant, that's also about soft skills, then you can understand, and you can be pragmatic, and take it forward. I want to move for a second to something similar but slightly different. Basically we're talking a lot about people, and that's how it sounds to me at least, who are young, who are juniors, but this can show up at all kinds of seniority levels, right, this feeling, and you also said that you sometimes feel this way.

Ronny Maate Keller: [28:25] Unequivocally. I also think we brought lots of examples from B2B worlds too, you know, like, I'll talk with the people and so on, and in B2C or B2B2C worlds, I think the problem space sometimes changes too, and also the product I put on the market, and there are also issues of stickiness and retention and many things worth taking into account. But if I go back to the question for a second, it can show up, I think, throughout the whole life cycle of a product, and at every seniority stage. Because really, if I talk again about the topic of company evolution, at the beginning everything is really really exciting, because you're building new things from scratch, and if they really succeed too, and there's adoption, it's really really exciting, and you feel a lot, and it's really really easy to feel it. For most, anyone who isn't doing a real early-stage startup, or within their company isn't part of, say, a new offering that's really from scratch, then in the end every product manager, or team lead, or director, and also VP Product or CPO, deals a lot, say, with this, almost a kind of maintenance, let's call it, maintenance to mature the product, to keep creating value in it. And if we're in B2B worlds, then many times customers, when they adopt your product and they're loyal customers, suddenly have use cases that are more complicated, and suddenly they want your product to cover more of their edge cases, and you're suddenly required to do all kinds of bits that you decided to do, because the force involved, and you think it will be important to enough customers, and that it even created a differentiator for you, because other products won't do it. But in the end you feel you're dealing with trivia, I'd almost say, because it's really some feature that can be almost esoteric, and it's not a feeling of, wow, I'm moving the needle, really not, rather I'm doing it because this customer is important enough to me, because I want them to be happy, because I want to do the testimonial with this customer, they have an important logo, because retention is very very important to me, and in the end I'm dealing with a feature that's really small. Or sometimes, if I'm really dealing with highly regulated products, then every other day, at Payoneer, suddenly something like, I can't currently issue a prepaid card there, or all kinds of things every other day, they closed Turkey, and now I can spend a month dealing with closing Turkey. That's just an example of course, and it reached me when I was director of product, or VP Product, because in the end it's really really important and really acute, and I now need to change priority immediately, and move all the people who planned to do other things, basically bring everyone to the table and to this focus, and understand why it's important and more important than other things, and how we do it without hurting the plans, or with minimal harm. And you're suddenly required to do lots of things where you really feel, wow, sometimes you really sweat a lot, and you say all this just so they don't shut me down, or so I come out okay in the audit. And that's an understanding that is, you know, also an understanding of mature people, that in the end not everything is fireworks, right? But many times I can find myself for long months dealing maybe with things that I experience as not moving the needle or not impactful, but just to check the box, or just not to get disqualified, or just... It's a really really important understanding, to understand that it's part of the product, because in the end it's a product that has a life cycle, and has customers, and operates in some environment, and if it's a product, as I said, in a regulated financial environment, then we have all kinds of SOC 2 and all kinds of things I need to do for compliance. Connected to the goal, that's probably what drives, rightly, to the big picture,

Eyal David: [33:25] and then you just understand why, sometimes you also need to grit your teeth, I think. Again, with a company with impact, there's a process, there's a process that's happening, and everyone understands it's happening, and again probably someone more senior, and someone will manage it, because there's a risk in just any PM managing it, not just any, but basically it has to happen, right? So there's a big picture here. Tell me, in these periods you describe, or if you need to look, not as a CPO, for a second, at a lower seniority, how do you measure yourself? When you're this kind of feature factory, what, you ticked a check, okay, I delivered this thing and succeeded at it, or do you look, see, absolutely, or how do you actually cope, if for me, say, it's really hard in situations like these that aren't measurable. So that's a good question,

Measuring impact during audits and "grunt work" periods

Ronny Maate Keller: [34:10] like sometimes it's 0 and 1, and then it's really easy, right? Like we needed to close this, how long it took us, how much the deviation was from the original plan or from what we intended, and then it's... even in B2C it's even easier, because there's usually a deadline, or there's something very clear, maybe you can measure it. Now I need to prepare for SOC 2, or an audit, or this and that is managed as a project, simply a project, whose KPI in the end is truly 0 and 1, did I pass the audit or not? Can I continue operating? On a personal level, I think, from time to time you learn how to do it in a way that's more efficient, or more engaging, I think. If you manage to make the teams you work with not feel it's something that really feels like punishment, but rather you manage, let's think, how can we make this more efficient? What, really distill the minimum required to do it, or sometimes even, you know what? I'm trying to go back to the Payoneer days, where I think it was very very prominent, all the shifting of things that fall on you from the sky, and suddenly you must, in China there's something new. So I think there too there was room for creativity, in terms of how next time it happens we'll be able to respond much faster, we won't be surprised. And then you do think whether there's some dimension of genericity I can develop or add here, or some parameter that will let me open or close the door very efficiently. I can, you know, in days when everything can have a feature flag, right? So in those places too, I think there's a lot of maturity, and a lot of ways to measure efficiency. And I think really the feature-flag revolution, that today even at a young startup you don't develop anything without being able to control who you open it to, when, and being in full control of the scope and how the customer will experience it, that in itself gives you, I think, satisfaction, impact and a way to do the thing strategically,

Eyal David: [36:44] even if it really is the most garbage task. Wow. Wow, you reminded me now about feature flags, there's a whole other issue there, let's open parentheses for a second. There are the folks who are much more protective, it's like a side effect that was created, and then until you open it, until it's, come on, take a risk already. So that's also an issue. So basically, what you advise, if I understand from our whole conversation, is: don't let the day-to-day wash you away, lift your head, and try to get the most out of every tactical move, don't let it stay tactical. It always needs to be backed by some goal, and from it I derive my plan, and if I don't have a product I'm creating the strategy for, then I am the product.

Ronny Maate Keller: [37:33] From there I derive my decisions, and that's probably also where I measure success. Exactly like that, in micro-decisions, really God is in the details, in every decision of how I approach the task I was called to. The task can truly be something very high level, like bringing growth from some new market or some new vertical, where it's truly super strategic. And then down to the micro-decisions of how, in the end, I manage to onboard customers from China in the shortest time, or how I manage to close the Turkish market now at the lowest cost.

Eyal David: [38:26] So if you now need to give some advice to young product managers who now also want, like you, to move from company to company, to see different worlds, so in practice, you've really been in a variety of industries. How do you recommend, before going into a job, before making that leap, to maybe do a quick discovery for yourself, to understand whether you love it or not, whether you connect to it, how did you do it, for example? First I think it's really really important to understand that a product manager in every company,

Choosing a role: what a PM's day-to-day looks like here

Ronny Maate Keller: [39:00] in every industry, looks completely different, unlike a developer, for example, or a designer, where the definitions are much much clearer. Meaning, I'll write code, of course in each environment with different people, at a different level of complexity, and maybe even in a technology that's different. In the end it will be the same thing. A product manager, if I enter a bigger company, a smaller one, am I supposed to join a team that deals with internal tools, or with the product itself? Is it a company doing B2C, or a company doing B2B? Is it a company really in highly regulated worlds? Or not, is it a company whose product is even real time or not? Really, really really significant. And also at what evolutionary stage, in the end the pressure levels are different. So if I give one tip to product managers, and I think it holds all the way in terms of seniority, when you're thinking about a company, I think what's really really important to understand, or do due diligence on, is what will my day-to-day look like? Are there really processes in the company, and is it very very important for me to work, for example, with OKRs and a full-fledged methodology? Most likely in young startups or companies in growth, I'll find that less, and methodology sometimes helps, but sometimes it will really, I'd almost say, interfere, because we simply don't have the time, and if you come and want to do it by the book, I think you'll hit a wall, and it will be almost irrelevant. If it's the most back-office thing in the world, I'll describe one of the projects that in my eyes is the most impactful I've done, and people here who were with me during my Payoneer years will attest to it, which was actually a project that was back-office in essence, called IDC, Incremental Data Collection. What happened is we understood that different customers, for example customers in China versus customers in Ukraine, who want to come and open an account at Payoneer, let's say their incentives to provide Payoneer at the sign-up stage with information that ties them to their authentication, proof of address and all kinds of data like that you need to open an account through which you can transfer money, are very very different. Chinese customers would prefer to hand over all the details, including their grandmother's details, upfront, versus, for example, opening from Ukraine or probably any European country, where they'd want to provide those details only when money is actually being transferred to them and they now need to receive that money. So basically we wanted to create a mechanism that lets each type of customer provide this information incrementally, and also be able to see every piece of information they upload, whether it was approved, whether it wasn't approved, whether I actually want them to provide it, to see that it was rejected and so on. And just to give you a sense, in 2013 at Payoneer, service agents would ask via emails, send me this and send me that. Meaning it didn't exist, not through an app and not through our platform interface. And this whole interface of how customers upload documents, where they see what they uploaded, what they'll need to upload if they now want their account, basically their limit, to go up from five hundred dollars to five thousand dollars, all of that was developed in the platform that still exists today. It was one of the most beautiful and most impactful projects, in the end it basically shortened the path to retaining customers, which is pretty crazy, it's one of the most exciting things.

Payoneer: incremental KYC and shorter customer approval

Eyal David: [43:40] That's what you need to remember, that was basically the metric, or the thing we wanted to solve there. Gorgeous, a great story and good advice. I'll ask a question, tell me, you said earlier that you've mentored in the past and so on, if people have questions, can they reach out to you? How?

Ronny Maate Keller: [43:58] On my LinkedIn, with great pleasure. With people, really, all along the way, and also today, with all kinds of career questions. Going to work at this or that company, or preparing for interviews, of course, in full honesty, with great pleasure. People wondering about fintech worlds, I'm very happy to.

Eyal David: [44:27] My experience, so I... you asked earlier, so first I don't need to do any discovery, I'll just ask you, I'll reach out to you, I'll ask if the industry fits me.

Ronny Maate Keller: [44:37] Excellent. And what do you wish for yourself a year from today? I... I feel like all of us, I think, the endless FOMO, that every morning I wake up and something new is happening. So as much as I really try to keep up, truly daily, every day, there really are amazing people with newsletters and podcasts, excellent ones, by the way. I wish for myself, and I really really try and experiment in my daily life, my private life too, to manage myself with agents and talk to myself all the time, talk to the chat of course, and run experiments. So I just wish for myself that I never get left behind.

Eyal David: [45:32] I don't think that will be a problem. What I see, you've also given a golden tip here, to stay relevant, and to experiment and get your hands dirty and all, and that connects again too. It may be that if in the day-to-day you're still doing a lot of things that feel very Sisyphean, that really don't move the needle, maybe this is the opportunity to use these and other tools to at least learn from that experience. So I wish you exactly that. Ronny, I really had fun. And I hope you come back for another interview in a year, because you have a million more topics. Gorgeous, so thank you very much Ronny.