Lenny's Podcast: Product | Growth | Career: Building minimum lovable products, stories from WeWork and Airbnb, and thriving as a PM | Jiaona Zhang (Webflow, WeWork, Airbnb, Dropbox)

I think it's really important to become really good at and also known for something.

You could be known for shepherding the most complex launches because you're just so good

at quarterbacking, working with go-to-market teams and cross-functional stakeholders.

That could be your thing.

You could be known for working on the most technically complex problems, find something

that you can be really, really good at.

The reason I give that advice is because when you do that, you can crush the projects that

you get because you're making a name for yourself for reputation.

And then you're giving more responsibility.

People tend to flock and give responsibility to the people that are known for being excellent

at something.

Welcome to Lennie's podcast where I interview world-class product leaders and growth experts

to learn from their hard-won experiences building and growing today's most successful products.

Today my guest is Jay-Z.

Jay-Z is Senior Vice President of Product at Webflow.

She's also a lecturer at Stanford teaching a course on product management.

Before this, she was Senior Director of Product Management at WeWork, a long-time product

leader at Airbnb where I got to work with Jay-Z for a number of years.

And she's also PM at Dropbox and at a gaming company called Pocket Gems.

In her conversation, we dig into the most common mistakes early product managers make

in their career, plus Jay-Z's biggest product mistake.

We cover the concept of minimal lovable products versus minimal viable products.

We talk about Jay-Z's unique frameworks for road mapping and predestination and OKRs,

and her take on how to structure your first 90 days as a product leader at a new company,

plus what she's learned from her wild year at WeWork, also the best advice she's ever

gotten around product and leadership, and the story of Airbnb Plus and where it went

wrong.

I've been hoping to get Jay-Z on the podcast for a while and I'm really happy that we finally

made this happen.

With that, I bring you Jay-Z after a short word from our sponsors.

This episode is brought to you by Brave Search and their newest product, the Brave Search

API, an independent global search index you can use to power your search or AI apps.

If your work involves AI, then you know how important new data is to train your LLMs and

to power your AI applications.

You might be building an incredible AI product, but if you're using the same data sets as

your competitors to train your models, you don't have much of an advantage.

Brave Search is the fastest growing search engine since Bing and it's 100% independent

from the big tech companies.

Its index features billions of pages of high quality data from real humans and it's constantly

updated thanks to being the default search engine in the Brave browser.

If you're building products with search capabilities, you're probably experiencing soaring API costs

or lack of viable global alternatives to Bing or Google.

It's only going to become harder to afford these challenges.

The Brave Search API gives you access to its novel web-scale data with competitive features

intuitive structuring and affordable costs.

AI devs will particularly benefit from data containing thorough coverage of recent events.

Lenny's podcast listeners can get started testing the API for free at brave.com slash

Lenny.

That's brave.com slash Lenny.

Today's episode is brought to you by Miro, an online collaborative whiteboard that's

designed specifically for teams like yours.

The best way to see what Miro's all about and how it can help your team collaborate

better is not to listen to me talk about it, but to go check it out for yourself.

Go to Miro.com slash Lenny.

With the help of the Miro team, I created a super cool Miro board with two of my own

favorite templates, my one-pager template and my managing app template that you can

plug and play and start using immediately with your team.

I've also embedded a handful of my favorite templates that other people have published

in the Miroverse.

When you get to the board, you can also leave suggestions for the podcast, answer a question

that I have for you, and generally just play around to get a sense of how it all works.

Miro is a killer tool for brainstorming with your team, laying out your strategy, sharing

user research findings, capturing ideas, giving feedback on wireframes, and generally just

collaborating with your colleagues.

I actually used Miro to collaborate with the Miro team on creating my own board and it

was super fun and super easy.

Go check it out at Miro.com slash Lenny, that's M-I-R-O.com slash Lenny.

Jay-Z, welcome to the podcast.

Thanks for having me.

I'm so excited to be here.

It's 100% my pleasure.

Amongst your many accomplishments, you teach product management at Stanford, which sounds

very fancy.

How long have you been doing this at this point?

I think six years.

Yeah.

Wow.

My question, the real question I want to ask about this is, in that time, you've seen

a lot of new PMs, and you've seen these PMs succeed, you've seen some fail.

What are the most common mistakes that you find new PMs make in this experience of helping

new PMs get into the field?

I think something that is really hard to untrain, but I think every human does it, is

you jump to solutions.

One of the biggest things I see, not just in my course, but also just as a PM and some

of the mistakes that you make as a PM, is the idea of get really attached to a solution,

a way of implementing something, something that you can see in your head that you want

to build.

That's the first thing I really want to unteach in our course.

A lot of people will literally come in, they'll be like, I want to build X startup, or I want

to do this thing, or I'm in blank school, and I've been doing a lot of research on this

particular area.

Like untraining that and being like, hey, we're going to go out there, we're not going

to think at all about the thing that you want to build.

Instead, we're going to be focused on users and people in the real world and their problems.

The first step is to understand their problems and then to understand if there's an opportunity

here as opposed to, hey, you want to build X thing for Y person.

That's the biggest mistake that you really have to unteach and like retrain thinking

around.

There's a lot of this comfort and people want to get into product management because they

think like, finally, I'll have the power, finally, I'll be able to tell people what

to build.

Finally, my idea is really going to matter.

Is that where a lot of it comes from?

I think there's a part of that.

One of the first things I teach is you're not a CEO, you're not here.

You actually have very little true authority because you don't actually manage anyone.

It's a lot of it is all through influence.

That is also a piece where you have to untrain that thinking.

I do think a lot of people come into the product role thinking that I get to call the shots,

I get to make the decisions, I get to decide what gets built.

Really your job is not that.

Your job is to understand here are the opportunities and then you're pulling together all the different

possibilities and you're really editing.

I do think it comes from desire for a lot of people thinking that's what the product

role is and what it actually isn't.

Let's go to the other side of this question.

We talked about what mistakes new peams make.

I'm curious, what's the biggest product mistake that you've made?

Wow, that's a good one.

It's so interesting.

I feel like as product people, we're always making mistakes and we're always learning.

Maybe I'll give an example from Airbnb since you and I were both there.

This one does stand out to me.

We're working on this concept called Airbnb Plus.

If you took a step back, we're really trying to do this to be like, hey, not everyone trusts

Airbnb in terms of, it's a platform.

It's not like it's managed inventory.

It's not a hotel.

How do you go in and really make sure that all the Airbnbs are meeting the quality bar?

I do think we were very solution first.

I think we're also competitor afraid at the time.

It was during a time where there were managed marketplaces.

There were the Saunders out there.

I think that as a company, we're very much like, oh, goodness.

What are we going to do in the world of managed marketplaces?

We went really hard down the solution space.

We essentially were like, let's go inspect our inventory.

Let's actually try to manage our inventory more.

Really what we should have done is taken a step back and be like, what's the real problem?

The real problem is people want to know what they're getting themselves into.

We need to represent the homes a lot better.

I think the other piece here that's really important is what as a company, is there strategic

strength and what's in your wheelhouse?

For example, Airbnb, we weren't that strong in operations.

Again, we're this platform with this marketplace.

If you don't have that muscle and then you're asking the company, the teams to essentially

