How to build your product team from scratch, attract top product talent, go multi-product, and more | Rohini Pandhi (Mercury, Square) | Lenny's Podcast: Product | Career | Growth

The CEO of the company you work at now, Mercury, tweeted a few years ago where he basically was very proud of not having any product managers.

Clearly you have product managers today.

You're a product manager at Mercury.

What was the sign to Ahmad and the leadership team that it was time to hire product managers?

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.

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

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.

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.

Let's talk about the final big topic.

going multi -product?

The organizational structure is really important.

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

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 2 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 and 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 workdays per month.

Think bold, build big, ship fast, let Cloudinary handle your media needs.

Start your free plan today at cloudinary .com slash Lenny.

I'm excited to chat with Kristina Gilbert, the founder of One Schema, one of our longtime podcast sponsors.

Hi, Kristina. Yes, thank you for having me on, Lenny.

What is the latest with One Schema?

I know you now work with some of my favorite companies like Ramp, Vanta, Scale, and Watershed.

I heard that you just launched a new product to help product teams import CSVs from especially tricky systems like ERPs?

Yes, so we just launched one scheme of 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.

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.

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 of those distractions that come up with integrations.

We have a built -in validation layer that stops any bad data from entering your system, And One Schema will notify your team immediately of any data that looks incorrect.

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 wanna learn more, head on over to oneschema .co.

That's oneschema .co.

Rohini, thank you so much for being here.

Welcome to the podcast.

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

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 a few years ago where he basically was very proud of not having any product managers of this idea that engineers are going to do the pm work designers basically everyone's doing pm duties and clearly you have product

managers today you're a product manager 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, they 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 the value of PMs.

So I want to spend some time on this topic.

How does that sound broadly?

Perfect. Let's go into it.

Okay. So first of all, how many engineers slash employees at Mercury have by the time they ended up hiring the first PM?

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.

I'd say at least half of them were in some level of like the R &D role.

So engineering, design, those types of core roles.

Wow. So 200 engineers, 400 employees.

Probably. That's pretty far.

Okay, great. So this is going to be really good.

Okay. And then how How many PMs are there now, roughly?

Now we have about 30 PMs across the company.

And I think it's split between junior and more experienced PMs, but it's about more than half are senior PMs with managers baked in there somewhere.

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

So, yeah. So two years ago, no PMs at Mercury or no one with that official title.

There are still people doing the PM duties and having those responsibilities.

And then I joined about a year ago.

So I think they were in there.

You know, what was the first set of learnings from that first year of having PMs and me joining and kind of doing a bit of revamping of the product discipline internally?

Okay, cool. So there's a few threads that are going to 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 what how they built this team to be successful.

So I want to start with that first kind of thread of just a lot of founders start off feeling, I don't need product managers.

Who needs them? Everyone's going to do PMDs.

So annoying. Yeah, so annoying.

Just slow them down.

What do they even do all day?

They're bottleneck.

Yeah, exactly. But I think it's rare to actually work out really well.

A lot of companies just become chaotic with FMDs.

And I think Mercury did something right in order to be successful with FMDs for a long time.

So here's the question.

What do you think Mercury had in place or needed to have in place to be successful for as long as they were without product managers?

I think the crux of it comes down to the founders.

And the founders are your original PMs, right?

And I think whenever I talk to any small seed stage company who's asking, 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 that.

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 work that product does and the intentionality 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 piece of it?

I do think it's hiring amazing engineers, hiring amazing designers, because as you scale, those are the people, the disciplines that you really need to build 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 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 surface areas.

And so they know kind of 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.

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

There's one element that's scale.

It's just there's so much going on.

And a single PM, a single CEO couldn't handle that kind of scale.

We have three co -founders.

But even at some point, that scale becomes too broad for three PMs to handle.

And I think there was, like, one, the bottlenecks started popping up.

So if every decision kind of depends on these co -founders to make every single call, things just slow down or even halt until they're available again.

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.

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 that 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 responsibilities.

And so for I think for Mercury, that kind of started breaking way before the 200 or 400 employee marker that probably broke under the 100 marker.

And so what they had was generalists.

They hired, quote unquote, like these business lead titles.

And those business leads started doing those cross -functional collaboration meetings, making sure everything was kind of like the I's were dotted, T's were crossed, 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 kind of the core, maybe the basics of what product management needed internally were missed.

Like strategic planning wasn't exactly right or roadmapping 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 2020.

