Rohini Pandhi: Why founders should be the PM until it breaks

1. 0:00 – 5:00

   Rohini’s background

   1. LRLenny Rachitsky0:00

      (instrumental music) ... the CEO of the company you work at, now Mercury, tweeted, uh, a few years ago where he basically was very proud of n- not having any product managers. Clearly you have product managers today. You're a product manager (laughs) at Mercury. What was the sign to Emad and the leadership team that it was time to hire product managers?

   2. RPRohini Pandhi0:16

      The bottlenecks started popping up. To take things from, like, soup to nuts on every single project, it requires design and eng then to take on a lot more responsibility, which means somebody's doing the PM duties even if you don't have a PM.

   3. LRLenny Rachitsky0:28

      What is it that you think people most miss about the value that a PM brings to your org?

   4. RPRohini Pandhi0:32

      There's just so many different flavors of what a product manager is. We use this idea of, like, a pioneer, a town settler, and a city planner. So the pioneer is a PM that's really good at zero to one. The settler PM is in that growth stage of maturity of a product. You're in a town. There might be a bank. There might be a post office. But nothing more than that. And then a city planner is a PM that's really good at mature products. They have the city.

   5. LRLenny Rachitsky0:56

      Let's talk about the final big topic: going multi-product.

   6. RPRohini Pandhi0:58

      The organizational structure is really important. One thing we learned was having new product areas, new seedlings being too close, uh, within the, like, true org structure to the core banking or payments or mature products made it hard for that new product to even grow.

   7. LRLenny Rachitsky1:15

      (instrumental music) Today my guest is Rohini Pandey. Rohini is currently a product leader at Mercury where she leads the product expansion team which incubates and scales new product lines within Mercury. Previously, she spent over seven years at Square, also known as Block, leading product work on Square Payments, Invoicing, and the Bitkey hardware Bitcoin wallet. She's also the co-founder of the startup bootcamp Transparent Collective and a very active angel investor. In our conversation, we talk about why founders are often so resistant to hiring product managers and Mercury's journey on deciding to hire their first PM and then scale their product management team. Also, we get into what attracts great product managers to join your company. She makes an argument for why it's important to invest in quality and user experience versus just working on things that move metrics and how that could differentiate your business. We also do a deep dive into how she successfully launched a half dozen new product lines at Mercury just this past year, which is extremely rare and very hard to do, and also something that every single startup hopes to do and tries to do and often fails. If you enjoy this podcast, don't forget to subscribe and follow it in your favorite podcasting app or YouTube. It's the best way to avoid missing future episodes and it helps the podcast tremendously. With that, I bring you Rohini Pandey. This episode is brought to you by Cloudinary, the foundational technology for all images and video on the internet. Trusted by over two million developers and many of the world's leading brands, Cloudinary is the API-first image and video management platform built for product leaders who rely on visual storytelling to express their unique product value, who are building engaging web and app experiences, and who understand that harnessing the power of AI to automate is the only way forward. Gil Grossman, engineering team lead at Fiverr, says that "Our users share billions of images, video, and audio files. Cloudinary's ability to automate our post-production work at scale amounts to a savings of up to 92,000 work days per month." Think bold, build big, ship fast. Let Cloudinary handle your media needs. Start your free plan today at cloudinary.com/lenny. I'm excited to chat with Christina Gilbert, the founder of OneSchema, one of our longtime podcast sponsors. Hi, Christina.

   8. CSChristina (OneSchema ad spokesperson)3:36

      Yes. Thank you for having me on, Lenny.

   9. LRLenny Rachitsky3:38

      What is the latest with OneSchema? I know you now work with some of my favorite companies like Ramp, Vanta, Skale, and Watershed. I heard that you just launched a new product to help product teams import CSVs from especially tricky systems like ERPs.

   10. CSChristina (OneSchema ad spokesperson)3:53

       Yes. So we just launched OneSchema File Feeds, which allows you to build an integration with any system in 15 minutes as long as you can export a CSV to an SFTP folder. We see our customers all the time getting stuck with hacks and workarounds and the product teams that we work with don't have to turn down prospects because their systems are too hard to integrate with. We allow our customers to offer thousands of integrations without involving their engineering team at all.

   11. LRLenny Rachitsky4:15

       I can tell you that if my team had to build integrations like this, how nice would it be to be able to take this off my roadmap and instead use something like OneSchema, and not just to build it but also to maintain it forever?

   12. CSChristina (OneSchema ad spokesperson)4:27

       Absolutely, Lenny. We've heard so many horror stories of multi-day outages from even just a handful of bad records. We are laser focused on integration reliability to help teams end all those distractions that come up with integrations. We have a built-in validation layer that stops any bad data from entering your system and OneSchema will notify your team immediately of any data that looks incorrect.

   13. LRLenny Rachitsky4:47

       I know that importing incorrect data can cause all kinds of pain for your customers and quickly lose their trust. Christina, thank you for joining us and if you want to learn more, head on over to oneschema.co. That's oneschema.co.

2. 5:00 – 9:51

   The role of product managers at Mercury

   1. LRLenny Rachitsky5:00

      (instrumental music) Rohini, thank you so much for being here. Welcome to the podcast.

   2. RPRohini Pandhi5:06

      Thank you, Lenny. I'm excited to be here.

   3. LRLenny Rachitsky5:08

      I'm very excited to have you here. I want to start with this tweet that the CEO of the company you work at, now Mercury, tweeted, uh, a few years ago where he basically was very proud of n- not having any product managers, of this idea that engineers are gonna do the PM work, designers, basically everyone's doing PM duties. And clearly you have product managers today. You're a product manager (laughs) at Mercury. And the reason I want to chat about this and spend some time here is a lot of founders, there's a- kind of this meme of, like, "We don't need product managers. Who needs PMs? What a waste. They slow everything down. They disempower people on the team." And then eventually they realize, "Oh, okay. I see. (laughs) I see the value of PMs." So I want to spend some time on this topic. How does that sound broadly?

   4. RPRohini Pandhi5:52

      Perfect. Let's go into it.

   5. LRLenny Rachitsky5:54

      Okay. (laughs)

   6. RPRohini Pandhi5:55

      (laughs) .

   7. LRLenny Rachitsky5:55

      So first of all, how many, uh, engineers/employees did Mercury have by the time they ended up hiring the first PM?

   8. RPRohini Pandhi6:01

      Prior to two years ago, there were no PMs at the company. And I think at that time, there was probably close to 400 employees across Mercury. Um, I'd say at least half of them were s- in some level of, like, the R&D role, so engineering pro- uh, design, those types of, like, core roles.

   9. LRLenny Rachitsky6:19

      Wow, so 200 engineers, 400 employees?

   10. RPRohini Pandhi6:23

       Probably. Probably.

   11. LRLenny Rachitsky6:23

       That's pretty far. Okay, great.

   12. RPRohini Pandhi6:24

       Yeah.

   13. LRLenny Rachitsky6:24

       So this is going to be really help- really good. Okay, and then how many PMs are there now, roughly?

   14. RPRohini Pandhi6:28

       Now we have about 30 PMs across the company, and I think it's, you know, split between junior and more experienced PMs, but it's about ha- more than half are senior PMs with, uh, with managers baked in there somewhere.

   15. LRLenny Rachitsky6:43

       Okay, and then where do you fit in the timeline of no product managers to the PM team is built?

   16. RPRohini Pandhi6:48

       So yeah, so two years ago, no PMs at Mercury, or no one with that official title, um, there were still people doing the PM duties (laughs) and having those responsibilities, and then I joined about a year ago. So I think they were in their, you know, what was the first set of learnings from that first year of having PMs, and then me joining and kind of doing some- a bit of revamping of the, the product discipline internally.

   17. LRLenny Rachitsky7:10

       Okay, cool. So there's a few threads that are gonna be really interesting here. One is clearly Mercury has done well and has thrived without PMs for a long time, so I think there's, like, that thing, and then there's also just, like, uh, what- how they built this team to, to be successful, so I want to start with that first kind of, uh, thread of just a lot of founders start off feeling, "I don't need product managers. Who needs them? We're gonna have- everyone's gonna do PM duties."

   18. RPRohini Pandhi7:34

       "So annoying," yeah.

   19. LRLenny Rachitsky7:35

       Yeah, "So annoying, just slow everything down. What do they even do all day?"

   20. RPRohini Pandhi7:39

       A bottleneck, yep. (laughs)

   21. LRLenny Rachitsky7:40

       Yeah, exactly. But I think it's rare to actually work out really well. A lot of companies just become chaotic without PMs, and I think Mercury did something right in order to be successful without PMs for a long time. So here's the question, just what do you think Mercury had in place or needed them to have in place to be successful for as long as they were without product managers?

   22. RPRohini Pandhi8:03

       I think the crux of it comes down to the founders, and the founders are your original PMs, right? And, uh, like, I think- I- whenever I talk to any small seed stage company who's asking, "When should I hire a PM?" I'm like, "Absolutely not. Until you cannot do the job anymore, you yourself should be the PM." The co-founders, the founders, they need to be there, and I think this was true even at Square. I guess I got lucky with some of my past experiences being at places that took product seriously or the kind of the- the work that product does and the intentionality of- of making product decisions. It doesn't matter that there wasn't, like, a PM title necessarily at the company, but you need to be as close to the customers as you possibly can, you need to be as close to the solution that's getting built, and in that early days, in those early days, the founder needs to be that PM. They need to take on those duties. I think what was kind of- you talked about, like, what was the magic, um, piece of it. I- I do think it's hiring amazing engineers, hiring amazing designers, because you're pro- as you scale, those are the- the people, the disciplines that you really need to- to build, um, your solution in the software product world. And so having those types of folks that have that product obsession, have that product mind already there makes me excited to join companies that hated PMs (laughs) or had a negative reaction to this idea of a PM because they already do the product role. They already have that, like, implicitly as part of the way that they operate. They have these autonomous teams that are able to make local decisions in their product service areas, and so they know kind of- they have this intuition and they're already close to the customer. They're already close to how to build it. And I think that's what made Mercury successful at the start of not having any PMs. I think early Square days, it was the same exact story.

