Building 0 to 1 Products and the Inside Story of Figma Slides | Mihika Kapoor (Figma)

Anyone can do this. It doesn't need to be a pm. It doesn't need to be an engineer. So one is, yeah, don't let your. Your own skill set or your own perceptions of what you are good at get in the way of your ambitions. Be ready for, like, a decent amount of emotional whiplash. And what I mean by this is I think that every single high on this journey was followed by a low, because I think it's very natural to think that once you hit a high, the next step will be up and to the right. And it almost never. Like, for example, when we did the hackathon and the zoom chat blew up, I was on, like, such a high. I was like, this is incredible. Everyone's aligned. We can just build this thing. This is amazing. And then it was like, no, you need to, like, prove yourself and you need to, like, build a vision. So it was like, step backwards. Then when we presented the vision, it was incredibly well received. I was like, okay, amazing. So now we can, like, go forward. And then it was like, again, like, no, now you do your like and prototyping. And so every high was immediately followed by a it wasn't as good as what I thought in my head. And so I think just being ready for that, a not now doesn't mean a no. So just have that persistence.

All right, well, my guest today is Mihika Kapoor, proudly at figma. Mijica and team built figma Slides from just an idea to be a feature product at Figma Config this year. And I'm excited to dig into your advice on how anyone can build 001 products inside large companies, which is like, one of the hardest things to do. Not to mention, I think Mejica does this without writing any PRDs. So. Welcome, Mejica.

Thank you for having me, Peter. Really stoked to be here.

Yeah. So why don't we dig right in? Let's start with when Figma Slides or Flies was just an idea. Right, so let's go back to, I think, August 2022, when you first pitched Figma slides at a PM off site. Like, why did you want to build this product?

Yeah, the journey of figma Slides started even earlier than that. I would say just like two or three months after I joined the company. And the context there is that I had actually joined Figma as the second PM on figjam. And so I was working on scaling up figjam. And what's pretty interesting is that for most folks who work at figma, you kind of get this Ask this question of, hey, like, what's it like to build figma inside of figma? And. And is it like trippy? Is it weird? You know, what's that like? And I think the reality is we actually use figma quite similarly to most other companies. However, our use of figjam is like out of this world and totally on steroids. And so internally, not only do we use Figjam for brainstorms, retros, etc. But we use it for our presentations, for our product reviews, for our all hands, for our kids, QBRs and more. And sort of the reason that we do this and the reason that we lean into this is because it really democratizes the conversation. And so normally these high visibility, high stakes forums, you normally have one person talking at a time. It's either the loudest or the most senior person in the room. And we found that Big Jam was really effective at really democratizing that conversation and allowing 20 sticky threads to be happening at the same time. And so, you know, we were using figjam internally for presentations and I would go and I would try and evangelize this way of working to other folks who were in tech and I would basically pitch them on like, hey, y' all should also do your presentations inside of figjam. And I think there were some like, early adopters that were down to try, but I would say the majority of folks that I talked to sort of recoiled a little bit and they were like, no, like when I present to my leadership or to my executive team or to my stakeholders, like, I really crave this sense of polish. And I think that, you know, figjam is this place where you don't want the users to think about what is it looking like, Right? You just want people to like, be spitballing ideas, not be constrained, not be thinking about form factors, et cetera. And so that's really where I kind of got this idea of like, okay, we need to have a tool that potentially marries the interactive feedback mechanisms of figjam with the visual fidelity of figma. Because we had seen so many people also using figma for presentations.

Got it. So you actually kind of experience this pain yourself, right? Like try to convince letter PM students and they wouldn't do it.

Yeah, exactly.

Got it. And how did you build more conviction that this is something that you want to kind of like build a team around and just make it happen?

Yeah, definitely. I think that's where actually looking at the figma side of the equation really helped. As you mentioned, we had this PM off site in August of 2022 where we had this discussion about what are the future strategies or bets that we should be taking as a company. And I was really bullish on forcing this conversation around presentations, which was like, hey, like we internally have seen this kind of unlock by leaning into a collaborative presentation with Big Jam. At the same time, we know that people love using figma for presentations, right? You get a tweet a month or so which kind of goes viral of people saying like, hey, Figma, please just like build a slides tool, right? And so there was kind of this question of like, okay, do we build a tool on top of FigJam? Do we build a tool on top of Figma or do we build this standalone product? And I think like really pushing that in that forum and getting visibility across all PMs led to a lot of insights coming together in a really helpful way. I would say probably the most helpful insight was from the prototyping team. And there was basically another person on the product team, avanthica, who raised this stat about a really high percentage of Oregon end files actually being presentations. And when we launched slides at configuration, we actually spoke about how in the last year over 3.5 million presentations inside of Figma had been created in the last year. And so not only was there this sort of bet in terms of differentiator value, prop and vision, but there was also this like data backing in terms of seeing how so many users were hacking one of our products in this way.

Yeah, I love that. That's like one of the most surefile ways to actually build something people want. Like it just like if they're already hacking something to make it happen already and just make it easier for them, chances of success are much higher.

Yeah, definitely.