build it from the ground up, that's really, really difficult.

Not to mention the unit economics.

Are the unit economics actually going to work even as you scale?

Yeah, I feel like Airbnb Plus is an untold story that somebody should tell and that could

be its own podcast, I guess.

You and I can tell it.

We could tell this could be Airbnb Plus, the hidden story.

As you said, the problem it was trying to solve was people don't really trust.

They don't want to even consider Airbnb because it's like, no, I don't want to stay in someone's

home.

I don't know what it will be.

It's unpredictable.

So, as an outsider, it felt like a really clever approach that we're going to vet them.

We're going to make sure they're awesome.

There's a minimum bar.

The question is, do you think it was just like, this is never possible because we'll

never make money as a business doing this because we don't make it that much per booking

and investing time, resources, sending people pillows, all that stuff is ever going to

be economical?

Or do you think there was a path that was just not executed well?

I think there wasn't really a clear path.

I think it was less than execution.

Exactly.

It was more just like, if you understood, again, this is my point around unit economics,

there are things where I think you have like magical thinking around unit economics.

You're like, well, when we get to the scale of X, it's all going to work out.

We can make these things happen.

I think you actually need to really make sure the unit economics work quite at the beginning.

So that is definitely one lesson.

And I think the other thing is, and going back to spirit of what are you trying to achieve?

If you're trying to achieve this idea of really knowing the quality of the place and for a

platform like Airbnb, the right way to go about doing it is through our reviews, right?

Our guest reviews, which are essentially free as opposed to literally sending out inspectors.

And I think that the other things are, if you can get signal on what are the things

around quality that people care about, is it cleaning?

Hey, I'm locked out.

And I think that there are other solutions besides inspection that then get at that.

So for example, it is actually cheaper to go send everyone a lock box than to deploy

an inspector and go look at your property, right?

It is actually cheaper to maybe do a partnership with a bunch of cleaners in different local areas

and then get that as part of the fee as opposed to doing the inspection.

So again, it's really about what are you really trying to achieve?

What is the user problem in each of these areas?

And can you target that problem with the particular listing that you're looking at?

And so I personally don't believe the unit economics ever would have really worked out.

I think we should have known that.

We should have dug into that more at the very beginning and then to get very tailored instead

of one blunt instrument to solve it all.

Hey, we're going to go inspect.

It's like, what is the problem for this listing?

And what's the best solution to fix that problem?

There's a couple of things that I think are important product leadership lessons here.

One is Airbnb and Bryan and many great leaders are famous for imagining the ideal situation,

imagining the great end result and then working backwards.

And often that leads to great results when you're being really ambitious and I don't know

how we're going to get there.

We're just going to shoot big and hopefully we figured out.

Sometimes it works out.

In this case, it didn't work out.

And what you're finding, maybe you even knew this early on is just like,

there's no possible world where this could work in this approach.

I guess, is there anything you've learned about just when to think big and not even forget it?

We're going to figure it out.

I know there seems impossible, but we're just going to try it anyway.

Do you have any kind of framework of when to think big like that and just go for it?

Let's just work out the math today.

Is this ever possible?

I think it's really important for every company to be dreaming big.

Like if you don't have a big vision, it's really hard for you to innovate.

But you got a couple of that really big vision with thoughtfulness around your execution.

And so I think one of the biggest tips I have is how do you just be very,

how do you be clear about the phase that you're in?

So I think it's totally fine to be like, hey, we are going to try X for six months,

three months, whatever it is.

And we're explicitly going to go learn these types of things.

We're going to learn why are people, are there signals that we would get that would indicate

that the communication with hosts isn't great?

Or this type of listing, if it's hosted by a person with multiple property,

I think there are factors that can be like, hey, we can learn this very explicit thing

in a given period of time.

And you can do what I call like unscalable things in that prototyping phase,

in that early phase to go learn those lessons.

But you just have to be very, very clear with your team on like what phase you're in.

Hey, we're in the learning phase and we explicitly are trying to learn these things

versus, hey, we have this really big vision and we're just going to kind of go at it.

Like that is not recommended in my mind.

It's like breaking it down into these smaller chunks.

That I think gets you the balance of thinking really, really big,

but also being able to be like, okay, we are still going to be able to say,

okay, this path is not going to work out.

We ran at it for a short period of time.

Got these learnings.

Now let's go down this other path.

Yeah, there's also like some cost fallacy that kicks in of just like,

spend so much time and money and resources on this thing.

Let's just go a little bit longer.

Let's just see if we give it another quarter, maybe it'll work out.

You should articulate what success looks like and the milestones you want to hit

in the small intervals that I talked about.

Right? So you don't get into this world where you're like, hey,

I've gone for two years investing in this thing.

Now we got to cut it.

It's like, what is the quarter long milestone?

Okay, what's the next quarter long milestone?

And at every single point, what does it go and no go?

I think that really can help a team and a company say,

it's okay, I invested a quarter in it, but I didn't invest two years.

The other important lesson here is about the importance of as a product leader,

pushing back and convincing leadership that you're wrong and this shouldn't

happen. I remember talking to one of our colleagues, Mike Lewis,

who was leading a different team with an Airbnb and he was just like,

oh, I realized I'm the person that should be saying, no, we shouldn't do this now.

Because he was like the head of product for one of the new bets.

And I know maybe in that situation, it was impossible because

Brian was very into this and everyone was like, we need to do this thing.

I guess, is there anything you've learned about how to push back on these sorts of things that

the founders really into when it makes sense to kind of go along and like, cool, let's do it,

let's buy in. As a leader, you have to be excited and teams to feel like,

oh, Jay-Z is really excited about this too. We got to try it,

even though maybe you feel like it's not going to work out.

So I guess the question is, when do you think it makes sense to try to convince the founder,

no, this is the bad idea versus like, let's go for it.

I think first it comes down to your conviction. Do you actually have conviction that this is a

bad idea or are you still, are you personally still learning? I think if you're at the point,

if you're like, I have total conviction, then your job is to say no.

If you do not, you're not doing your job. And then the question is, what are the tips in how

to convince someone who's very bought into an idea that that's not the right idea?

And there, what I would say is, it's understanding the spirit of what they're trying to achieve.

Being able to go back with, hey, I understand the spirit. The spirit is that we're trying to get

people who previously considered Airbnb before to come and use Airbnb.

But the right way to do it is not this very time-intensive, cost-intensive way to

inspect all these homes. The way to do it is to be much more granular in what we ask people when

they upload their home, right? And more checks in that. And that could be automated through

technology as opposed to through humans. It's coming back with actual options.

And I think we did that a little bit, to be honest. As a team of all, we learned and we're like,

this isn't going to work. And I explicitly moved off the team and I was like, I'm going to work

on the review system. I'm going to continue to evolve this and make it better because that is

the actual scalable way to do this as opposed to keep going at it in the very manual process.

And so I think that the biggest thing, biggest tip I would have for people in this situation is,

really understand whether it's the founder or your manager or whoever it is, what is it that

you're actually trying to, what is it that they're trying to accomplish for the user and for the

business. And remind them of that, like get aligned on that and then come back with better

options. You know, very few people, I mean, we're all, a lot of these people, they're very smart

and they're very motivated. They ultimately want to just do the right thing for their users. When