3. 9:51 – 13:18

   Key indicators that it’s time to hire PMs

   1. RPRohini Pandhi9:51

   2. LRLenny Rachitsky9:51

      Following this thread, what was- what was the sign to Emad and the leadership team that it was time to hire product managers?

   3. RPRohini Pandhi9:58

      There's one element that scale. It's just there's so much going on and a single PM, (laughs) a single, like, CEO couldn't handle that kind of scale. Um, we have three co-founders, but even at some point, that scale becomes too broad for three PMs to handle. And, uh, I think there was, like, one, the- the bottlenecks started popping up, so i- if- if every decision kind of depends on these co-founders to make every single call, things just slow down to- or even halt until they're available again. Um, the other piece was complexity. We were starting to not only scale, but just grow in complexity, and when you think of, like, fintechs, you have a lot that you need to work with. You have a lot of partnerships, cross-functional collaboration you need to do. We need to work with compliance, we need to work with legal, we need to work with risk. We need to do all of these checks before a product even gets launched, and so to take things from, like, soup to nuts on every single project that's kind of going out the door, it requires design and eng then to take on a lot more responsibility, which means they're- somebody's doing the PM duties even if you don't have a PM. But then that means they're not doing their engineering or design, uh, responsibilities. And so, uh, for- for I think for Mercury, that kind of started breaking way before the 200, uh, or 400 employee marker. That probably broke under the 100 marker. And so what they had was generalists. They hired, quote unquote, like, these, uh, business lead titles, and those business leads started doing those cross-functional collaboration meetings, making sure everything was kind of, like, the Is were dotted, Ts were crossed type project management pieces of the PM duties, and they started becoming, like, the product managers, so to speak, within the company, and then they officially changed titles about two years ago, I think. So a bunch of those business leads became PMs. The problem with that became they weren't PMs. They didn't have experience in the PM role, and so, uh, kind of the core, maybe the basics of what product management, um, needed in- internally were missed. Like, strategic planning wasn't exactly right, uh, or road mapping was really hard for some of these folks. Prioritization, doing any sort of goal settings.... doing deep customer research wasn't necessarily part of, like, what they've been trained for or had gotten experience with. And so, they kind of struggled with a bit of that. And I think, in hindsight, we should probably done the official transition to the PM role a lot sooner, but, you know, hindsight's always 20/20. (laughs)

   4. LRLenny Rachitsky12:25

      This is so interesting. So one, it feels like, (laughs) the team was like, "No product managers," and then they're just like, "Okay, you guys do, do this thing that's, like, wait, sort of product management, but n- we're not gonna call you product managers. You're something else."

   5. RPRohini Pandhi12:37

      Yeah.

   6. LRLenny Rachitsky12:37

      And then eventually it's like, "Oh, I see. There, there's people that are very good at all these things that we need help with, and maybe we should just-

   7. RPRohini Pandhi12:44

      Yes.

   8. LRLenny Rachitsky12:44

      ... uh, admit that, and that's okay. That we need PMs."

   9. RPRohini Pandhi12:47

      I think so. And it's, it's... One, it's good to just have that, like, um, recognition (laughs) of, okay, here's what these folks are really good at. And when you hire a really good PM, they can make that, um, the velo- the product velocity, the quality just 10X better.

   10. LRLenny Rachitsky13:04

       Yeah. That's what I always say. A lot of people are like, "Oh, PMs suck. I don't... They make everything worse on our teams." And I'm like, "You just haven't worked with a great PM."

   11. RPRohini Pandhi13:10

       Yes.

   12. LRLenny Rachitsky13:11

       Because great PMs make your life easier. You-

   13. RPRohini Pandhi13:13

       Exactly.

   14. LRLenny Rachitsky13:13

       ... have more joy. You could do the thing you want to do more.

   15. RPRohini Pandhi13:15

       Yes. Yes. 100%.

4. 13:18 – 19:53

   Building the product team at Mercury

   1. RPRohini Pandhi13:18

   2. LRLenny Rachitsky13:18

      Okay. Let's talk through the journey of building the product team at Mercury. So, it went from zero, we don't need PMs, to 200 engineers. Potentially, you could argue it was 100, 'cause they had sort of PMs that were sort of doing the PM job, to the PM team now. So, a lot of founders are trying to figure out, "What does the beginning of my product team look like? Who do I hire? What does that look like and how does it scale over time?" And you were in that journey. Can you just talk through the journey of Mercury building out their product team, and any lessons along the way for folks that are trying to do this today?

   3. RPRohini Pandhi13:49

      I think the, the first step for us was just defining what the discipline is, and like, what the expectations of a product manager are internally. When I started, a lot of the questions that came from the PM groups are like, "Am I doing this right? What should I be doing? How should I be doing it?" And so step one was almost just putting that on paper and making sure we were all aligned from, like, leadership down to an individual PM on what those expectations of the role were. So, one of the first things that, um, we put together was a career ladder. It was just literally a matrix of the role at different levels and expectations. Um, and we kind of put in what, what was really important to us. So, we have a career ladder for Mercury overall, just for everybody at Mercury that hits some of our core values. And that was... Kind of set the foundation of it. Like, humility, low ego. Those types of things are really important to us. But then what was it that added on, um, in order to be a PM at Mercury, and what were those expectations? So, we kind of took a step back and we said, "All right. What we want is for Mercury PMs to strive towards, like, building a product, building products that our customers just genuinely love." And that was really important to us, so that was one vector of the, the career matrix. And then the other was like, it needs to have... The work that you do needs to have a positive i- positive impact on the business in whatever way th- that is. It doesn't have to be a revenue goal or anything like that, but it needs to be some sort, some outcome-based, um, impact. And then there was also work around, like, can you build a long-term vision? Can you communicate that? Can you... Again, we're in a regulated space. Can you work with cross-functional, uh, leaders? And so we started building out these necessarily, like, skills across the different roles, putting that on paper. Then that led to, okay, we know what our current PMs need to be able to do. As we bring in new PMs, we need to update our hiring process and interview process to fit these same sort of criteria that we're looking for. So like, what skills do we want to figure out? W- where's the signal in the interview process to say that these are the skills that we really value at Mercury and this person has them? So, we test for things like product sense. Customer and quality obsession is really, uh, important to us. Analytical skills, uh, strategic or, like, system-wide thinking skills are really important to us. We, we pretty much took what we had in that career ladder and applied it to the interview process. Um, one thing that I would love to have in the future is a written, uh, element of our interview process. We ha- we don't have that yet, but I really do think quality in writing demonstrates this ability to go i- in depth with something and to really put your thoughts on paper. And so, there's something in there that I really want to try to do, uh, in the next few months or quarters and just experiment with, but we'll see how that goes, yeah. But aside from that, I think we're, we're getting to a really good place with some of our, um, hiring and interview process to get the right folks in the door.

   4. LRLenny Rachitsky16:42

      That's actually really interesting. I've never heard of a PM interview process with a essay component, and it makes so much sense 'cause so much writing.

   5. RPRohini Pandhi16:48

      Right? It's something-

   6. LRLenny Rachitsky16:49

      Yeah.

   7. RPRohini Pandhi16:49

      ... about, like, being able to edit, being able to put thoughtful content in there and have, like, a two-pager that gets everyone aligned on what you're trying to communicate. It's a really important skill, especially at the senior levels, especially at a scaling, growing company.

   8. LRLenny Rachitsky17:03

      Yeah. So what I love about what you talked about is something that basically every company has to reinvent from scratch. What is a product manager? What are their responsibilities? What is the career path? What does success look like? What does interviewing look like? What helped you develop this? I imagine you borrowed a bunch from Block and places you worked. Is there anything else for folks that are trying to do this themselves versus just copying exactly what you did that helped you develop these things?

   9. RPRohini Pandhi17:26

      I think it was a mix of, yes, taking work that others had already done. One of my old professors used to say, "Well stolen is half done." And I think that's very true. (laughs) And so-

   10. LRLenny Rachitsky17:36

       Well stolen is half done. (laughs)

   11. RPRohini Pandhi17:38

       That's right. (laughs) Well-

   12. LRLenny Rachitsky17:40

       Love it.

   13. RPRohini Pandhi17:40

       It has to be well stolen.

   14. LRLenny Rachitsky17:41

       Yeah.

   15. RPRohini Pandhi17:41

       And then you're only halfway done once you get to that point.

   16. LRLenny Rachitsky17:44

       Yeah.

   17. RPRohini Pandhi17:44

       But it i- it does help. Um, and I think, like, taking some of those cues from Block, but then also just talking to product, senior product leads across companies and saying, "W- what do you guys test for? How do you do this? What, what are some key learnings that you've had?" was really helpful. And then we kind of went and, you know, worked with our exec team. "What were the values that you really think are important?" There's some skillsets that are just like table stakes for a PM to have. But then, there's superpowers that you want to flex into at different companies or at different roles. And so, really just kind of baking that in. You wanna,... you want to stay a little weird, you want to stay your personality as part of this process. A, a good example is we still go through, we have this Mercury presentation in our interviews. And it's, the prompt is very, very generic. It's like, "Just talk about something that you're interested in, um, and talk in depth through, to a panel about it." And what we're really testing for there is attention to detail, the craft and care. The, uh, desire to go deep into a specific area, and, and show your passion for that area. Uh, one of the PMs, we talked about his presentation, um, internally a lot, was he went through, uh, I think it was like an Airbus or a Boeing plane. And all the de-, and truly, just from like soup to nuts, uh, what was the, um, reason for this, like for this type of plane structure all the way to like what kind of bolts do they use for this plane and why are those important? And just going into-

   18. LRLenny Rachitsky19:09

       That's, that's-

   19. RPRohini Pandhi19:09

       Yeah. (laughs)

   20. LRLenny Rachitsky19:09

       ... yeah, and I like how that, how that turned out to be very prescient and, uh, (laughs) important-

   21. RPRohini Pandhi19:13

       I know. We had a lot of questions after. (laughs)

   22. LRLenny Rachitsky19:16

       ... versus the competitors. Yeah.

   23. RPRohini Pandhi19:16

       Yeah. Um, but yeah. It was, it's just something that kind of shows off your personality, shows that you care about some, like a, a topic in depth and, uh, you're able to go into the details of something like that.

   24. LRLenny Rachitsky19:28

       So to kind of reflect what you shared of here's what, to build a product org to start hiring PMs, you need to have in place a career ladder with basically the skills that you're looking for from the PMs so that it's clear-

   25. RPRohini Pandhi19:42

       Yep.

   26. LRLenny Rachitsky19:42

       ... what you're looking for.

   27. RPRohini Pandhi19:43

       Yep.

   28. LRLenny Rachitsky19:43

       There's values of the PM org. I imagine there's like a job description is-

   29. RPRohini Pandhi19:47

       Totally.

   30. LRLenny Rachitsky19:47

       ... just describe the responsibilities of the role, and then the interview process.
