Lenny's Podcast: Product | Career | Growth - An inside look at how Figma builds product | Yuhki Yamashita (CPO of Figma)
Episode Date: January 8, 2023Yuhki Yamashita is Chief Product Officer at Figma. Prior to Figma, he was Head of Design of Uber’s New Mobility efforts, and before that a product manager at Google and Microsoft. Adding to his impr...essive resume, Yuhki also taught introductory computer science at Harvard. In today's episode, we talk about operationalizing quality, the case against OKRs, and how Figma isn't just known for product-led growth, but also for building a community of empowered users. Yuhki also shares why he thinks storytelling is key to being a great product manager, owning the "why," and the potential impact of Adobe's acquisition of Figma.—Find the full transcript here: https://www.lennysnewsletter.com/p/an-inside-look-at-how-figma-builds—Thank you to our wonderful sponsors for supporting this podcast:• Notion—One workspace. Every team: https://www.notion.com/lennyspod• Vanta—Automate compliance. Simplify security: https://vanta.com/lenny• Flatfile—A CSV importer that says yes instead of error: mismatch: https://www.flatfile.com/lenny—Where to find Yuhki Yamashita:• Twitter: https://twitter.com/yuhkiyam• LinkedIn: https://www.linkedin.com/in/yuhki/• Website: https://www.figma.com/@yuhki—Where to find Lenny:• Newsletter: https://www.lennysnewsletter.com• Twitter: https://twitter.com/lennysan• LinkedIn: https://www.linkedin.com/in/lennyrachitsky/—Referenced:• Yuhki’s guest post on Lenny’s Newsletter: https://www.lennysnewsletter.com/p/how-figma-builds-product• Shishir Mehrotra on Lenny’s Podcast: https://podcasts.apple.com/us/podcast/the-rituals-of-great-teams-shishir-mehrotra-of/id1627920305?i=1000576021672• Five Why’s template: https://www.figma.com/templates/5-whys-template/• Dylan Field on Twitter: https://twitter.com/zoink• Jeff Holden on Twitter: https://twitter.com/jeffholden• Figma: https://www.figma.com/• Friends of Figma: https://friends.figma.com/• Camille Ricketts on Lenny’s Podcast: https://www.lennyspodcast.com/how-notion-leveraged-community-to-build-a-10b-business-camille-ricketts-notion-first-round-capital/• Adobe Illustrator: https://www.adobe.com/products/illustrator/campaign/pricing.html• Adobe Photoshop: https://www.adobe.com/products/photoshop/• Switch: How to Change Things When Change Is Hard: https://www.amazon.com/Switch-Change-Things-When-Hard/dp/0385528752/• The Story of the Stone, or The Dream of the Red Chamber: https://www.amazon.com/Story-Stone-Dream-Chamber-Vol/dp/0140442936• Serial podcast: https://serialpodcast.org/• The Good Nurse on Netflix: https://www.netflix.com/title/81260083• FigJam: https://www.figma.com/figjam/• Asana: https://asana.com/• Slack: https://slack.com/• Notion: https://www.notion.so/• Dropbox Paper: https://www.dropbox.com/paper/start• Figma’s Alignment Scale: https://www.figma.com/community/widget/1030848035996871692—In this episode, we cover:(00:00) Yuhki’s background(09:05) What Yuhki learned from being on a design team(10:29) Why managing designers is more difficult than managing product teams(12:20) Why storytelling is important for product managers(16:35) How to improve your storytelling skills (18:51) Why PMs need to know the “why” of the product they are managing(22:34) The importance of developing a community and strong customer relationships(26:13) How to use different types of feedback(28:11) Working with Dylan Field(32:44) Testing at Figma and the branching emerging feature(34:54) Why your entire company should be using your product(36:50) The importance of having personal accountability (38:48) Why Yuhki likes to stay out of the way of engineers fixing their own bugs(40:50) Yuhki’s thoughts on OKRs and how they are used at Figma(48:40) Figma’s interview process(51:45) How Figma’s sales team works by creating human connections and empowering designers(54:57) How Figma built community and created organic growth(56:36) Advice for founders (58:57) The potential acquisition by Adobe and the future possibilities for Figma(1:01:42) Closing thoughts (1:03:44) Lightning round—Production and marketing by https://penname.co/. For inquiries about sponsoring the podcast, email podcast@lennyrachitsky.com. This is a public episode. If you'd like to discuss this with other subscribers or get access to bonus episodes, visit www.lennysnewsletter.com/subscribe
Transcript
Discussion (0)
There's something controversial about this idea that, you know,
everyone can see what you're doing, right?
Or that, you know, multiple designers can be in the file at the same time.
Like, we like to say that one of the first responses we saw Oeylon's stigma was,
if this is a future of design, I'm quitting, right?
I'm changing careers.
And there's that kind of like tension of that narrative tension.
But like, that is signal that you're kind of part of this revolution.
And you're trying to change something.
And when did you make quips, you know, your customers or use,
are based with that. And I think that's something that they can really get behind and champion.
So it's not just that they're attempting for a tool. They're also champing for like a new way
of working. Obviously, that's a tall order or something to kind of come up with that. But hopefully,
you know, if you're a founder and you're working with something, your vision is so big that like you
have those kind of ideas. And it's like, how do you actually equip your customers to want to
talk about that? Welcome to Lenny's podcast. I'm Lenny. And my goal here,
is to help you get better at the craft of building and growing products.
Interview world-class product leaders and growth experts to learn from their hard-won experiences
building and scaling today's most successful companies.
Today, my guest is Yuki Yamashita.
Yuki is chief product officer at Figma, where he's been for almost four years.
Prior to Figma, he was at Uber, both as a product leader and also interestingly as head of design
for one of their bigger product teams.
Before Uber, Yuki spent time at Google and Microsoft, even taught an introductory computer science
course at Harvard. In our conversation, we explore Figma's product development philosophy,
how they build such consistently great products, how they hire, what habit Yuki has found to be
the most instrumental in his success in his career, and also what Yuki and his product team have
learned by building a product-led growth business. This episode builds on a newsletter post where I interview
Yuki about how Figma builds product. So if you enjoy this episode or even while you're listening to
it, I highly recommend you check it out. It's currently my four.
most popular newsletter post of all time. You can find it at Lenny's newsletter.com. With that,
I bring you Yuki Yamashita after a short word from our wonderful sponsors. This episode is brought to you
by Notion. If you haven't heard of Notion, where have you been? I use Notion to coordinate this
very podcast, including my content calendar, my sponsors, and prepping guests for launch of each episode.
Notion is an all-in-one team collaboration tool that combines note-taking, document-sharing, wikis, project management, and much more into one space that's simple, powerful, and beautifully designed.
And not only does it allow you to be more efficient in your work life, but you can easily transition to using it in your personal life, which is another feature that truly sets Notion apart.
The other day, I started a home project and immediately opened up Notion to help me organize it all.
Learn more and get started for free at Notion.com slash Lenny's Pod.
Take the first step towards an organized, happy team today.
Again at notion.com slash Lenny's Pod.
This episode is brought to you by Vanta,
helping you streamline your security compliance to accelerate growth.
If your business stores any data in the cloud,
then you've likely been asked or are you going to be asked about your SOC2 compliance?
Soct 2 compliance.
taking proper security measures to protect customer data and builds trust with customers and partners,
especially those with serious security requirements. Also, if you want to sell to the enterprise,
proving security is essential. Sock 2 can either open the door for bigger and better deals or it can
put your business on hold. If you don't have a sock 2, there's a good chance you won't even get a seat at the table.
But getting a sock to your report can be a huge burden, especially for startups. It's time-consuming,
tedious and expensive.
Enter Vanta.
Over 3,000 fast-growing companies
use Vanta to automate up to 90% of the work involved with SOC2.
Vanta can get you ready for security audits in weeks instead of months,
less than a third of the time that it usually takes.
For a limited time, Lenny's podcast listeners get $1,000 off Vanta.
Just go to vanta.com slash Lenny.
That's V-A-N-T-A-com slash Lenny to learn more
and to claim your discount.
Get started today.
Yuki, welcome to the podcast.
Thank you for having me, Lenny.
I am quite honored to have you on this podcast.
For folks who don't know, we actually collaborated already on a newsletter post
that has quickly become a fourth most popular post of all time,
which you can find if you search for how Figma builds product.
And so I am really excited to dig into a lot of the stuff that we maybe didn't cover in that newsletter.
Also, just like how product works at Figma in more depth.
how the PM team works, how you think about product, and things like that.
So again, thank you for joining me.
My team is a huge style of this podcast.
So I'm really honored to be here.
Wow, that means a lot.
I really appreciate that.
So you are currently chief product officer at Figma, which is such an epic role.
It's such an epic company.
Could you take just maybe a minute or two to high level share your career arc,
how you got to where you are today as CPO at Figma?
My first job out of college is actually at Microsoft, and I was the product manager on Hotmail.
If anyone, any listener remembers Hotmail.
And, you know, I didn't really know what product management was at the time.
And I kind of viewed it as a kind of interdisciplinary function that will give me exposure to all the other functions
so that I can actually decide which function is interesting to me.
And so spent a couple years at Microsoft through that also moved on to podcast.
about to Windows.
And at the time, they were working on Windows 8.
And Windows A was really interesting because there was a very, like, a very, like,
touch-forward version of Windows.
And so there's just a lot of conversations about UI and UX, and that was really fun for me.
And, you know, as I was thinking about what's next, I really felt the draw of Silicon
Valley.
And I ended up at YouTube.
And I believe this year has been on a podcast before.
Yes, this year was leading YouTube.
at the time and he continues to be a great mentor of mine. But you know, had the opportunity to
lead the YouTube app on iOS over there. It was really funny because I had never touched the iPhone
before my first day. So my manager on my first day just sent me to the Apple start to buy an iPhone.
But, you know, that was kind of like my next job. And that was kind of like a really interesting change
for me too of like, and we can talk about this later. So all different companies and different styles
of product management and really kind of figuring out, you know, I think it was a place that taught me
a lot about some of my product philosophy today. And this is also around the time where there are a lot
of interesting companies that were working in the physical and digital space. And so, you know,
Airbnb was one of them. Uber was another. So I kind of felt this draw just because, you know,
it seemed just like a really interesting space to be in. So eventually kind of ended up at Uber.
Uber was another kind of company where I feel like a lot of my philosophy that hopefully we can get into today
around how to build products, how to build products in the kind of environment that's really fast moving.
And so that I learned a lot from there.
And today, like, all of those companies has really been like focusing on the core experiences on consumer products.
And that's really been most of my career.
And it's part of that worked with a lot of amazing designers.
But at Uber, I kind of realized that I wanted to dip my toes into design directly.
So the tail end, I actually switched from PM to design and managed a few design teams working on our bikes and speeders efforts just to understand what that's like.
And it was around this time, around my Uber career where we encountered this school called Figma.
You know, I happened to be working on a project that experimentally brought Figma into the company.
it was a time in the company where we're trying to transform our culture to be much more transparent
and inclusive and Figma, what's the perfect fit for that.
So, you know, I got to watch how Figma changed the way it worked, how it spread within the company.
We got to know the Figma team a little bit as well.
And yeah, it's really drawn to that mission.
And as a product manager who's been straddling that boundary between design and products
for all my career, I really loved how Figma proactively blurred that boundary.
and opened up that kind of process of participating in design.
So I really got behind that decision.
And that's how I ended up here at Bigmo.
It's so fascinating that you moved into design from product and then back into product
at Uber.
What was the role?
You were ahead of design for the mobility team?
Yeah, it's called new mobility focused on micro-mobility efforts, basically.
You recommend this path for PMs to switch into design.
I know it's not like something anyone can do, but do you feel like that,
is an important skill role to experience as a PM?
You encourage people to try that?
Well, you know, I just said it's not for everyone,
but I think that it's, first of all,
a really great empathy-building exercise
of, you know, understanding that point of view
and also kind of pushing yourself to push on the products
from a different angle.
Because I think as a PM, you're kind of in the center
facilitating all these different tradeoffs.
And when you go into design,
you kind of have to ignore some of those other aspects to really be insistent on pushing on the best experience possible.
Like just kind of suspend everyone's, you know, disbelief in business feasibility or engineering feasibility to push on a vision.
And that's just kind of like an interesting exercise to do.
And then I think the last thing is like, I actually think it's an opportunity for design and PM to learn from each other, right?
Like when I became a manager of design teams, one of the things, one of the things,
these like codes designers on or like how to win over PMs, you know, and like how to speak in PM's
language. And, you know, likewise, it's important for a DMs to understand that as well.
So those are some of the things that I thought were helpful. But again, you know, it has come from
place of passion that, you know, you really want to do this. Which job would you say is harder,
design or product management? They're hard for different reasons. I would say managing designers
it's harder than managing product managers. Interesting. And I think part of it
is that designers are, it's really important to focus on growing their craft, right,
and helping them develop its designers.
So, you know, it might not be that the company's biggest problem is one where you can
actually learn this new kind of thing you're trying to learn as a designer.
And this probably happened for engineers too, right?
Like, you could be working on the onboarding funnel, and that might not be the best place
to be learning, you know, micro-interactions.
Or maybe it is, but, like, you know, those aren't always aligned.
Whereas with PMs, it's a little bit more like PMs are just hungry for impact,
and so you can point them to the biggest problems the company has.
And while PMs also do want to understand different kinds of problems
or have the experience working in different kinds of problems,
at the end of the day, I feel they want to be working on a thing that matters most of the company.
So from that perspective, it's easy.
As you know, and the reason this podcast exists is because PM isn't easy.
And so the discipline I think is harder in a sense that, like,
It's sometimes hard on a day-to-day case to know
if you're doing the best thing you could possibly be doing.
And so I think that makes it a little bit harder as a PM as well.
I had a designer friend who moved into a PM role.
I had a product role at a startup.
And she's like, holy shit, I had no idea how hard being a product manager was
and a product leader.
I have so much more empathy for the PM role.
And so it's interesting it works in both ways.
Similarly, I was actually a manager of engineers at one point, and I felt the same way where managing PMs was a lot easier than managing engineers.
So it kind of translates to a lot of different roles.
Folks listening to your career arc and just all the places you've been, all the wonderful things you've done, imagine many people are like, wow, how do I have a career like that, Microsoft, Google, Vigma, Uber.
if you had to think back and identify maybe one habit or one skill or behavior that you think is most contributed to your success as a leader, as a product leader, what do you think that would be?
Yeah, people who work with me know that I often talk about storytelling. And in fact, if you've ever reported to me, storytelling has showed up in some kind of performance review, I feel, and that's how much I care about it.
And, you know, I actually think that a lot of being a great product manager is being great storyteller.
And I know, like, a lot of us have already talked about it out there.
I think the importance of storytelling is understood.
But maybe I would share two things that are specific about it that I think are interesting.
One is just understanding the power of synthesis.
And, you know, it's this idea that maybe even as kind of like a early career PM, you know,
you're inside some of these reviews and, you know, a lot of people say, hey, like,
at least you could take some notes for the meeting, right, so that, you know, you're adding value.
And so that's common advice here.
But I think the most powerful part of that is that in some ways you can synthesize what happened,
right?
And a lot of things are said in a review and there's still this kind of like bring it all together
into like a distillation of a message.
And even that's like, that's a lot of power, I think, you know?
And what do you take away from all these different opinions that all these leaders had?
And like, how do you push that, you know, push the project forward from there?
So that's kind of one example.
Or another example is I really love thinking through frameworks and offering ways
of talking about a problem or ways of thinking about a problem.
And that's kind of synthesis to of figuring all these different disparate parts and kind of, you know,
coming up with a way to a lens to look at something.
And I feel like it's something that was, I learned,
mostly through kind of literature classes almost, you know, where you're doing kind of literary
commentary and you're reading like William Yates poem and you're trying to kind of like,
you observe all these interesting things. But then you have to take those different observations
and like distill it into a thesis, into something cohesive. And I think that's what a good PM can do,
like all these different ideas and opinions and problems and how do you kind of distill it down.
And so I think that's one aspect of storytelling. That's really,
important. And the other aspect of storytelling, of course, it's like, you know, a story is
only as good as, you know, the actions that's capable of driving. And a lot of times that I often
coach my product managers are, we're living in a world where everyone is constantly distracted,
right? And you kind of get like these 30 seconds of attention at a time. And so just the ability to
kind of like really tell something powerful that sticks is really important, kind of like
the memorability of it. And I often talk about
memeification, which is this idea that, like, I found this out most at Uber, I feel, where
there are certain insights, data insights, research insights that were memified to the point where
like someone like Travis or Dara was just cite this insight in the middle of a meeting.
And you know that you've really done your job as maybe a researcher or a data scientist or
product manager if like people were able to do that and draw from that way.
And that's what ultimately kind of like sticks, right?
And so when you kind of start thinking about it from that perspective, it's really powerful because it's the way in which knowledge is transferred within the company and you kind of compel action for it.
Or, you know, when when I'm kind of like being maybe asked questions by other leaders or stakeholders, the thing that's going through my head is like, okay, there's a kind of story that that leader is trying to develop or like a meme about like what this project is about or, you know, what the biggest problem is.
And so what kind of story are they trying to kind of like create in their heads so that they can kind of like remember or talk about what's happened?
And if you kind of take that mindset, you just realize that it's a really useful way to think about everything.
I'm really excited to chat about this idea because it comes up a lot.
The power of storytelling.
It's similar to like being good at vision.
It's like, yams are always told like, hey, you got to improve in vision.
Here's like a skill that's the great PMs are really strong at.
And I feel like storytelling is similar.
this vague cloud of a skill that you build over time.
And you mentioned a few things that you recommend to people that you work with,
like think of it as a me, maybe.
Is there anything else, like when you're doing a performance review with the PM
and they're like one of their skill gaps as storytelling,
is there anything else you recommend they specifically do to get better at the skill?
Or is it just do it again and again and watch me do it,
watch other people do it and you'll learn.
Yeah.
I think of it as kind of like resetting the internal computer.
of my brain a little bit so that like I start from scratch again.
And when I'm starting from like no context at all,
can I build up the story from Barrett to explain what's happening?
And oftentimes you're just like caught in the middle of everything.
And you have all this context that might not be obvious if you step away from it for just a
second.
I guess the kind of the way to think about it is put yourself in another user's shoes.
And that user is someone who has no idea what's happening and still wants to understand
in a nuanced enough way
what you're grappling with.
And so that kind of like reset moment
and to pull yourself out
helps you tell a better story
in many cases. So that's
one thing I keep comes to mind.
Got it. So it's kind of escape the curse of knowledge
a little bit and just like assume people
don't know anything about the context, the background,
why this is important. Come back to
the beginning. Yeah. I think the
other thing that I, where I learned
storytelling is through teaching.
So when I was kind of like a course assistant
for a computer science class
and to explain pointers. You're like,
okay, like, I really have to
borrow on real-world
metaphors or something that is like much more
grounding because if you assume a lot of
knowledge, then like it can be
inaccessible to a lot of people.
And so if you can tell a story
that any student can understand,
then you've really done your job.
And once you learn that skill of being able to tell
anyone who has no context,
then it becomes much easier to kind of turn to these other
audiences that are kind of closer and closer.
When I asked you in our newsletter interview what one of the core philosophies of product
managers is in the way you think about product and the role of PM at Vigma, an interesting
thing that you highlighted is that to you, it's really important that PMs own the why of a product
and an idea.
And I think it connects to what you're talking about now.
I'm curious just why you think that's so important for product managers and why that's so
core to the way you think about product and at Vigma.
I really can't remember where I heard.
but it really stuck with me because, you know, oftentimes there's just debate about, well,
is the PM person who comes up with the idea and the answer is usually, no, it doesn't have to be at all.
And in many cases, you know, in our case, like their customers come up with a ton of different ideas, right?
And, you know, certainly kind of the what and the how are things that are shared within the company
and not something that PM uniquely drives.
But I do think the why is something that I really always hold the PM uniquely responsible for.
And I think the place where I learned this, the importance of this the most was actually first at YouTube.
I had been working at Microsoft for a long time.
And I was earlier in my career.
So I was just really focused on what we called our feature crew, like our engineer, designer, our tester,
and just writing specs that really specify exactly how everything works.
And so that was kind of the Microsoft culture back then.
And your specs had to be perfect.
Then moved over to YouTube, and all of a sudden, you know, you're responsible for an entire app,
and you have a pretty big team, and you cannot specify everything that happens.
And so naturally, designers and engineers are just making their own choices, right?
Like, made as an error handling situation, and, you know, in Microsoft culture,
you would have had a table that specifies exactly what happens during that era, right?
But in Google culture, it's kind of like, okay, well, the engineers and developers, they can kind of figure it out.
So then it's like how do they make a really great decision?
How do they, you know, all these local decisions that are you're not a part of how do you make
sure that great decisions made?
And if everyone is the understanding of why we're doing this, what problem we're solving,
then, you know, people can make really great decisions.
It's the only way you can really scale.
So that's kind of where it came from.
And then since then I've started to realize also that there are other functions that do this
well.
So for example, our engineering team at Bigmo, whenever we do a retro or post-mortem, you know,
we do this thing called five.
wise, right? And it's kind of the idea behind it. It was like, well, why did this happen?
Outage happen? Okay. And why did that thing happen? And go deep enough where you can kind of find
the root cause and go fix all those things. And I think a PM can do this too, which is, you know,
a customer is asking for a feature. But then you say, okay, why are they asking for it and kind
of back up the problem? But I think there's one more step we can take, which is like, why do they
have that problem in the first place? And maybe there's something there. And that could be an
opportunity to, you know, make a bigger product impact by fixing kind of like that underlying
condition that created the problem in the first place. That's so cool that you actually do the five-wise.
I hear people talking about the five-wise all the time, and I don't know. I haven't heard people
actually using it. So you actually do this at your post-mortems, you said? Yes, engineering team.
That's a set thing. That's so interesting. Can you talk a bit more about these post-mortems?
Is this just like when someone goes wrong or is this just every project, you do retrospective post-mortem sort of thing?
As it relates to vibe-wise, it's more when something went wrong.
But I do think we have a retro culture at Slal, like, where, you know, there's always
opportunity to make things better.
And if you don't create kind of the environments to talk about it, then, you know,
some of those will go unaddressed forever.
Cool.
Okay.
Another attribute of the product team and how you build product at Figma, that you should, that was
really interesting, is you mentioned that you just have an obsession with a proximity to customers,
that you make sure your PMs and product are really close to customers.
When you hear that, you're just, like, I imagine everyone listening is like, oh, yeah, we're really
close to customers.
We talk to customers all the time.
Of course, you've got to talk to customers.
I'm curious what it is that maybe you think sets you apart in terms of how you think about
being close to customers.
And if there's a story, maybe of just like, wow, this is how close we are to customers and
maybe something that emerged out of that.
That'd be really cool to hear.
Well, I think a lot of it starts with our origin story in many ways, which is that,
way back when Dylan,
small group people were building Bigmont,
this is the time when no one believed
that was possible to have a design editor in the browser, right?
And so it just seemed like science fiction almost.
And yet, what Dylan did, you know, consistently throughout
was just put the product in front of designers,
ask them for feedback, come back to them the next time
with that feedback implemented,
and it becomes better and better and better.
And, you know, at no moment was there,
kind of this expectation that the designer suddenly turns around and implements that tool in their
organization. It was really just about kind of like listening really carefully to what the community
had to say and through that process making them, you know, evangelists, right? And that's kind of where
a lot of how Figma came to be and why we have such a strong connection with our community,
where we've actually, you know, they've really helped shape, you know, the product to date. And
And there's a deep belief in that.
And they're the ones that are now advocating for Figma and helping us spread within the community
and within their company.
So, you know, that's kind of the backdrop for why we have such a strong connection with our
customers.
And, you know, there's a lot of things that you see.
So, for example, there's someone on my team's show.
And oftentimes show will tweet out to the community, like, here's what we're thinking.
Or, you know, we're actually thinking about focusing a lot more in prototyping.
What are the top problems you're seeing?
And people come back with all these different answers because everyone's passionate.
And we kind of go in there and just look at all the feedback and understand what people are saying
and just have a stronger pulse on how people are feeling.
And that's not to say that everything is then implemented verbatim.
But, you know, we really find it useful to feel like we have a sense of what people are thinking.
And I think like the most crazy version of it maybe is, you know, Dylan is always reading customer
feedback. In fact, it reads the most customer feedback of all of us and has been doing that for
like a decade, right? And oftentimes, you know, there used to be this thing where he would drop in
tweets that you see into different Slack channels to be like, hey, this seems concerning or
we're getting this feedback. And it kind of got to a point where, you know, we got big enough
where people would feel like they had to drop everything and deal with that tweet. So Chris,
RCTL and I kind of like intervened. We created this new channel, private channel called
concerning tweets. And it just, you know, for,
this small group of us
that Dylan can kind of like drop those
and these are tweets that aren't going viral
by any means. There's just things that you see
with like one likes, sometimes zero likes
but he feels there's an
essence of truth to them.
And we make sure that, you know, we look at what's going
on there and see if there isn't something
much bigger that we should be focusing
on. But that's kind of like the extent
to which, you know, someone like Dylan
from the, you know, from top down
implements this idea that like we need to be
staying close to what our users are saying.
That's an awesome idea for a channel,
a way to kind of contain that potential madness that it creates.
Is there anything else you've learned around hearing feedback like that in a tweet,
let's say, or just a few loud voices and deciding what to actually work on?
Do you have kind of an approach there, just deciding what's worth paying attention to?
As we've built out our research and data functions, you know,
it's really important to kind of balance out the vocal minority with, you know,
what's actually happening, right? So I really view some of those tweets more as kind of like
canaries in the coal mine in a way and inputs into many inputs we have around, you know,
everything our customers could possibly be experiencing. And, you know, it's important to realize
that, you know, we have certain forums like our support tickets where customers are,
tend to be much more dissatisfied. And we have other kinds of inputs that are kind of sales
conversations with prospects, you know, where it's really more about perceptions around Figma in some
cases. And I think it's just important, especially as a product manager, to feel like you have
this balanced portfolio of different kinds of feedback to know that you don't have any blind
spots. So I think that's one of the things that, like, I focused a lot on when I came in,
which is like, you know, the Figma team is very good at Twitter and, you know, staying on top of the
sentiments. And luckily for us, a lot of designers on Twitter, right? But the
reality is that most of our audience at this point probably aren't. And so, you know, building our
capabilities to extract feedback or more insight from those other sources as well.
That reminds me. I think Twitter was really instrumental to the beginnings of Figma. I believe
Dylan made this kind of social graph of the most influential designers on Twitter. And that was
kind of his go-to-market strategy, get those designers on Figma. And then I think he open-sourced
as this code to do that. Is that right? Yeah. Yeah. That sounds right to me. And his
very intentional about which designers we need to win over. I think it's very novel a deterred.
What does it like to work with Dylan Field? He's, you know, as an outsider, he's a legend.
Feels like he's an incredibly smart, talented, hardworking CEO. There's always tension a little bit
between a chief product officer and a CEO. And so I'm just curious, what's he like to work with
as a product leader? And then is there like, I don't know, memory that comes to mind of just like a way
that encapsulates what it's like to work with Dylan? We're very different, actually. And, you know,
The diligence very, it's very based on intuition and instinct.
And that intuition is actually built off of, you know, thousands and hundreds of thousands
of customer interactions where he might look at something and be like, you know what,
this isn't going to land well or, you know, here's the biggest problem right now.
And you're kind of like, well, how does you conclude that?
And, you know, part of my job is kind of like filled out that logic tree for him of like,
how does you arrive at that conclusion so that people can.
kind of understand that at scale in a way.
But it's very much about that.
Or, you know, I think there's a way which sometimes
it's a product manager, you kind of want to lay out a problem
and say, okay, we're going to first focus on this problem.
And then these three approaches, we're going to take this approach
and have a review at every step along the way.
But for Dylan, I think it's very hard for him to really kind of like
fully get bought in until he kind of sees like the end implementation
to literally feel like if this is a good solution or not.
And so I think that's kind of like the kind of thinker he is
where you really needs to see it to kind of feel it.
But it's not totally random.
It's based on like all these interactions of customers
and somehow encoded in him to kind of like build up some of those kind of
intuition.
And I think one of the things that's really interesting about him
is that like he actually really cares like very deeply
about any given user and how they're,
feeling about Figma. And I remember when during the height of the pandemic, we were doing a 101
walking around DeLar's Park because, you know, this is the era where you would take meetings.
If you take meetings, they're all outside, right? And then he needed to use the bathroom.
So he came out to my house in the Castro. He used the bathroom. And then he met my partner.
And my partner was on Figma and the Figma and pulled up because, you know, it's just doing work.
And then Dylan, you know, just went straight in there and went.
wanted to ask what the biggest problems were, like, what's not working?
And they started kind of like gicking out on some issue around Google fonts.
And, you know, this is like the first major interaction between the two of them.
But it's kind of one of those things are like, that's how much Dylan cares.
And on one level, it's just, you know, it's easy to say, hey, this is like a single user
who just happens to be using your product and be dismissive with it or not care about
deeply because you think you already know, like all the biggest problems.
But that's not as they did.
And so that's kind of the level of, I guess, customer obsession, if you will, Pagy exhibits and then in turn informs his intuitions.
That's amazing. Figma's like 10 years old at this point, right?
Like he's been at this for a long time, like a decade.
And the fact that he's still so obsessed with just like a random person just using Figma.
And he's taking the opportunity to like experience it in real time.
Every chance he gets, sounds like.
Yeah.
Hey Ashley, head of marketing at Flatfile.
How many B2B SaaS companies would you estimate need to import CSP files from their customers?
At least 40%.
And how many of them screw that up?
And what happens when they do?
Well, based on our data, about a third of people will consider switching to another company
after just one bad experience during onboarding.
So if your CSV importer doesn't work right, which is super common,
considering customer files are chock full of unexpected data.
and formatting, they'll leave.
I am zero percent surprised to hear that.
I've consistently seen that improving onboarding is one of the highest leverage opportunities
for both sign-up conversion and increasing long-term retention.
Getting people to your aha moment more quickly and reliably is so incredibly important.
Totally.
It's incredible to see how our test stores like Square, Spotify, and Zora are able to grow their
businesses on top of flat file.
It's because flawless data onboarding acts like a catalyst to get a catalyst to
get them and their customers where they need to go faster.
If you'd like to learn more or get started, check out Flatfile at Flatfile.com
slash Lenny.
As an outsider, it feels like Figma's just like always firing in all cylinders, shipping the best
product.
People love it.
I use it.
I should mention this, but I use it probably every day for my newsletter, for illustrations
and banners and all the stuff.
Yeah, like, I don't know what I do without it.
And it always feels like Figma's just killing it.
I know that's never the reality.
I'm curious, is there a story of something that just maybe didn't work out the way you hoped,
whether it's a feature or launch or something like that that just kind of shows people that
it's like, not everything always works out?
We run experiments all the time that don't come back with any results, you know,
and we certainly have built a lot of more complex features that took a while to take off.
So a good example, this is in a design system space, we have something called branching
emerging. And matching emerging is this workflow of maybe you're building a really complex design
system. And then you don't want anyone ever on randomly touching your components that are used
by thousands of other projects. So you kind of create this workflow of so long maybe, you know,
effectively suggesting a change, you're reviewing it and then pushing it in. And so in theory
makes a lot of sense and things that our customers asked us for. But once we built it,
you know, in the initial stages, didn't really see that much of the option. And, you know,
didn't feel great because there's like a really big investment for us. It's like a lot of work that
we put into it. And there's just many different reasons. Some of it was performance. Some of it was like,
this is a foreign workflow and it just takes time. And like us helping customers kind of
implement some of those workflows. We realize some gaps because we don't really use it that much
ourselves. And so I think as we're getting bigger, one of the things that I'm realizing is that
we're starting to build a lot of features that are not necessarily for organizing.
like ours. And when we do that, we really need to be creative about how we understand
how effective those are because we've had such a strong culture of internal testing and dog fooding,
and those are the things that really helped make sure the quality of our product was good enough.
But now we're working with really new types of customers and, you know,
needing to push ourselves and build that muscle as well.
Speaking of high quality software, again, I'll repeat, I think Figma is one of the most
beloved software products, it's kind of becomes central to a lot of the ways people work.
It's also, I think, one of the fastest growing SaaS products in general.
And I don't know, this may be the ultimate softball question, but I'm just curious,
what is it that you do at Figma to build such high quality software?
Because it's rare for B2B software especially.
What do you do as a product leader, as a product team to just set this high bar,
make sure that the stuff that you put out is great consistently.
And, you know, the more tactical, the better.
it's so important that you're using your own products.
And I think we're in a very lucky position where all of us can get creative around using Figma in some way.
And obviously, designers are, you know, that internally within Figma are kind of the most vocal and the ones who are in the product like six hours a day, essentially.
But even for PMS, like one of the first things I did when I arrived was we were a little bit more of a memo culture.
and I was like, you know what, we should be a deck culture
because we can build those decks in Figma.
And just that act alone allows you to kind of encounter a lot of issues
and for you to get familiar with it.
And so I think there are ways in which sometimes you have to get kind of creative
to enable your company, your entire company, to use the product more.
Or as an example, recently we just did
calibrations for performance reviews in FIG jam.
and our head of design
NDA kind of came up with this amazing template
and we distributed their HR
and that was another reason for everyone to use
Big Jim. And so
that's the biggest thing. More hours
people are spending inside your product internally
I think it just naturally becomes better
because a lot of times it's not just about
people raising their hands and saying this. The problem,
it's more about like you just want to make your own
own workflows,
your own day-to-day better
and derive satisfaction from improving that,
right? So the takeaway there is
get your product teams to use the product as often as possible.
That is a really clever way of doing that at Figma.
I know you mentioned in our newsletter interview that you switch from MOs to Dex.
It usually goes the other way around.
And now I get the kind of the second door to effects of that where people are building
their decks in Figma.
That is very clever.
Not everyone's building collaboration software, but that is a really clever idea.
And I think there's probably a bit of trickle down from Dillon's obsession with the product
in making it just continuing to just be obsessed with making it great experience.
combined with that right, like people using the product and this trickled down of,
we really need to make this as awesome as possible.
There are other companies, for example, when I was at Uber, you know,
especially working on the driver's side, of course, like we went out and driving,
and that kind of speaks to some aspects of it.
But one of the things that I've realized is when you are logging a bug and you kind of like
add some engineers to it to have them look into it, the degree of motivation is so different
if that engineer has somehow experienced a problem in some way.
So, for example, you know, everyone at Uber would take Uber's into work, right?
And if an engineer working in a driver app saw a driver struggling with something,
they would find a kind of like find it embarrassing and kind of feel personally accountable
to go and fix that.
And like, when you can create that sense of personal accountability, then like all this
crazy things happen and, you know, all this progress happens.
So I think for us is getting creative at Uber about, okay, well, how do we
kind of increase those interaction
points to the point where like if someone
building feels like they have some
kind of personal relationship with the
end user. And this is what happens
that big stigma too, where a lot of our designers
feel personally accountable in a way
because all their customers
are people they already know
in the community like on
Twitter and all those kinds of things. So they
feel like they have to put something out there
that's defensible or that they're really
proud of. So I think that kind of
personal accountability
The A can really make a difference.
That begs the question of, I imagine this engineer at Ruper coming back to their desk and like,
I'm going to fix this bug.
And then their PAM's like, no, we got goals to hit.
Here's our priorities.
We got this roadmap.
We don't have time to fix this right now.
It's just one random bug.
And so there's kind of a two-part question.
Just like, you have an approach to that.
Do you encourage engineers, designers just fix stuff that seems broken?
Slash.
You mentioned that you have a fun experience with OKRs and how you've approached OKRs at Figma.
And you've kind of gone back and forth a little bit.
And so maybe as a second part, just like talking about your experience with OKR is at Pigma.
The first part, I would say that I think one of the most powerful things, especially for startups,
is that kind of bottoms up energy, right?
And maybe a developer noticing something is wrong and just going off and fixing it.
And for the most part, I try not to get in the way of that because if people are doing that constantly
and everyone in the company is kind of trying to make the product better,
that is sometimes a way more effective way to improve the quality of experience and this top down of like,
oh, let's define this quality experience metric and, you know, try to like change all the things because you might miss these things.
So that's one aspect.
And the second thing is, you know, I think a lot of PMs have grown to realize this, which is like,
if you ask an engineer about how much time it'll cost to go and build something,
and it's something that they came up with or they're advocating for,
it's almost always past the time as something that like you are asking for us at the PM, right?
And that kind of like motivation is so different.
And that's why, you know, getting the buy in of developers is really important, right?
Because you want to feel like they're personally invested in this problem.
And then all of a sudden, like their willingness or their creativity or all these things kind of spike.
And so when you kind of think about all those things,
when there's a situation where like an engineer or your designer is trying to fix kind of a real customer,
problem. I'm kind of like by all means, right? So that's on that. OKR is like totally bigger topic.
And maybe I'll kind of set it set the context of why I have such of this like love,
hate relationship with it, which is that a lot of my career, I've actually just worked on
core experiences. And OKRs are kind of like the day in my existence in a way, right? Because
when you're working on a core experience, sometimes they're just kind of like, I'm just trying
to make the experience better. And sure, I can come up with this like,
yes way to measure what that looks like. But, you know, that's not what I'm thinking about every day
anyway. So it just seems like very performative and there's just like a lot of work that goes
and you kind of encounter one of two situations. Like one is you come up with some secondary
metric that nobody actually cares about, right? That technically you can measure and technically
you can move. But like you haven't actually proven that it really matters. So maybe it is some
kind of like satisfaction metric that you kind of have on in some survey. But you know,
you haven't actually done the work to show that that actually has correlations with retention
or anything that actually quote matters for real in the business or, you know, it's some kind
of weird usage metric or something like that, right? And then the other extreme is to say like,
no, we're going to be ambitious and we're going to send it for business goals. So for example,
you know, even if I was the PM for the rider experience at Uber, I'd be like, you know what,
we're going to contribute incremental trips because the experience is going to be so good that we can get more people to come back, right?
And I think the reality for a lot of that is it's kind of a metric that you don't have full control over or there are many hops until it can kind of affect it.
And like, okay, well, maybe you make the experience better and maybe that kind of improves your attention.
And maybe this, you know, and by the time you get there, you actually can't even prove that you moved like the top level metric.
So either you anchor something that like matters, but you can't move or you bankered something that you can move, but doesn't actually matter.
That's kind of a relationship I've had with OKRs.
And so it's really frustrating, right?
So when I arrived at,
you know, one of the things I realized is that, you know,
we had OKRs, but people were kind of treating it almost as like a to-do list
or a task list of like, okay, here's how by the end of quarter,
I need complete these tasks and then I will feel like, you know,
I did my job kind of thing.
And we would have these dreadful meetings where we go through these spreadsheets
and like have people stand up in front of everyone and like talk.
about those commitments or those those key results rather, but they were dreadful for a reason,
which is that like, you just couldn't really understand what the team actually really cared about.
And it kind of got to this point where we had all these, and this kind of is similar to the
secondary metric problem, but like either you could approve that you actually moved it,
or you're trying to work on something that, like, I don't actually understand why it's
useful. And so that was when I kind of deprecated it and said, I just want to understand
like your headline. Like, what are you trying to do, like philosophically? And just like,
don't stress about whether you can measure it or not. I just want to understand where you're
optimistic for, right? And let's first have that to date. Right. And then once we get there,
then let's talk about, okay, well, what are some ways that you can measure it? And some of it's
qualitative. It's qualitative. That's fine. And then I will. And then,
almost kind of feel like sometimes it's better to take the report card like approach of saying,
hey, just do yourself up a score.
Tell me how you derive that score.
Let's all understand that like the metrics and those inputs that go into it can change over
time and we're going to get more sophisticated about how we measure it.
But like at least everyone understands like what on earth you're trying to go for.
So that's kind of like where, you know, where it kind of moved in my first year, I would say.
And then we hired a head of data, who is a friend of mine, you know, from Uber too.
And one of the things she kind of felt was like,
okay, that it's just still very loosey-clusive and super subjective.
So, like, let's just try to bring OCRs back and see if we can just do them better next time, right?
And so we've done that.
And they were definitely better than, like, you know, when it first arrived just because we had a data science team.
And, you know, we had more rigor around metrics and things like that.
But again, like, this time it was less about not understanding what people were doing.
But more like not understanding if teams are actually committed to moving those.
is okayr's. And one of the problems that you find is, you know, we have these okayers,
but they kind of feel like post rationalizations of the projects that you're working on anyway.
And at the end of the quarter, you kind of come back and see if those okayers move fingers crossed,
right? But like if you stop an engineer in the middle of the hallway or the virtual
hallway, so to speak, and ask them, okay, like, what are your team's biggest goals or
okay? It's like, I mean, it's like, they wouldn't be able to say it. They're just like,
well, I'm working on this project that's really important, right? And so it's like, well,
what's the point of kind of publishing this okay or if like you're actually not
thinking about moving it on a daily basis almost right and so that's when you know we
tried to experiment with this terminology like maybe what should call it commitments instead
like people would kind of take it a little bit more seriously and it's kind of my belief that
you know oftentimes like commitments are kind of this care between the why and the what
and sometimes the face of the commitment is the what it's like a project and there are many
Y's behind it or it's the Y and there are many projects behind it.
I kind of was trying to formalize that idea, but it definitely felt a little bit complicated
or sometimes people are like, well, like, I mean, okay, has existed for a reason and like
this is basically an OkiR with just like a different name. So my honest sense is we still haven't
figured it out, you know, and we're still iterating on a bunch of different things. But I think
I've developed some philosophies around it, which is, you know, no matter what you call it, right?
because like, you know, these, it doesn't matter as much.
I think that, like, for me, there are three things that really matter about, like,
the good OTR.
And what is legibility?
Like, people look at it and understand what it is.
And, like, it's not some, like, weird, officicated metric that doesn't mean anything to anywhere.
I think, like, actionability, like, I want an OTR to inspire action.
Like, you look at that and you're like, it stirs action.
It makes me want to, like, do something differently.
Right.
And then the third one is authenticity, which is like, does this actually honestly depict what you're doing, what you're trying to do on a day-to-day basis?
Because if it doesn't, then like, it's hard for me to trust that that it matters.
Or if that's something that just happens to describe what you're doing but isn't really connected in a meaningful way, then, you know, I kind of question the value of it all.
So that's why I am in the process.
but, you know, I definitely
all years to
advice around this kind of stuff because I feel
like we haven't quite cracked the code.
I love hearing that whole journey.
I feel like you always hear from product teams.
Here's what we do now.
You never hear.
Here's the experiments we've been through.
Here's what we've tried.
Here's what work for a while.
Here's what doesn't work now.
And here's what we're doing now.
So it's really cool just to hear all the experimentation
you've done.
Clearly, Figma is a company
where you encourage experimentation
and trying new things that aren't working.
And it's cool they have the flexibility to just like, let's just do headlines for now.
No more specific goal metrics.
We're just going to build things that we think are important.
And then the newsletter posts for folks that are listening,
you actually show the templates that you're using these days for planning your projects
and kind of laying out your OKRs.
So folks can check those out if they're interested in seeing how you're doing that now.
You also mentioned you've hired this awesome data scientist and maybe just expanding that further.
I imagine a lot of the success of Figma and the product that you,
built is the people that you hire at Figma. I believe you have 22 product managers, which
sounds very small for a company like Figma. And I imagine they're all amazing. I'm curious what you
look for in product leaders and product managers that you hire that maybe other folks aren't as
focused on. And just like what does the interview process look like at Figma? Yeah, I shared some of these
things, right? Like I really feel passionately about storytelling and, you know, not to give it away or anything,
but one of my favorite interview questions is asking,
describe to me a time when you're part of a controversial product decision, right?
And, you know, what did you do and all those things?
And I think it's really revealing because, you know,
if they can kind of like set up this conflict and understand like why this problem is really important
and represent both sides and a subset, you can understand why that conflict exists in the first place,
and they can do it.
And there's kind of like, you know, even key.
old way where you realize that they can take on these different perspectives, like, you start
to learn a lot about that person, I think.
Or sometimes I just ask something for basic things like, okay, talk about kind of like a big
problem that you worked on.
And the thought experiment for me is always like, coming out of that, do I feel compelled
to work on that problem?
Right.
And no matter how boring it sounds on the surface, like, I think a really great product
manager kind of like, cash something.
It's like, well, this is why it's so exorcet or so close.
And this is why it's so interesting.
and really rallied a trip.
So that's kind of one big thing of like storytelling and communication
because at the end of the day, like so much of our job is around that.
I think other than that, you know,
some of the things that I value are things like I kind of think about it's like
hide down with UX conversations.
It's kind of like we talk about problem.
And, you know, I think about kind of like when you're exploring solutions,
it's kind of this tree of, okay, there's just these branches of explorations.
And if you kind of finally arrive at these solutions,
And a ton of people who can go up and down branches really quickly have a really high, a command of all these different altitudes as well.
So that we can talk through a lot of things at the end of the day, kind of feel like we walk away with some progress.
And, you know, I think that like at Uber, our first two product officer, Jeff Holden, was someone who often talks about kind of fast forwarding to the future.
And this idea that, you know, okay, like, let's just pretend we ran that experiment.
what do you think it will come back with?
Or let's pretend we like ran that.
You just use a study.
And like the kinds of PMs have the ability to kind of imagine those outcomes.
I think like it helps us be much more efficient too because we're like,
well, if we all think that's going to go there and that's not going to compel us to take
any action, why do it at all?
And so I think a lot of PM is about kind of those kinds of shortcuts that you have
to take.
Right.
And it's not just about what we build.
It's about, you know, building the right things.
and sometimes just is important to like decide not to build something.
But it's only possible if you can have that kind of like imagination or that ability to see around quarters.
I love that. I was going to ask you for your favorite interview questions in our lightning round and you jumped ahead, which is great.
And those are really good examples. Hopefully they don't give too much away.
I want to chat a bit about growth and how Figma grows. If you ask people about product-led growth and just like whenever people talk about product-like growth, they're always like companies like Figma.
Slack dot, dot, dot, Figma is always seen as a model of product-led growth and a product that grew
through product.
I imagine now there's a very robust sales team, and I imagine even earlier than people
probably imagine there was a sales team.
I'm curious as a product leader what you've learned about how to effectively work with sales
and what you teach your product managers about how to work with sales to collaborate
effectively. We're really lucky to have a sales team that understands their product really well and can
hold their own with customers who are often also design leaders, product leaders, and things like that.
And I think that kind of credibility goes a really long way. One of the things that I kind of,
we all are collectively realizing is, you know, we talk about product like growth, but in some
ways, I like to think about it more as kind of like community-led growth or there are certain people
inside a company that feels so strongly about Figma and that they're helping kind of push for it and
these like advocates and evangelizing for Figma, right? And so oftentimes like what the Felsstein does
is really empower those individuals to make a stronger case or kind of connect them to the rest
of a company so that we can kind of get a wider deployment or more readers to buy it and things
like that.
And so oftentimes a sales team is kind of like playing that role of, you know, creating those
human connections and helping equip designers and feel passionately inside a company with the data,
you know, with the stories and all those things to help make a case.
And I think that's like the most powerful way in which we can spread where, you know,
the space of like Figma is not the same.
sales team, but in fact, it's the internal, you know, designer, right? And so that's kind of like
the mental model that I think we've been using it. We're fortunate enough to have people inside
companies who are so passionate to kind of want to play that role. And so when you kind of like
take that lens on, then you start to kind of understand, okay, like, how can we help set this
person up for success? And the sales team has like different ways to do it. Like the product team
help in terms of like giving them visibility into how.
how we're thinking about, like, involving the product or what other customers might be doing.
And so I really see it as kind of this partnership to enable a vast, which is possible.
You know, and I think that's what, to me, what product like growth, you know, looks like at Figma is that.
That is really interesting.
Basically making your champion inside the company kind of a superhero,
helping them be more effective at what they're already doing, which is evangelizing this product that they really love.
Interesting.
Is there anything that you think Figma did early on that you think was really important for it to start to grow, either in this way or in a different way?
Imagine there's just a lot of product-led growth founders that are trying to create a product-led growth product and they fail.
And so I'm curious, just like, what do you think people often miss and what do you think Figma did right that got it going?
I think a lot of it was about the level of intention around building community.
And the more there are organic conversations happening about Figma, the better, right?
And one of the nice things about Figma is you can kind of like share out a file that you've been working on and like effectively open source something.
But it's kind of your way of showing, here's how we do it as so XYC company and sharing that with the rest of the community.
And, you know, when people see that and when people kind of feel like they have this like insider view and how other companies work, that's where there's a lot of interest, right?
And, you know, more recently, you know, over the last few years, we've really been focused on a program called Friends of Figma, where we have people who are passing about Figma and all our different geographies kind of like come together in like that Discord channel.
They meet regularly and are helping us evangelize.
And again, it's kind of like that human connection between users.
And then between us and the users, there's something that really helps build that kind of like loyalty, which is the thing that then fuels all that.
champions to really kind of push for it internally and give people kind of like the enthusiasm
and courage to do that inside their organization. It's interesting how many corollaries there are to
Notion and how they got started. I recently chatted with Camille. I don't know if you heard that
episode, but there's a lot of similarities with how Notion use their community to help
jumpstart growth and continue to grow. Totally. It's interesting that that's you can call that
community like growth, product like growth. There's a lot of overlap there potentially. For sure.
what advice would you have for folks that are, I don't know, maybe you already shared this,
but just like, if you're a product-led growth founder listening to this,
give any other piece of advice to that founder about how to get started with their product,
their community, their growth strategy, anything else you'd want to share there.
Maybe a different way to talk about what we just talked about is just like, you know,
there has to be this almost like irrational, this like emotional response to your product, right?
This like love for it, right?
first it has to be cultivated internally too like you know people internally have to
authentically love something to really stand behind it but then you know externally too if people
are loving something to the point where they can you know sitting at the top of their lungs and just like
really talk about how phigma it's great like if we can get there like that's that's like a wonderful
place to be right and i think that's both a combination of like you've really solved their problems
slow, but you also kind of like equip people with a philosophy around a different way of working.
And I think that's what worked well for Pygma too, which is like there's something controversial
about this idea that, you know, everyone can see what you're doing, right? Or that, you know,
multiple designers can be in the file at the same time. Like, we like to say that one of the first
responses we saw Oeylon's stigma was, if this is a future of design, I'm quitting, right?
I'm changing careers. And there's that kind of like tension of that narrative. And,
narrative tension, but like that is signal that you're kind of part of this revolution and you're
trying to change something. And when you can make quips, you know, your customers or user base
with that. And I think that's something that they can really get behind and champions. It's not just
that they're championing for a tool. They're also championing for like a new way of working. Obviously
that's a tall order or something to kind of come up with that. But hopefully, you know, if you're
a founder, you're working at something, your vision is so big that like you, you have those
kind of ideas. And it's like, how do you actually equip your customers to want to talk about that?
That's awesome. Reminds me of a quote and kind of a tagline that the Airbnb's first growth team had for a long
time. Love drives growth, not the other way around. They made posters of this, put it all over
the product teams. I love that. Part of the office and seem to have worked for Airbnb, clearly
working for Figma. One last question. Feels like a question we have to touch on. I don't know how much
you can say about all this stuff, but with the potential acquisition with Adobe, which I know
hasn't done yet. But I'm just curious, what do you think will change, may change, you're hoping
will change, you're hoping won't change in how you build product at Figma within Adobe.
Totally, yeah. I mean, you know, as she said, it hasn't closed yet, and so we're still
independent companies, but, you know, when we think about that theoretical future, I think about
kind of like, people often ask me, so, like, what's going to happen in terms of, like, the products
that you work on and, like, how is that going to influence Figma?
And dances we don't know yet, but I get excited about two avenues.
One is just like really continuing our current mission of making product design better.
And the reality is when you look at product design, a lot of people are still using both Adobe and Figma alongside each other.
Right.
And maybe you're creating that micro interaction in AfterFest or maybe you're kind of doing that intricate like illustration and illustrator or, you know, editing Rastor in Photoshop.
operate. And then you're bringing some of those things into Figma. But when you think about
kind of like that end-to-product development process, there's so many ways in which if we can make
all those things seem worse so that you're going to like juggling a bunch of apps or if you can
kind of have one single source of truth, that's really exciting to me to think about. So
concretely what that means, I don't know yet, but like as kind of like thinking through those journeys
that gets exciting for me. And then the other thing is really collaborating with the rest of
the Dole and thinking about kind of, you know, we've figured out.
something really interesting in the form of real-time multiplayer collaboration and that is a platform.
Adobe has a much broader set of use cases that they've been pursuing.
And like, what do those two things together?
Like, what could that enable, right?
And that gets exciting for me to think about all the creative tools that I've used in the past video editing or 3D objects or things like that where it's like, okay, if we can bring in the power of the browser, of multiplayer, of, you know, this feeling of like openness.
Would that make it way easier for people?
Would it make it much easier for people to share work or get involved?
So those are the things that kind of like go through my heads in terms of like what's possible.
In terms of what, you know, I don't want change.
Like I really think that we've figured out something really amazing in terms of our relationship with the community.
You know, we talked about kind of like proximity to community and our users.
Like those are things that we intend to keep and keep doubling down on.
And I think it's such an important part of the magic of how Figma works.
It's something that, you know, I think I will continue to do.
And that's what I draw a lot of motivation from in the first place.
Awesome.
You also get to work with Scott Belski, which is going to be pretty sweet and hoping to get Scott
on this podcast at some point, too.
That'll be awesome.
Any closing thoughts before we get to our very exciting lightning round?
It's really easy to listen to some of these podcasts and feel like, oh, these people have
kind of figured everything out, right?
But the reality is we haven't, you know, and we're still experimenting.
with a lot of things.
You know, OCR's is a really good example of that,
but a lot of other things, right?
And so, you know, just to the other day,
I wrote about kind of this idea of, like,
us living in a work in progress world.
And I was talking about more from the context of,
like, we live in a world where all of our products,
our product players, our strategies,
our work in progress.
And like, how do you, like, work in a world like that
when what you were doing can change the next day, right?
But, you know, in a similar way,
I think the way we work,
the way we run product processes as product managers
are themselves very much a work in progress.
So I would love to kind of encourage this kind of conversation,
Lenny, that you're facilitating,
just because we have so much to learn us from each other.
And I'd love to continue to learn more from all of you.
And interesting ways that you grapple with these, like, ageal problems
around things like how to set goals or, you know,
how to review work or how to plan.
So anyway, just wanted to kind of like,
signal that we are very far from perfect and I really eager to learn from everyone else as well.
I love that. That also reminds me of something that Airbnb founders always came back to.
Joe and Brian were both designers. And as you learned to be a designer, you kind of ever taught
that everything around you is designed by someone. Someone just decided this webcam is going to
look this way and work in this way. This chair, somebody decided very specifically it's going to be
like this. And we kind of assume the things that we're working with energy.
just like they're figured out, someone much smarter than me figure this out,
but it's usually just someone just like you that had to figure something out quickly,
and then that's what you're doing now.
And so they always encouraged everyone to just remember.
Someone designed this doesn't mean it's the perfect solution,
and you should always rethink things like that and not assume.
Well, with that, we've reached our very exciting lightning round.
I've got six short, quick questions for you.
I'll just go through them pretty quick, whatever comes to mine, share,
and we'll see how it all goes.
Sound good.
All right.
Sounds great.
Awesome.
What are two or three books that you've most recommended to other folks?
First one that comes to mind is Switch.
It's really about how to affect organizational change, something that's just here recommended
to me.
And yeah, the difficulty of like affecting change in a large organization, basically,
and how to overcome that.
The second one, I would say, is my favorite book of all time is one called The Story
The Stone, and it's a Chinese novel.
one of the most famous Chinese novels of all time.
It's like thousands of thousands of pages.
It all takes place in a garden,
but it's one of the most beautiful piece of work I've read.
So I like to recommend that it even about nothing to do with you.
Do you say thousands of pages?
Yeah.
About a stone.
Wow.
I will check this out.
I love it.
I've not heard this one before.
Favorite other podcast other than the one you're currently on?
Well, I'll have to admit, you know,
I'm actually much more of a visual learner.
not like a listener.
And so I rarely listened to podcasts,
but the two that I have listened to in earnest.
The first one was serial a long time ago.
And then, and yours.
So, you know, I think some of the best actually,
but otherwise more into reading.
Awesome.
This show is also on YouTube for folks
that don't like listening and like watching things.
Plug Plug.
Favorite recent movie or TV show?
The last movie I watched was called The Good Nurse.
And it was about kind of a,
a cereal tour, working in a hospital, but it was a very different take on it. It was very
human. It wasn't grotesque at all. And it was talking about how broken a system was. So
highly recommend it. It's quite sad. But yeah. Okay, good tip. What are some SaaS products
that you love, that you maybe use at Figma or that you just discovered that you find very
useful? Kind of cheating, but like, you know, as I mentioned earlier, like, we're starting to use
big jam for everything from Cal.
collaborations, to interview debriefs, to product reviews, everything.
So that's thoroughly started to dominate our usage.
It's been cool to see.
And then, you know, we have our usual suspects like Slack and Asana.
And then we're kind of all over the place on the rest.
Like some of us use notions, some of these use Dropbox paper, some of these Coda.
And so we're kind of still quicker in that one, I say.
Dropbox paper.
Very cool.
Yeah.
I love that product that I feel like no one uses it anymore.
But it's cool that you guys do.
Final question, favorite fig jam or Figma plugin or template?
We have this one called the alignment scale, which is a widget that you can insert into FIG jam or Figma design actually.
And we use it all the time.
So basically, it's just a simple scale.
And whenever people click it, their face appears on one end of the spectrum or the other.
And so it's a quick way of being like, we're doing a product review.
We want to pulse check.
We drop it in.
And we're like, how are people feeling aligned up, not a lot?
aligned. And, you know, if keep our line, we just move on. If not, then, you know, you know that
it's worth a discussion. So it's just, yeah, it's just a fast way to figure out where all the hot
spots are. Awesome. And if folks want to find that, they can actually go to the newsletter
interview that we did. I think if you just Google how Figma builds product, it comes up number one.
And then there's a link to actual templates. You can plug that right in. Yuki, thank you so much
for being here. I am going to go play with Figma and FIGM right after this. Two final questions. Where can
folks find you online if they want to reach out, learn more. Are you guys hiring? Anything there?
And then, how can listeners be useful to you? Yes, you can find me online on Twitter or
LinkedIn. Feel free to reach out there. In terms of how you can be useful to us, you know,
we're really starting to build a lot of products for this audience, right, for product managers.
Fig jam is one example of this, right? So, you know, definitely try it out, give us a feedback. Tell me
about all the cool things that you're doing or you wish you could do on Big Jam or Figma.
And they can tweet at me.
You can find me anywhere.
And of course, we're also hiring.
So if you know great people or are interested, yeah, there's a lot of roles.
So please get in touch.
Awesome.
Yuki, thank you so much for being here.
Thank you so much for having you, Wendy.
Thank you so much for listening.
If you found this valuable, you can subscribe to the show on Apple Podcast, 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 lenniespodcast.com.
See you in the next episode.