So you guys had a big PM off site and then a lot of people liked your sticky on the presentations. How do you keep the momentum going? What did you try to do next after this PM off site?

Yeah, so I think at Figma we really have a very see to believe culture. So as soon as I really built conviction in this idea and like early stage conviction, but I think enough that I felt comfortable internally pushing for it. Even before the off site, I would talk to anyone and everyone about how I thought that we should build slides. And I think the reality is like just talking to people literally got me nowhere. Like I would talk to various execs and I would be like, we should build this tool, you know, visual fidelity of figma, interactive feedback mechanisms of figjam. And I would hear like A maybe in the future, like, you know, just sort of the idea would get thrown into the abyss, sort of. And I think that it was very clear to me that in order to really generate an almost like irrationally emotional connection and desire to invest in the product, I needed more than words. I needed to, like, really put something in front of folks. And so we have this concept called Maker Week, which is our biannual hackathon. And this is a week where the entire company, not just the org, not just the tech org, but like, literally the entire company across, like sales, finance, biz, dev, marketing, more go on pause and basically just hack on things. And what I was intent on doing was leveraging this Maker Week to build something that I actually hoped people could use inside of the company to similarly build conviction around this idea. And so in fall of 2022, we had our Maker Week, and it was this funny Maker Week where I was both hosting the Maker Week and also trying to, like, build a net new product. And so I was like, walking around the New York office basically begging anyone to work on this idea. And there was an engineer on the Figma editor team named Dorothy who was like, yeah, I'm down to help. And what's really magical is I think once you get one person on board, it becomes a lot easier to gain momentum and to gain traction. And so once Dorothy was on board, her whole team and her whole pod, the editor experience pod inside of New York, jumped on board and along with several others, worked on fleshing out this idea. And I think that when you're thinking about how to pitch something in a hackathon, I think a lot of people generally get constrained by, okay, what can I do in a week? Or, like, in this case, it's really like, what can I do in three days? Because the first day is coordination and the last day is demo day. And I think, like, my advice for anyone who is going into a hackathon with an idea that they're trying to pitch to their company is don't be at all constrained about what's possible in three days. Instead, just be ruthlessly scrappy about what you can reuse. And so our initial prototype inside of the Maker Week, actually, we took the Figma editor and we added a carousel to the side so that it would feel more slidesy. And then our presentation mode, because we were trying to show the interactive feedback mechanisms of FigJam, was actually FigJam. So you hit play and your presentation got ported into figjam, where people could add stickies and vote and Respond and interact with the presentation in a really dynamic way. It was a far cry obviously from what the actual product ended up being, but it was enough to lean into specifically the two differentiators that we were trying to push for, which was that visual fidelity of figma, interactive feedback mechanisms of figjam. And it's also where the name Flies grew to prominence. We had this little part of the demo towards the end which was what should we call this thing? And we had a name Storm. And there was Flies and there was Sligma and there was fec and there were all of these very, let I say creative names that got thrown around, which were really fun as well.

Okay, so the prototype was basically like a bunch of smoke and mirrors to try to show these two value props that you had in mind, right?

Yeah, we could call it Smoke and Mirrors. I think it's just creative repurposing.

But yeah, I really think like more teams should build prototypes first. Usually what happens to these companies is like you go off, you want to build a zero to one product and you go off and write like a six pager, like you make it like a fancy deck, right, like with the division and all that stuff. And we'll talk about that more. But like, yeah, just like, why don't you just freaking build prototypes and bring this shit to life so people can actually play with it? And then once you play with it, you kind of innately know why it's valuable.

It's pretty interesting. I think once Figma slides went out the door at config, I actually got approached by a lot of designers who asked this question of if there is a thing that I believe in, how do I get my PM on board? Like, how do I get my PM to prioritize the things that I think are really going to make a difference, but might not, you know, bubble up to be a P0 on the roadmap? And I think my advice for those situations is exactly what you said, which is just prototype it, design it, build it, and take the afternoon to really invest in showing your idea in the best light. And I think often when folks disagree about what should be built or what direction to go in, it's generally either because they have different assumptions in their head or it's because those different assumptions are leading them to have a different solution in their head. You end up disagreeing without even realizing that you're talking about different things. And I think what a prototype does or what a design or a mock does is it grounds the conversation in something real and is much more effective at driving alignment and getting people to agree. Like, okay, yes, we're excited about this, or okay, no. And this is why rather than shooting down the idea in abstract.

Yeah, exactly. Because otherwise you have a vague vision statement and some of the descriptive lines and it's kind of upping the ether what this thing actually is. Let's keep going. So, you know, got the prototype, did you present it to Dylan and the exec team? How was the reaction of this thing?