5. 19:53 – 22:26

   Why you should avoid hiring PMs too early

   1. LRLenny Rachitsky19:53

      Something that I, I should have highlighted that you spoke about earlier that I think is a really important lesson of a sign that it's time to hire PMs is, is essentially what you highlighted is bottlenecks. Your team is starting to get bottlenecked more and more. Just coming back to that real quick, do you, do you have a sense of just like, like it sounds like there was already bottlenecks, things are not going amazing all the time and, okay, what like, where does it flip to like, "Okay, shit. We really need PMs now." Do you, do you have any insight there of just like here's like, "Okay, now is the time," versus like, "Wait a little longer"?

   2. RPRohini Pandhi20:23

      The one piece of advice I always have is like, "Don't hire PMs too early." It's not worth it. There's not a need for it. And I think when founders are asking themselves that way too early, it feels like they're giving over the reins to somebody else to handle everything from like customer conversations, the product development, um, the, the personality of what this company needs to be. And so, you want to be as close to it as possible, but I think you do start bringing PMs in when, one, work just isn't getting done without you. Like, you are that bottleneck as a founder. Or, when people other than you are doing kind of the core PM work at scale. So design and eng are starting to do more of that, and not doing some of the core stuff that they need to be doing. Um, and similarly, I guess, uh, when you're, when you can't scale yourself, uh, in like the decision-making or wearing multiple hats or, you know, doing the cross-functional collaboration with folks, getting things from start to finish, that's another sign that you probably need to just hire some PMs or project managers in, in that space. And then truly when it's like, okay, you need a product person here is when you start moving into adjacent surface areas or different product areas with different kind of target segments of customers, because now you have to learn what that customer is, uh, what they need, and what you should be building for them.

   3. LRLenny Rachitsky21:39

      I love that you mentioned that. We're gonna spend a bunch of time on that. I know that's what you spent a lot of time on at Mercury. And I actually have a post on what is a sign you need product managers now. And you touched on all the points that I made in this post, which is bottlenecks, uh, or you want to go deep on a specific subject and hire someone to take it.

   4. RPRohini Pandhi21:58

      Mm-hmm.

   5. LRLenny Rachitsky21:58

      Snapchat actually is a good example of that, where they brought in their first PM when they wanted to go deep on ads, and they brought in someone just like-

   6. RPRohini Pandhi22:04

      That's perfect.

   7. LRLenny Rachitsky22:04

      ... "Oh, that's your thing."

   8. RPRohini Pandhi22:05

      Yes.

   9. LRLenny Rachitsky22:05

      Okay, cool. We'll link to that in the show notes. Also, uh, something I'll link in the show notes that will be very helpful to people, I have the career ladders of something like 20 to 30 companies, the attributes that I look for and links to their actual, uh, ladders. And so, for folks that are developing this, we'll give you-

   10. RPRohini Pandhi22:20

       Love that.

   11. LRLenny Rachitsky22:21

       ... a link to that.

   12. RPRohini Pandhi22:21

       Yes. I think I even, I saw that. I probably referenced it at some point-

   13. LRLenny Rachitsky22:24

       Great. Perfect.

   14. RPRohini Pandhi22:25

       ... and just went into my subconscious.

6. 22:26 – 26:15

   The different flavors of product management

   1. RPRohini Pandhi22:26

   2. LRLenny Rachitsky22:26

      So, as a final question along this topic of building out PMs, hiring PMs for the first time, for someone that's still like, "I don't know, I don't really want product managers at my company and they're just so annoying," w- what is it that you think people most miss about the value that a PM brings to your org that may be a sign, "Okay, I see. Maybe we do need this"?

   3. RPRohini Pandhi22:47

      All right. So I think there's like different kinds of PMs, and different flavors of PMs. One thing that I, I really, I feel like, um, sometimes gets lost in, when we talk about, "Oh, I've met one PM and they kind of didn't do what I wanted them to do, or they didn't work in the way that I wanted them to work, so therefore all PMs suck." Um, there's a problem with that because there's just so many different flavors of what a product manager is, and it depends on the company, depends on the industry, depends on the role within a company. Uh, and so a framework that I really like using to determine, okay, what kind of PM do you need, and then hire for that is something that I learned at Square. We use this idea of like a pioneer, a town settler, and a city planner. And that idea is like, okay, so the pioneer is a PM that's really good at zero to one. They can create something from nothing. You know, you're pioneering into this uncharted territory. There's nothing there for you. There's not any sort of infrastructure. You're building it from scratch. You're kind of taking natural resources and seeing how you can reapply them into building what you need in order to survive, and then hopefully grow. The town settler PM is in that growth stage of, of maturity of a product. They're really working on like, again, to use the same metaphor I guess, you're, you're in a town. There might be a bank, there might be a post office, there might be a school, and there might be some like gravel roads. But nothing more than that. And so you have some level of infrastructure, but what you're trying to do is further grow the, the town that you're building out, and put in some foundational elements, but also try to do some experiments. Maybe things don't work out exactly the way you want, but then you also want to build for the future.And then a city planner is a PM that's really good at mature products, really good at driving efficiencies at scale. They have the city. They... Everything that they do touches hundreds, thousands, millions of customers immediately. And so the type of PM that you need for something like that is going to be very different than a zero to one PM. And so when you... When people, uh, especially founders say, "I don't want a PM," I think it's because they're thinking of a mature, a city planner, when they could find a, a former, uh, entrepreneur, a former founder, a good pioneer to build out the next set of products or they really need somebody who's great at growth and like starting to put some of the process in, but not build it to the point of, "You know, I'm a big mature enterprise company" anymore.

   4. LRLenny Rachitsky25:06

      I love this metaphor. And is the advice that as... The smaller you are, the earlier in the spectrum you want to be hiring like more pioneers and a few town settlers as you build your team?

   5. RPRohini Pandhi25:17

      Probably. I think like it just really depends on what you're hiring for. There's like... Even for Mercury, we had our banking, core banking services. We're still a mature product in our, uh, spectrum, right? Like there... Everything that we do there, we have to truly not even measure twice, measure three times, cut once, be really sure about what we're doing. And that scale and the ability to have a PM that can think about all of that scale is really important. And so you really want to test out have they done it before? Do they know what they're talking (laughs) about? Uh, and then like in which case would... Were you willing to take like riskier bets versus being really conservative about what you're doing and then determine what kind of PM you need for it. Because otherwise, you see re- uh, you see their resumes, you see what they're... what they say they've done, but when you've talked to somebody, when you're interviewing someone, really try to drill into what kind of experience they are good at, what they want in their next role. Because otherwise the... You know, the resume without the receipt is just a piece of paper, and you want to get the receipts. What are the... What's the work