you come back with a much better solution and you have the data and you have the thinking behind it,

it's very rare that someone will be like, well, I still want to go after the solution despite

the fact that it's not working and you proposed a much better path forward.

And I think to touch on what you've already said is also make sure it's like actually,

there's a world where this could work, like do some math to figure out if this is a business

that will actually make some money in the future. Totally. Okay, I'm going to bounce around a little

bit. I have a bunch of different questions around different topics. You popularize this concept of

minimal lovable product versus this idea that everyone always comes back to, which is minimal

viable product. Can you just talk about what is a minimal lovable product and then when does it

make sense to kind of go in that direction versus a traditional MVP? The reason I care so much about

minimal lovable product is because I do think in a world where there are so many different options,

it's hard to just be like, hey, use this thing and barely meets a quality bar. And so I think this

idea of like actually deeply understanding for the thing that you're working on, what is a lovable

experience? What is the quality bar that resonates with your users? And again, especially in a world

where there might be a lot of different options, like minimal lovable products is the new MVP,

right? The new minimal viable product. So I think that's the real point. But at the end of the day,

it does come back to what are the options that a user has? And what are they trying to do? So

there's a world where your quality bar, your quote unquote quality bar or your, let's call it your

polish bar can be a little bit lower because the reality is the thing that you're quote unquote

competing against or like you're replacing is literally like a manual workflow. It's like

spreadsheets, it's doing something in a super terrible way. So you want to get your product

to market as quickly as possible, right? So it doesn't make sense for you to be like,

I'm going to build these like 15 additional features because compared to what, you know,

people are doing right now, your product without those 15 additional features is perfectly fine,

perfectly usable and perfectly quite honestly, like lovable. So it requires a lot of understanding

of like, again, your users and the space that you play in and the tolerance of your given user.

So for example, a designer might have a lot higher of a bar of like, this is the kind of workflow I

want. This is the kind of like bar for my product. But, you know, again, someone sitting on the

finance team or the IT team, right? Like their bar might be like, Oh, I'm used to doing these like

15 things. And so your thing is just a lot better.

I love to go even one level deeper. Is there an example of something you've worked on that

was a minimal lovable product that you think about? Or is there something out there that's

an example of like, here's maybe an example of a minimal level product versus MVP?

Again, it's very hard. I think every product team, every product person struggles with this

idea of like, what is the minimal viable, even that concept itself is difficult and not to mention

like minimal lovable. I'll give a workflow example. Very recently, you know, we, so we have been

investing in a couple of new features, you know, memberships and logic, new functionality for our

users. And what we realized at the end of the day, after investing in these areas, we were like,

Hey, we can get to minimal viable, but we don't know if we can actually get to minimal lovable

in a way that our users really, really want. And so does it make sense for us to continue to go

down this path of like, keep like, continue to ship away to get to minimal lovable when we are

maybe hitting diminishing returns for user base, or does it actually make sense to release what we

have, but then encourage our ecosystem to contribute the lovable piece. And again, it's not just like

you, you put it out there and you hope that you have to have a very strong point of view of like,

are we at minimal viable? Are we at minimal lovable? What kind of where in between are we,

right? And so having that point of view and then being able to say, are we going to be able to

meet as a company? Are we going to rely on our ecosystem to help us meet it? What are we actually

going to do? And then even within the future set, it's very much a, how do we do some things well

as opposed to do a little bit of everything? And that is a big piece of minimal lovable, which is,

again, you know, to me, it's like better to do five things instead of the 15 things and a really,

really great way with a high degree of polish with like, Oh, this really meets my need versus

trying to do everything and just doing a little bit of everything. And so every part of the experience

feels a little bit clunky. It's not quite there. People, I think, would actually respect this

idea of like, you've given me minimal lovable in five areas as opposed to minimal viable in 15

areas. Is there anything you've seen of just like that makes something lovable? I don't know. I know

it's not like easy to define, but like, what are things you've seen that make something lovable?

Is it like delightful features? Or is it what you're saying, which is just things are actually

good? Like there's fewer things, but they're each really good. There's definitely this idea of like,

the thing is just good. It has like all like it is high quality. It's not janky. It doesn't feel

weird. I'll give you like a very small example. Again, just from Webflow, this idea of like keyboard

shortcuts, right? Like that feels small, but like that is a piece that creates a lot of love from

user base who are power users. And then there's this concept of like pixie dust. Maybe I'll pull

out of the, you know, color like design tool space. And we'll talk about some of the other things,

whether it's Dropbox or Airbnb, but you can just do a little bit of that like extra pixie dust.

So an example from Airbnb, when we're doing the mobile app revamp, we're like, okay, there's like

these basic table stakes. But if we actually added in templates and we, and we made it so that these

templates could be maybe pre-populated in certain ways from the content they already have, that is

lovable. That is that extra little bit of pixie dust and spending the time to do that. And again,

you can't again, can't pixie dust everything that that will just at the end of the day, you know,

you basically have like your time, your staffing, right? And the scope of your project and like

something has to give. And so, you know, at the end of the day, you can't just like keep investing,

keep investing, because it's going to push out your launch timeline. But can you pick a few

different areas where you're like, I'm going to scatter that pixie dust, I'm going to do a little

bit more than what users are expecting. And that creates that lovelability.

Shifting to a different topic. I know you have strong opinions about road mapping and

OKRs and prioritization. And I know that's a big topic, but let me just ask, what's the most common

advice you give around how to roadmap well, do OKRs prioritize and or just like, I don't know,

common mantras or things you always come back to, to be successful in these areas?

Road mapping and prioritization are kind of one bucket for me and then, you know, OKRs and others.

So I'll maybe give you my biggest tip in each one of these buckets. So for road mapping, my biggest

thing that I tell my teams is you're telling a story. So what I want from you is I want themes.

I want a story like, like why are these things like things, the biggest things to invest in,

these levers, the biggest ones to pull. And what I really don't want, what I think is a very common

mistake from road mapping is people thinking like a spreadsheet with a bunch of projects, all, you

know, the rice framework, right? Like everything has like an impact or cost and, you know,

like an effort column filled out. Like they think that that is prioritization and that is a roadmap.

Like if you just do that, right? And then you present that to your team, like they're off to the

races. But what people, what humans really crave is like, why am I doing this body of work? And I

think it's also really, really important to have that really crisply articulated in your own head,

because ultimately what happens is you will learn things as a product person. You'll be like, oh,

I assumed this in the narrative in my head about my users or about my product area.

And then I learned why. And therefore my thinking changed, right? So instead of it being this massive

spreadsheet where you're going in, you're tweaking all the values, what is the story that you're

telling about your roadmap that these inputs can then go and influence? It could be like, hey,

I just realized I didn't know before that we have a lot more power users on or like maybe we have a

lot more like non-technical users. Well, that input changes my roadmap and changes my themes

in a pretty dramatic way. So skating at that level is really, really critical, I think for a

roadmap as opposed to going down to like the really granular details of the how. So that's the biggest

thing on road mapping, which is like, tell a story. What are your themes? Make it so that your team

can come up with the actual like how and the projects and all the little details, but really

create that scaffolding for them to know what's important. Can I ask a follow question on that?

Totally. Yeah. It's easy to visualize the roadmap of a spreadsheet to help people visualize what

