Office Hours with Yuhki Yamashita
Welcome to Merit Office Hours! This week, we're talking to Merit mentor and investor Yuhki Yamashita about the value of process, adapting to asynchronous work, and the importance of mentorship.
Yuhki Yamashita is the Chief Product Officer at Figma, where leads the product and design teams. Before joining Figma, he was at Uber for over 4 years, where he led the redesign of both the rider and driver apps. Prior to that, he was responsible for the YouTube app on iOS at Google.
Want to talk to Yuhki more about switching jobs, adopting process, working with product and design, or asynchronous collaboration? Book some time with him on Merit.
Our interview has been edited and condensed for length and clarity.
Rachel Spurrier: You've spoken about how process itself is a product and how teams at Figma use process. For people who are in their first few years as a product manager or a designer, how would you encourage them to think about why process exists, and how to adapt to process that they're being asked to follow?
Yuhki Yamashita: Good question. For the most part, process enables people to speak the same language. In an organization, it’s really important to be able to share ideas where you’ve removed the ambiguity about what things mean.
By defining the language that the organization speaks, you spend less time figuring out what people mean. Instead, you can focus on the heart of the problem. This shared vocabulary allows you to have a more focused conversation.
But all that said, I also think that it's important for people to realize that if you feel beholden to [the process], or if you feel that [process] is limiting the way that you're solving the problem, you should also feel empowered to challenge it and propose ways to make it better. Because as a company grows, it also outgrows its processes. I think of [process] as a shared responsibility versus something that's imposed top-down that you have to follow.
Process enables people to speak the same language…In defining the language that an organization speaks, you spend less time figuring out what people mean. Instead you can focus on the heart of the problem.
RS: You mentioned that each company has its own way of doing things. One of the more jarring experiences folks can have is moving from their first job to their second job: new people, new teams, new processes. All of a sudden, the assumptions that you have about the way things are done can be totally shaken. How do you recommend someone navigates that transition?
YY: [Moving jobs] is very much like moving countries and experiencing different cultures. First and foremost, approach it from a place of curiosity and trying to understand what this organization values and is optimizing around. Second, assume that there are good intentions behind this particular process and try to draw some of those out. Over time, you might find that there are opportunities to break some of your practices from your previous role. You may even find that the practices [at your new job] are better.
In any case, while it can be really frustrating to arrive at a place that works very differently and while it's tempting to map it to what you’re familiar with, it’s an opportunity to learn a lot and, over time, develop your own perspective on what's most effective for you.
Moving jobs is very much like moving countries and experiencing different cultures. First and foremost, approach it from a place of curiosity.
RS: You also mentioned that Figma evolves its processes as the company grows. For those who join a startup earlier in its life, if that person stays at the company for several years, they may watch that organization go from pre-series A all the way to series D and beyond. In that time, a lot is going to change, particularly around process, team structure, general organizational practices. How can people adapt and grow as their company does and weather some of those growing pains?
YY: One of the most common things for early employees is this feeling that, as the company grows, they’re losing a little bit of influence, whereas before they [always had] all of the context. You'[ve] always been in the middle of everything; you'[ve] been exposed to all of the information about the company. And as you get bigger, you're starting to get a little bit more siloed, or there's different ways in which information is shared, or the things that were valued early on may no longer be valued.
I think it's easy to take it a little bit personally, to say, "Hey, I'm not as valuable to the company anymore.” Instead, reflect every six months on where the company is, and think about “What does this company need right now, and how I can adapt to that?” Recognize that companies change every six months, every year.
RS: In a blog post for Figma, you mentioned that the boundaries between product, engineering, and design are becoming more blurred—and that in particular, the overlap between product management and design is growing. How would you advise product managers and designers to approach that collaborative relationship when the roles and responsibilities between them increasingly overlap?
YY: A healthy relationship collectively covers different bases. For example, maybe one partner is more generative and the other one is more synthesizing. It’s helpful to have a relationship where you can complement each other. And it doesn't matter who plays what role. I always find that it's helpful for one person, oftentimes the PM, to help map out the solution space and then drive some discussions around which branches of exploration we should cut off immediately, while the designers actually explore some of those branches.
There's some level of intentionality around who says, “I'm going to make sure that the problem is really well-defined, while you're going to focus on laying out potential types of solutions,” even if it’s role-agnostic. Acknowledge that sometimes that's more a function of personality or interests rather than job definition.
The other is not to have a particularly rigid idea of who does what, but rather talk about what needs to be done. So for example, there might be this preconceived notion that the PM has to be the one who presents at a stakeholder review or that maybe the designer is the one who writes the user stories. But you can look at it as a collective responsibility that [the product manager and designer are] accountable for. It can create a more healthy dynamic where you invite each other a little bit more into each other's territory.
RS: On that collaboration note, tools like Miro and FigJam are becoming increasingly popular as teams work remotely. They act like virtual whiteboards. What are the main challenges for highly collaborative teams when they're working remotely, and how would you recommend approaching those challenges?
YY: First and foremost, one of the biggest challenges can be finding overlapping time zones, especially if your team is distributed. I think a lot of creativity is needed on how to collaborate in this asynchronous way so that, just because you weren't participating in that meeting, it shouldn't mean that you don't have a voice in that decision, or you don't have visibility into what's going on. If you take the view that anyone can catch up [after the fact], or anyone can participate in decisions even if they're not there, it forces you to radically change many of the ways in which you work.
If you take the view that anyone can catch up on things, or anyone can participate in decisions even if they're not there, it forces you to radically change many of the ways in which you work.
And then use the perhaps limited time together in a more intentional way. Think about the classes of discussion for which it's really powerful for everyone to be present together, and save that for the synchronous moments. Really interrogate all the other meetings and ask if those are things that could be better served through asynchronous means.
RS: One thing that I've noticed with this shift is that the asynchronous communication can be kind of challenging at times because you have to write a lot more or leave information for someone to pick up later. Are there any tools or ways of working that you've found to be helpful?
YY: One of the hardest things about asynchronous is this feeling that you have to engage on your own free time. For example, there's some doc, and you have to leave comments and review it. But you have to do it on your own free time because, if we were meeting to review the doc, someone would put it on your calendar, so it would feel like it was accounted for in the workday. It always feels like the synchronous things might be more urgent.
Part of it is rewiring: “What are the ways in which I can treat this with the same level of urgency as something that's synchronous?” Maybe instead of responding to all Slacks during the 30-minute window between meetings because they feel more urgent, you take that moment to say, “I’m going to block out some time to read this doc and respond to it.” There's a little bit of calendar hacking. And if you’re finding that you don't have time to engage in this [asynchronous work], it means that you have to rethink some of your calendar more generally.
The other thing is that there are some aspects of asynchronous collaboration that can feel very drawn out. You have this back-and-forth over comments that spans multiple days. Recognize when that's starting to happen, so that you can bring [the discussion] into something more synchronous.
One of the hardest things about asynchronous is this feeling that you have to engage on your own free time....It always feels like the synchronous things might be more urgent.
RS: The last question that I wanted to ask: in terms of mentorship, what to you has mentorship really meant—either giving or receiving it? And has mentorship change over the past two to five years?
YY: The more I have worked in smaller companies, the more I've found that mentorship is important because you don't have these natural peers around you. You have to go out of your way to find mentors. At a large company, there are many people "like you," and you can look at how they work and compare yourself to them.
Since I joined Figma when it was a little bit smaller, being mentored has let me hear different ways people were tackling similar problems and helped me recognize which problems are common.
On the opposite side, mentoring has been really important, too, because it provides me this opportunity to zoom out from my day-to-day and generalize some lessons that I've learned. People ask you advice about something, and in recounting some of the stories that you've experienced in the past, it forces you to extract the lessons from it. Once I've extracted those lessons, it feels like I can share them more broadly to help even more people.
In terms of how things have changed over the last few years, I would suspect that these opportunities to connect with people outside of your work have [increased]. The organic opportunities may have been reduced, but at the same time, you have more of this openness for people to connect across time and space.
Have more questions for Yuhki? Grab some time with him by joining Merit today.