7. 26:15 – 35:59

   How to attract top talent

   1. RPRohini Pandhi26:15

      that they've actually done?

   2. LRLenny Rachitsky26:16

      Following this thread, I asked a bunch of people that work with you at Mercury and Block, uh, what to ask you. And one of the questions that I loved came from the COO of Mercury, Jason Zheng. And his question was, "What do you think attracts great product managers and great talent to a company? What makes them hungry to join your company?" How do they hire a Rohini, basically?

   3. RPRohini Pandhi26:38

      Okay. There's a few answers to this. So let's... I mean, maybe just starting off, let's take away some of the table stakes. Like, let's assume that candidates know that, you know, the company's viable, it's doing well, paying market rates, all of that. Like, the candidate and the product have good... there's a resonance with that, the culture has good vibe checks. So taking away kind of like the, the table stakes of hiring, (laughs) um, I think there's a couple things from the company side and then the candidate side. I think it... From the company side, it really boils down to do you understand the candidates that are coming through the door, especially when you're hiring for seniority and experience. You kind of have to take it like a product manager would think about this problem and say, "All right. If this is my customer, what's their... what's their next... What's their goal? What's their jobs to be done kind of an idea?" And consider like where this... the PMs would be that you're hiring for on this, um... Actually, a, a mentor of mine had this great framework. He said that like every career follows a S curve. And if you think about the Y axis being kind of level of ambiguity, X axis being level of scale, you start off in this S, uh, kind of near the origin and you're usually trying... Especially when you're just starting off in the discipline or your career, you have one project, low ambiguity, and you're just saying, "Can I do this one thing? Like, can I fix onboarding?" There's only so many different ways to kind of cut that up and do it. And you know the goal. It's a defined goal. You're just kind of driving towards being able to, to make it improve- make these improvements or make it better or make it better designed, whatever you need to be doing. That's like this one project. And then you kind of move around, along that S at the bottom and you're doing multiple projects with low ambiguity still, but can you handle multiple things and juggle them all at the same time? At some point, you get into this inflection point and you have this one really ambiguous problem set at some point in your career. It's like 10X revenue in 12 months. There's a lot of different ways you could probably do that, but, uh, there's a lot of, uh, wrong ways to probably do that and there's (laughs) a few right ways and you got to figure out which way is up and there's just so much ambiguity and like, um, you, you just don't know how to maybe do that immediately, but that's the challenge for that part of your S curve. And then at another scale, it's like, like towards the top of that S, you're pretty much just doing all ambiguous projects or problems at scale. That's all that hits you. So you think of like a VP of product, CPO kind of level. All it is is strategic questions that you don't know the answers to and have to figure that out across 10 or 12 different, um, topics. And so I think going back to like w- how to attract these types of talent, know where on the S curve they are and what's their next step in that S curve. Because then you can say, "All right. The... If..." I can then give you a fun challenge for what you need next in your career. I think senior folks want to know, "Is the problem area big enough? Is it meaty enough that where I wake up every day and I get to be working on this scope and, uh, working to serve these types of customers? Will it challenge me? Will it make me a better PM?" Those are the... kind of the considerations that they're making. And then the second consideration is like, "Who do I get to work with?" So, uh, we actually kind of talked about this in a recent post that we wrote for your newsletter of like the functional, um, types of organizational structures, and I think when you have a functional structure within your org, it's really nice 'cause then you can say, "Oh, I get to work with these types of PMs," 'cause there's a product lead, there's a product, um, group, and y- you want to... I play tennis. You want to play tennis. You want to, uh, challenge yourself with people that are a little bit better than you and, you know, bounce that ball back and forth and it's fun. And the same thing goes for like the functional leads within design and eng because those are going to be your peer groups. You want to make sure that you're working with folks that, you know, uh, are excited and, uh, are fulfilled by doing this kind of work. And so for me, it honestly comes down to those pieces, understanding that... the candidate where they are and then communicating things, uh, to them in a way that like-... breeds transparency, honesty, trust, uh, overall. It, I tell them when I have conversations with candidates, the good, the bad, the ugly, um, I want to be as upfront as possible and like where the challenges are for us right now, and where the opportunities are. What I see as like, you know, you, you don't want to overpromise, but you do want to sell some, uh, the dream of why you're excited.

   4. LRLenny Rachitsky30:54

      So, that was awesome. There's so much here. So, I'm gonna reflect back a few of the things you said. So, when you're trying to hire the best people, a few things here that are really helpful is, one, this S-curve, I drew it as you were talking, of ambiguity versus scale. And it almost sounds like there's kind of like two things people would want potentially. One is more ambiguity, just something really meaty and complicated, which is like they're accelerating on, up that S-curve. The other is more scope. They're already really good at... They've done a bunch of really complex, ambiguous stuff, and they just want something bigger and, and more impactful.

   5. RPRohini Pandhi31:27

      Yeah. That's a great way to, uh, like... Probably a third dimension on all of that. (laughs)

   6. LRLenny Rachitsky31:31

      And I love that it's not just like a up and to the right, like, linear line. It's an S-curve where it's like, okay, now you're on something really complicated-

   7. RPRohini Pandhi31:37

      Yes.

   8. LRLenny Rachitsky31:37

      ... just going, walking it up this ambiguity-

   9. RPRohini Pandhi31:40

      Yes.

   10. LRLenny Rachitsky31:40

       ... kind of Y-axis.

   11. RPRohini Pandhi31:41

       Exactly. And it's... And you can kind of trace back, like, our own careers into this idea, or like even engineers and designers. It doesn't have to be a product S-curve, but it's, it is really interesting to kind of see it from like, oh yeah, this is how you get good at the functional skills. This is how you get good at the strategic skills.

   12. LRLenny Rachitsky31:57

       What was that project for you, the one that shot you up the S-curve on ambiguity?

   13. RPRohini Pandhi32:01

       Uh, I think it was probably, uh, at Square. Uh, I worked... One of, um, the first products that I worked on there was, uh, invoicing. And it was one of those projects that was like... It was a hack week project that just did really well. And we got a team on it. There was, I think... At the time that we, I started, it was three engineers, a designer, and myself. And it was like, "Okay, just go make this work." (laughs) And, uh, a lot of the first sets of work was like, "Oh, we just need to make this less hacky. Just make this a real product that, uh, you know, you're not embarrassed to, to be serving up to customers that are using Square Invoices." And then, uh, very soon, you started kind of seeing the next levels of work that needed to happen. And, um, for me, that was the first time that I got to really just drive this, um, the strategic plan. So like, Square Invoices, first, step one was like, just get it to a place that was functional. It was, it was... The first rev of this product was almost... People would use it, but they would have to spend so much time in order to figure out how to use it. That's honestly where, when I knew that we had product market fit, but we just needed to make it better. And then the next insight was, oh, the people that are using our Square mobile app, no idea that Square Invoices existed because it only existed on des- desktop, on dashboard web. And we're like, "Okay, get into mobile." That was the ne- like, truly a- another st- uh, step of growth that we just saw. Uh, and then, like, it was a huge step function there. And then the next one was we wanted to, uh, draw out people. So, instead of going after existing Square customers, uh, we wanted to be a front door product. And that drove another step change of, of growth for us because it was like, oh, when you're looking for invoices, you don't think of Square immediately. You're just looking for invoicing solutions, and so the app store and those types of places were much more interesting for us to, uh, go after and do SEO and SEM on and find net new customers. So, there was some, like, really interesting challenges of saying, "Okay, how do I increase, how do I increase the top of funnel? How do I then also decrease risk loss at the, the loss level?" Um, and just being able to kind of play around with all those different levers was my huge ambiguity experience. (laughs)

   14. LRLenny Rachitsky34:17

       Yeah. Speaking of levers, that's... I was gonna highlight just... I love the, the way you described this, as a such a good example of a great product manager skill of just breaking the problem down into these step-by-step steps, uh, versus like, "Oh, shit. We have to scale this massive business of invoicing." It's just like, make it less hacky, make it easy to discover, bring it, bring in new customers. Uh, and so I think that's a really good skill to learn as you're ramping up this curve of ambiguity.

   15. RPRohini Pandhi34:43

       Absolutely. Yep.

   16. LRLenny Rachitsky34:45

       Awesome. Okay, and then coming back to, like, the other tip you shared of how to hire amazing people, just to close that thread, it's-

   17. RPRohini Pandhi34:50

       Yeah.

   18. LRLenny Rachitsky34:51

       ... uh, make it clear how awesome the other people at the company are that you're gonna work with-

   19. RPRohini Pandhi34:55

       Yes.

   20. LRLenny Rachitsky34:55

       ... because, like you said, you're gonna learn the most from playing tennis with awesome people, and these-

   21. RPRohini Pandhi35:00

       Exactly.

   22. LRLenny Rachitsky35:00

       ... awesome people want to work with awesome people.

   23. RPRohini Pandhi35:02

       Exactly. And I think the other thing to, like, add on to that is the candidates are, um, testing you as much as you're testing them. And so you're... That's why we had to do the interview revamps, because I would judge a company based on the interview questions that they would ask me. As a senior lead, I want to know that they understand what they're even asking me for and they understand how to kind of change those prompts around for the right type of candidate. And so a lot of what we did was revamp things based on just my experience of the Mercury interview process. (laughs)

   24. LRLenny Rachitsky35:33

       Oh, that's... I love that. (laughs) That's dogfooding it.

   25. RPRohini Pandhi35:38

       Exactly.

   26. LRLenny Rachitsky35:39

       Okay. So, I want to talk about quality, and I want to t- talk about multiproduct, going multiproduct. Let's start with quality. So, uh, classically, a lot of PMs are just not, uh, the person that advocates for high-quality user experience, investing in things that aren't moving metrics. And I know you're kind of on the opposite

