Behind Figma's IPO: The Principles of Building Products People Love

Yuhki Yamashita built his product philosophy across Microsoft, Google, and Uber by focusing on deep problem definition, operational scrappiness, and breaking down rigid boundaries between discipline roles. After discovering Figma while leading design at Uber in 2017, he joined the company to oversee both product management and design under a shared conviction that design belongs to everyone. Today, as Chief Product Officer, Yamashita is in charge of Figma's expansion from whiteboarding in FigJam to code handoffs in Dev Mode. His career demonstrates how combining deep customer listening with intuitive product bets can reshape how global software teams build together.

My name is Yuhki Yamashita, and I'm the Chief Product Officer at Figma. Figma is a product that teams all around the world use to build digital products. It's a design collaboration platform that takes you all the way from brainstorming an idea in FigJam, our whiteboarding tool, to bringing it to life in Figma with mocks and interactive prototypes, and then turning it into a final product through a new thing we have called Dev Mode. We really think about the end-to-end product development process.

I grew up in different parts of Asia. I spent half my childhood in Tokyo, where I'm from, and the rest in Southeast Asia, in Singapore and the Philippines. Through all of that, I spent a lot of time doing design, specifically graphic design and publication design, working on newspapers and magazines. That was always a passion of mine. When you see people's reactions to what you created, and when you see something you designed printed a thousand times, there's something really satisfying and delightful about it. That ability to create something so many people see was what I fell in love with. Building products turned out to be an even better version of that, because you're not only designing, you're creating something that makes someone's life better.

In college I studied computer science, and when I started programming and building websites and little apps, seeing people use them and somehow saving them five minutes or making them smile, those were the things that motivated me, and they still do. Honestly, I was very new to the idea of product management when I chose it. I chose it mostly because I didn't know what to do. I didn't consider myself a great engineer, and I didn't know that being a designer was a real profession at the time. Product management felt like a role that would let me understand all the different parts of the business, and Microsoft seemed like a great place to learn from amazing people. I grew up on a lot of Microsoft products, too.

Google was an interesting chapter, because when I moved there from Microsoft, I suddenly became responsible for a very large app, the YouTube app on iOS. At Microsoft I had been figuring out every single detail of how something should work, writing specs for everything. At Google I couldn't possibly figure out all those details myself. Instead, I had to make sure everyone understood the problem we were trying to solve so they could make the best decisions on their own. That's still core to how I think today. How do you define the problem really well, and how do you tell the story so people are motivated to solve it and can make the best decisions themselves?

Uber was at a really interesting time, back in 2014 and 2015. It was one of many startups exploring the intersection of the physical and digital world as mobile was taking off, along with companies like Airbnb. How do you take technology and apply it to really hard real-world problems?

Probably the hardest product decision I've been part of was at Uber, when we decided to change our model. Instead of entering the car not knowing how much you're going to pay, we would tell you first. We would ask where you're going, give you a price, and then you get in. That was scary, because the understanding inside the company was that a lot of people used Uber without thinking much about the price, and only later, looking at the receipt, said, oh, that was expensive. If people knew the price up front, would they be scared away? But when we thought about the end-user benefit, and about Uber's vision of making transportation accessible to everyone, we felt good about it. Users should know what they're paying, and our job is to make it as cheap as possible. That made the bet easier to take, but it was still scary, because there was already a huge business and we didn't understand the implications. It wasn't my decision alone, and there was a big team around it. But we were changing the rider experience entirely so you see the price as soon as possible. It was really exciting and really scary at the same time.

Some things from my Uber days still apply today. The first is that when you're trying to make an experience better, you often turn to the digital experience, making the screens more efficient, more beautiful, more streamlined. But at Uber I learned that operations, what's actually happening on the ground, is really important, and that sometimes you can get people to do something just by sending them an email. Be open-minded about all the different ways you can improve an experience or change behavior. Uber is first and foremost an operations company, with world-class operations, and being exposed to that helped me understand it. The second thing is scrappiness and hustle. Uber's culture was that you figured out any way to make something happen, and that attitude and optimism is something I try to carry into every project I work on.

Later in my Uber career I switched from product to design, overseeing design for micromobility, our efforts around bikes and scooters. One reason was that throughout my career I'd felt there was an unnecessary division between design and PM. Even as a product manager, I always wanted to get into the designs and help out somehow, and I noticed that designers wanted to talk about strategy and why we were working on something. My worldview was that the boundary is much more blurred, so I wanted to experiment with being on the other side and promote a stronger collaboration where those worlds overlap.

At Uber we were also experimenting with different products for how we did design, trying to solve a problem where people in the company felt they didn't understand what was happening in the design world. We wanted a tool that made it easier to be transparent and share the design process. We discovered Figma back in 2017, started using it, and immediately saw how it changed the way we worked. People like me could be inside the product, helping and collaborating on designs. We could send designs to all sorts of people, including lawyers and people on the business side, and they could comment and participate. We became avid customers, and I got to know the team. What I love about Figma is that it fits my worldview. Design is for everyone, and the boundaries between disciplines are blurred. That's what the tool promotes, and because it was so aligned with how I thought about design, I wanted to be part of that mission.

Moving from Uber to Figma felt less like moving back from design to product and more like joining an organization that brought all these things together. Today, design is part of my organization and product management is part of my organization, so it's the best of both worlds. At Figma we believe a lot of these things overlap. Some designers do PMs' jobs, some PMs do designers' jobs, and that's okay. That's how I see the world evolving.