This is so interesting.

So one, it feels like the team was like, no product managers.

And then they're just like, OK, you guys do do this thing that's like sort of product management, but we're not going to call you product managers, something else.

And then eventually it's like, oh, I see there's people that are very good at all these things that we need help with.

And maybe we should just admit that.

And that's OK. We need PMs.

I think so. And it's one, it's good to just have that like recognition of, OK, here's what these folks are really good at.

And when you hire a really good PM, they can make that the product velocity, the quality just 10x better.

Yeah. That's what I always say.

A lot of people are like, oh, PMs suck.

They make everything worse on our teams.

And I'm like, you just haven't worked with a great PM.

Yes. Because great PMs make your life easier.

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

Yes. Yes. 100%. 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's 100 because 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 are 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?

I think the first step for us was just defining what the discipline is and 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 leadership down to an individual PM on what those expectations of the role were.

So one of the first things that we put together was a career ladder.

It was just literally a matrix of the role at different levels and expectations.

And we kind of put in 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 career matrix.

And then the other was like, it needs to have the work that you do needs to have a positive, positive impact on the business in whatever way that is.

It doesn't have to be a revenue goal or anything like that, but it needs to be some sort of outcome -based impact.

And then there was also work around, can you build a long -term vision?

Can you communicate that?

Again, we're in a regulated space.

Can you work with cross -functional leaders?

And so we started building out these necessarily 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 the same sort of criteria that we're looking for.

So, like, what skills do we want to figure out?

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 important to us.

Analytical skills, strategic or, like, system -wide thinking skills are really important to us.

We pretty much took what we had in that career ladder and applied it to the interview process.

One thing that I would love to have in the future is a written element of our interview process.

We don't have that yet, but I really do think quality in writing demonstrates this ability to go 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 in the next few months or quarters and just experiment with, but we'll see how that goes.

But aside from that, I think we're we're getting to a really good place with some of our hiring and interview process to get the right folks in the door.

That's actually really interesting.

I've never heard of a PM interview process with a essay component and it makes so much sense because so much writing.

It's something 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.

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 the 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 of 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?

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.

And so. Well stolen is half done.

That's right. Well, it has to be well stolen.

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

But it does help. 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, what do you guys test for?

How do you do this?

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 skill sets that are just like table stakes for 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 want to stay a little weird.

You want to stay your personality as part of this process.

A good example is we still go through, we have this Mercury presentation in our interviews.

And the prompt is very, very generic.

It's like, just talk about something that you're interested in and talk in depth to a panel about it.

And what we're really testing for there is attention to detail, the craft and care, the desire to go deep into a specific area and show your passion for that area.

One of the PMs, we talked about his presentation internally a lot.

He went through, I think it was like an Airbus or a Boeing plane.

and all the deep and truly just from like soup to nuts 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 why are those important and just going into yeah i like how about that how that turned out to be very prescient

and uh important i know we had a lot of questions yeah yeah um but yeah it's it's just something that kind of shows off your personality shows that you care about like a topic in depth and you're able to go into the details of something like that 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 what you're looking for there's values of the pm org i imagine there's like a job description is just describe the responsibilities of the role

and then the interview process.

Yeah. Okay, cool. Something 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 essentially what you highlighted as bottlenecks.

Your team is starting to get bottlenecked more and more.

Just coming back to that real quick, do you have a sense of just like, it sounds like there was already bottlenecks, things are not going amazing all the time.

And OK, what like where does it flip to like, OK, shit, we really need PMs now.

Do you have any insight there of just like here's like, OK, now is the time versus like wait a little longer?

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, 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 edge are starting to do more of that and not doing some of the core stuff that they need to be doing.

And similarly, I guess, when you can't scale yourself in the decision -making or wearing multiple hats or 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 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, what they need and what you should be building

for them. I love that you mentioned that we're going to spend a bunch of time on that.

I know that's what you spent a lot of time on, 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, or you want to go deep on a specific subject and hire someone to take it.

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 that's your thing yes 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 they look for and links to their

actual uh ladders and so for folks that are developing this we'll give you love that yes i think i even i saw that i probably referenced it at some point and just went into my subconscious 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 what is it you think people most miss about the value that a p .m.

brings to your org that maybe a sign okay I see maybe we do need this all right so I think there's like different kinds of p .m .s and different flavors of p .m.

one thing that I I really I feel like 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.

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, it depends on the industry, it depends on the role within a company.

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 maturity of a product.