8. 35:59 – 44:10

   Advocating for quality in product development

   1. LRLenny Rachitsky35:59

      of that. You actually have a really interesting approach to advocating for quality and helping people understand why it's worth investing in. And in particular, you've worked on, uh, in quote, "boring," boring products, banking, finance stuff, but have ma- helped make them awesome and great experiences. What can you share with folks about how to advocate for investing in quality when it's not something you can really measure?

   2. RPRohini Pandhi36:23

      This is something I've, I've learned a lot from the Mercury folks, uh, over the last year, even the r- like, OGs back at Square in the early days. There was a lot with, um...You know, on the surface... I think Emad even says this, on the surface, it's completely irrational to invest in quality, right? Like, especially for a KPI-driven company or... KPI-driven company or organization, there's often this, like, false dichotomy that creeps up that's like you either have to be this quant heavy of, you know, uh, experimentation, like move fast type of company, or you can be this design heavy, focus on artistry but doesn't really drive any customer value, and I feel like those two ends of the spectrum are just, uh, completely insane. You need to be somewhere in between. But... And I think, like, what I've learned from the- the companies that I've most recently been at is the details done right really matter. The- especially when you're in, like, a boring industry like fintech (laughs) , meaning, like, it's just unsexy. There's not a lot of, um... You know, it's not like this consumer exciting app, but you need the details to be, uh, precise, to be intentional, in order to breed that trust and confidence that the customer base needs in order to save its money with you, in order to move its money with you. One of the examples we had recently was we, we launched a product called Bill Pay, and in that, you can kind... You can upload an invoice, you can just drag and drop your invoice, like, from a vendor, and we will OCR it. We'll, like, read all the details, and we'll prepopulate some fields for you. And as you kind of go through those fields and check that we got everything right, the right-hand screen kind of zooms into the right part of the, of the invoice. And that little, that little, uh, detail, that little additional, like, "Hey, we just helped you with this and highlighted where you needed to be," won't, won't move a completion rate, won't move a singular metric, really. But it is the thing that everyone who uses this product, every customer that comes to me, they're like, "That was fantastic. I loved using a product to pay my bills," which is not something you hear every day (laughs) . And I think one of the Mercury values that I've really tried to internalize is, like, have an... Have that intention behind every detail in order to make the product... In order to take that product to that next level of care and, and craft. And when you consider, like, the compounding effect of all those little intentional incremental improvements, it... Altogether, it- it starts becoming a mode. It becomes this competitive advantage for you. And so, I think there's, like... There is an argume- a strong argument to really think about quality, craftsmanship, however you're building something that can be evergreen and, um, beautiful, confident, um, confidence-inducing, and- and trustworthy. And then on the other side of it, like, I just think it's... Building great products should be fun and fulfilling for all of us. And so, you want to spend your life on something that you... that people love and enjoy using. I think that's something that Jason's really taught me. And so, like, by doing this, by investing in quality, by thinking about quality, you're also having this second order effect of attracting great talent who want to be there and be proud of what they're building. And then it, it also has this effect of, like, endearing customers to you, because they know that you're focusing on what matters and how to make their lives a little bit easier and better and simple. And so, it's this circular effect that I do think has compounding interest rates on it (laughs) .

   3. LRLenny Rachitsky39:38

      There's a couple of things here that I think about as you talk about this. One is, if there's, like, a PM at some, you know, bank that's like, "Oh, great. We're gonna do this. I love it. We're gonna invest in quality. We're gonna make beautiful product," it's hard to do in reality if the founder is not on board and if it's not kind of core to the principles and values of the company. And so, I think you almost need that kind of top down. And the other thought is, I feel like there's kind of, like, strategically, we will differentiate by blank, and one of the blank can be quality. Like, Linear is a great example. Mercury's a good example. A lot of competitors in the space, we believe we can win by quality and experience. I don't think that exists in every market, but thoughts on just, like, that is like, if you decide this is our differentiator, then that's a huge opportunity to invest in quality in the US.

   4. RPRohini Pandhi40:28

      Yeah. I completely agree with both points. Like, one, it has to come. It's a cultural value. It has to come from the top. It has to come from the beginning. And I think the second piece of it is, like, there's a... There was, like, this trend of, I don't know, B2B products that became, I think, like... I don't... Maybe a decade ago, a lo- a big push was simplify it. Make it feel like a B2C product. Make it simple. Make it easy to use. And there was this push of just, like, I don't know, rounding corners and making the fonts better or something like that. Ma- you know, using some white space. Just, like, very simplistic ideas of it, but now, we... I think the, the next generation of all of these products is not just, make it simple. Make it still powerful, and make it easy to use. So, now you have both concepts coming together. And so, quality is truly just this idea of, how do you build these products that fit within a s- you know, a small mobile screen and still have the full power and capacity of, like, an enterprise level product line, um, but are still easy to use on the go and being able to do a bunch of banking that wasn't even close to this level of, like, ease and customizations in, I don't know, two decades ago? It's something that we really think is kind of the basis of why quality is, like, im- embedded into everything that we talk about and do. It's, it's an obsession within the company, quite honestly.

   5. LRLenny Rachitsky41:50

      Mm. Interesting. Uh, so yeah. I think... I feel like there's a big rise in, "We will just make beautiful, incredible, craft- high-craft products," probably because there's so much competition and so much, uh, so many options that that's, like, one of the few remaining ways to differentiate and stand out, especially in a boring industry, is... Uh, like, another example is a company that I'm invested in, it's called Zip, which is procurement, and there's all these boring-ass companies that were just... Are, like, billions of dollars and just so ugly.

   6. RPRohini Pandhi42:18

      Yes.

   7. LRLenny Rachitsky42:19

      And it's like, "Cool. Here's how we can compete. We'll build an incredible-"

   8. RPRohini Pandhi42:21

      Exactly.

   9. LRLenny Rachitsky42:22

      "... experience."

   10. RPRohini Pandhi42:22

       Nobody wants to be at the other, like, the audience end of this (laughs) or the user end of this.

   11. LRLenny Rachitsky42:27

       Right.

   12. RPRohini Pandhi42:27

       And so, you don't want something that, like, "Oh, it's for procurement, so therefore they don't care." No. Everyone wants to have a nice experience (laughs) in dealing with the work that they have to do day in and day out.

   13. LRLenny Rachitsky42:36

       Mm-hmm.

   14. RPRohini Pandhi42:37

       And so, I really do love s- unsexy products, um, that-... can just be done right and, you know...

   15. LRLenny Rachitsky42:44

       And that's a cool opportunity for PMs to just, like, find a company that is struggling in a market that's big and just, "Maybe this is how we win." Just make it incredible versus more features. And I feel like... I should write a post about this. What are the ways to differentiate? There's experience, there's probably price, there's maybe features, just like we have the most features, like Jira. There's probably a few others.

   16. RPRohini Pandhi43:05

       Probably the customer segments and, uh, who you're going after.

   17. LRLenny Rachitsky43:08

       Mm-hmm, mm-hmm.

   18. RPRohini Pandhi43:08

       Yeah, I love the, um... Yeah, I love this thread. I think we could talk about that for another hour.

   19. LRLenny Rachitsky43:13

       Oh, man, this could be a whole other... (laughs)

   20. RPRohini Pandhi43:14

       (laughs)

   21. LRLenny Rachitsky43:15

       That'll be your... Our second... Or your second visit to the podcast.

   22. RPRohini Pandhi43:19

       (laughs)

   23. LRLenny Rachitsky43:19

       This episode is brought to you by Airtable Product Central, the unified system that brings your entire product org together in one place. No more scattered tools, no more misaligned teams. If you're like most product leaders, you're tired of constant context switching between tools. That's why Airtable built Product Central after decades of working with world-class product companies. Think of it as mission control for your entire product organization. Unlike rigid point solutions, Product Central powers everything from resourcing to voice of customer to road mapping to launch execution. And because it's built on Airtable's no-code platform, you can customize every workflow to match exactly how your team works. No limitations, no compromises. Ready to see it in action? Head to airtable.com/lenny to book a demo. That's airtable.com/lenny.

9. 44:10 – 46:37

   Going multi-product

   1. LRLenny Rachitsky44:12

      Okay, so let's talk about the final big topic that I know you're passionate about. And this is what you work on at Mercury, which is super cool.

   2. RPRohini Pandhi44:18

      Yes.

   3. LRLenny Rachitsky44:18

      Which is going multi-product, going from one product that is doing well to layering on additional products.

   4. RPRohini Pandhi44:24

      Yeah.

   5. LRLenny Rachitsky44:24

      This is kind of the holy grail for a lot of founders, a lot of teams. Expanding TAM, finding more ways to generate revenue, expanding into your customers, building new products. You've done this at Mercury. Block is really successful at this. So, uh, I want to learn everything I can from you about how to do this well. A lot of companies try this and fail and waste a lot of time. So, let's just talk through this. What are maybe just, like, lessons from your experience building products, multi-products, additional products at a company like Mercury? Maybe just share some of the new products that Mercury has, just 'cause... To give folks a sense 'cause I think b- people think of Mercury as a bank.

   6. RPRohini Pandhi45:00

      Everyone still does. And so we're in the early days. So yeah, I'll take this opportunity to make sure that we talk about which products first and then I can go through kind of our lessons learned. But we shipped a lot this year. There, there was just a ton of activity this year, which was really exciting. 2024 marked the first foray into consumer for us. We launched Mercury Personal Banking in April, which has been a wild success, and we have a lot more coming up with personal banking as well. And then we launched a suite of software that sits on top of our business banking and, like, our core offering. And that s- uh, suite allows our customers to do things like, you know, the accounts payable work that they need to do as they grow, um, accounts receivable, accounting workflows, those types of things. And so in the last, um, let's say like six, seven months, we launched what I talked about before was bill pay in, in May. We launched invoicing, uh, something near and dear to my heart, in August. Uh, we had updated, like, spend controls and spend management tools and employee reimbursements that launched in October. And each of these, one of the... One of my favorite, um, learnings from all this or the favorite stats is each subsequent launch that we just described took less time than the previous from concept to launch. So, we're getting really good at, like, understanding what that product velocity is, how we build products, and then how we launch and find the right product market fit within these systems. And so a lot of exciting stuff. We're still in the early days of kind of, uh, building out the SaaS model, building out personal banking, but lots more to come. So, excited for kind of where Mercury's set up for in the next few quarters.