Yeah, so it was pretty interesting. We have at the end of Maker week, we have like a two hour demo day where a bunch of presentations and a bunch of the hacks are basically presented to the entire company. And so there's Dolan, there's the entire executive team, but there's also the literal entire company on a zoom chat or in the offices, et cetera. And what happened when we presented slides at the time was the chat exploded and everyone who had never seen the idea was stoked. Everyone who had thought that we should build a slides product because there are many people inside the company who had faith that we should build a slides product, they were stoked. And the thing that shocked me was everyone who was skeptical in that moment was also stoked. And I think it was like a confluence of things. I think one was the fact that people were excited about the prototype. But two, I think there was also an aspect of a level of ambition of building a net new product, or at least framing that so called smoke and mirrors as a net new product was really, I think emblematic of what we hope that people do inside of maker week, which is take these big bets and push the envelope on something that you couldn't do in your day to day, right? So we try to carve out space for people to like dream big and do what you could do in that time. And so I think that what was really powerful about the prototype was it was no longer just me pushing on this idea, but it was this entire company now who would every now and then when we had all hands and stuff like that, be like, so like what happened to flies? Like what's going on there? And you create this internal momentum that I think about it as like if you're trying to push an idea through a company, like you want to make it bigger than yourself, right? If it's just one person pushing on something, it's never going to get anywhere. And so I think what was really cool was now there are a bunch of evangelists across the company. I think there was also like a little Bit of a hard part or almost like something that was surprising to me in the moment was when the chat exploded and went wild. I was like, okay, great, so we're like building this, right? And. And then the answer was no. You know, like, you can't just build a prototype and you know, get headcount to spin up a team. But what it did do was it was not a green light for the project, but it was a green light for the next step. And so, you know, we had this meeting with Dylan where we presented, you know, we are better than xyz, other players in the space on visual fidelity. We're better than XYZ players in the space on collaboration. You know, like put that together and we think we can like win in this space. And I think Dylan's reaction to that was, you know, you can't just invest in a space because you think you can outdo your competitors. You need like a very tangible perspective on if you are successful. How does the way that people are working or, you know, going about their lives really change? And so subsequently, after the make a week project, we did a one month vision sprint on really figuring out if this product was successful, what kind of change would that look like in the workplace and otherwise? This was a one month sprint. In January of 2023, it was me, a designer, Kian, a researcher, Gus, and an engineer, Alex. And we basically came together and I think sort of violated all the rules of how you're supposed to do product development because we just had a month to put this thing together. And so instead of doing the typical, I think cycle of what normally informs like a vision, which is, you know, first, you know, do a couple weeks of research, then a few weeks of design, then build and basically have this like waterfall process. What we actually did was we stacked research, design and engineering all on top of each other and we started designing immediately with our best guess at what people wanted. And we started researching people's like, core needs. And we basically changed the questions and research like almost every day as we like learned new things and wanted to dig into more aspects. And what my day would look like was like I had a daily one hour sync with Kian and then I would spend the rest of the day in research sessions with Gus. And we would make sure that there was like a constant cross pollination of like research insights informing the designs and then the new designs helping to inform new questions on the research side. And so we were able to cover like a lot of ground in a quite short period of time. And put together this vision deck that, again, to your point, was not just words, but I would say 90% of the deck were these design prototypes about specifically what we thought would be the inflection points or the differentiators in the product. In terms of where we netted out. I think that something that's pretty interesting, or one of my most interesting takeaways from doing the vision Sprint is talking to users about their foundational needs will often take you in a pretty different direction than having them react to mocks and prototypes. So on the research side, we kind of divided it into two parts. We had the first half being very foundational research, not anchored in designs because we didn't have the designs as yet. And then the second half of the month was focused on concept testing and we had this hypothesis going in, which was basically that while creation and deck creation is part of the presentation that people, you know, slave over and spend a million hours on, the actual problem that people were facing was that they left presentations frustrated because they would present a bunch of things and leave without an outcome, or they would leave with like a bunch of people on Zoom disagreeing or something like that. And, you know, we would talk to folks, we would ask them their goals of a presentation, and we would ask them if they were frustrated when they couldn't achieve those goals. And what we, generally speaking, heard from users was people being like, oh, yeah, that's definitely a problem that I have, but I don't expect this tool to solve it for me. Like most people, when they fail to drive to an outcome in the context of a presentation, they take it on themselves. They're like, I did not structure the conversation appropriately. I did not pace the presentation appropriately. They take a lot of this, like, trouble on themselves. And it kind of reminded me of if you've read the design of everyday things, there's this part where, where the author basically talks about how, you know, most people pull push doors and push pull doors and they take it on themselves when they do it wrong, but probably there's like some design flaw there. And so I think we had like a similar hypothesis with like, the fact that most people who went into a presentation were actually unable to get the outcomes that they wanted, which was that they weren't having the most effective conversations. Fast forward to when we started presenting some of our concepts to users. We were presenting things like polls and alignment scales and things like that. And. And there was this unlock moment of folks feeling like, wow, this can help me get, you know, signal from my entire engineering team not Just the tech lead like this can help me concentrate the conversation not just on like maybe the loudest people who already agree with me, but like the quieter person who might have some insight the rest of us aren't thinking about. And what was really cool was to see that like change in people feeling like the burden was on themselves. To people starting to see like, oh, maybe this tool can help me solve my problems in this way.