You can look at my career and say, wow, you made the perfect moves at the perfect time. But all I was doing was pursuing my interests and what I was passionate about. At the end of the day, if I work on something I'm excited about, a change to the world or to the way design is approached, and it fails, I still got to work on something I was excited about, and I learned from it. Some people try to over-optimize their career, but if you follow the things you're really excited about, you'll put more effort into making them a reality. The second thing is that I think about storytelling for my own career, too. What is the narrative I get excited about? What is the story I want to tell my kids or grandkids about what I did and why? Sometimes that's how I find it. I'm really excited about this story, so how can I make it possible?

Back in 2019, we were still super small. There were early adopters like Uber, Microsoft, and Airbnb, but not everyone believed in the power of Figma yet. It's definitely true that some people were very resistant to the idea of more people in the file and a design tool on the web. When I talk about listening, I mean listening very deeply. Sometimes what people tell you on the surface is not enough.

One thing our engineering team does that I love is called the five whys. Why is the customer saying that? Because they have this problem. Why do they have that problem? Keep going deeper, and that's when you get to the real truth. Sometimes customers tell you they want feature X. One way of listening is to just build feature X. A better way is to ask, why do you want feature X? What problem is there, and why do you have it in the first place? There may be something better we can build. That depth is what matters.

Every product has a point of view, and every product that's trying to disrupt the current way of working definitely does. Uber was disrupting taxis and had a point of view on what a better world could be. Figma was disrupting design and had a perspective on where design needed to go. That disruption still comes from customer insights, but customers might not express it that way. They might just express a pain point they don't realize is solvable. Great products understand those pain points, get users to articulate them, and then come up with creative solutions people couldn't have imagined.

I always try to put myself in different users' shoes and visualize how they would interpret what we're building. If it doesn't quite make sense for any one of those users, I start to question whether it could be better. The second thing is that you don't always know if a decision is right, so you ask, is this a one-way door or a two-way door? If it's a one-way door, where you can't change back once you decide, you spend a lot more time on it. If it's a two-way door, you can experiment and learn. Not every decision has to be perfect, as long as you're thinking about the future implications.

As a product team, we want to participate in the community, understand what people are thinking, and engage. One thing I always encourage my product team to do is to go out and talk to users and build relationships. A lot of my product team have relationships with customers where they can just text them and ask, what do you think about this idea? What are your top five issues right now? That kind of input builds intuition and helps us prioritize. That deep connection with customers is what has made Figma special, and something we really prioritize.

In order to build something people love, you have to love it yourself, and you have to be really proud of it. Something I've observed throughout my career is that the best things sometimes get built not because there was a perfect metric to move or a perfect business objective, but because an engineer and a designer were passionate and wanted to build something they were proud of, something they wanted to show their friends, customers, or the community. That excitement is hard to create, but when it exists naturally it shows up in the product. You're no longer fighting to add delight and magic. It just happens, because it's part of the culture.

One of the most important things in a startup is being aligned around the story you're telling. Why should people be excited about Figma? Where is it going? Why is that exciting? In a startup you don't have many resources, so everyone needs to be focused on the right things, and for that you need to rally around a story internally. Externally, a lot of people use your product not just because they like what's in front of them, but because they believe in your vision and philosophy. The more you tell that story and help people understand where you could be going, the more forgiving they'll be if the current product doesn't have everything.

I've always talked about the importance of storytelling for product management, for a couple of reasons. First, as a product manager you're often not the person building the final product. You're not writing the code, and often not designing directly either, so you operate in a slightly removed way. So your core job is to motivate everyone to focus on the right thing and to want to solve a particular problem. If you can't motivate people that way, you won't get them to build and design the most compelling products or solve problems in the best way. People understanding the problem and feeling excited to work on it is only possible with great storytelling. Second, when you talk to customers, you're communicating through stories too. You're not saying, I'm launching feature ABC. You're saying, imagine this world, now that you can do all these things and your life is so much easier, or, in Figma's case, how much more expressive and creative you can be, how much faster you can work. Those stories about value are what we have to be able to tell, and sometimes they're what focuses us on what to prioritize in the first place.

I don't know what I want to build in the future just yet. We're in the middle of a huge transformational change, where creativity has become accessible to so many more people. There's a lot of talk about AI and how it will change design and designers' jobs, and I have a few thoughts. The first is that designers' jobs are already changing a lot. As product design has matured, more and more people work with Lego blocks like design components. I like to call it moving up the stack. In engineering, you no longer work in zeros and ones, you use libraries other people built, without needing to understand the underlying technology. In design too, you use a lot of things people have already built, so you can design faster and at a higher altitude. Because of that, designers' jobs have shifted from small execution details toward solving bigger problems, and solving them more rapidly. That's why I also believe design and PM are starting to converge. PMs have been thinking about the problem at that altitude, and designers have naturally moved up to it as well.

AI does this too. Creating something takes far less time, it's more efficient, and more people can take part in the creation process. As a result, more people are free to solve more problems and be creative about problem-solving, instead of focusing on execution details. At Config, our head of design used a metaphor that really resonates with me. The floor is lowered and the ceiling is raised. More people can take part in creation, and people who have been doing this for years can produce more, and higher-quality, work. That's what I'm excited about, helping people create more things. Helping builders build.