They're really working on like, again, to use the same metaphor, I guess, 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 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.

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 people, especially founders say, I don't want a PM, I think it's because they're thinking of a mature city planner when they could find a former 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 starting to

put some of the process in, but not build it to the point of, I'm a big, mature enterprise company anymore.

I love this metaphor.

And is the advice that as the smaller you are, the earlier on the spectrum you want to be hiring, like more pioneers and a few town settlers as you build your team?

Probably. I think it just really depends on what you're hiring for.

Even for Mercury, we had our core banking services.

We're still a mature product in our spectrum.

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.

That scale and the ability to have a PM that can think about all of that scale is really important.

You really want to test out, have they done it before?

Do they know what they're talking about?

And then like in which case 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 the 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, you know, the resume without the receipt is just a piece of paper and you want to get the receipts.

What's the work that they've actually done?

Following this thread, I asked a bunch of people that work with you at Mercury and Block what to ask you.

And one of the questions that I loved came from the COO of Mercury, Jason Zhang.

And his question was, what do you think attracts great product managers and great talents to a company?

What makes them hungry to join your company?

How do they hire or Rohini, basically?

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 table stakes of hiring, I think there's a couple of 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 high 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 hiding for on this,

actually a mentor of mine had this great framework.

He said like every career follows this 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 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, make it better designed, whatever you need to be doing.

It'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 there's a lot of wrong ways to probably do that and there's a few right ways

and you've got to figure out which way is up and there's just so much ambiguity and like 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 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, 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 working to serve these types of customers?

Will it challenge me?

Will it make me a better PM?

Those are the kind of considerations that they're making.

And then the second consideration is like, who do I get to work with?

We actually kind of talked about this in a recent post that we wrote for your newsletter of the functional types of organizational structures.

I think when you have a functional structure within your org, it's really nice because then you can say, oh, I get to work with these types of PMs because there's a product lead, there's a product group, and you want to, I play tennis.

You want to play tennis.

You want to challenge yourself with people that are a little 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 edge, because those are going to be your peer groups, you want to make sure that you're working with folks that, you know, are excited and 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 to them in a way that like breeds transparency, honesty, trust overall.

I tell them when I have conversations with candidates, the good, the bad, the ugly, 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 don't want to over promise, but you do want to sell the dream of why you're excited.

So that was awesome.

There's so much here.

So I'm going to 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, 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 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 more impactful.

Yeah, that's a great way to, probably a third dimension on all of that.

And I love that it's not just up and to the right linear line.

It's an S -curve where it's like, okay, now you're on something really complicated, just rocking it up this ambiguity y -axis.

Exactly. And you can kind of trace back our own careers into this idea or even engineers and designers.

It doesn't have to be a product S -curve, but 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.

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

I think it was probably at Square.

One of the first products that I worked on there was 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 I started, it was three engineers, a designer, and myself.

And it was like, okay, just go make this work.

and 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 strategic plan.

So like Square Invoices first step one was like, just get it to a place that was functional.

It was the first rev of this product was almost, people wouldn't use it, but they would have to spend so much time in order to figure out how to use it.

That's honestly when I knew 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 desk desktop on dashboard web and we're like okay get into mobile that was the net like truly another 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 go after and do SEO and SEM on and find net new customers.

So there were some like really interesting challenges of saying, OK, how do I increase how do I increase the top of funnel?

How do I then also decrease risk loss at the loss level?

And just being able to kind of play around with all those different levers was my huge ambiguity experience.

Yeah, speaking of levers, I was going to highlight just I love the way you describe 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 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.

And so I think that's a really good skill to learn as you're ramping up this curve.

Absolutely. Yep. Awesome.

Okay. And then coming back to the other tip you shared of how to hire amazing people, just to close that thread, make it clear how awesome the other people at the company are that you're going to work with.

Because like you said, you're going to learn the most from playing tennis with awesome people.

And awesome people want to work with awesome people.

Exactly. And I think the other thing to add on to that is the candidates are testing you as much as you're testing them.

And so 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.

I love that. That's dogfooding it.

Exactly. Okay. so i want to talk about quality and i want to talk about multi -product going multi -product let's start with quality so classically a lot of pms are just not 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 of that you actually have a really interesting approach to advocating for quality and helping people understand why it's worth investing in and And in particular, you've worked on, in quotes, boring products, banking, finance stuff, but have helped make them awesome and great experiences.