Kind of like personally, like I don't like presentations where it's just like a PM or designer trying to get buying for something. Like the best product reviews are. Like someone in the room actually has a good idea that changes their mind or something. Like what's the point of presenting other than having a discussion? So is that kind of what you found?

Yeah, you know, for example, I would say like, I don't know how familiar you are with the alignment scale, but it's a tool that we religiously use internally. It's basically the spectrum where you can pose a question and people can either strongly disagree at the red end of the spectrum or strongly agree at the green end of the spectrum. And it's a very simple paradigm. But what actually happens is that the way that we use this tool is everyone will vote and you get the spectrum. And then what we do is we ask the person who's most to the right and most to the left to like voice why they think what they think and like hash it out. And at that moment you're able to kind of get the extremes perspectives vocalized and the center of the discussion. Because other times you can have people like very much like agreeing without even realizing they're agreeing or disagreeing without even realizing what they're disagreeing on. And I think that having those kinds of visualizations of where people stand are really great. To your point, like eliciting the ideas that maybe the working team hasn't even thought about or something like that.

What kind of users do you talk to? Like is it designers or PMs or.

Great question. We talk to 1/3 designers, 1/3PMs, 1/3 other miscellaneous non designers. So that would be like biz, dev, sales, et cetera.

Got it. I think you talked about how you broke all the rules, but I think what you did is actually what most startup people would do, right? They're not going to do research for like a month and then make a design for a month. The company would die by then. So the fact that you can go through this loop, iterate loop as fast as possible is kind of what should be Done. I think at most companies.

I hope so.

Okay, so you did the same for a month. Did you get buy in from people like Yuki and Sho along the way or just kind of like this thing for a month and then go for this big presentation to Dylan?

No, I would say like Yuki, who's our cpo and Cho, who is the VP of product at the company and third, one of the honorary co founders were very instrumental along the way and helping package the insights. And so I think that what's pretty interesting is before I came to figma, I was kind of taught, and this works in a lot of companies, but I was kind of taught that the shorter the deck the better. Right? So to the extent that you can make a seven slide vision deck or strategy deck and put that in front of someone, like that is the gold standard. And When I joined Figma, it was really interesting. I would see these 60, 70 slide decks, I would be like, whoa, the executive team is going through all of this. This is so much content. And I think it's really tied to what I was saying before, which is Figma has this very see to believe culture. And a bunch of bullet points about what we wanted to do will do almost nothing to drive alignment versus a bunch of prototypes with user quotes of what we heard in our research sessions is basically one both aligning and being very explicit about what we have in our head as the target end state, but also gives us the ability to show the proof points. And so Yuki gave a lot of really helpful advice about how to help the audience feel like an emotional connection. And so, you know, you can say something along the lines of this is like a feature that we had in mind that hasn't shipped yet, but might ship in the future. We think that users should be allowed to emote when someone else is presenting so that they can express their enthusiasm about the idea at hand. And you can say like, the problem is that, you know, people get bored during a presentation, right? And so you can kind of like say that I think something like that you can like nod your head to or something like that. And what I really, you know, tried to do at the push of Yuki in this presentation was to really put the listeners of the presentation in the shoes of the person who's like undergoing like extreme embarrassment. So like one of the starting points of the presentation was kind of like you're presenting, you're up on stage or in a zoom call, like delivering this thing that you've slaved over and you present your thoughts and there's like silence, right? And like everyone has been there, right? Where you're like, this is my thing and like, this is what I want to do. And like you have no idea if people care or agree or disagree. And you know, the, on the audience side of the equation, you don't feel the pain, you're just kind of like, oh, if no one else is talking, I'm not going to talk, etc. But as a presenter you're like in agony, right? And so it's kind of like, how can you constantly just show the points of agony throughout the presentation process and anchor the solutions around those? And so it was sort of this like six part presentation where it was like, okay, first like you are the presenter and then like went through all the pain points that you were facing, all the solutions we had, all the proof points we heard from users, then it was like you missed the presentation and you're trying to catch up and all of those. Then it was like, go back in time, you're building the presentation. We went through all the creation pain points and it was this like constant immersion of the user and the listener in the user's shoes and building up from there. And I think that was really powerful. I think a piece of advice that I got from Sho that was really powerful was to kind of like use marketing language. There's sort of this internally we sometimes say like, Dylan thinks in tweets and I think that that has sort of like rubbed off on a lot of the company in terms of thinking about like, thinking in tweets is basically a another way of saying like, think how you can talk directly to the user as concisely as possible. That's like kind of how I think about the translation of thinking in tweets. It's like we're not talking to the Figma executive team when we're presenting the Vision Sprint. We're talking to like the user that is just stumbling stumbled into this new feature on Twitter or on product Hunt or LinkedIn, what have you from their co worker, etc. And framing the presentation in terms of that being like really moving. And then I think the last piece of advice that I really got from this was both from Yuki and Chris. Our CTO was in the days before the actual presentation, I did like a dry run with each of them, walking them through the deck and both of them are kind of like, yeah, like this is looking great, like super stoked. But just so you know, like Dylan is going to stop paying attention. And this wasn't a byproduct of how long the deck was. As I said before, this was a byproduct of like how much time you spend setting context before getting into what you're building. And I think that to the extent that you can just minimize that to like be maybe like two minutes maximum before you get into the like those pain points that I was talking about, that's more likely to have an engaged audience.