10. 46:37 – 50:57

    Organizational structure for multi-product success

    1. RPRohini Pandhi46:38

       Going into some of the- maybe the biggest lessons learned about going, like, from one product to multi-product, there's probably, like, two general categories. One or- the organizational structure is really important and probably as important as just the product decisions, and the organizational, like, culture is also important. So, one thing we learned was, like, having, um, new product areas, new seedlings being too close within the, like, true org structure to the core banking or payments or mature products made it hard for that new product to even grow, because they were always being pulled in, sucked in. The gravitational force of, like, a- a- more mature product always had prioritization work, maintenance work, things that were more impactful to be done. And so their roadmaps would always get trumped by any of that. So, it didn't afford any space, uh, for seedlings to, to grow. And, um, yeah, like this idea of, like, when you have this small little, uh, fire, you want to give it air in order for it to truly blossom into a flame. And so, uh, the organizational structure really gives these teams that space. We actually created completely different orgs. This is why my team exists as an expansion org, because it is completely separate from some of the more mature product teams.

    2. LRLenny Rachitsky47:53

       And when you say separate, like dedicated resources-

    3. RPRohini Pandhi47:55

       Yes.

    4. LRLenny Rachitsky47:55

       ... on this project for some number of months? Like, what's the timeframe you give new seedlings?

    5. RPRohini Pandhi48:01

       We're- we're thinking of these compan- like, these as small seed stage companies, and every quarter, every, uh, half year, we look at them as like, "Do we want to keep investing?" And so, there's no end time for them to ever move back into the mature products until they become, I don't know, a series C company, uh, in and of themselves. So, we're not- we're not really, like, looking at an end time. We're just saying, "You have this dedicated team. We will continue investing and- and providing headcount and whatever you need as- as this product, this business line shows, um, the path towards success."

    6. LRLenny Rachitsky48:34

       And I think that- that point is really important. So it's basically every quarter slash two quarters you check in, "How's this going? Do you agree to here's a milestone that we're looking for in the next quarter, six months?" Any... Do you make it super concrete? Is it pretty qualitative? How do you think about that?

    7. RPRohini Pandhi48:48

       We have goals, and we also allow these teams... They're so early that, like, the learnings are really important. It's just like an angel investment. There's gonna be pivots. We realize that. We- we're not saying that it's gonna...... you know, we're gonna kill it if it doesn't hit X. But we do have, uh, goals in mind, we have financial projections in mind. And we say, "If you don't hit that, what's, what's the key learning that we made that we think we can still hit something in that ch- general direction in the next six months?"

    8. LRLenny Rachitsky49:13

       And what does a seed team look like generally? What's the, what are the resources you put into it?

    9. RPRohini Pandhi49:17

       We have, I mean, it's, it's the full cross-functional squads of, um, eng, design, product, uh, data science, everyone that you'd probably need, and then we kind of have cross-functional, uh, overlaps with kind of our core teams across the company. So like, uh, sometimes we would, we will have like dedicated, uh, if we need it, dedicated CS or dedicated risk or dedicated ops folks on these teams, but usually it's just, you know, leverage the, you know, central teams that already exist for some of those functions.

    10. LRLenny Rachitsky49:47

        And how many engineers do you usually try to put on a seed investment?

    11. RPRohini Pandhi49:50

        It kind of depends.

    12. LRLenny Rachitsky49:51

        Mm-hmm.

    13. RPRohini Pandhi49:51

        Um, like, our personal banking product has a lot more engineers, probably, you know, a 3X than maybe our invoicing product line.

    14. LRLenny Rachitsky49:59

        Even at the beginning?

    15. RPRohini Pandhi50:00

        You, uh, well, so I think, uh, seeding that, it just required, like we were going after a completely different market. We were going after a different base. And having another banking solution, while we still had one, we, we took a lot of the learnings and efforts that the business banking side did, but we had to rebuild a bunch of that. And so the initial investment just was a different, uh, request. Whereas like in invoicing, we were building the software on top of the banking, and it's just, it requires a different level in order to get to minimum lovable product. And so, you know, we're, we're giving the teams just enough, uh, but we want them to stretch.

    16. LRLenny Rachitsky50:36

        And I feel like there's also a c- connection to how big this opportunity is. Invoicing versus like becoming the new personal bank of the world, you know? So it makes sense why let's just, let's put a few more resources on this one.

    17. RPRohini Pandhi50:48

        Right. Absolutely. I, I would say I think the PMs on those teams both want world domination, so yeah.

    18. LRLenny Rachitsky50:53

        (laughs)

    19. RPRohini Pandhi50:54

        I mean... (laughs)

    20. LRLenny Rachitsky50:54

        Let's not hate on invoicing.

    21. RPRohini Pandhi50:55

        Yeah. (laughs)

    22. LRLenny Rachitsky50:55

        Okay. I understand.

11. 50:57 – 52:07

    Organizational culture for multi-product success

    1. LRLenny Rachitsky50:57

       And so what... Okay. So specifically, they hired you to create this carve-out almost for new product investments.

    2. RPRohini Pandhi51:05

       Mm-hmm.

    3. LRLenny Rachitsky51:05

       I think that's a really cool lesson, just like hire a leader that is overseeing all of these new seed bets versus just a team off to the side.

    4. RPRohini Pandhi51:12

       Yes. I think there's, um... That, that kind of hits that culture that needed to be instilled into this organization too, because we're gonna be a zero to one team, and we're gonna have to work in a little bit of a different way. Uh, our counterparts on like, the core mature products, uh, will use monthly development cycles. They'll, they'll figure out their roadmap for the month and then just start executing on it. I could not find a way in which like, like I wouldn't know what was changing in a month. And so we had to move towards like two-week sprints and then weekly check-ins with a bunch of our, our work just to stay as nimble as possible. We wanted to like, be able to learn, iterate, repeat. And we also have a, like a really heavy-handed culture of customer calls, customer research that the PMs needed to do. Like, there is a, just much more kind of like touchpoint, pulse check with who these customers are. We're going after adjacent areas. And so make sure that, you know, as a team, you know what your customer needs and why it's important.

12. 52:07 – 57:36

    Customer obsession and product development

    1. RPRohini Pandhi52:07

    2. LRLenny Rachitsky52:07

       Can you share more about this customer call culture for folks that maybe wanna learn from how you do it?

    3. RPRohini Pandhi52:13

       It's kind of like, I don't know, just the heartbeat of how we operate. So it, it almost feels so natural that I- I'm not sure if I can impart any new learnings on it.

    4. LRLenny Rachitsky52:23

       That's interesting.

    5. RPRohini Pandhi52:23

       But it's like, I kind of expect a customer conversation at least one a week from the team. That seems like such a low bar to me that I think the teams do close to like... Some teams, when they're really into discovery mode, are doing 20, 25 calls with people. It's wild. Or like even just going through surveys and understanding what, like qualitative imp- uh, info that they're getting from the surveys, quantitative info that they're getting from it. I think all of that really counts. We, we're customer-obsessed at Mercury, and so you'll even see like Ahmad will talk to folks on Twitter or on X, um, directly. We'll get pings, um, from different folks across the company. We'll look at why people, um, off-boarded with us and we get those messages in a Slack channel, and it just kind of hits every like, whenever it happens in real time. And so all of those pieces are customer touchpoints in my mind. And so it's like get on a call with CS, get on a call with RMs, drive those calls yourself, but just learn as much as you can from what our customers need and what they're doing.

    6. LRLenny Rachitsky53:24

       I'm gonna follow this thread a little bit more because, uh, one, a lot of companies say, "We're customer-obsessed. Our teams are customer-obsessed. We love cus- talk to customers all the time." But they still build bad stuff. What do you think they often miss that maybe you're doing that companies you've seen actually that, uh, really are obsessed and do this well, that often is missed when people think they're doing this?

    7. RPRohini Pandhi53:44

       I think there's a little bit of like what a customer says versus what they want are gonna be two different things nece- Like if you... I think there's just so many inputs to all of this, but like if you take just a conversation, people are really nice, especially when they're talking on the phone. They'll be really nice. They'll say nice things about your product. They'll tell you that they messed up and, and the UX is great. You built it the right way and they were doing something wrong. And they try to take some of that pressure off of you, and what you don't want is to go into a conversation with a bias. You wanna be a researcher. You wanna be like this third party, non-judgmental kind of like you're br- you're being brought into the jungle and just watching what's happening. You're an observer. You're being a, like a documentarian. It's, it's not about getting f- your biases checked or validated or in- unvalidated, invalidated, but it's like just understand what it is that the customer's trying to do, what context they were trying to do it in, and get to a truth that seems to like find a pattern or you hear about multiple times and then, then validate that truth and see if that still sticks. Like, have a prototype, do betas, see if the numbers actually work out in your favor. I think the other thing is like, the customer obsession needs to also be anchored back into does it...... work for your business. Just because a customer wants it, they, I mean, they probably want free products. (laughs) That doesn't work for what we're gonna be able to serve them with, uh, and still be a viable business and still survive. And so, uh, y- I think I actually used a lot of, when we were doing pricing, I used a lot of, uh, insights from your podcast with Madhavan.

    8. LRLenny Rachitsky55:17

       Mm-hmm.

    9. RPRohini Pandhi55:17

       That was a great, I mean, if I can, um, promo a different (laughs) podcast episode on, on this one, that was great. I think I listened to it twice just to hear it a few times. And I think there was an example of, like, a water, um, at a fountain is free. A water at a hotel is like five bucks. A water on the plane is, uh, d- like, it, it, the context and the price of what you're offering somebody changes the value perception of what they're getting delivered. And so, I think that, like, customer obsession needs to be just anchored back into the business and the business needs and, like, what you can actually offer. And so, it all needs to be triangulated and balanced out. And so, it's not just customer obsession for the, uh, sense of customer obsession, but where does it, where does that artistry meet the business?

    10. LRLenny Rachitsky56:06

        Awesome. That was a great example. We'll link to the, uh, Madhavan episode-

    11. RPRohini Pandhi56:09

        (laughs) Awesome.

    12. LRLenny Rachitsky56:09

        ... for folks that want to check it out. And then one very tactical question, how do your teams find customers to talk to and organize that? Is there anything operationally that folks can learn about how you do that?

    13. RPRohini Pandhi56:18

        We do have a UXR team, which is great. We have a research team, um, and so they can, they help us, like, make sure that we can schedule it. Honestly, the scheduling Tetris that has to happen is probably the hardest part in a PM schedule, um, 'cause you're going from meetings to meetings. So, it's like, uh, sometimes we'll just have dedicated research weeks where we just, we know there's a question that we need answered and we need to go through that discovery. And so, we'll clear off our calendars and just book customer calls. When it's like regular kind of sessions that are happening every week, then it's like, then we try to leverage, um, kind of like a central team to help us manage those calendar and meeting invites and getting people booked. Um, we'll also just kind of get in the sidecar of an RM call or a sales call or a c- uh, CS call whenever we can. Anybody who's doing any sort of research or, like, voice of the customer calls, anything like that, we're in (laughs) and we want to hear about it. And then we're also looking and just kind of responding on X or on email or, we want to hear from people, so find us any which way you can. (laughs)

    14. LRLenny Rachitsky57:20

        Okay, cool. And then, uh, what does RM stand for, by the way?

    15. RPRohini Pandhi57:22

        Oh, sorry, sorry, uh, relationship managers, our sales team.

    16. LRLenny Rachitsky57:24

        Okay, cool. So, like account managers?

    17. RPRohini Pandhi57:26

        Y- yes.

    18. LRLenny Rachitsky57:26

        Awesome. Okay. I'm gonna come back to where we were. I've pushed us off track.

    19. RPRohini Pandhi57:30

        (laughs) All right.

    20. LRLenny Rachitsky57:30

        We're, I'm gonna bring us back on track. So, we're talking about things you've learned about building multi-products-

    21. RPRohini Pandhi57:35

        Right.

    22. LRLenny Rachitsky57:35

        ... additional products