What can you share with folks about how to advocate for investing quality when it's not something you can really measure?

This is something I've learned a lot from the Mercury folks over the last year.

Even the OGs back at Square in the early days, there was a lot with, on the surface, I think Ahmad even says this, on the surface, it's completely irrational to invest in quality.

Especially for a KPI -driven company or KPI -driven company or organization, there's often this false dichotomy that creeps up.

That's like, you either have to be this quant heavy experimentation, 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 completely insane.

You need to be somewhere in between.

But, and I think like what I've learned from the companies that I've most recently been at is the details done right really matter.

Especially when you're in like a boring industry like FinTech, meaning like it's just unsexy.

There's not a lot of, you know, it's not like this consumer exciting app but you need the details to be 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 is we launched a product called BillPay.

And in that you can upload an invoice, you can just drag and drop your invoice from a vendor and we will OCR it, we'll like read all the details and we'll pre -populate 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 invoice.

And that little detail, that little additional like, Hey, we just helped you with this and highlighted where you needed to be.

Well, it 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, that was fantastic.

I loved using a product to pay my bills, which is not something you hear every day.

And I think one of the Mercury values that I've really tried to internalize is 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 craft. And when you consider like the compounding effect of all those little intentional incremental improvements, it altogether, it starts becoming a moat, it becomes this competitive advantage for you.

And so I think there's like, there is an argument, a strong argument to really think about quality craftsmanship, how you're building something that can be evergreen and beautiful, confident, confidence inducing and trustworthy.

And then On the other side of it, I just think building great products should be fun and fulfilling for all of us, and so you want to spend your life on something that people love and enjoy using.

I think that's something that Jason's really taught me, and so by doing this, by investing in quality, by thinking about quality, you're also having the second -order effect of attracting great talent who want to be there and be proud of what they're building, and then it also has this effect of 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.

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 bank that's like, oh, great, we're going to do this.

I love it. We're going to invest in quality.

We're going to 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 is a great 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 it's like if you decide this is our differentiator then that's a huge opportunity to invest in quality in you.

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 there was like this trend of, I don't know, B2B products that became, I think, like maybe a decade ago, a lot of 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, I don't know, rounding corners and making the fonts better or something like that, using some white space, just very simplistic ideas of it.

But now I think 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 small mobile screen and still have the full power and capacity of like an enterprise level product line, 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 two decades ago.

It's something that we really think is kind of the basis of why quality is embedded into everything that we talk about and do it's it's an obsession within the company interesting uh so yeah i think i feel like there's a big rise and 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 this company that i'm investing is 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 yeah and it's like cool here's how we can compete we'll build an exact experience nobody wants to be at the other like the audience end of this or the user end of this 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 in dealing with the work that they have to do day in and day out.

And so I really do love unsexy products that can just be done right.

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 went, 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.

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

Yeah, I love this thread.

I think we could talk about that for another hour.

That'll be your second visit to the podcast.

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 roadmapping, 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 slash lenny to book a demo that's airtable .com slash lenny okay so let's talk about the final big topic that i know you're passionate about and this is what you work on mercury which is super cool which is going multi -product

going from one product that is doing well to layering on additional products this is kind of the holy grail for a lot of founders a lot of teams expanding tam finding more waste of general 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 to give folks a sense?

Because I think people think of Mercury as a bank.

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 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, like our core offering.

And that suite allows our customers to do things like, you know, the accounts payable work that they need to do as they grow, accounts receivable, accounting workflows, those types of things.

And so in the last, let's say, like, six, seven months, we launched what I talked about before was BillPay.

In May, we launched invoicing, something near and dear to my heart in August.

We had updated spend controls and spend management tools and employee reimbursements that launched in October.

And each of these, one of my favorite 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 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 building out the SaaS model, building out personal banking, but lots more to come.

So excited for kind of where Mercury is set up for in the next few quarters.

Going into some of the, maybe the biggest lessons learned about going like from one product to multi -product, probably like two general categories.

One, 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 new product areas new seedlings being too close within the 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 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 for seedlings to grow.

And yeah, like this idea of like when you have this small little fire, you want to give it air in order for it to truly blossom to a flame.

And so 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.

And when you say separate, like dedicated resources on this project for some number of months, like what's the timeframe you give new seedlings?

We're thinking of these companies, like these are small seed stage companies.

And every quarter, every 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 Sirius C company 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 providing headcount

whatever you need as as this product this business line shows the path towards success 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