you're suggesting there. What does that actual artifact look like? Is it a dock with maybe an

ancillary spreadsheet of the actual characterization? Is it a deck? How do you actually deliver this to

you with like Jay-Z? Here's our proposal for our team. Yeah. I'm a big fan of docks and decks are

obviously helpful if you're talking live, but I do think in a remote first culture or like lots of

us are in hybrid remote cultures, it's a tard because you know, decks typically require a

voiceover. And so we have been doing a big push even on my teams where I'm like, write it down in

document, force yourself to write the pros. Because when you write the pros, you can actually

add that level of granularity. So very much so like the same way I'm like, a roadmap is a story.

You're telling themes. Like you write a story in a notebook, right? You write a story on pages.

And so a dock is definitely preferred. And even in the dock, just being like,

here's what we're trying to achieve. Here are the, you know, the big areas I want to invest in.

Here are my big themes. And then going into each of those themes and be like, these are the big

projects. And then linking out again, not even to a spreadsheet sheet, but linking out to the

artifacts and the, the systems that your team actually uses. So if your team uses JIRA,

go ahead and link up to JIRA. Because, you know, so often docks get out of, or like spreadsheets

get out of date, right? Because they're, they're like a snapshot of whatever it is that you needed

at that point in time. But if you said you link up to the actual things that your teams are working

out of, you can always be like, these are the themes. I will edit these if I find major,

learn major things that would change my themes. And then let's go link out to the JIRA where

you can just see the snapshot of the roadmap at any given point in time.

Do you have a template or common structure you suggest the teams for think laying out the story?

Or is it just depends on the quarter and depends on the year?

I'll give a plug for a new thing coming out of Reforge, which is, you know, this concept of like

artifacts. And so we, we do have a lot of artifacts out there. So like, what are, what's our general

product development process? What are our templates for our specs? What are our templates for some of

these things that we're talking about? A roadmap, like a broader roadmap, instead of just like a

feature spec. So yes, we have a ton of those artifacts are always evolving. I think every team

kind of takes it and like tweaks it a little bit. But I do, I'm a big believer of like, bring those

artifacts back and then sharing them across the team. And so product operations is also a function

that we've invested in because it just really greases the wheels, gets all of our teams kind of

speaking the same language. Awesome. This episode is brought to you by Superhuman.

How much time do you spend in email each day? How about your team? You may not realize this,

but your email tools are wasting your time. Superhuman is blazingly fast email for high

performing teams. Built to work with Gmail and Outlook, teams who use Superhuman spend half the

time in their inboxes, respond to twice the number of emails and save over four hours a week.

That's over a month of save time per year. With Superhuman, you can split your inbox into streams

for VIPs, team members, and emails from your favorite products to reduce context switching and

make sure you never miss an important email. You can set reminders if you don't hear back

so that you can follow up and never drop the ball on an email thread. You can also work faster than

ever before with powerful AI features like writing, editing, summarizing, and even translating.

Join the ranks of the most productive teams and unleash the power of Superhuman.

Try one month free at superhuman.com slash Lenny. That's superhuman.com slash Lenny.

Moving to a different topic. Yeah. What is your number one piece of advice to

new PMs who want to accelerate their career? What do you find most often is the blocker

or thing holding them back or something they can change that'll accelerate things?

There's so many parts to it, but I'll pick one. There are many frameworks even beyond the one,

but let's pick one for your question, which is, I think it's really important to become

really good at and also known for something. What I mean by that is, when you're known in your company

for a particular thing, I'll give you a couple of examples. You could be known for shepherding

the most complex launches because you're just so good at quarterbacking, working with go-to-market

teams and cross-functional stakeholders, that could be your thing. You could be known for working

on the most technically complex problems. You can be known for working on things that are really

regulatory complex. Find something that you can be really, really good at. The reason I give that

advice is because when you do that, you can crush the projects that you get because you're making

a name for yourself for reputation. Then you're giving more responsibility. People tend to flock

and give responsibility to the people that are known for being excellent at something.

Is there something you were known to be excellent at in the course of your career?

I would say early on in my career, it was actually the fact that I had a strong analytics

background. When I joined gaming, I came from consulting. I didn't have any CS background

or a design background. It was really creating reputation around being very analytical, around

being able to analyze the data sets of my game and then make decisions. I also learned as I was

doing that, I was actually really good at execution. Being able to keep a lot of plates spinning and

working on the largest studio and managing all the complex pieces of that, that was what I

discovered. I didn't know this, but I discovered as I started working on the role. That was something

I brought to Dropbox when I joined Dropbox. It was like, I knew that I could work with a lot

of different teams and make sure that we hit a launch deadline. I would find myself trying to

lean into that superpower. Then when delivering upon that, getting more responsibility. Like,

hey, you just launched this really complex thing. This was a project that I had to work

across a lot of different platforms. We're using brittle APIs. It was a very, very small team.

I had a very, very tight deadline. When you were like, okay, I can do something like this,

you end up getting more responsibility because people are like, oh, she was able to do something

that was really hard with a small team. That's how you get more responsibility.

But it has evolved in my career. I think that at the beginning of your career,

you do want to lean into some of these pieces. It makes sense. But also,

even when you start to manage, it shifts dramatically. Being known as the best executor

is not necessarily the thing that gives you and your team the most responsibility. As I've

run my career, whether it's at Airbnb or we work at other places, I flex into maybe a different...

It's like taking your core strength, but then flexing it and finding different ways to bring it

to life. Much of what I just heard is you just worked incredibly hard and just got shit done.

I think that's very, very important and often leads to a lot of success.

PMs have to get shit done. Ultimately, you're responsible for the outcome,

just no matter what happens. Yeah. I like that. Be known for getting shit done

and working really hard. That's never going to serve you badly. I think that is just

lasting advice for being successful as a PM. I realized that we were talking about your tips

on prioritization road mapping and then OKRs and then I shift to topics and you never got to the

OKR buckets. Let me come back to that. Yes. My biggest tip on OKRs is actually get really,

really crisp on qualitatively. What would make you say, yes, we did a great job. The reason I

pushed so hard on that is because I see so many teams get really mucked down by OKRs. They're

like, oh man, if I don't hit my OKR, I feel like I'm going to have a really bad reputation or maybe

I won't get promoted. You just get all this fear around OKRs. You see people sandbagging.

You see people being hesitant to put in numbers until the very last second until they're super,

super confident. That results in ultimately a failure for your company to innovate and move

quickly. What I really pushed on for OKRs is like, what are you actually, what's the spirit?

I think I asked this question maybe too much to my teams. What is the spirit of what you're trying

to achieve? What would make you say, I really, really crushed it this past quarter. It's less

about I would rather have all the OKRs be red or yellow and we missed everything. We learned around

why we missed it than everything to be green. In fact, when everything's green, you're like,

we definitely did not set ambitious enough OKRs. It really pushed a lot on what does it truly mean

to crush it and be successful? What does it mean for our users? What does it mean for our business?

For our users to feel X, can you describe that? Can you write that out? For our business to see

this in terms of the revenue growth? I think it's really hard because a lot of times you get

your data scientists, you get the PM themselves being like, oh man, I'm only an input metric,

not an output metric. I definitely can't sign up for that revenue target because I have an input