13. 57:36 – 1:05:57

    More lessons from going multi-product

    1. LRLenny Rachitsky57:36

       at a company. Uh, the first kind of theme was the org and creating barriers almost to pulling resources away from these seedling teams into your core.

    2. RPRohini Pandhi57:46

       Yeah. I think the, the other decisions that we had to make that might be helpful to folks was like, what are the next products? And so w- we really looked at like, okay, we need to, we need to find solutions that tie closer to the existing spaces we're in, or there, it needed to be like an adjacency that's just, just beyond the core. So, you're not like, it's not about just building a new feature. You are building a new product line. So, what is that, that adjacent customer segment that would be interested in, in a deeper, more fuller, like, product experience? A good example is, is invoicing. We de-risked that when we were thinking about, okay, what's the next set of products that we could look at? We, we looked at a bunch of different, um, areas and were really, like, thoughtful a- around who is our, our target segment, our ICP, and then who do we want to serve? And we saw some like, some work that was interesting 'cause we had this, this concept of this product called, uh, payment requests, where you could send somebody a URL. They could go to that URL and send the money that they owe you directly to your bank account. And that had traction. And so that, that was something that we, like, used as a kind of competitive advantage because we were like, "Oh, we can talk to people that were already doing something that was like invoicing, which is a request for payment over the web." And so, um, we talked to a bunch of those customers. We also knew that we had a distribution advantage 'cause if we already had people that were using this, we could probably get more folks that were, that were on M- Mercury already. We didn't have to go find them outside. We didn't have to do a full go-to-market effort. We could just kind of test out if they had a fuller invoicing solution, would they want to use that? And so, we, we used, uh, that adjacency to our advantage and our distribution to our advantage and said, "Okay, let's, let's build out these next products that are kind of in that same ecosystem or universe, uh, and see what works and see what sticks." We also kind of used that current UX to drive the attach to these new products. So, on the opposite sideline, like the, uh, accounts payable side, when you're sending a payment, we highlight bill pay if you need more complex vendor payments. And so, it's a really easy way to just fit into the natural flow of what a customer's doing anyways and say, "Hey, do you actually need something more robust? We have something for you. Try it out."

    3. LRLenny Rachitsky1:00:01

       So, the two kind of some attributes you look for is, can, have you de-risked that, like, basically you're already seeing there's a need here from kind of a baby feature of that product, and then do you have a distribution advantage essentially? Can you find a way to get people, get in front of people in your existing product?

    4. RPRohini Pandhi1:00:19

       Exactly. That's it.

    5. LRLenny Rachitsky1:00:21

       And then there's probably just like TAM. Is this like a big opportunity? Is this, and then just thinking about-

    6. RPRohini Pandhi1:00:26

       Right.

    7. LRLenny Rachitsky1:00:26

       ... what are the biggest opportunities we have?

    8. RPRohini Pandhi1:00:28

       Right. Yeah, we did all of that kind of like pre-work as just, you know, does, is it even viable? And then, do we have an advantage around that? And I think the, the places that we hit are like, yeah, we already have an advantage. This would be, there's a, a little bit less friction in order to get to the escape velocity that we need. And then, like right now, I think once you start laun- once you've launched, that's one step. That's one, like, big hurdle. Then there's, um, the next hurdle, which is really trying to find that product market fit, and that's where we're at now. And I think that's a really important lesson of don't go from launch to try to like revenue optimize or find that efficiency immediately. I think you, what we, what we really want is to give away that, the second product, the third product, a-... for free, encourage as much usage and engagement and retention to show that there's something there, and allow customers to feel good about how they would use us in their workflows. And then once they get to a place where they're needing more complexity or needing some, like, areas where they could save time and drive some, like, just ease of use, then yes, they'd, they'd actually be willing to pay for it. But it's not like you, you put this paywall in and then automatically just launch a product and say, "Now you have to pay us." We want to encourage this idea of, like, what worked for our core product, we were always free to customers. Now, we had to go to kind of a paid offering. And so, we want to make sure that people feel good about it. We're not overcharging customers that are too small and don't want to pay, and we're really focusing on the customers that need that extra, you know, the, the heft that comes with these products.

    9. LRLenny Rachitsky1:01:57

       It's interesting 'cause if I reflect back to the Madhavan pricing episode, he's actually like, "Don't ever discount. Charge exactly what you want to charge at the beginning 'cause that's actually a test of product market fit." How do you think about that balance?

    10. RPRohini Pandhi1:02:08

        Yeah. I think I really love this idea of like the, um, what he talked about was like know what your product value is and you have to put a price on it in order to know that. And I think we do see that, we just don't, uh, we're, um, our target customer for these products is someone at the other end of the complexity scale. It's not everyone that we serve right now with our banking solution. And so, we had to be really tight about who that ICP was. And then yes, we do put that price in front of them and say, "Tell us that it is worth X dollars or Y dollars," and we did a whole, like, willingness to pay process as part of the homework for that. But I think it's, there's, like, this customer journey, um, with these products, especially accounts payable, accounts receivable. You don't need that immediately when you start a business. You do need a bank account immediately. (laughs) And so, you need somewhere to save your money, you need somewhere where you can move money around, but there might be 6 months, 12 months, 18 months until you need something that's more complex to pay your vendors or to receive payments and things like that. And so, at that point, that's when we wanna have the pricing conversation with you and may, and say, "We have this product already available. It works seamlessly. It's beautiful with your bank account. You don't have to do anything more."

    11. LRLenny Rachitsky1:03:18

        Got it. So, it's essentially, it's just a part of the journey of finding product-market fit and figuring out what to build-

    12. RPRohini Pandhi1:03:22

        Exactly.

    13. LRLenny Rachitsky1:03:22

        ... is let's just see if anyone even wants this at all for free. And then it's, "Okay, here's a product-"

    14. RPRohini Pandhi1:03:26

        Well, there's-

    15. LRLenny Rachitsky1:03:26

        "... we should probably charge."

    16. RPRohini Pandhi1:03:26

        Yeah. And there's, like, some basic functionality that we think should still be free. Like, our core banking-

    17. LRLenny Rachitsky1:03:31

        Mm-hmm.

    18. RPRohini Pandhi1:03:31

        ... core money movements should always still be free. So, when invoicing asks for a different kind of, like, metadata on top of that money movement, that should still be free. But when you need anything more complex and you really are offering your services or consulting fees or, uh, products or goods, and you do need an invoice solution that, like, works really well with your accounting and then you, you know, your CPA knows how to track all of that, then that's a paid product.

    19. LRLenny Rachitsky1:03:55

        Awesome. Is there anything else along these lines of building a new product, layering on additional products that you think might be helpful to people? I'm also curious if there's any missteps you've had along the way, uh, either at Block or Mercury of building something that just failed, which I imagine.

    20. RPRohini Pandhi1:04:09

        Well, one, one other learning that I've had from, like, the Block and Mercury world is, like, one thing that Gokul always said, um, and something that he said he learned from Jack actually, was something that I, I feel like is very true with the Mercury co-founders as well. They're never, uh, hyperfocused on the revenue. They're never focused on a number that they're trying to drive. They really want to build the, they keep telling these, the teams to build the products that people love, and the revenue will just be a byproduct of that. And so, if you can get this one step done, the, the second step is almost a, um, it- it's a, like, you, you will get there. And so, I think that's one learning. I think one, a few missteps that we have made but we're trying too many things at once. It's, it's the classical example of like, "Oh, we have so many ideas. Let's go build all of these things." And then there is, like, an element of you're gonna understaff these new efforts. There's not gonna be enough folks to, again, take that seedling, put it into the ground, put (laughs) enriched soil on it, water it, take care of it. And so, trying too many things, understaffing them, and then there's just a lot of, a lot of, uh, missteps, uh, learnings around pricing that I think we've, we've talked about a bit. But we were, there was a lot of internal discussions on, like, pricing model bundling versus a la carte, um, how we would price it, how much work we would do on, like, understanding that willingness to pay. Um, all of those pieces were exciting.

    21. LRLenny Rachitsky1:05:35

        Is there a product that you launched that d- just did not work out, fail, in spite of doing all these things? Or have generally things been successful in your, on your journey of adding new products?

    22. RPRohini Pandhi1:05:43

        I think we're still early, and so I don't want to say that there isn't a failing yet or anything like that. But I do think everything's showing really strong positive signal. But yeah, fingers crossed. Uh, we'll see how things go, and it's always an iterative, uh,