When you say, say in the context, you mean like why are we doing this? How are we adding up to the overall strategy? That kind of stuff.

Yeah. So it actually changed many times over the course of flushing this deck out. So I would say the early versions of it were something similar to that, which is like we're seeing these problems. This is what we heard in research. And it's like bunch of slides up front setting context and like this is what we're seeing in the data, so on and so forth. What it ended up turning into was a very, very small number of slides on what we thought was the biggest overlooked area of presentations, which was the presentation itself. For example, we were kind of talking about how when slide tools came out like decades ago, it was revolutionary. Right. It was like the first time that you had a basically a design tool, even though we don't call it a design tool, to put together these ducks that were this gold standard of communication inside of any organization. And if you talk to people about what is the most painful part of presentations, as I was saying, they'll tell you, okay, the amount of time it takes to make a presentation. And we care about lake so much more than that. As a user who's putting together a presentation, we care about like facilitating our goals. Like why does someone do a presentation? It's to get sign off, it's to inspire an audience, it's to get by and it's to do all of these things. It's to, you know, gather a bunch of ideas. And most players in the space have kind of talked to users, heard the pain points around creation and said, we're going to take creation, we're going to make it better. And there's this overlooked part, which is the presentation that was really where we wanted to get in on. And I think that that piece was just like communicated succinctly upfront as like this overlooked part. And this wasn't the only part if you use the tool, you know, that we care so much about creation. Right. This is where we lean into like the figma ness of figma slides. But I think just kind of highlighting this is the thing that no one else is talking about was really what we wanted to get across in the like upfront section of the presentation.

Got it. So the upfront is kind of like what the key differentiator is. And then most of the deck is like, put yourself in the shoes of the presenter. This is kind of like a painful moment. And here's kind of like our designer prototype showing the solution and maybe here's some quotes about what people said from the feedback sessions. Dylan does seem to come off like someone who's very customer focused and so like that kind of messaging probably focused. Yeah, yeah, I just put myself in the shoes of Dylan and some of the execs. Did you also try to ladder up this product to an overall company objective? Because, you know, just putting myself in the shoes of like one of the execs. They probably have like an annual plan or something like with like you know, three priorities and then here's Mihe coming to pitch this new product. So did you try to try to be like, okay, this actually helps Figma expand to other customer segments or something like that?

Yeah, definitely. So I think that if there's an idea that you're passionate about, the only world in which it makes sense to pursue it in the company where you are already at is if it lines into a business outcome. I think like at Figma we have many focuses, but in my mind it can kind of be distilled into two. One is like, and this is most companies, honestly it's like funnel broadening and funnel deepening. Funnel deepening is how can you take existing offerings, make them more valuable, etc. And then funnel broadening is how can you get more people into your suite such that you can start cross pollinating the products against each other. And I think historically Figma has been branded as sort of a company for designers, which is really interesting because that is no longer how we see ourselves internally. And when we look at the most Figma like fanatic companies, we don't see that at all. Right. We see, you know, not only designers in this tool, we see PMs in the tool, engineers in the tool marketers in the tool sales, folks in the tool, etc. And figma slides was basically so exciting as a concept to me because it was a known visual communication tool, but at the same time it was also known for non designers. And so it was basically like in my mind our best shot at making it clear that we think about the entire product development cycle, if not literally everyone as a member of the audience that we care About, Yeah, like, I.

Think a lot more people make slides than making product designs, so definitely broadens the adjustment market. Okay, so let's talk about the sausage making of actually making a product. Right? First of all, you were still a PM on figjam, right? Dylan's like, okay, now go spin up a podcast. So was it kind of awkward? Like, how did you talk to your manager about this? Like, was it weird to be like, okay, I'm going to work on figma's lives now and try to recruit people from other teams? How did that work?