metric. All of those things are true. If you don't do the homework of really drawing that line of

being like, this is the ultimate thing I want to do for the company and for my users, then a lot of

times you end up hitting all your OKRs, but the company and your users at large are like,

I don't feel anything different. Your company doesn't look at the things that you've worked on,

and they don't say this is a smashing success. Your users are feeling no differently. That is

the worst outcome in my head where you're almost doing OKRs for the sake of OKRs as opposed to

letting them be a guide to delivering really great product to your end customer.

I like the idea of that, but I imagine what often happens is you sign up for an ambitious OKR,

you don't wait until the last second to commit to it, and then ends up being read, and then you go

into performance reviews and like, oh, Lenny didn't hit his OKRs. Look at this, guys. Teams

is not doing great. How do you think about that as a product leader, understanding if the team

actually did well and the PM is performing well when they sign up for these really ambitious OKRs

and their story is great, and they're doing the right thing, but they fail?

First of all, I think it's creating a culture where you are not punished for that, because I

definitely don't want a culture where it's like you took a risk and you failed, and therefore

your performance is impacted. I'd much rather people take risks than to be safe. I think that's

the first thing. That being said, you're also not doing a good job as a PM if you're like,

this is my super, super ambitious thing, and you're like, I have no idea how to achieve it.

Your job is to dream big and also have a plan to go tackle it. What I would expect the PM to be

able to say is, this is my North-North star. I'm not going to be able to do that in a quarter.

That just is unreasonable. Here are the five milestones, whatever number, some number of

milestones that it's going to take me to do quarter over quarter to achieve this really,

really ambitious thing. Let me draw you that path. Here's the milestone all the way across,

and this is the first one, and this is why it's so meaningful. I expect that combination where

you're like, I know where I'm going. It's really, really ambitious, and then you can then break it

down. Again, I would much rather have someone shoot for the moon, even for someone to say,

this is the thing I really want to do. I don't know my path yet, then to be really,

really safe, because when you're safe, you're always going to be building something suboptimal.

It's going to be some optimal use of your resources as opposed to actually trying to figure out what

the best swing that you can take is. It sounds like it comes back to the story of the roadmap

and what they're trying to accomplish. As long as it feels like the story makes sense,

there's a path there. The team did their best. I think we knew. We knew it was really ambitious.

We knew maybe they wouldn't get there. It sounds like that's the thing you look for

in a performance at the PM. Totally. Yeah. Awesome. You mentioned WeWork,

and I want to spend a little time on WeWork. You were at WeWork for about a year, and I think it

was in the middle of a lot of the craziness that went on at WeWork. It was. It was 2019.

I feel like that year, headlines were either about Trump or about WeWork in the news.

That's tough. What was I like being a PM leader at a company in that craziness? Is there a takeaway

from that experience that helps you be a better product manager or leader person?

Yeah. I learned a lot from my time there. I think the most important lesson I learned was really

around. I think there's a people-lead management lesson, and then there's also just how do you

build an org period. The people lesson I learned was just really around empathy.

In fact, essentially what I was doing was I built a team. I spent the first six months of my time

there actually growing my team a lot. Not just in the US, but in Asia and in Europe. Then the

second half of my time there was actually being like, okay, what do we do? If this is what's

happening with WeWork, what are we actually going to do with all of these people who have come to

WeWork to work? There's so many lessons there around leadership. How do you think about people?

How do you think about giving them the right transition plans? It was a lot of learning.

I think probably a lot of people even right now through the macroeconomic downturn,

they're learning that lesson in a really hard way. It was definitely something that

I got a crash course on early. The second lesson really was around not over hiring.

I think that was huge. I personally learned that lesson through my time there and it's

something that I'm very conscious of at any company that I go to. Just because laying off

half your team is a terrible feeling. Literally having hired people and then having to let them go,

it's not something you want to do. Being really thoughtful around how do we not over hire? How

are we really clear about these milestones? We've got to get through these gates. We've got to be

able to show these types of results. Then we unlock hiring in XYZ ways. That hygiene is really,

really important. It feels like this connects back to there being people's story of just,

let's just be really ambitious. We don't have any idea we're going to get there,

but we're just going to go for it, hire like crazy scale, put a lot of investment in this thing,

and hopefully we'll figure it out. I do think there was a little bit of that in the ethos of

how we work with functioning, for sure. I think that what was really important for us to do was

to be like, we have this. Operationally, we work as really strong. In fact, I went to WeWork because

having been at Airbnb, I was like, I don't feel like we've dialed this operational muscle down,

but I know from what I've seen and the way WeWork has expanded that they're really,

really excellent at the operations. Again, we hired beyond our skis on the tech side.

It's like we don't need a team of this size to go do the things that are needed for the product to

feel really great. At the end of the day, it's about booking. Yes, there are technology that

would accelerate that, but do we need it to be super platform aware? Do we need it to be super

futuristic? That's actually not what people care about. This all goes back to what are people's

core desires and whatever product that they're using, whatever thing that your business is trying

to serve them. Really understanding that will help you have a sense of like, hey, you still be

really ambitious. Again, in a hybrid world, it's like, why have real dedicated office space?

Every company could go through WeWork as opposed to this dedicated space. That's still a really

good idea. That's still a really big vision and a relevant vision, but what's the key piece of

that vision? The key piece of the vision is around inventory. Then you make that inventory

management easier. You make all of these things easier, but that's not a technology play in the

same way as it is an operational play. Just really understanding again, you can still dream really

big, but you don't have to dream big and higher big in all the things in order to have a very

ambitious vision that you deliver to the market. If you think back to WeWork, what was your favorite

memory? What was your hardest, least happy memory if anything comes to mind? I think this idea,

dreaming really big. I think everyone who had joined WeWork, they were like, we could do a lot

here. The idea of really the physical space and fusing technology. I just feel like the people

at WeWork were dreamers in the best possible way. I feel like for every company that I've been at,

it's really about you join. I personally joined for the product, but I say for the people. You

joined because you're like, I want to work on this mission. This product is really motivating,

and then you really stay for the people. The people at WeWork were really great.

So that was definitely my favorite memory. I think the hardest memory was,

this gets a little bit personal, but I was actually in my first trimester when we were going through

all of these layoffs. I basically was faced with a choice. It was like, hey, do I stay at WeWork?

I would be guaranteed maternity leave. I was going to be moved on to this other team that was

definitely going to stay. Do I do that? I think they're just a last piece of the thing I was

wrestling with is I hired a lot of these people. I felt really responsible for the fact that I

convinced them to come to this company that now was going through a lot of change. I specifically

remember someone, when I hired them, we had a long conversation about their visa. In my head,

I was like, I just don't feel right, again, laying someone off. That's only going to have so many

days to be able to go find their new role. The hardest moment, I actually remember this very

vividly. Am I going to take this new role, or am I going to put myself on the layoff list,

essentially, and give the role to someone else on the team? When I really think about it, yes,

I was pregnant, but I would have more time and more freedom to go find my next thing versus

someone who I brought to the company who was on a visa. So that, to me, just really stood out and

goes back to this concept around leadership is so much about empathy and people. It's as much

that as it's about understanding your market, your customers, and the strategy of your product.

Damn. What convinced you eventually to take off and try something different?