and you make it super concrete is it pretty qualitative how do you think 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 going to be pivots we realize that we're not saying that it's going to you know

we're going to 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've made that we think we can still hit something in that general direction in the next six months.

And what does a seed team look like generally?

What are the resources you put into it?

I mean, it's the full cross -functional squads of eng, design, product, data science, everyone that you probably need.

And then we kind of have cross -functional overlaps with kind of our core teams across the company.

So sometimes we will have dedicated, 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 central teams that already exist for some of those functions.

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

It kind of depends.

Like our personal banking product has a lot more engineers, probably, you know, a 3x than maybe our invoicing product line.

Even at the beginning?

well so I think 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 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 request whereas like in invoicing we're building the software on top of the banking and it's just it requires a different level in order to get to minimal level product.

And so, you know, we're giving the teams just enough, but we want them to stretch.

And I feel like there's also a connection to how big this opportunity is.

Invoicing versus like becoming the new personal bank of the world, you know, so it makes sense.

Well, let's just, let's put a few more resources on this one.

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

So yeah i mean let's not hate on invoicing okay i understand and so what okay so specifically they hired you to create this carve out almost for new product investments 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 yes i think there's um that kind of hits that culture that needed to be instilled into this organization too because we're going to be a zero to one team and we're going to have to work in a little bit of a different way.

Our counterparts on the core mature products will use monthly development cycles.

They'll figure out their roadmap for the month and then just start executing on it.

I could not find a way in which I wouldn't know what was changing in a month.

And so we had to move towards two -week sprints and then weekly check -ins with a bunch of our work just to stay as nimble as possible.

We wanted to 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's just much more kind of like touch point 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 can you share more about this customer call culture for folks that maybe want to learn from how you do it it's kind of like, I don't know, just the heartbeat of how we operate.

So it almost feels so natural that I'm not sure if I can impart any new learnings on it, 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 info that they're getting from the surveys, quantitative info that they're getting from it.

I think all of that really counts.

We're customer obsessed at Mercury.

And so you'll even see it like Ahmad will talk to folks on Twitter or on X directly.

We'll get pings from different folks across the company.

We'll look at why people 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 touch points 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.

I'm going to follow this thread a little bit more because one, a lot of companies say we're customer obsessed.

Our teams are customer obsessed.

We love to 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 I really are obsessed and do this well, that often is missed when people think they're doing this.

I think there's a little bit of like, what a customer says versus what they want, going to be two different things.

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 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 want to be a researcher.

You want to be like this third party, nonjudgmental, kind of like you're being brought into the jungle and just watching what's happening.

You're an observer.

You're being like a documentarian.

It's not about getting your biases checked or validated or invalidated.

But it's like, just understand what it is that the customer is trying to do, what context they were trying to do it in, and get to a truth that seems to find a pattern or you hear about multiple times.

And then validate that truth and see if that still sticks.

Have a prototype, do the betas, see if the numbers actually work out in your favor.

I think the other thing is the customer obsession needs to also be anchored back into, does it work for your business?

Like just because a customer wants it, I mean, they probably want free products that doesn't work for what we're going to be able to serve them with and still be a viable business and still survive.

And so I think I actually used a lot of, when we were doing pricing, I used a lot of insights from your podcast with Madhvan.

That was a great, I mean, if I can promo a different podcast episode 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 at a fountain is free.

A water at a hotel is like five bucks.

A water on the plane is like 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 sense of customer obsession, but where does it where does that artistry meet the business?

Awesome. That was a great example.

We'll link to the amount of on episode 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 we do have a UXR team which is great we have a research team 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 p .m.

schedule and because you're going into from meetings to meetings so it's like 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 we try to leverage kind of like a central team to help us manage those calendar and meeting invites and getting people booked.

We'll also just kind of get in the sidecar of an RM call or a sales call or a 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 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 okay cool and then uh what does rm stand for oh sorry sorry uh relationship managers our sales okay cool it's like account managers yes awesome okay i'm going to come

back to where we were i pushed us off track i'm going to bring us back on track so we're talking about things you've learned about building multi products additional products 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 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 we really looked at like okay we need to we need to find solutions that tie closer to the existing spaces we're in It needs to be like an adjacency

that's just beyond the core.

It's not about just building a new feature.

You are building a new product line.

So what is that adjacent customer segment that would be interested in a deeper, more fuller product experience?