Yeah, good question. So I think, fortunately, following the hackathon, there was general agreement that we could spin up a Vision pod around it. And so as of the vision sprint, like, me, he and Gus and Alex, like went full time on it. And we actually incubated the Figma Slides team from figjam. And so the designer he and who I worked with on slides was the same designer I had worked with on figjam. He built like the figjam toolbar, amongst other things. And so I think that what, I mean, I think what's really nice about figma is in general, I don't think there's like much territorialism. I think that Fig Jam was born out of figma, Dev mode is built on top of figma, figma Slides was incepted out of figjam, so on and so forth. And so I don't think that there's that much territorialism. But I do think that at the same time, when you're building a team, there are a lot of other important things to keep in mind. I think that probably the most important is screening for passion, I would say. I heard of this concept in college, which was this concept of like a first follower. And it's basically saying that, you know, if you have someone who like, goes into the street and starts dancing on their own in the middle of the street, everyone's gonna kind of be like, what is that person doing? And, you know, you would kind of walk by and you'd be like, oh, like, I think I'm gonna, like, stay away from that person. Like, what are they doing? But then the second that a second person comes and starts, like dancing in the street next to that person, you're like, oh, interesting. Like, there's. There's really like something there. And then maybe what that second person joining leads to is like a flash mob in the middle of the street. And, you know, you go viral or something like that. Right? That's like an extreme version. But I think that, like, Sort of moral of the story is that it's not just the person who first walks onto the street that's like responsible for creating something. It's the first person that decides, oh yeah, I to believe in that thing and I want to shape it in my own way. And then the third person, the fourth person, and that kind of like compounding. And so like, I think that like the earliest, you know, engineers, designers, researchers, etc. That join your team should have that first follower mentality of like, they're not there because their manager told them to join. You actually like almost don't want that. You want them to be there because they believe in it. And so it was pretty interesting is that our first or longest tenured engineer on the team, John, who's basically the tech lead for Figma Slides, was begging his manager for over a month before he actually joined the team as to could he join the team. And it was kind of hard to move him because he was working on a bunch of important initiatives and things like that. It was unclear if my slides was even becoming a thing when he joined. It was still unclear if it was becoming a thing. But he followed up every single day with his manager and he was, I want to join this thing. And then I would push his manager and be like, I think John should join this thing. And then what ended up happening in the end was not only did John join as the first engineer, but a few months later his manager Alice joined and became the engineering manager on Figma Slides. And so you get this kind of like really excellent domino effect of, you know, great people attract great people.

So it's kind of just like organically, right? Like you did a good job promoting a product internally and you know, people were aware of it. And then organically, I guess people just want to join and you kind of encourage that behavior.

You need to put your product in front of folks in order for them to know it even exists. So I think that Maker Week was one example of that. Where it went in front of the entire company piqued some interest. I think the second example was in fact the Vision Deck, where after we presented to Dylan and the rest of the executive team, the deck sort of went viral. I don't know how it got posted literally nowhere, but there were like 20 plus people in it at all times, like constantly like cycling through throughout the day. And so that was like a second that time. And then third is just like once you have engineers on the team who are like really excited about the direction and the vision and also Forming that direction and vision in their own way. And like, to the extent that they can talk about it with other engineers, designers, et cetera, that they know at the company, that's kind of how you're able to like galvanize that interest.

So now after this Vision presentation, I think you had like 15 months or something to try to deliver this product config. What was like the hardest thing about from the Vision to config? Is it like, I think you mentioned that people doubt that you can ship this thing or what are some of the hard things that you had to overcome.

So it's really interesting it did, to your point, end up being 15 months from vision Sprint to launch. But I think the thing that most people would not have expected was that we entered this year with Figma Slides actually not on what we internally refer to as config path. And so it was not internally perceived as something that would be ready to go out the door when it did. And so I think it's kind of interesting because it's like there wasn't a leadership enforced deadline for Figma Slides. There was like a self enforced, let's move as fast as we possibly can in order to build a product that the rest of the company and eventually our alpha users, and eventually the entire world is excited to use. And so I think that the challenges are many, I would say, like, if I had to distill a few of the most challenging moments during the process, I think first would be, I think just sort of like there's a little bit of mental toll on folks, not necessarily thinking that this is going out the door. And I think that ideally you can take any sort of like mental toll like that and turn it into a challenge. And so what we actually ended up doing for Figma Slides was in the context of this year, we entered the year with a sort of product keynote by Yuki and Chris, our PO and cto, where they were going to speak to the entire company about the three top initiatives inside of the company that we were rallying behind. And we had three top initiatives and Figma Slides was not one of those three, which was pretty top. But at the same time I, in my head and like several folks on the teams and their heads, wanted to push for this thing to go out in a sort of config time frame. And so what I actually pushed for along with Yuki was how can we actually do this presentation of the year, this opening presentation of the year inside of Figma Slides and in the end reveal that the entire presentation was built inside of Figma Slides. Now, if you watch the keynote, that's actually exactly what Dylan did at the keynote at Config, which was we built the entire thing inside of Figma Slides. We didn't announce Figma Slides until the very end when Dylan though at the time Yuki fake ended and was like, oh, actually one more thing. This is made inside of Figma Slides. And so I think like, what that was really effective at was a few things. One was that it just sort of totally strengthened conviction in the state of the product. And I think that as a PM building zero to one products or it's funny, someone recently pinged me that if you're building inside of a company, you can call it like something to one, but you always need to be like selling ahead. You always need to be like way more optimistic than everyone around you in order for them to get like a little bit closer to where you want them to end up. Figma Slides in January of this year was barely a functional product. Speaker notes were supposed to come in the week after this presentation was taking place. And of course they needed speaker notes because this was a presentation to the entire company about our 2024 strategy. We were stretching the product to its limits. There was a chance that it would crash at the end. The entire team went on two weeks of pause of what they were normally doing in order to make this thing possible. And it was pretty interesting because at the time that was perceived as a sacrifice against development velocity. But in reality it actually ended up tremendously accelerating the development of the product. Because what's better than having people brute force test your product to its limits? And the things that we found were actually the things that were at the edges and ended up being like really important for us in the long run. And so we like put all this effort in, launched and did the presentation inside of Figma Slides. Through some miracle, it worked perfectly. And a few weeks after that we decided that we would in fact announce Figma Slides at Config. That was kind of like this skepticism turned champion moment, which was really exciting.