Well, I made the call in that particular case and give the role to someone else.

And then once I made that call, I was like, well, I got to go find something. I know that this is

my last day. So I'm going to have to go find something. And it was really interesting because

I actually, well, I went through an interview process. Well, I was in my second trimester,

and then ultimately I chose to join Webflow. And I joined when I was literally at the beginning

of my third trimester. So I had exactly 90 days before my first son was born.

That's a great segue to the question I was going to ask is around your 90 day plan that I know

you have, you put a lot of thought into how to think about the first 90 days. But before we get

there, the movie on WeWork with Jared Leto, how similar to reality was that brought?

I actually have not watched it in parent life. You don't have any time. And I do think there's,

I feel like if you ask people at Uber, if they've watched some of the time, or they're like,

it's not for me. Same way, why haven't I watched Silicon Valley? You're like, it's a little too

close to home. Well, it was quite a great movie, and I really enjoyed it. I'm curious how close

it was to realize. Okay, so then back to the 90 day question. So I know you spent a lot of time

thinking about your first 90 days of Webflow, you're pregnant, as you described. And you have a

perspective on just how to think about the first 90 days when you join a company.

Can you just share what you've learned there and what you recommend there?

Yeah, I do think the first 90 days, depending on your role, is very different. But maybe I'll

just talk a little bit about the first 90 days as like a header product, right? Because you're like,

whoa, or even just as a leader, like how do you go in? How do you really absorb all the

information and get all the contacts you need and then effect change? And I think what was unique

about my first 90 days is it was time bound. It was literally something where you're like,

sure, I'd love to absorb information for many months, but I just don't have the luxury of the

time. Because you're going to go on mat leave right after. Because yeah, essentially I was going

to go on mat leave. That's great. And so the biggest things that I thought a lot about for my

first 90 days was at the end of the day, yes, you have to read like the most important thing

for anyone's first 90 days is to build context and to build context well. But what I had to think

about a lot was, well, how do I quickly build context probably like faster than I'd be given

a luxury, you know, any other time in my life. And so I thought a lot about who do I speak to

at the company? How do I create like a, like a, even just like a calendar of like speaking to

people, yes, my leadership team, but also like across a bunch of functions and then across a

bunch of levels. So it's really important for me to like even start talking to some of the

engineers from the team, some of the engineers who had been there for the longest time to really

understand, well, what's hard about our tech stack, like what's going on, like what's hard about

your day to day. And so I actually took time to really think about, okay, well, I want to speak

to all of these types of people at the company. And I packed my first like a couple of weeks with

like a lot of those meetings. And so I think that was one piece, which is like, how do you build

context as quickly as possible? And my tip there is like, again, it's not just with your peers,

it's not even just with your team, but to really think across all the different functions and then

think about where you're going to get the most amount of information in that particular function.

And that was one piece of it. The other piece was like, I was like, well, I'm going to be out.

I was only out for two months, but I was like, that's still a long period of time in the life of a

startup. And so what I, it was really important to me was like, I did not go out having just listened

and like, great, like I have the context, I'll see you in two months. But it was really important

for me to actually have a plan in place before I went out for my team. And so there were pieces

where I was like, okay, I want to first, again, get that lay of the land, I want to have enough of

like a strategic, hey, these things make sense, keep going, keep executing, these things like

don't make sense. Let's get the, like, let's identify what those things are. And let's actually

start to do research around these things so that when I do come back, we have a body of work that

we can look at and be like, okay, this information, this data is making us choose to go down the path

or this is a no go or no go decision, we can make that decision now where we couldn't make that

decision before. So that was another big piece, which is getting all the strategic pieces in place,

having a plan laid out and explicitly articulating in that plan, keep moving. These are things that

we got to do a lot more research on and then like assigning people like, hey, you're going to do this

research and then we're going to come back and talk about it in, you know, the two months that I was

out. And I also, you know, took the time, actually, funny story, I think I literally had a board meeting

the day before I went in for a checkup and then in the checkup, they're like, you're in labor.

And it was really important for me to do that because I was like, I want, you know, for the

things that I'm seeing for the gaps that I'm seeing, I want everyone to be aware, I don't want to just

like be with one founder, I want the whole leadership team, I want all the founders, I want the

board, I want everyone to be aware that like, for example, engineering hiring was really,

really important. And I was saying, you know, I was communicating, hey, we are just not staffed

in a way where we can deliver some of the ambitious things that we want to do. And so explicitly

calling those things out and creating awareness around them and then asking other executives,

right, to like step in and be accountable. Those are big pieces of what I wanted to achieve in

my first 90 days. So I took notes on this. So the first is just get context, figure out who

you need to talk to. Is there a tip there of just like how many people, because you could do this

infinitely, meet everyone eventually? How many people did you end up maybe scheduling meetings with?

Well, definitely everyone on my direct team and definitely everyone in like on the leadership

team. So call it those two combined were maybe, I don't know, like 20 or so people, 25 people.

But then it was really about like finding the people and the other functions. And to me,

for any given function, it was really like getting a read from again, that leader, but also

someone closer to the actual work. And so you kind of like look at the functions,

whether it's product marketing or engineering, you know, whatever was back then, I didn't have

designs like design and really getting a couple of data points for each one of those functions.

So if you add that up, that probably, you know, was like 45, 40 to 50, like conversations. But

again, if you if you're doing them back to back and you're really synthesizing, you're actually

getting a really good picture of what's going on. And then the second bucket was identify things that

need to be shifted, changed, flagged. I imagine there's also an element of trust and building trust.

Was that a part of this of how you thought about it? Or do you feel like as a product

leader coming in, that's less essential versus like, say, a new PM joining it, a team, a team as

that I see. Trust is so important. I mean, trust is everything, right? You know, as a PM,

the trust that your cross functional partners have in you, the trust that the, you know,

the CEO has in you, like it's huge. Trust is everything. And maybe here, I'll even talk

about some of the mistakes I made in the first 90 days. I think I was so much like, okay,

I only have 90 days. I got to, you know, go, go, go. We got to go. I was almost pushing too hard.

I was pushing too hard for change. And I think that's that's the tricky part that every product

leader, especially if they're coming into a new role, has to figure like, how do I gain trust?

And then take that trust and then push for change, as opposed to push for change too quickly,

before I have that trust. And so again, it was, it was a personal learning. And I think,

you know, I think part of it was really driven by this, the time bound nature of it. But if you,

if you, hopefully not everyone has only 90 days. So if you take that learning into mind, it's like

really thinking about your trust as like a bank, right? It's like, you're putting money into your

bank. And then at some point, you're going to take money out, you're going to use that social

capital, you use that trust to go push for things, push for change. But you have to be,

you have to be thoughtful about how full your piggy bank is, and you don't want to be spending,

you know, when you don't have the trust in the bank.

What were signs maybe looking back, that you didn't necessarily have the trust that you

thought you did, or you should have had? I think something like, you know, a product like Waffle

is a very complex product. And there are so many pieces to it. So it, you know, it's very difficult

to learn the product in, you know, the first 90 days, especially if I was also prioritizing all

these conversations with the team. And so I think that again, without the time constraint,

what I would recommend, right, is to be like, Hey, every product leader has to take the time to

really go deep on the product, given the complexity of what flow and given the time about the nature