14. 1:05:57 – 1:09:54

    Transparent Collective: supporting underrepresented founders

    1. RPRohini Pandhi1:05:57

       process.

    2. LRLenny Rachitsky1:05:58

       Awesome. Okay. Last thing I wanna touch on is something that I know s- you're passionate about. This is kind of outside the core of our conversation, but, uh, I'd love to spend a little time on it. You started this organization called The Transparent Collective.

    3. RPRohini Pandhi1:06:09

       Mm-hmm.

    4. LRLenny Rachitsky1:06:09

       Uh, former guest IOs told me I need to ask you about this.

    5. RPRohini Pandhi1:06:13

       Oh, that's awesome.

    6. LRLenny Rachitsky1:06:14

       Yeah. So tell me what The Transparent Collective is, the impact you've had with it, and what folks, uh, should know if they wanna check it out.

    7. RPRohini Pandhi1:06:21

       Oh, gladly. That would be great. Um, so Transparent Collective is a 501 (c) (3) nonprofit organization. Um, we help underrepresented founders get access to resources, connections, uh, whatever they need to build successful tech companies. Uh, we started this, gosh, I think it's been about nine years now, eight or nine years ago, and, um, it really was born out of just this, like, organic, uh, conversation that happened. Uh, uh, my co-founder and I, uh, met up for drinks one night. We both knew each other from, like, Michigan back in the day, went to school together, and we were talking about how, um, we both kind of went on this entrepreneurial journey. And trying to raise money in the Midwest was very different than raising money in New York, which was very different than trying to raise money and, and sell this dream in the West Coast. And so-... where we kind of, like, had to learn a lot of the tribal knowledge that just existed, uh, on our own, we wanted to create this collective, uh, that transparently shared information with one another in order to ... Where we kind of start at step one, we would have the next generation start at step two, and then pay it forward. And so we ... Like, our programming really focuses on, like, preparing founders to fundraise, being able to connect investors to high-caliber founders that, that we have in our Rolodex, and then also the, the entrepreneurs to, to the right investors for them, and then just ultimately contributing to an ecosystem that can, like, really, uh, allow these types of founders to flourish. So, we host a bunch of programming, webinars, workshops, that kind of thing, but our, uh, our kind of, like, um, spotlight event is we fly founders in from all over the US, uh, once, maybe twice a year to participate in our seed programming. And so we have, like, 200 to 250 applications that come through. Uh, we bring about 8 to 10 founders in to join us for a week in SF where we pay for everything, and we have, uh, sessions for mentoring, small group workshops. Um, we even do hands-on training. Like, we'll ask our investor friends to come in and do mock investor meetings and kind of get the, get the butterflies out from- for these founders that are coming in from all over. They're not coastal founders. Um, there are folks that come in from Detroit or Baltimore or Atlanta, and they have amazing companies. And so, uh, we kind of just connect the dots and help them, uh, along the way. So far, I think we've had 90-plus alums, uh, across our 11 batches, and I think 65% or 70% of them have raised venture funding now because of our programming. I, I think we have a total of, like, $125 million in seed, uh, e- early-stage fundraising from, uh, across all of them. And I think we've now done it for so long that about 10% are already acquired and exited companies too in our, in our alumni group.

    8. LRLenny Rachitsky1:09:06

       So cool. Such a, such a, a thing that obviously should exist, and I love how well it's going. For folks that either ... And it's a ch- it's a 501 (3) (c) , you said?

    9. RPRohini Pandhi1:09:15

       Yes.

    10. LRLenny Rachitsky1:09:16

        So for people that either wanna donate and support this work or people that want to apply, how do they do that? What's the best way to learn more?

    11. RPRohini Pandhi1:09:25

        TransparentCollective.com. Uh, we have both-

    12. LRLenny Rachitsky1:09:28

        (laughs) Easy.

    13. RPRohini Pandhi1:09:28

        ... a donate button there and an application button. So yes, we would love to ... I think we're starting to figure out the next batch, and so great applicants, please come and, and drop your, uh, information. And then we do operate on donations, and so we would love to find folks that would be interested in helping us, uh, achieve our mission.

    14. LRLenny Rachitsky1:09:46

        I love that. It feels like in a perfect world, there would be no need for this, but we are not in that world, and I love that this exists to help folks. Um,

15. 1:09:54 – 1:11:59

    Lightning round

    1. LRLenny Rachitsky1:09:54

       Rohini, we've covered so much stuff. You're awesome. With that, we've reached our very exciting lightning round.

    2. RPRohini Pandhi1:10:00

       (laughs)

    3. LRLenny Rachitsky1:10:00

       Are you ready?

    4. RPRohini Pandhi1:10:01

       Ready.

    5. LRLenny Rachitsky1:10:02

       All right. Here we go. First question, what are two or three books that you find yourself recommending most to other people?

    6. RPRohini Pandhi1:10:09

       I got this book recently called Vectors: Uh, Aphorisms a- uh, Aphorisms (laughs) and, uh, Ten-Second Essays. It is so much fun to just kind of, like, pick out a couple of these, like, ten-second essays at night and just read a couple of these and go to bed. I'm, I'm gonna recommend it to other folks. A friend gave it to me, and I'm gonna pay it forward. Um, and then the other, I guess, the other one that I really just enjoy is, uh, this book called The Inner Game of Tennis. I've al- already mentioned that I'm a tennis fan, but, like, it talks about the state of flow that you need when you're playing and, like, this idea of relaxed concentration. I just love that idea of how do you get into that state of flow in your day-to-day. Um, other books that I think, that I've read recently are- have all been fiction, so Pachinko, Cutting for Stone, Song of Achilles, all great ones that I've read recently when I've had some beach time, so highly recommend.

    7. LRLenny Rachitsky1:11:01

       People love fiction recommendations-

    8. RPRohini Pandhi1:11:03

       Okay, great.

    9. LRLenny Rachitsky1:11:03

       ... on our podcast, so I'm glad you threw those out. The Inner Game of Tennis, I know ... Uh, I read, I think, half of it, and then I some- for some reason stopped, but, uh, it's important to note, it's, like, tennis is kind of this metaphor, and le-

    10. RPRohini Pandhi1:11:14

        Yeah.

    11. LRLenny Rachitsky1:11:14

        ... its lesson's from this coach that t- taught people how to be amazing tennis players, which apply to all kinds of greatness.

    12. RPRohini Pandhi1:11:20

        Exactly. And I, I will say, I love stopping a book in the middle sometimes when-

    13. LRLenny Rachitsky1:11:25

        Mm-hmm.

    14. RPRohini Pandhi1:11:25

        ... you just can't finish it. (laughs) I, like, I don't know why I waited for someone to give me permission on that, and I think it's a, it's really helped me. Like, oh, I got through a few starts of books. (laughs)

    15. LRLenny Rachitsky1:11:35

        Yeah, I think Naval was one of the few that's like, "You don't need to finish books."

    16. RPRohini Pandhi1:11:38

        Yeah. Yeah.

    17. LRLenny Rachitsky1:11:39

        "Just stop as soon as you want. It's fine."

    18. RPRohini Pandhi1:11:40

        Exactly. It's fine.

    19. LRLenny Rachitsky1:11:41

        And then he said-

    20. RPRohini Pandhi1:11:41

        No, it's good. (laughs)

    21. LRLenny Rachitsky1:11:42

        Yeah. "It's funny that we need permission

    22. NANarrator1:11:43

        "

    23. RPRohini Pandhi1:11:43

        Yeah.

    24. LRLenny Rachitsky1:11:44

        "... to just not." 'Cause then it makes you feel more comfortable starting a book and trying books.

    25. RPRohini Pandhi1:11:46

        Right. Right.

    26. LRLenny Rachitsky1:11:47

        You know?

    27. RPRohini Pandhi1:11:48

        It's easy.

    28. LRLenny Rachitsky1:11:48

        All right. There we go.

    29. RPRohini Pandhi1:11:49

        Yeah.

    30. LRLenny Rachitsky1:11:49

        If you haven't heard Naval's advice on this, just, like, don't worry-

Episode duration: 1:19:24