It's kind of the same theme of making it real. Like you said, you have to promote this stuff internally just as much as you promote externally. After you launch. You have these four really good pieces of. Let's kind of take a step back. Four piece of advice for anyone who wants to build zero to one inside a company. I love that you mentioned anyone, because a lot of times people think like, you know, the PM used to come with ideas. Do you want to just briefly capture These four pieces of advice.

Yeah, definitely. So the first is kind of related to what I was saying before about John joining the team and the entire team building up from folks who were like, really excited. But the first is find your people. I think everyone works differently, right? And you can have two totally exceptional people who don't necessarily work well together because they have different styles. And so I think like, a style match on working style is just like, absolutely necessary for sprinting because if you're able to find someone who works in a similar style to you or works in a complimentary style to you, you'll find that you'll just be like, running always. I think like an example of this. One was like the example that I said in terms of always screening for people who want to join your team. I think two is to be like, as inclusive of other folks during your development process. And what I mean by this is like, I think it's pretty dangerous to kind of treat your product as a walled garden. You want to instead have like as many people feeding in as possible, possible. And so, for example, one engineer at the company, Carl, who is like the longest tenured engineer, actually decided to join the Figma Slides team after we looped him in for a random jam during an off site and just originally wanted to get his advice. He had so much fun that he asked if he could join the team. And so you really want to create those opportunities to get the product in front of folks who it might resonate with. But I think that anyone you need to like, really bend over backwards to convince they might not be the right person. Two is around building a brand. And so I think that rewinding a few weeks to config something I honestly never thought would happen was the term slides going viral on Twitter. It was just absolutely not in my bingo card for 2024. But basically, I think that every company is different culturally. I think Figma has this very kind of like fun, kooky culture in a sense, right? Like the fact that we launched a product named figjam, I think speaks to that in a really nice way. But Flydes as a term, I think was so absurd of a term that it couldn't not get attention inside of the company, right? And if I really believe that if we called this product Figma Slides internally, we would not have had the reach or the attention that we did. Like, I think with a name like Flydes, someone hears it and they're like, what is that? And like, how can I learn more about that? Right? And so to the extent that you can build a brand either through the name or through other things, I think you really, really should because you want to be that product, that idea, that initiative that like when a person joins the company they're like, hey, what's that? And how can I learn more about it? Right, you want to open up the funnel for that you, your people piece. Third is to really be delusional. I think that generally speaking this goes to the sell forward point, but you always want to be the most optimistic person in your company about this product if you are going to push it forward. Because if you think you're going to ship it in two months and everyone else thinks you'll ship it in like two years, you're going to end up with something in between. And if you don't have that like insanely, literally delusional level of optimism, it might not ever show. Just having that like fortitude to really believe in that is very important. And then the fourth piece is I always say don't manifest, which I think sounds kind of strange because this I know in a lot of ways sounds like a project that was manifested out of an idea, but I think that the term manifesting has really taken off. It's become very trendy. And I think that the way that it has taken off and what it encourages from a behavior perspective is actually kind of dumb or potentially harmful, which is that I think manifesting kind of says like, if you really want something to happen, just like say it enough times, wish it enough times and then it'll come to be. And I think that that is like in a sense far too passive. And I would say like, if you want something to get done, go out there, find the engineers, recruit the team, pitch it in company forums. If you're building a startup, pitch it in worldwide forums and go out and do the things that need to be done in order to get it out the door and build a product that you believe in.

Yeah, I think the last two really come together. You can be delusional, but if you don't take any action, it's not going to work out for you. You got to be delusional and take action. Last few questions now that you launched was a big moment at config. I think a zero to one product is like very fragile. Do they expect to Figma slides to scale to millions of users in like a few months? How do you manage expectations so that you can keep investing in this and like keep making traction?

It's a good question. This is actually where historical precedent does Help. So actually what we did for Figma Slides was we decided that when we went out the door, we were not going to have a target goal. We were going to have like an exhaustive dashboard that gave us like all kinds of cuts, like weekly active editors, weekly active users, designers, non designers, who are our champions, who are our collaborators, so on and so forth. Like, we have an exhaustive dashboard, but our goal for the first few weeks after launch was simply learning and understanding. Like, where are we seeing traction? Where do we have faith? Where, you know, where maybe are we seeing like slower than ideal growth growth? And then what we did was we basically used the initial few weeks of data to inform what our Q3 and eventually H2 projection should be and to make those ambitious, but to only do so once we have an idea of like, what the levers are that we can move. And so I think that like, in a lot of ways the launch exceeded a lot of the metrics that we didn't think that it would. And I think that seeing where it's spiking and where it's not is actually the most informative piece in terms of building a strategy and setting real goals. And I think that blind goal setting is actually really tough because if you set a goal without knowing your levers, then you might be gold on something that's outside of your control.

Yeah, that's like a really dangerous spot to be.

Right.