of what I had to go out, and given the fact that I really also wanted to build that like social

context around like, what is working and not working from like a function working together,

not just like what the product is, what I wasn't able to do is spend enough time with my,

with the product to be able to have all of that in my back pocket to be able to be like, Oh,

okay, well, like, I know how this, this and this works, because I've like, literally used it like

a bunch. So like, you had to choose. And in my head, I was like, I would much rather understand

how the team is functioning together. And the reality is like the team was comprised of a lot

of people with a lot of deep product context. So ultimately, you know, as all things in product,

you know, this Lenny, like, everything's a trade off. And so it's a trade off. And so,

you know, you kind of had to make the call of what you want to trade off. And the thing I traded

off the most was that that product context in my first 90 days. And again, it got me some things

because I was able to have the time to go deep on the things I mentioned, but it didn't give me

enough trust in the piggy bank around the actual like product fundamentals or like product, like

the actual thing we're building as opposed to like the discipline.

So at this point, you've worked at four legendary companies, Dropbox,

Airbnb, WeWork, Webflow. If we were to just go through each one, what's just one lesson

that you take away from each of these companies in terms of how it's informed,

either how you build product or lead people, anything along those lines?

I'm going to actually give you my biggest thing across all four on the product side and then on

the people side. There are so many nuances also. And you know, we could spend another two hours

talking about each one of these. But I think just to impart like my biggest high level learning

on the product side, it's really about really understanding why people love you.

And like not forgetting to invest deeply in that core concept and then building everything around

that. And so I'll walk you through the different companies. So specifically for Dropbox, I think

we did waste cycles where we would be like, Oh, we see, you know, X happening in the market,

like Slack is really taking off. Why don't we build like a Slack competitor? Or like,

why don't we build chat? And I think that it really missed this idea of like, well, why do people

love Dropbox? And what do we need to do to continue investing in that so that that remains true?

People love Dropbox for simplicity, for how delightful it is, how easy it is to use, right?

So, you know, I think we actually went for a period of time where we didn't invest enough in like

just like performance of our client. Like how long it takes for the thing to sink is a big part

of the experience of using Dropbox, right? And so I think that is like a big, big learning where

it's like really understanding that would have shifted your investments into like doing that

performance work as opposed to kind of like chasing the competitive space. And I think going

back to chasing the competitive space is this idea of like, what is your alpha? Like again,

why do people come to you, you know, people come to Dropbox again for all the things I mentioned,

but also ultimately like, we have your files, right? Like so if you're going and building a

chat product, that's fine. But really that the best chat experience or like collaboration

experience is going to be more around your files, as opposed to around just the conversation, right?

So I think really understanding that is like a huge, huge learning. And I think that same lesson

can be, you know, it's very true for Airbnb, right? So at the end of the day, Airbnb is known for

like all the homes, the fact that these are homes that real people put on the platform. And

we spent some time talking about Airbnb plus, when you are thinking like, I got to go in,

I got to manage the inventory, I'd inspect it, you're, you're almost like taking away from the

thing that is like what makes Airbnb special as opposed to leaning into it, right? We also spend

a lot of time on experiences. We dabbled in transportation, we spent a bunch of times on

other things. But if you really sat back and you're like, well, what makes Airbnb special?

How do you double it down on your strength? It's like spending the time to make that,

that experience of like really understanding what's in a home so people don't go and get

surprised. Like making that, you know, onboarding journey for the host and then discovery journey

and like, you know, like, you know, guest booking journey really, really great. So I think that

that same lesson would apply to Airbnb would have in my head like changed the way we invested.

I think we would have gotten more returns as opposed to spreading ourselves and then like

having things that like sort of work, but then didn't quite work. And then same again,

same principle applies. So it's a we work. What is the thing that makes you really special? It's

the inventory. It like, it's not actually like, oh, it's so amazing that I get to use this key card

and this key card does like 10 different things. Like that's not what makes the we work experience

special, right? And so again, if you knew that you wouldn't spend all that time being like,

I'm going to really deeply invest in the tech team. I'm going to do all these interesting things.

You'd be like, I just need to make inventory management great. Like I need to make it so

that like the sales team that operations team, like they have the tools they need to go out and

get the inventory on the platform, you wouldn't do all this other stuff. That's just not the core.

And then finally, like even at Webflow, we are learning this lesson, you know, all the time,

we're like, at the end of the day, like people really love our designer. They love the fact

that they can use it. It does so much for them. It's so powerful. And then you add our CMS and

it's really powerful design with data. So like investing deeply there as opposed to spreading

ourselves too thin is also a lesson. So I think that that I think across so many companies, this

lesson around like, understand why people love you, double down on that. And then whatever

else you build around it, because again, you don't want to also be like, you're not like a

single product company, you're not like a one trick pony, you are going to invest in these

multi products. But when you invest in a new product, really go back to again, what's the core

of our advantage? And how can that be something we leverage and deliver delivering a really great

product experience for our users in X adjacent area or X add on? Final question before we get to

our very exciting lightning round. Okay, what is the best advice that you've gotten that has

transformed or impacted the way you build product or hire or lead? Has anything come to mind?

I can't remember where I got this advice, but I feel like I got it in multiple forms.

And it just really sat with me is this idea of like, asking for help.

And I do think about that a lot, because I think there are so many times when you're like, oh,

I'm the leader of X thing, like everyone's looking to me like the puck stops to me.

I need to have my like, act together, you know, like, I can't be asking for help if I'm asking

for help, like, is everyone to feel like, you know, I don't know what I'm doing. And ever since

I've been people managing, I've been pushing myself to be like, I know it feels not intuitive to go

ask for help when everyone is looking to for you to give them advice. But if you don't ask for help,

there are so many times where you're just going to be sitting there with your problems.

And there's like, whatever you have in your mind is just not the global best thing.

And you have to go ask for help, you have to go ask for help from your, your partners, your

peers, even your team, even being like team, I don't know, like, I really don't know, like,

here's the guidelines, like, here's how you might want to think about it. But like, I don't know

the answer, you know, the answer, going out and getting mentorship. Like, I think this idea of

like really being able to say like, be honest about what you know and what you don't know and

ask for help when you don't know something, that's probably the biggest thing that I hold

as like a core principle and just helps me build better products.

What's something that you've asked for help about recently, as an example?

So I'm working on our product strategy for the next three years. I'm thinking a lot about how do

we really leverage AI to support all of our service providers and support all our users who

come into Webflow and, you know, have a hard time sometimes learning how to use our product.

And so I'm not an AI expert. So asking for help from the founders, from external folks,

from engineers to be like, well, what's happening? Like every single week, I feel like LLMs are

changing. What's possible in the world is changing. And so constantly asking for help to iterate on

the strategy is a huge part of what's happening every day for my, for me and my job.

Jay-Z, we've reached our very exciting lightning round. I've got six questions for you. Are you

ready? All right, let's do it. What are two or three books that you've most recommended to

other people? I love the Design Sprint by Google. I also really like Julie's book around managing

people, how to be like a good manager. That one's really great. And so those are my, I guess, like

more like business side of the housebooks. And then, you know, we can also talk about like fantasy

stuff if you want. But yeah, give us some, give us some recs there. I'm a big fan of Brandon