A good example 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 looked at a bunch of different areas and were really like thoughtful around who is our target segment, our ICP, and then who do we want to serve?

And we saw some like some work that was interesting because we had this concept of this product called 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 was something that we like used as a kind of competitive advantage, because we're 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 we talked to a bunch of those customers.

We also knew that we had a distribution advantage, because if we already had people that were using this, we could probably get more folks that were that were on Mercury already, we didn't have to go find them outside, we'd 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 used that adjacency to our advantage and our distribution to our advantage and said, OK, let's let's build out these next products that are kind of in that same ecosystem or universe and see what works and see what sticks.

We also kind of use that current UX to drive that attached to these new products.

So on the opposite side, like the 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 is doing anyways and say, hey, do you actually need something more robust?

We have something for you.

try it out. So the two kind of some attributes you look for is can't have you de -risk 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 and get in front of people in your existing product?

Exactly. That's it.

And then there's probably just like Tam, is this like a big opportunity?

And then just thinking about which are the biggest opportunities we have right yeah we did all of that kind of like pre -work as just you know is it even viable and then do we have an advantage around that and I think the the place that we hit are like yeah we already have an advantage this would be there's

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 launch once you've launched that's one step that's one like big hurdle then there's 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 what we really want is to give away that the second product, the third product 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 actually be willing to pay for it.

But it's not like 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 a core product.

We were always free to customers.

Now we have 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 heft that comes with these products.

It's interesting because if I reflect back to the Modavan pricing episode, he was actually like, don't ever discount, charge exactly what you want to charge at the beginning, because that's actually a test of product market fit.

How do you think about that balance?

Yeah, I think I really love this idea of like the 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, we're 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 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.

And so you need somewhere to save your money.

You need somewhere where you can move money around.

But there might be six 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 want to have the pricing conversation with you 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 got it so this essentially it's just part of the journey of finding product market fit and figure out what to build exactly is let's just see if anyone even wants this at all for free and then it's okay here's yeah and there's like some basic functionality that we

think should still be free like our core banking 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 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.

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, either at Block or Mercury of building something just failed, which I imagine.

Well, one other learning that I've had from like the block in 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 feel like is very true with the mercury co -founders as well they're never uh hyper -focused on the revenue

they're never focused on a number that they're trying to drive they really want to build 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 second step is almost a, it's a, like, you

will get there. And so I think that's one learning.

I think one, a few missteps that we have made, we're trying too many things at once.

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 going to understaff these new efforts.

There's not going to be enough folks to, again, take that seedling, put it into the ground, put 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 missteps, learnings around pricing.

I think we've talked about a bit, but there was a lot of internal discussions on like pricing model bundling versus a la carte, how we would price it, how much work we would do on understanding that willingness to pay.

All of those pieces were exciting.

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

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.

We'll see how things go.

And it's always an iterative process.

Awesome. OK, last thing I want to touch on is something that I know you're passionate about this kind of outside the core of our conversation.

But I'd love to spend a little time on it.

You started this organization called the Transparent Collective.

Former guest I .O. told me I need to ask you about this.

Oh, that's awesome.

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

Gladly. That'd be great.

So Transparent Collective is a 501c3 nonprofit organization.

We help underrepresented founders get access to resources, connections, whatever they need to build successful tech companies.

We started this, gosh, I think it's been about nine years now, eight or nine years ago.

And it really was born out of just this organic conversation that happened.

And my co -founder and I met up for drinks one night.

We both knew each other from like Michigan back in a day, went to school together.

And we were talking about how 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 is very different than trying to raise money and sell this dream on the West Coast.

And so where we kind of like had to learn a lot of the tribal knowledge that just existed on our own.

We wanted to create this collective that transparently shared information with one another in order to, where we kind of started 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 we have in our Rolodex, and then also the entrepreneurs to the right investors for them.

And then just ultimately contributing to an ecosystem that can like really allow these types of founders to flourish so we host a bunch of programming webinars workshops that kind of thing but our kind of like spotlight event is we fly founders in from all over the U .S.

once maybe twice a year to participate in our seed programming and so we have like 200 250 applications that come through we bring about eight to ten founders in to join us for a week in SF where we pay for everything and we have sessions for mentoring small group workshops 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 there are folks that come in from detroit or baltimore or atlanta and they have amazing companies

and so we kind of just connect the dots and help them along the way so far i think we've had 90 plus alums across our 11 batches.

And I think 65 % or 70 % of them have raised venture funding now because of our programming.

