0:00
...
...
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 Immad and the leadership team that it was time to hire product managers?
The bottlenecks started popping up.
To take things from 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 the 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 Pandhi.
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 Pandhi.
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 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.
Yes, thank you for having me on, Lenny.
What is the latest with OneSchema?
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 OneSchema FileFeeds, 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 ad 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 OneSchema 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 want to 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 this meme of, "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 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/employees that 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 the R&D roles, so engineering, design, those types of core roles.
Wow, so 200 engineers, 400 employees? Probably. Probably. That's pretty far. Okay, great.
So this is going to be really good. Okay.
And then 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 their, what was the first set of learnings from that first year of having PMs and then me joining and 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 that thing.
And then there's also just 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 PM duties. They're so annoying. Yeah, so annoying.
Just slow [inaudible 00:07:37] down.
What do they even do all day? They're a bottleneck. Yep. 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 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, 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 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 those early days, the founder needs to be that PM, they need to take on those duties.
I think you talked about 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 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 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.
Following this thread, what was the sign to Immad 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 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 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 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 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 these "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 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 the core, maybe the basics of what product management needed internally were missed.
Strategic planning wasn't exactly right 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 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 have done the official transition to the PM role a lot sooner, but hence, it'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, "Okay, you guys do this thing that's quite sort of product management, but we're not going to call you product managers. You're 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 okay. We need PMs." I think so.
And one, it's good to just have that recognition of, okay, here's what these folks are really good at, and when you hire a really good PM, they can make 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."
Because great PMs make your life easier. You have more joy.
You could 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 was 100 because they had sort of PMs that were 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?
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 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 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 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 the work that you do needs to have a 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 the long-term vision?
Can you communicate that? Can you...
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 these same sort of criteria that we're looking for.
So 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 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 and 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 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 [inaudible 00:16:49].
It's something about being able to edit, being able to put thoughtful content in there and have 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 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 to help 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 taking some of those cues from Block, but then also just talking to 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 worked with our exec team.
What were the values that you really think are important?
There's some skillsets that are just 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 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 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 was he went through...
I think it was an Airbus or a Boeing plane, and truly just from soup to nuts, what was the reason for this type of plane structure, all the way to what kind of bolts do they use for this plane and why are those important? And just going into... Yeah.
[inaudible 00:19:10] how that turned out to be very prescient and important. I know.
We had a lot [inaudible 00:19:15] of questions after. Yeah.
But yeah, it's just something that shows off your personality, shows that you care about a topic in depth and you're able to go into the details of something like that.
So to 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 a job description, 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, it sounds like there was already bottlenecks, things are not going amazing all the time.
And okay, where does it flip to like, "Okay, shit, we really need PMs now." ?
Do you have any insight there of just like, okay, now is the time versus wait a little longer?
The one piece of advice I always have is 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 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, you are that bottleneck as a founder.
Or when people other than you are doing 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.
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 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 spend 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 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. That's perfect. Yes. Okay, cool.
We'll link to that in the show notes.
Also, 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 ladders.
And so for folks that are developing this, we'll give you- Love that. [inaudible 00:22:21]. Yes, I think 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 that you think people most miss about the value that a PM brings to your org that may be a sign? "Oh, okay, I see. Maybe we do need this."
All right, so I think there's different kinds of PMs and different flavors of PMs.
One thing that 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 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'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, 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 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 in the spectrum you want to be hiring?
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 banking, core banking services, we're still a mature product in our spectrum.
Everything that we do there, we have to truly not even measure it twice, measure it 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 about?
And then in which case, were you willing to take 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 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 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 a Rohini, basically?
Okay, there's a few answers to this.
Maybe just starting off, let's take away some of the table stakes.
Let's assume that candidates know that the company's viable, it's doing well, paying market rates, all of that.
The candidate and the product have good...
There's a resonance with that.
The culture has good vibe checks.
So taking away kind of the table stakes of hiring, I think there's a couple things from the company side and then the candidate side.
I think 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 goal?
What's their jobs to be done?"
kind of an idea and consider where the PMs would be that you're hiring for on this...
Actually, a mentor of mine had this great framework.
He said that 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? Can I fix onboarding?"
There's only so many different ways to 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 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 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 got to figure out which way is up and there's just so much ambiguity and 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 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 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 topics.
And so I think going back to 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 a problem area big enough?
Is it meaty enough 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 considerations that they're making.
And then the second consideration is who do I get to work with?
So we actually kind of talked about this in a recent post that we wrote for your newsletter of the functional types of organizational structures.
And 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 I play tennis.
You want to play tennis, you want to challenge yourself with people that are a little bit better than you and bounce that ball back and forth and it's fun.
And the same thing goes for 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 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 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 where the challenges are for us right now and where the opportunities are.
What I see as 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 of ambiguity versus scale.
And it almost sounds like there's 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 into the right linear line, it's an S-curve where it's like, okay, now you're on something really complicated.
You're just going [inaudible 00:31:38] 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 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.
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 you're not embarrassed to be serving up to customers that are using Square Invoices.
And then very soon, you started seeing the next levels of work that needed to happen.
And for me, that was the first time that I got to really just drive this strategic plan.
So 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 desktop, on dashboard web.
And we're like, "Okay, get into mobile."
That was truly another step of growth that we just saw.
And then it was a huge step function there.
And then the next one was we wanted to draw out people.
So instead of going after existing Square customers, we want it to be a front door product.
And that drove another step change 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 really interesting challenges of saying, "Okay, 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 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 described this as 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 make it less hacky, make it easy to discover, bring in new customers.
And so I think that's a really good skill to learn as you're ramping up this curve of ambiguity. 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, it's 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 these awesome people want to work with awesome people. Exactly.
And I think the other thing to add onto 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 [inaudible 00:35:19], I want to know that they understand what they're even asking me for and they understand how to 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 [inaudible 00:35:34]. I love that.
[inaudible 00:35:37] 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 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 in 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.
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 Immad 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 [inaudible 00:36:48] heavy of 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
And I feel like those two ends of the spectrum are just completely insane.
You need to be somewhere in between.
And I think 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 a boring industry like FinTech, meaning it's just unsexy, there's not a lot of...
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 Bill Pay.
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 read all the details, and we'll pre-populate some fields for you.
And as you kind go through those fields and check that we got everything right, the right-hand screen zooms into the right part of the invoice.
And that little detail, that little additional, hey, we just helped you with this and highlighted where you need it to be, 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.
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 take that product to that next level of care and craft.
And when you consider the compounding effect of all those little intentional, incremental improvements, altogether, it starts becoming a moat.
It becomes this competitive advantage for you.
And so I think there is a strong argument to really think about quality craftsmanship, how you're building something that can be evergreen and beautiful, confidence-inducing, and trustworthy.
And then on the other side of it, 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 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 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 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.
Linear is a great example, Mercury is a good example.
A lot of competitors in the space, we believe we can win by quality and experience.
And I don't think that exists in every market, but thoughts on just that is like if you decide this is our differentiator, then that's a huge opportunity to invest in quality in UX.
Yeah, I completely agree with both...
One, 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 there was this trend of, I don't know, B2B products that became, I think maybe a decade ago, 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, 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 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 ease and customizations in two decades ago.
It's something that we really think is the basis of why quality is embedded into everything that we talk about and do.
It's an obsession within the company, quite honestly. Interesting.
So yeah, I feel like there's a big rise and we will just make beautiful, incredible high craft products probably because there's so much competition and so many options that that's one of the few remaining ways to differentiate and stand out, especially in a boring industry as...
Like another example, this company that I'm an investor in is called Zip, which is procurement.
And there's all these boring ass companies that are billions of dollars and just so ugly and it's like, cool, here's how we can compete.
We'll build an incredible experience.
Nobody wants to be at the other, 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 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.
This could be a whole other...
That'll be your second visit to the podcast.
This episode is brought to you by Airtable ProductCentral, the unified system that brings your entire product org together in one place.
No more scatter 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 ProductCentral after decades of working with world-class product companies.
Think of it as mission control for your entire product organization.
Unlike rigid point solutions, ProductCentral 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/lenny to book a demo. That's airtable. com/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 at 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 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 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 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 because 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 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, our core offering.
And that suite allows our customers to do things like 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, six, seven months, we launched what I talked about before was Bill Pay 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 philosophy 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 building out the SaaS model, building out personal banking, but lots more to come.
So excited for where Mercury is set up for in the next few quarters.
Going into some of maybe the biggest lessons learned about going from one product to multi-product, probably two general categories.
One, the organizational structure is really important and probably as important as just the product decisions, and the organizational culture is also important.
So one thing we learned was 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 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, this idea of 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 dedicated resources on this project for some number of...
What's the timeframe you give new seedlings?
We're thinking of these as 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, series C company in and of themselves.
So we're not really looking at an end time.
We're just saying, "You have this dedicated team.
We'll continue investing and providing headcount and whatever you need as this product, this business line shows the path towards success."
And I think that point is really important.
So it's basically every quarter/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?
Do you make it super concrete?
Is it pretty qualitative?
How do you think about that?
We have goals and we also allow these teams...
They're so early that 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 we're going to kill it if it doesn't hit X.
But we do have goals in mind, we have financial projections in mind, and we say, "If you don't hit that, 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 have cross-functional overlaps with our core teams across the company.
So sometimes we will have dedicated...
If we need a dedicated CS or dedicated risk or dedicated ops folks on these teams.
But usually, it's just 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.
Our personal banking product has a lot more engineers, probably 3X than maybe our invoicing product line. Even at the beginning?
Well, so I think seeding that, it just required...
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 build a bunch of that.
And so the initial investment just was a different request.
Whereas in invoicing, we're building the software on top of the banking and it requires a different level in order to get to minimal lovable product.
And so 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 becoming the new personal bank of the world. So it makes sense.
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.
Let's not hit on invoicing. Yeah. Okay. I understand.
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 hire a leader that is overseeing all of these new seed bets versus just a team off to the side. Yes.
I think 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 really heavy-handed culture of customer calls, customer research that the PMs needed to do.
There's just much more kind of touch point, pulse check with who these customers are.
We're going after adjacent areas, and so make sure that 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...
Some teams, when they're really into discovery mode, are doing 20, 25 calls with people. It's wild.
Or even just going through surveys and understanding what 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 Immad 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 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 us through a little bit more because one, a lot of companies say, "We're customer obsessed, our teams are customer obsessed, we 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 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 what a customer says versus what they want are going to be two different things.
I think there's just so many inputs to all of this, but 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 this third party non-judgmental, kind of like being brought into the jungle and just watching what's happening.
You're an observer, you're being 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's 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?
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 Madhavan.
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 a water at a fountain is free, a water at a hotel is like five bucks, a water on the plane is...
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 customer obsession needs to be just anchored back into the business and the business needs and 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 that artistry meet the business? Awesome.
That was a great example.
We'll link to the Madhavan 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 help us make sure that we can...
Honestly, the scheduling Tetris that has to happen is probably the hardest part in a PM schedule because you're going from meetings to meetings.
So sometimes we'll just have dedicated research weeks where 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 regular sessions that are happening every week, then we try to leverage a central team to help us manage those calendar and meeting invites and getting people booked.
We'll also just 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 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 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 what does RM stand for by the way? Oh, sorry, sorry.
Relationship managers, our sales team. Okay, cool.
So 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.
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 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 find solutions that tie closer to the existing spaces we're in.
It needs to be 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 we're really thoughtful around who is our target segment or ICP and then who do we want to serve?
And we saw 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.
That had traction and so that was something that we used as a competitive advantage because we're like, "Oh, we can talk to people that were already doing something that was 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 on 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 used that adjacency to our advantage and our distribution to our advantage and said, "Okay, 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 used 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 some attributes you look for is have you de-risk that...
Basically, you're already seeing there's a need here from a baby feature of that product.
And then do you have a distribution advantage essentially?
Can you find a way to get in front of people in your existing product? Exactly. That's it.
And then there's probably just like, "Damn, is this a big opportunity?"
And then just thinking about what are the biggest opportunities we have. Right.
Yeah, we did all of that kind of like pre-work as just is it even viable?
And then do we have an advantage around that?
And I think 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 right now, I think once you've launched, that's one step, that's one 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 revenue optimize or find that efficiency immediately.
I think what we really want is to give away 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 areas where they could save time and drive some 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 what worked for a core product.
We were always free to customers, now we had to go to 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, the heft that comes with these products.
It's interesting because 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 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...
What he talked about was 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...
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 have 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 willingness to pay process as part of the homework for that.
But I think there's 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 that 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 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 essentially, it's just a part of the journey of finding product market fit and figuring out what to build.
Let's just see if anyone even wants this at all for free and then it's okay, here's [inaudible 01:03:27].
Yeah, and there's some basic functionality that we think should still be free.
Our core banking, core money movements should always still be free.
So when invoicing asks for a different kind of 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 works really well with your accounting and then 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 and just failed, which I [inaudible 01:04:09]?
Well, one other learning that I've had from the Block and Mercury world is one thing that [inaudible 01:04:15] always said 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 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 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... You will get there.
And so I think that's one learning.
I think a few missteps that we have made were 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 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 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 on 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. Okay.
Last thing I want to touch on is something that I know you're passionate about.
This is 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 IOs 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. Oh, gladly. That'd be great.
So Transparent Collective is a 501(c)(3) 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.
My co-founder and I met up for drinks one night.
We both knew each other from Michigan back in the day, went to school together, and we were talking about how we both 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 in the West Coast.
And so where we 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 where we started step one, we would have the next generation started step two and then pay it forward.
And so our programming really focuses on 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 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 spotlight event is we fly founders in from all over the US once, maybe twice a year to participate in our seed programming.
And so we have 200, 250 applications that come through.
We bring about 8 to 10 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.
We'll ask our investor friends to come in and do mock investor meetings and get the butterflies out for these founders that are coming in from all over.
They're not coastal founders, they're 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 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 thing that obviously should exist and I love how well it's going. For folks that either...
And it's a 501(3)(c) 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.
Rohini, 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 to other people?
I got this book recently called Vectors: Aphorisms & Ten-Second Essays.
It is so much fun to just pick out a couple of these ten-second essays at night and just read a couple of these and go to bed.
I'm going to recommend it to other folks.
A friend gave it to me and I'm going to pay it forward.
And then 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 beach time. So highly recommend.
People love fiction recommendations on our podcast, 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 for some reason stopped, but it's important to note, it's like tennis is kind of this metaphor and it's lessons from this coach that he taught people how to be amazing tennis players, which apply to 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." Exactly. It's fine.
It's funny that we need permission [inaudible 01:11:44].
Because then, it makes you feel more comfortable starting a book and trying books. Right, right. It's easy. All right, there you 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 council's reading it basically.
Next question, do you have a favorite recent movie or TV show you've really enjoyed?
I got to 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 I'm behind on these, second season, but Shrinking or Bad Sisters, Slow Horses was great, Severance, I'm waiting- It's come up a bunch. Yeah. Yeah.
Slow Horses has been coming up a bunch.
Sorry, you said something else after that.
Oh, I think Severance is coming up in its new season. Severance.
Yeah, there's some good ones on Apple TV. Also Presumed Innocent. Have you seen that? Oh, I haven't. So good. Apple TV. Watch it. It's only six episodes.
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....
You've experienced these rides, right?
Yeah, it's mind-blowing and it's mind-blowing how quickly it becomes just like you forget that you're in a self-driving car. Yes.
I actually asked one of the product leads of Waymo this at a happy hour and I was like, "Is it kind of like when you kind of remember this old elevator, there's always an elevator guy still there, even when it was all automated and 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?"
And he was like, "You'll feel comfortable in less than five minutes." He was right.
I felt comfortable in 30 seconds. It's wild. I love Waymo. Yeah. Me too.
I love seeing many Waymos in a row on the road in the Bay Area because it's like it's coming.
The future is coming so fast. So true.
And I started seeing it in LA now too. It's going to be fun. Yeah. [inaudible 01:13:37]. I 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 and cross 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, it's a whole other level. It's great. Two more questions.
Do you have a favorite life motto that you often repeat to yourself, share with folks, find useful?
I write a lot of quotes down and I think there's...
I don't know, I just really like reminding myself of some of these kind of quotes. So I use a bunch.
I think I use a Bruce Lee quote pretty often, or I used one Jesuit's line in one of my job reqs.
And there's certain ones that I do repeat, but I actually found this and I forgot about it, but I really love it and so I'm going to read this one out. Please.
This is from 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 each moment and every encounter expecting magic or miracles." Isn't that great?
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 this too.
It makes me think about Cyan Banister was just on the Tim Ferriss podcast.
I don't know if you heard that one. No.
And there's a lot of this and that. Worth listening to. She's fascinating. That'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 a favorite angel investment, one that you're most proud of or most just [inaudible 01:15:26]? That one's really tough.
What's one that like, "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.
"Rohini, why didn't you mention us?"
Yeah, 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, 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 got acquired.
Bobby Matson, he was the CEO and co-founder or founder of Payitoff of student loans and working on making student loan repayment easier for people, finding them ways in which maybe they didn't have to repay...
Doing a lot of this again, unsexy work.
in which maybe they didn't have to repay... Doing a lot of this again, unsexy work. And when we talked the first time, he was telling me that he had a new kid, he was still up at 3:00 AM reading regulations and what's happening with the student loan process and the federal
government, and 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 what actually needs to happen, what doesn't need to happen, and it deals with real money that these folks are coming out with, a real debt they're having to deal with, there was an emotional tug. And I love
And I love when founders have the drive, that passion, and the detail orientedness of finding a solution.
For folks that want to raise money and maybe have Rohini as an investor, here's your lesson of what she looks for.
[inaudible 01:17:07] 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, @rohinip.
Would love to connect with folks there.
I'm also on LinkedIn, not really on anything else.
So hopefully you find me in one of those.
And we are hiring, mercury.
com/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 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 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. [inaudible 01:18:32].
Did you say how many you're giving away?
Well, I think we'll have 25 available. 25. Okay.
There'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. Yes. Awesome.
We're definitely going to include that in the show notes. Thank you.
Rohini, thank you so much- Thank you. ... 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 lennyspodcast. com.
See you in the next episode.