Sanderson. He completed the Wheel of Time series on behalf of the Prius author. He, you know, he

has the Mistborn series. And so he, he's a great one. He actually has this, during the pandemic,

he like, hold up and like wrote a bunch of books. And this was like, I have a confession to make,

or I wrote, I wrote like four extra books. And the latest one is Trust by the Emerald Sea that I

really love. I saw the video of him sharing that news. And he's just like, I wrote a book during

COVID. And then, okay, I wrote a second book. And then, oh, it wrote a third book also just keeps

going. I think he was like, I have a secret, or I have a confession to make. And everyone was like,

Oh, no, are you going to say that you have like a ghostwriter because you're so prolific? And he's

like, no, I just wrote formal books. What a beast. Next question on that topic a little bit. What's

a favorite recent movie or TV show that you watched? I know you said you don't get to watch much,

but anything come to mind? I feel like every night I'm watching Sesame Street, like, like video,

like songs, we don't do TV, but we do do YouTube songs. So I honestly don't have an answer to that

other than like, we watched like the Elmo song and the ABC song with three year old.

There's been a lot of parenting advice on this podcast with my child coming soon.

And so this is very on brand. Before we started this, you mentioned the painting behind you is

referenced in like Arcane as it's connected to the show Arcane, which I imagine.

Yes. I'm a big, yeah, I'm a big fan. So painted this a long time ago before Jinks and Vi were

a thing. And, you know, when Arcane was made, both my husband and I were like,

What? How did we predict this? This is amazing. So it's a good one.

There we go. Some adult content. What is a favorite interview question that you like to

ask candidates? I do like to do behavioral questions is really understanding like when

they've been in challenging situations, when they've been in ambiguous situations,

like how do they navigate ambiguity is a big one for me. Because at the end of the day,

like the PM job is really ambiguous. Like it's really hard to describe on a piece of paper

all the things that you're going to encounter. So asking a lot of behavioral questions around

around that. And is there anything specific you look for in their answer that tells you

this is a good answer or not a good answer? Yeah. Good answers are people who put structure

and a way forward through the ambiguity. Like that's what you look for. Like you want your PM

to not just be like, Oh, no, we're swimming in ambiguity, but like actually put a path forward.

I think also looking for people who are like seeking help, seeking those inputs as opposed

to being like, this is the way this is very clear. Because again, the chances of whatever path you

chart out for any product for anything that you're doing is like the right path from the first time

that you do it. So rare. And so I want to see someone be able to like get those inputs, be able

to like say like, this is the path, this is how I like learn why, you know, I put this path together.

And then going back to a lot of the stuff I think we touched upon in this podcast is like,

what are the little milestones that make you say, Hey, is this working? Is this not working? And

then make you either make a different decision. Seeing people do that really well is a big thing

I look for. Awesome. What is a favorite product you've recently discovered that you love?

I love, I mean, it's not recent, but I do love the SNU. And it's very top of mind because I just

graduated my second son from the SNU. And it was, it was a little bit like, Oh my gosh, like no more

rocking of the baby. But I do think it, it does a good job of like actually doing the thing and

also giving parents peace of mind. The other thing I'm a big fan of, again, you'll see where my

head's at, lots of child like related things. A mid journey for your toddler is actually great,

because instead of it being like absolute instant gratification of like, I want to see a fire truck

and here we go, here's my phone. It's like, let's wait for mid journey to create the fire truck.

And specifically, you can even tell the journey what you want. It could be like, I would like it

to be blue. He's obsessed with Jungle Book, wearing a fire hat next to a fire truck, right?

And so you can actually like create and I do believe in the future so much of what we are

going to be doing as humans is literally like, what is the creative process? What's the idea?

It's less about like, executing all the pieces of it. But it's so important to still be able to

be like, I want, like, this is the idea that I want to bring to life. And so I just think like

training that is as huge.

Feels like you've just defined your three year strategy for Webflow right there

with AI. Next question. What is something that you've changed in the way you built product that

might be relatively minor that had a big impact in your team's ability to execute?

There's so many different things that we've done at all the different companies. It's,

it really depends on the company. And what I mean by that is like at a company like Webflow,

where the tech stack is complex and where a given feature has so many different interactions,

right? You're like, I, you know, people depend on this workflow. This thing interacts with this

thing. It's a whole platform. One of the biggest things we've been tweaking is like, how do we do

more of a tech spike at the beginning to be like, do we have a good sense of like, how difficult

this is going to be the unknowns? Can we get a little bit more detail in them so that we don't

go down a path and be like, Oh, this, this doesn't make sense. So I feel like that that's like a

tweak in the process that has really made a big difference at a company like Webflow. But

when I look back to other companies, again, that that might not be your biggest problem.

Another problem could be like, Hey, it's just like so difficult to work with press functional

partners and doing a little tweak in the process where you bring them in in a kickoff meeting.

That might be the thing that just like changes that dynamic of like how you work with teams.

So it's really, I don't know if there's like one thing, but it's almost like every day I'm

thinking about small tweaks in process to make all of us more efficient.

Final question. What is your number one pro tip for using Webflow and being successful with Webflow?

My number one pro tip is, you know, there's a lot of stuff coming out that I'm very excited about.

I do think, you know, Webflow has traditionally had a high learning curve and it's because we're

pro tool or professional tool, we can do really amazing stuff, so much power that would deliver

you. But with that power, it has come with like, it's like hard to learn. And so one of the things

that I'm really excited about pro tip for using Webflow in the future is, you know, we're really

going to bring the magic of Webflow University, the magic of AI all together so that you can just

use and learn Webflow so much faster. Learn Webflow in the context of what you're doing is supposed

to going into a different tab and like looking for like the Webflow University stuff in the

in context to the product, being able to actually like take action directly, like prompting Webflow

to be able to do things for you. Like it's just going to be so much easier in the future to use

the product. So that's what I'm excited about. We're working on it and it will be out in the

future. Okay, no specific dates yet. Yeah, you could share. And this sounds like breaking news

of cool stuff coming. Some things are in, you know, Alpha and Phi Beta, but we do want to be

developing it with our users and really learning like, is this the power that you're looking for?

Is this thing that's going to get you over the activation hump that you've struggled with in

the past? Jay-Z, I think we've made a maximally lovable podcast episode. Thank you so much for

being here. Two final questions. How can listeners find you online if they want to reach out? And

how can listeners be useful to you? Well, I always love feedback. So if there's feedback on the

podcast, send it my way. Or like, even just like, what would you want to learn? Send it my way. And

the reason I ask that is because I'm actually working on a course, another course through

Reforged, which is around managing your PM career. And so really just, you know, I've talked to so

many people advice around their career. But if you want to reach out and be like, these are the

problems that I'm facing, it would actually really help me as I am creating this course,

which is going to launch in a couple of months. And so I'm excited to find me there if you want

to chat more and send the problems that you're struggling with when it comes to your career.

And that would help me refine my course. And that's just Reforged.com. There's no

URL yet specifically for that course. Not yet, but it will come soon. And what maybe I'll do

is I'll post it on my website, which is built in Webflow. So my full name.com. Got it. Jay-Z,

thank you so much for being here. And thanks again. Thanks for having me. 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.

Machine-generated transcript that may contain inaccuracies.