Productized Podcast · 2026-07-15 · 26 min
Key moments - from our scoring
Substance score
63 / 100
Five dimensions, 20 points each
Rich Mironov, a veteran product coach and author, argues that product teams waste organizational attention by talking to revenue-focused executives in technical language they don't understand or care about. Instead of discussing Scrum, Kanban, backlogs, and architecture, Mironov advocates for "money stories" - simple financial narratives built on no more than three numbers, multiplied together to estimate impact. The first critical story is the ROI story: product teams are profit centers that must earn back six times their annual cost to cover the rest of the organization. The second is the roadmap story, which should lead with revenue figures ($2-5M annually) rather than feature names to prevent executive distraction when customers call with new requests. The third story addresses discovery and go-to-market strategy, warning that faster code development doesn't translate to revenue if positioning, pricing, channels, and marketing aren't aligned. Mironov's core insight is that executives hear only currency symbols; product leaders who master translating their work into financial terms gain credibility, prevent roadmap disruption, and protect their teams from cost-cutting during downturns.
A money story is a financial narrative that product leaders use to communicate with revenue-focused executives who don't care about technical details. It contains no more than three numbers multiplied together to estimate revenue impact, because executives only hear messages that include currency symbols.
Teams should state: 'For every euro you spend on us, we bring in [6-8x return],' positioning R&D as a profit center, not a cost center. This answers the executive trust question of whether product spending generates returns and protects teams from cost-cutting.
Put revenue estimates ($2-5M annually) in bold on your roadmap, then tell executives: 'The roadmap items we show you every three days are worth $2-5M/year, so asking us to drop them for an $80K deal is bad business.' Executives understand that bigger numbers matter.
Code is only part of product; it becomes revenue only when paired with positioning, pricing, messaging, channels, and go-to-market strategy. If users won't try new features or customers can't find them, fast code creates waste, not value.
Executives forget what's on the roadmap within days because big customer requests erase their memory. Adding revenue impact figures to roadmap items gives executives a reason to remember and defend priorities based on financial value, not technical merit.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode delivers concrete, actionable frameworks that product leaders genuinely need - specifically the concept of 'money stories' and how to communicate value to revenue-focused executives. However, there is substantial padding: lengthy introduction, repeated throat-clearing about roadmap amnesia, and filler around organizational dynamics that dilutes the core insight. The core thesis (reframe all product communication around revenue impact) is strong but compressed into roughly 12-14 minutes of actual substance in a 26-minute talk.
when you're speaking with the go to market execs at your company, they cannot hear anything you say unless the sentence includes a currency symbol
My team or my portfolio or my organization earns some ratio. I put eight here, right? So for every euro you spend on us, we bring in eight
The 'money stories' framework is genuinely useful and represents a fresh angle on internal product communication, challenging the typical product management orthodoxy around user stories and technical debt arguments. However, the core insight - that executives care about revenue, not process - is not particularly novel, and the execution relies on familiar SaaS playbooks (SWAG estimates, simple ROI models). The three-story structure is clear but not groundbreaking.
money stories, not user stories
we've just realized that we spent all this money on things that our users won't take where nobody's told us about
Rich Mironov is a highly credible practitioner with ~40 years of operating experience, including 15 head-of-product roles and current deep coaching work with B2B enterprise CPOs globally. He speaks from sustained, high-level operational context rather than theory. The introduction establishes genuine relationships and respect. However, the transcript does not clearly surface recent company scale data, major exits, or current operational challenges beyond coaching feedback, which would elevate credibility further.
I did uh, 15 interviews, room head of product jobs at uh, Silicon Valley startups
I'm a one on one coach, mostly for B2B enterprise heads of product and chief product officers around the world
While Mironov uses specific numbers and examples (60,000 bronze customers, €90 annual upsell, 6x return ratio, 2-5 million value on roadmap items), most are invented SWAGs or generic illustrative examples rather than real company data. There are few named companies (HSBC mentioned once), no actual product metrics, and no concrete case studies showing the framework's real-world impact. The roadmap examples are vague (Project Voltron, LEGO project, NASA project) - code names rather than real product stories.
we have 60,000 bronze customers. However, we have, you can look it up. It's €90 a year extra to go to Silver. Whatever. You can look it up and then grab some numbers out of the air. We think maybe 1 to 5% will
the thing on the roadmap, which we show you every three days and you forget the thing on the roadmap is worth 2 to 5 million a year
This is a lecture/conference talk, not an interview format, so traditional host-guest dynamics don't apply. The speaker does demonstrate engagement with the live audience through rhetorical questions and humor ('I'm a product manager. I don't trust anyone'), but there is minimal push-back, challenge, or productive disagreement. The moderator's introduction is lengthy and off-topic. No one on stage interrogates assumptions or asks hard follow-up questions. The format itself limits conversational depth.
when we talk about product processes, the go to market side of our companies almost all hear excuses for why they can't have the thing they want
By the way, there's always a LEGO project and a NASA project and the teams always forget that they're not allowed to use those names when they ship it in public
Computed from the transcript - who did the talking, and the words that came up most.
Staff cuts, AI, constant escalations from Sales… it’s a tough time to be in Product. In this talk, Rich Mironov talks about three Money Stories that you need to keep close at hand - ready to answer the executive funding and priority challenges that are not about the tech. How do we build great products and also sell how our work is critical to overall organization’s success? - JOIN THE COMMUNITY
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign.
Speaker B: Welcome back. This is what I like to call the survivors. Sorry, the, um, the loyal people. Okay, so the ones that actually go all the way and get to the final talks. Actually, the ones that went away are going to miss out on two absolutely brilliant talks. So just saying. Okay, by the way, I have a, uh, special awards to someone who is going to be able to tell me. So, by the way, who has Rich's book? Okay, nice. So if you open Rich's book, you see that he has a nice picture of him together with someone. Okay, so do you know the name of that beautiful. You do know. So everyone knows. Uh, so to please reach. Okay. When I announce him, after I say his name, just go out widely. Say slashed. Okay. Come on. Okay. Yeah, yeah, no, but I want to hear. I don't trust you guys. I'm a product manager. I don't trust anyone. Now, come on. No, no, no, no, no, no. I sent the prd, then I want to test it. Okay, so. So sleft. Come on. Rich is a lovely person. He deserves better. Okay, What's. What's it perfect. And you can say it with American accent, with the Portuguese accent. I don't mind. He doesn't mind. It's all good. So I am very, very honored and super, super nervous to introduce the next person because it's someone that I really, really, really care. And I have a, uh, really admiration for, for him. It doesn't mean that I don't have an admiration for the other people, but I know Rich for the last two years, so. And, uh, we had some very cool conversations, and we've been having a lot of conversations to that. To the point that when I asked Rich, rich, can you give me a story? Or can you talk about imposter syndrome? Or can you mention something highly personal around imposter syndrome? And Rich goes like, okay, you know, I have almost 40 years of experience. I've done this, I've done that, or as I like to call it, I have a few of my ventures are lifelong learning opportunities. And the other ones went, well, cool. So that's how he put it, and I think very brilliantly so. To me, Rich is the money guy. I have no other expression better to reference that. So without further ado, I will get to the stage. Mr. M. Money man himself, Rich Mironov.
Speaker A: We're going to come back to the communications problem, but we're going to reset it slightly, because my focus, as you'll see, is how we communicate with the important executive folks at our companies who don't care about tech. So this is a challenge. So we're going to have three money stories. I'm going to dive back into that and do a quick, quick recap on money stories and then we're gonna tell three money stories which we as product and maker folks need to have ready at all times. Because when we're talking to the folks in the company who make decisions about what gets funded without necessarily a lot of grounding in how it works or who it's for or why we care, we need to be able to have the stories to tell that keep our teams intact and keep us working on what's important. So this is an internal communications problem. That's the one I spend most of my time on. Uh, for context, yeah, I did uh, 15 interviews, room head of product jobs at uh, Silicon Valley startups. That was just enough to teach me that that was a dumb thing to do and I stopped. These days I'm a one on one coach, mostly for B2B enterprise heads of product and chief product officers around the world. And this is a lot of what we talk about. So let me recap a little bit because last year I gave the talk on money stories and so between now and then, actually I did something rather bold which is I turn it into a book. Some of you have it, right. Celesh Celeste is on the back. Right. She's the much more important person, the chief canine officer. And just to recap the book, which is this one, it makes two very simple points. It's a skinny book. The first one is most of the execs in our company and I'm thinking sales and marketing and finance and all the folks on the go to market side, they're really, really concerned with revenue and they're really not interested in how we build product. Actively not interested. Right. Um, and so when we as maker folks who love what we do and are fascinated by what we do and make all these brilliantly fine distinctions between Scrum and Kanban and Safe or Rice or Backlogs or how we. Right. Um, we've lost our audience, Right. Not the thing we had on. In fact saying it more strongly. When we talk about product processes, the go to market side of our companies almost all hear excuses for why they can't have the thing they want. Right. Thanks for filling out the ticket. But we're agile, Right? That seems like a really good idea. But by the way, we're going to have to go back and interview all of the buyers and users within an inch of their lives because you didn't do it. Right. And by the way, the backlog's full. Right. So when we talk about product processes, we're almost always enraging and frustrating the half of the company that's truly not interested in this and we're wasting their time. Right. Uh, in my CPO coaching, most of the time we come to this conclusion, don't ever use the phrase product operating model with any of the folks on the revenue side of the house because it just confuses and frustrates them and it doesn't help. Right. Uh, so we're going to talk about the alternative here, which we call money stories. Notice they're not user stories. Right. And so the first takeaway from the book for anybody who didn't get it yet. I'm going to tell you that when you're speaking with the go to market execs at your company, they cannot hear anything you say unless the sentence includes a currency symbol. Right. Tech debt. Didn't hear it. Architecture. Hmm. What does that mean? Right. Uh, backlog, uh, you know, testing discovery. I didn't hear you. Okay, so we're gonna, we're gonna come back when you're talking to this one audience to talk in their language. So we're back to all the communications discussions about what do they care about and what do they hear. We're gonna talk about money stories, not user stories. And I'm gonna do the very quick run through of one of them. Just for anybody who missed the show last, going to dive into the three money stories you need to keep your team funded. So what's a user story? It's why we actually, it's why they should care. Right. Swag. Simple wild ass guests. We're going to make up some stuff and it's going to be close enough because it's going to be within a factor of five or 10. And that's good enough for this audience. And the rules are no more than three numbers. And we're going to multiply because that's the only operator. Quick quiz. Anybody ever worked with a, uh, VP of sales or chief revenue officer at your company who had a master's degree in math or science? Okay. So the reason we do this is for this audience. We really need to keep this at the right level. Right. When we're working with our team. Sure. Let's talk about Monte Carlo simulations when we're talking with the execs on the go to market side. Really simple. No more than three numbers and we multiply. Right. So I'll do one story here just so you have it and then we'll jump into the deeper stuff. So here's a story every one of us has told as a product person or whatever. It's the upsell story. Okay? Anybody ever had an upsell. And just imagine you've got a product and it's got three pricing tiers. Bronze, silver, gold, Right? And there's this really, really, really cool feature that you guys have thought of. And if we, uh, introduce it to the silver version of the tier of the product, a whole bunch of folks will pay extra money to get from the bronze version to the silver version. Right? Anybody had this pitch, this, had this feature, okay? It's not a complete sentence because we're missing something. M. What are we missing?
Speaker B: Money.
Speaker A: That's right. So this is how we talk about it with our developers and our designers and our makers when we're talking to the executives on the go to market side who are going to fund this piece of work. It's not a sentence they can hear, okay? So we have to finish the sentence. Let's do the maths really simply, right? So what's the formula? Right? How many Bronze customers do we have and how much more will they give us if we move from bronze to silver? And what's our wild guess for what portion of them might do it? Notice I didn't talk at all about the tech. Nobody in the room cares about the tech. They care about the fact that if we do this thing, whatever it is, folks are going to give us more money. Right? And so when we do the extension, right, we have 60,000 bronze customers. However, we have, you can look it up. It's €90 a year extra to go to Silver. Whatever. You can look it up and then grab some numbers out of the air. We think maybe 1 to 5% will, okay, multiply, multiply 50 to 250k. That lets us ask some good questions like, is that a lot of money? Do we care? M. Because if we don't, let's move on. We'll talk about other things. Have we thought about other things that might be bigger or smaller? Because now we can eliminate all the small ones and just talk about the big ones, right? And I will claim that any of us with an, uh, hour's worth of practice can come up with the money story within a factor of four or five in less than two minutes. And we can take all the ones that are four digits or less, a few thousand a year and not talk about them or work about on them anymore. Unless we feel like there's some other Reason, because it's the six digit and the seven digit money stories that everybody's going to pay attention to. So rather than looking at every ticket that comes in and says, what do we say? Oh, yeah, I'm going to put that in the backlog. No, we say, you know what? Unless you can help me understand why this is a six digit opportunity, I'm going to say no. Right. Moving on. Save some time. So anyway, that's the general money story. It's in the book. Uh, if you don't have one, come find me. There may be some copies left outside. We're going to uplevel ourselves though now and talk about the story that we as product leaders and everybody else in the room have to be able to tell to the folks in our company who allocate money, especially in this moment where there seems to be a lot of rather urgent irrational decisions, that speed is the only. Did you guys hear that speed was important? Yes. Uh, side note, uh, the first time I worked on AI was 1979 and it didn't do much then. Okay. Anyway, let's tell three stories, right? Here's the first one. And this is the earning our keep story or the ROI story. Right? And it goes like this. You folks on the executive team should continue to fund my team because we bring in more money than we spend. Right. Anybody ever told this story? Probably not so many. So you're going to need some facts and go get your own. Here was the ones I made up. Right. So, uh, an average maker team cost, let's say a million euros a year. You figure it out. It's your team, right? And most companies are looking for some return rate, at least 6x, which means it's not enough for your million euro, A, uh, year team to earn a million euros in product, you have to earn 6, right? Because we have to pay for the other 80% of the company, which is sales and marketing and legal and real estate and the trips that the CEO takes to beautiful places. Right? So you have to not just earn your keep, you actually have to, you have to earn back. Right?
Speaker B: Right.
Speaker A: So let's keep going. So I'm going to say that this isn't really about maths, it's about trust. Okay? Because the real question they're asking is, do we trust you to do stuff? And the first thing, by the way, um, we're going to talk in a minute about roadmap amnesia. But there's a broader set of amnesia that most executives have, which is not, uh, one of them can remember from Moment to moment, what product folks do or why we're useful or why they should keep us around. Right? And so part of this is going to be to tell the story about why we're handy to have and, and in the moment, when everybody's purging their organizations for reasons I don't understand, they might want to keep some of us around. Okay? So we're going to talk about trust. And first thing is, uh, a lot of folks have forgotten that R and D or maker groups are profit centers. Okay? In a product company, if we don't make products, we don't get to sell them, we don't make money. But we are a little shy about standing up and saying, we're a profit center. We're really important. The things we do drive the company. It's not just sales, Right? And so, uh, we're a profit center. And then I'm going to suggest there's an earning our keep ratio, which is take the revenue that your product brings in and divide it by the cost to your team and hope that comes out high enough that, uh, you know, uh, by the way, products that don't earn their keep are subject to summary execution. Okay? Anytime finance decides we need to cut costs, there you go. Right? And it answers this important trust question. Do we, as an executive team trust that you're going to spend the money we give you well? Right? Are you going to go make more for us? And we don't really understand the tech anyway, so it doesn't matter. But are you spending our money well, or do we need to micromanage you within an inch of your life? There's a better choice here, right? And so when I, when I get to, I'll tell you the story here. What's the story we need to tell? Here's the money story. And it goes like this. Fill in your numbers. My team or my portfolio or my organization earns some ratio. I put eight here, right? So for every euro you spend on us, we bring in eight. So why don't you give us more money so we can leverage that and be more profitable instead of treating us as a cost center and deciding that cheaper folks somewhere else is going to help. Right? So that's our first story. Everybody with me, we got two to go. The next one is the Roadmap story. Okay, so anybody know now, next later, Right? We've all seen this, okay? Not much use for this audience. So, Roadmap amnesia. How many of us have presented the Roadmap executive team within the last week? Okay, keep your Hand up if you think they still remember what's on the roadmap. Okay? There's a lot of causes of roadmap amnesia. In the enterprise space where I live, the proximate cause of roadmap amnesia is any phone call or email or message from any big customer or client or prospect who wants a thing that's not on the roadmap. Okay? Everything you told them is wiped out. And they're going to come back to you and say, well, I just talked to HSBC and they told us if we could deliver teleportation by Friday, right? There's 6 million in there. Right? And it's gotta be easy because the customer wants it and they've forgotten everything that we're doing and so there must be available people to do it, right? I tell you, we've all been there, right? You understand why it happens and I don't blame anybody. It's a symptom of the organization. Okay, so there's roadmap amnesia, right? And the other thing about roadmaps, and I'll put up a couple in just a sec, is they encourage our audience to ask the wrong question. Right? We're all being asked, okay, you put boxes on this thing. When will we have it? Because the only things on the chart are boxes and dates, right? Instead of why do we care? How's it going to serve us? Why is this good for the organization? Get me excited, right? There are pupils aren't dilating. Okay, so let's draw the roadmap here and I'll have a few versions of it. Here's a roadmap. And the short version of this, because I stole it from one of my clients, is they had an online application for consumers and renewal rates were really, really low. Churn was really, really high. And they looked into it and they figured out there was a whole bunch of technical stuff they were doing. Like the renewal link didn't go to the renewal page, right. And they forgot to save the credit card number. And a bunch dumb. Right? So there's a bunch of work we could do to boost renewals. The other is it turns out we're leaving money on the floor and so we could raise prices. Okay. And so the roadmap looks like this always, right? Yeah, Blah, blah, blah. We're going to simplify forms, we're going to add auto or fill, we're going to save, right? These are all the things we're going to do, right? And then for select, we're going to update the prices on the files and we have sku. Right? This is work. Really important for your team, really important for the folks who are going to execute on this. It's, uh, of very little interest as presented to the folks who allocate money. Right. We're missing something. What are we missing? Money. Thank you. I figured you guys would get there. So let's make one tiny, tiny change to the roadmap, okay? And uh, then very big, bold, green type, let's put our guesses for how much that's worth. You know where their attention's just gone on the map to the left, okay. They're actually ignoring all the boxes. Those don't matter anymore, right. And so when we come back and say, well, you know, we did a bunch of extra work and we want to switch these two boxes around, your answer is, that's fine. Is it going to bring the money in? Maybe sooner. Go do whatever you want, that techy stuff. But what we're interested in, right, is that in fact I think I have a picture here of what they're really seeing. Right? Not what we're seeing, but what they're seeing. Right. Much of your audience doesn't understand anything in the boxes, right? Their code names, their numbers, right? But we present it every third week and we expect them to remember what Project Voltron includes and doesn't include. Right. By the way, there's always a LEGO project and a NASA project and the teams always forget that they're not allowed to use those names when they ship it in public. Right? Okay, so this sets us up though for a much better argument than we used to have. Because when HSBC called, the sales exec went, escalated, uh, to the CEO and said, this isn't going to be hard, go do it. Right? And we sat there and said, well, we don't like the fact that you blew up our roadmap for the third time this week. Right? So when we put the numbers on there, when we put the money on, it lets us give a better answer. How about something like this, the thing on the roadmap, which we show you every three days and you forget the thing on the roadmap is worth 2 to 5 million a year. Okay? So please, it's a bad business decision for you to take everybody off of Project A for this other thing, for this mid sized deal which may never close and is worth a lot less now every single exec in the room understands that 2 million's bigger than 80,000 even, plus or minus 4x, right? And instead of arguing about tech debt and architecture and you know, Discovery, I would much rather say we've all agreed that the things on the roadmap are worth a lot of money. So please let us finish them instead of interrupting us with a bunch of other stuff. Notice, that's a much stronger argument. Right. Okay, that's two. We got one to go. And we heard a lot about it today. I think Discovery is the next battlefield, right? As building gets smaller and smaller and smaller, we can build a lot more stuff, right? So, you know, it used to be that the, uh, bottleneck was development, and now it's going to be user attention and go to market. Right? So what does that mean? We'll get to this M Money story in a sec. Right? So here's my thesis, and I wrote a post about it a few weeks ago. I'm going to claim that if your engineering team can build a hundred new features or products a day or a week, or an hour, right. That's great. But we've just moved the bottleneck such that 99 of those hundred will never see a user. Okay? If we haven't enabled the salesforce, if we don't have positioning and pricing, if our channels aren't ready. Right. Even more than that, just imagine any of your customers or users and whether they're willing to try and inspect a hundred new features a week from you, okay? They're kind of busy, right? And in the enterprise space, it takes a whole year to review them anyway, right? So when we've confused code with product, code is part of product, but it's not product. It doesn't turn into money until we do all of the other things which are required to turn code into money, like positioning, like messaging, like marketing campaigns, all. All the way down, right? So we're in this moment where it's easy to confuse code development speed with product. It's not going to end so well. And so we're going to end up hearing a lot of things that look like this, right? Grumble, grumble, grumble. Last quarter, we whipped everybody to use all these tools because we needed to ship 40 times as many features as we used to. And we've just realized.
Speaker B: Shocked.
Speaker A: I'm shocked. We've just realized that we spent all this money on things that our, uh, users won't take where nobody's told us about. You know, it's in the release notes. Anybody have any customers or users who read release notes religiously every week and use all the things that are in the release notes? Now, we, we can have our agent write those release notes, no problem. Okay? But you know, the, the one job to be done that they're using your product for, they're still using it for that one job to be done. Right. So we're going to have this syndrome come up really soon, which is failure rates on new products and features through the roof because we're mistaken code for product. Right. It's a part of it. So here's, here's our third story. And by the way, it's a plea. Let me, let me back up a step. The thing I'm most worried about and that I'm hearing from all of my CPOs and I'm reading all about is this confusion of code versus product means that discovery isn't valued, right? I'm the CEO. I had an idea in the shower this morning. It's really good. I need it coded by noon and shipped by 5. Right. We just had a big customer submit a ticket that says they want to change all of our interfaces. How hard could it be? It's not going to end well. Right? But faster coding becomes table stakes. Yes, the folks who don't get their ah are gone. But just imagine where you and every one of your competitors is coding 20 times as fast can deliver features 20 times as fast. By the way, your market didn't grow by 20x just because you can build code 20x faster, right. There's no more budgets, there's no more users. Just because we sped that up. We'll be chasing 20 times as many products against the same, the same money. Right? And so when we bring it back to the money, somehow our audience starts to understand. Right? So this is going to be the third of our three, uh, executive product money stories where we explain over and over again that faster coding is table stakes. But actually figuring out what we should build and maybe there's somebody who's going to give us money for it at the other end becomes more and more important. And the go to market strategy, do we have sales channels? Do we know what to call this? Are there campaigns? Is it priced right? Packaged are going to be the things that turn code into revenue. Right? And suddenly I think when, when that happens two or three or four quarters from now, uh, folks are going to rediscover, I hope, why product management's really useful because we've moved the bottleneck and now we've actually got to build things the world wants or certainly will pay for. I don't know about wants. Right, good. So let's wrap because I think I have some takeaways and I cleverly used a. I Don't know. Picture here of a, uh, takeaway. Okay, so things that we need to remember that are obvious to us but the rest of the company forgets every 15 minutes even though we tell them. Right. So the first one is R and D makers, right? Engineering, product design. We're a profit center, right? We create the things that bring money into the company even though the sales team gets the commission and the credit for it. Right. Sometimes marketing, if you're in B2C, right. The second one is the reason things are on our roadmap isn't because some rice chart with 11 columns and 700 rows got brought into a meeting. It's because we expect those things to deliver value to the company or the organization. And if you're a profit making organization, that means money, right? And so when we talk about the roadmap, we talk about why it's going to deliver value money to the organization so that folks let us finish stuff, right. Instead of blowing it up. Right. And then the third one is that discovery and go to market strategy are the things that convert, uh, code into revenue. And you know, we're going to have a lot of reorganizing and changing of titles and merging of departments, but somebody somewhere is going to have take this stuff and show it to the world, explain it to the world, use their words and extract value, whoever it is. And if we don't do that, then it's just code. Right? So those are our three stories here. If you're from Germany, it's this way. If you're in US it's this way. Three stories that we as product folks need to be able to tell pretty often because they're kind of unnatural thoughts for a lot of the rest of the organization. And we shouldn't fault anybody. They have their own jobs, they're not that interested in what we're doing, doing and vice versa. But we shouldn't assume that our organizations understand these basic things because mostly they don't. Right? Okay, so here's a word I learned, right? Moro in Portugal, I love it here. This is my new home. Thank you. For everybody who lets me stay here. Anybody who's clever enough to be able to spell my last name, which is not trivial, can find me on the web and find me on the email and there's how to find me on the uh, Portuguese telecom network. Great. All yours. Mhm.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.