I think we have a total of like 125 million in seed or early stage fundraising from 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 alumni group.

So cool. Such a, such a thing that obviously should exist.

And I love how well it's going for folks that either and it's a, it's a 5013C you said?

Yes. So for people that either want to donate and support this work or people that want to apply, how do they do that?

What's the best way to learn more?

Transparentcollective .com.

We have both 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 drop your information.

And then we do operate on donations.

And so we would love to find folks that would be interested in helping us achieve our mission.

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.

Brohini, we've covered so much stuff.

You're awesome. With that, we reached our very exciting lightning round.

Are you ready? Ready.

All right, here we go.

first question what are two or three books that you find yourself recommending most other people i got this book recently called vectors uh aphemisms and aphorisms and 10 second essays it is so much fun to just kind of like pick out a couple of these like 10 second essays at night and just read a couple

of these and go to bed i 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 this book called The Inner Game of Tennis.

I've already mentioned that I'm a tennis fan, but it talks about the state of flow that you need when you're playing in 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.

Other books that I think that I've read recently 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 each time so highly recommend people love fiction recommendations okay great yes so I'm glad you threw those out the inner game of tennis I know 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 it's lessons from this coach that taught people how to be amazing tennis players which applied all kinds of greatness exactly and I will say I love stopping a book in the middle sometimes when you just can't finish it.

I don't know why I waited for someone to give me permission on that.

And I think it's really helped me.

Like, oh, I got through a few starts of books.

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

Just stop as soon as you want.

It's fine. It's fine.

It's funny that we need permission to finish.

Yeah. Because then it makes you feel more comfortable starting a book and trying books.

Right, right. It's easy.

All right, there we go.

If you haven't heard Naval's advice on this, just don't worry about finishing a book.

Don't feel bad. It still counts as reading it, basically.

Next question. Do you have a favorite recent movie or TV show you've really enjoyed?

You know, I've really, I gotta admit, Apple TV's got some bangers, and they don't talk about it.

I don't know why they don't market these things better.

But like, I am behind on these second seasons, but like Shrinking or Bad Sisters, Slow Horses was great.

Severance. It's come a bunch.

Yeah. Yeah, Slow Horse has been coming a bunch.

Sorry, you said something else after that.

Oh, I think Severance is coming up in its new season.

Yeah, there's some good ones on Apple TV.

presumed innocent have you seen that i haven't so good apple tv watch it it's only six episodes all right it'll it'll pull you in immediately can't wait yeah it's a good one okay next question do you have some favorite product or a favorite product you recently discovered that you really like i don't

think it's a recent discovery but i still love the waymo experience as a product i don't have you've experienced these rides it's mind -blowing and it's mind -blowing how quickly becomes just like they forget that you're in a self -driving car.

I actually asked one of the product leads of Waymo this at a happy hour and I was like you know is is it kind of like when you when you kind of remember like this old elevator there's always an elevator guy still there like even when it was all automated and like you were just pressing buttons but you

wanted somebody there to make it feel like I'm not in death cage and I was like do you still need a fake driver to just make you feel comfortable?

He's like you'll feel comfortable in less than five minutes.

He's right. I felt comfortable in, like, 30 seconds.

It's wild. I love Waymo.

Yeah. Me too. I love seeing, like, many Waymos in a row on the road into the Bay Area because it's just like, it's coming.

The future is coming so fast.

So true. And I started singing in LA now, too.

It's going to be fun.

Yeah. Can't wait for them.

I live north of San Francisco, and so I can't wait for them to be able to get on the freeway across the bridge.

Oh, man. Yeah, I love Waymo.

It's so amazing. And it's just, it's like you hear about it, but then you actually experience it at a whole other level.

It's great. Two more questions.

Do you have a favorite life motto that you often repeat yourself, share with folks find useful?

I write a lot of like quotes down and I think there's like, I don't know, I just really like some of reminding myself of some of these kind of quotes.

And so I use a bunch, like I think I use a Bruce Lee quote pretty often or I used one a Jesuit's line in one of my job recs.

And there's like certain ones that I do repeat.

but i actually found this and i don't i forgot about it but i really love it and so i'm just gonna i'm gonna read this one out please and this is from um adam robinson i think and he wrote my three guiding rules of life first whenever possible connect with others second with enthusiasm strive always

to create fun and delight for others and third lean into lean Lean into each moment and every encounter expecting magic or miracles.

Isn't that great? Wow.