I think you're right. You should have a goal to learn. Basically. That's kind of what you should have. But in the past, when I've built zero to one, you have the CFO coming like, oh, you know, if we're going to invest 10 engineers in this thing, let's get to X million dollars by year two or something. And they just kind of like pull out a thing here and then you have like these crazy expectations that you can't beat.

Yeah. For what it's worth, I do think that like, once you hit the like six month mark, you should have very ambitious and concrete goals. I just think in the like, immediate aftermath, you need to be learning like where you're seeing traction. So then you know where to apply pressure, where to let it do its thing, so on and so forth.

Yeah, exactly. All right, well, any kind of closing words of advice for people who want to push for something inside these large companies? Like, I know you have four pieces of advice, but like, any inspiration to leave us with?

I would say a few things. One is, I agree wholeheartedly with what you said. Like anyone can do this. It doesn't need to be a pm. It doesn't need to be an engineer. I studied CS back in the day, but the engineers around me at Figma are so much more talented than me, and I was not on my own capable of spinning up a prototype for this thing. And so I think understand where you're strong, but also understand where you need to partner with folks and be very real about that, but also be very ambitious about what you as a team need and set out to get that. So, one is don't let your own skill set or your own perceptions of what you are good at get in the way of. Of your ambitions. That's one. And I think two is be ready for, like a decent amount of emotional whiplash. And what I mean by this is I think that every single high on this journey was followed by a low. Because I think it's very natural to think that once you hit a high, the next step will be up into the right. And it almost never is. I think, like, the journey is kind of like, up, down, up, down, and you're incrementally. And I'll give you examples of this. Like, for example, when we did the hackathon and we. The zoom chat blew up, I was on like such a high. I was like, this is incredible. Everyone's aligned. We can just build this thing. This is amazing. And then it was like, no. Like, no, you need to, like, prove yourself and you need to, like, build a vision. So it was like, step backwards. Then when we presented the vision, it was incredibly well received. I was like, okay, amazing. So now we can, like, go forward. And then it was again, no, now you do your English prototyping. And again when we hit. We did the sales kickoff product vision pitch at the beginning of this year, and that was built inside of slides. Again, that was a high. And I was like, amazing. So we'll launch a config. And initially it was like, yeah, we'll announce a config, but still TBD if it'll be a closed beta or an open beta. And so every high was immediately followed by a oh, it wasn't as good as what I thought in my head. And so I think just being ready for that and not now doesn't mean a no. So just have that persistence.

Yeah, you're like basically like a startup founder inside a company, right? That's basically what you are. You gotta go through the. You know, it's over. We're so back, back and forth all the time.

That is accurate.

All right, so, Mika, we've got to cover one thing, the most important thing, which is how do you do your job without writing PRDs?

It's a really good question. So my take on PRDs is that they're not very useful during the actual development process. It is possible that they are useful post development as documentation. I believe this because I have never in my life seen a PRD that is not out of date. I think some PRDs are better at staying in date than others. My PRDs are always out of date. And so that begs the question of like, okay, what do you do instead? Designs on the other hand, as a function of being like the literal thing that developers build off of, are always up to date. And so I have like a pretty, I would say like unique relationship with Ian, who's the primary designer on figma slides. We used to meet every single day for an hour. Now it's like every other day. And so what we, what our process is is basically like jamming together either inside of a Figma file or a figjam file on like various specifications, turning that into designs, and then reviewing the designs and adding all context next to the designs. And so designs basically become the source of truth for the project rather than a prd. And then that's complemented by like a set of strategy docs which span multiple products, not just a single product.

Okay, so you basically just write the words next to the design. Like if there's some edge case or something you have to capture, you just write it next to design.

Yeah. I also think that like PRDs are oftentimes like incredibly prescriptive, which I think doesn't work if you have like a very product minded designer or very product minded engineer. Like you might have something like there is a button that does this. But then like a designer reading that might be like why is it a button? Why isn't it this like other form factor that I thought of that's actually like a way better solution to this space, you know. And so like either you end up with like a PRD that is so vague in specifications that someone reading it doesn't really know what it is, or you end up with something that's too prescriptive on top of it, like almost always being out of date. And so I generally recommend it's really important to have anchoring Strategy docs for Q1, Q2, H1, H2, 2024, so on and so forth. But then beyond that, I think that designs should be the source of truth that everyone is going off of.

I love that. I think you just gave me permission to try that for my next product.

I highly recommend.

Cool. So where can people find you online, Mika?

I'm on Twitter Ihikapur. It's like my first name, last name put together and I'm on LinkedIn as well but I'm definitely more active on Twitter and I have been trying to spend as much time as possible like engaging with user feedback and so to the extent that you've tried out the product and have thoughts either about Figma slides or anything else in our product suite like I would genuinely love to hear from you. DMs are open.

Awesome. I think you should build a zero to one product next where it's like Figma specs so like I don't have to write specs anymore in Google Docs because no one looks on my specs. You just look at the design anyway so what's the point? Yeah, but yeah, cool. All right. Thanks so much Mika.

Thanks Peter. See you. Bye.