So I think that's going to be my life, or at least something that I remind myself about as much as I can moving forward.

I love that it includes both creating moments of happiness and joy for yourself, but also for other people.

It's a nice balance of those two.

It makes me think about Cyan Bannister was just on the Tim Ferriss podcast.

I don't know if you heard that one, and there's a lot of this and that.

Worth listening to.

She's fascinating. It's great.

Awesome. Thanks for sharing that.

Final question. You're a very active angel investor.

I know that it's hard to pick your favorites, pick your favorite baby, but do you have like a favorite angel investment, one that you're most proud of?

Oh, that one's really tough.

What's one? Oh, that was a good one.

I think, okay. What I'll say is, yeah, I really don't want to pick a favorite there.

I'm not going to get it.

Why didn't you mention this?

I'm going to get founder texts, but I will say I tend to gravitate towards people that are producty minded and when I hear some of the work that they're doing or their pitch, like even if they're not PMs, I tend to gravitate towards those and I really love their approach to how they think about the problems.

And so, you know what, maybe I will call out one because they just, they just got acquired.

Bobby Madsen, he was the CEO and co -founder of, founder of Pay It Off of student loans and working on like making a student loan like repayment easier for people, finding them ways in which like maybe they didn't have to repay, like doing a lot of this, again, unsexy work.

and he when we talked the first time he was telling me that you know he had a new kid he was still up at like 3 a .m reading regulations and like what's happening with the student loan process in the federal government I was like somebody that cares that deeply that really strives to try to make someone

else's life better because they're just finding like what actually needs to happen what doesn't need to happen and it deals with real money that these folks are kind of coming out with, a real debt they're having to deal with.

It was, yeah, it was, there was like an emotional tug.

And I love when founders have that drive, that passion and the detail orientedness of finding a solution.

Here's it. That's for folks that want to raise money and maybe have Rohini as an investor.

Here's your lesson of what she looks for.

I love you. They share that.

Two final questions.

Where can folks find you online if they want to learn more?

I know Mercury is hiring, so share anything you want to share there.

And also just how can listeners be useful to you?

I'm on X, aka Twitter, at Rohini P.

Would love to connect with folks there.

I'm also on LinkedIn, not really on anything else, though, hopefully find one of those.

And we are hiring mercury .com forward slash jobs if folks are interested, or if you know, great people that we should be talking to.

I think other than that, listeners can be really helpful to us in continuing to send us product feedback.

Please keep it coming.

We really do love it.

And we have a lot of Slack channels just focused on those pieces of like, oh, I've heard from this founder, or I'll get a text and I will post it in our Slack, internal Slack.

And so whether you're a business banking account holder, personal banking account holder, we just want to hear what's going well, what's not, what we can do to improve your lives.

One thing on the personal banking, we're going to be giving away so if anybody hasn't tried Mercury personal banking we want to give folks that are listening to this podcast the opportunity to skip our wait list and so we'll send you the link Lenny and hopefully you can add it to the show notes but we're

giving a small subset of skip the wait list opportunities for folks that are interested in trying out a new personal bank.

How cool is that? I'm going to use this link.

Did you say how many you're giving away?

Well I think we'll have 25 available.

25, all right, it's going to be 24 now.

You'll get one, don't worry, Lenny.

Okay, okay, it'll be 25 again, okay.

And if you're listening to this way beyond, it may be all out at this point, but if you're listening to this recently, it'll be available.

Awesome, we're definitely going to include that in the show notes.

Thank you. Rohini, thank you so much for joining me.

This was great. So great.

Bye, everyone. Thank you so much for listening.

If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify or your favorite podcast app.

Also, please consider giving us a rating or leaving a review as that really helps other listeners find the podcast.

You can find all past episodes or learn more about the show at Lenny's podcast .com.

See you in the next episode.

[Navigating Growth: Scaling Product Teams and Multi-Product Strategy at Mercury]-[How to build your product team from scratch, attract top product talent, go multi-product, and more | Rohini Pandhi (Mercury, Square)]

📋 Summary

Building and Scaling Product Organizations: Lessons from Mercury

The "No PM" Myth and the Tipping Point

Defining the PM Discipline: The "Pioneer, Settler, City Planner" Framework

Attracting Talent via the "S-Curve"

The Multi-Product Strategy: Seedlings and Structure

Quality as a Competitive Moat

🎯Key Sentences

📝Key Phrases

📖 Transcript