The Craft of Multi-Product: How Figma Builds Without Losing Its Edge

How did the idea for FigJam come about? What was the signal that told you it was time to build a second product?

We noticed that people were using Figma design as a whiteboard and brainstorming tool. This was during the pandemic when everyone was working remotely and sick of Zoom happy hours. So people started hanging out in Figma instead. We thought, "Okay, we should capitalize on this," because whenever your users are hacking your product in a fun way, that's really great inspiration.

But even if this was a compelling option for Figma's second product, I knew not to rush to stamp the decision. The next product had to support the business and fit within the company's larger goal. A lot of people see Figma as a design tool where you draw some mocks and build some prototypes, but we know that's not the end goal. The broader goal is to actually get a product built and in users' hands. FigJam was a step toward that process.

What was the debate when deciding whether to carve out a new team to build FigJam, or keep it within the core team?

Internal debates centered on two factors: speed and creative divergence. For speed specifically, we were playing catch up. There were a lot of great players. Speed seemed of the essence. But speed comes at a cost. If you're building quickly, it's difficult to fully grasp how a second product might fit into the bigger picture. The more we create divergence, the more difficult it becomes to unify later on.

Now, as we build our third and fourth products, we have more of a framework. We know we should have a different way of organizing so that there's a team that's thinking about these shared primitives right out of the gate. But back then with FigJam, we were just kind of winging it.

How do you find the "starters" — the people who can get a new product off the ground from nothing?

At Figma, we often talk about "starters," the people who are really great at getting something off the ground — people who can come up with a core idea that you can latch on to. So whether that's in engineering or design or PM, we definitely look for that skill set. We've created an internal forum to give grassroots ideas a platform: Maker Week, a hackathon that gives all employees the chance to pitch new projects. People make everything from software to physical things that express themselves.

So how do you spot those starters? Sometimes it's brute force and hustle and scrappiness. Other times it's the ability to sell the team on an idea. But in my view, starters all tend to share one trait: I think entrepreneurs are slightly irrational. By taking something from nothing and bringing it into existence, they're doing something that people didn't really believe was possible. There's a lot more brute force and selling that needs to happen. New products don't emerge from a rational line of thinking.

Figma Slides came out of Maker Week. How did that happen?

With new products, we always start pretty small. We can do all the reviews that we want, but a working prototype can take an idea from something on paper to something that's actually believable. That was the case for Mihika Kapoor's initiative to get Figma Slides onto the product roadmap — it was just her as a PM, an engineer, and a handful of other team members who she successfully pitched to work on a Maker Week demo. After that initial company-wide presentation, the small team was able to quickly scrap a prototype together so that decision makers could visualize the idea's potential.

We didn't give that green light to Mihika right away. But her small team persisted and she convinced some teams to start using it. And the next thing you know, it proliferated internally. A small prototype or MVP completely changes the game — when you see a surge of everyone wanting it internally, it gives you more conviction that there's something there.

Dev Mode was built for an entirely different persona — developers. How did you approach building for someone so different from your core designer user?

You look at our core product and you'd think that every new product has to create an infinite canvas. That's just table stakes at Figma, right? But it turned out that developers found a blank canvas really hard to navigate. It was important to bring on people who could advocate for that perspective and challenge core assumptions — and through that debate, you build the best product.

For our developer efforts, we found our engineering leader Emil through an acquihire of a team that was thinking about how to translate design into code. So they built their own tool because they didn't think Figma was doing enough. The fact that this company existed meant that Figma as it stood was not doing enough for developers. So they brought in an outsider's perspective, which was really healthy. To build new products, you need to create an environment where people can really feel ownership of their new audience without feeling the burden of legacy.

You talk about storytelling as central to product launches. What does good product launch storytelling look like?

Every good narrative has a little bit of tension. Perhaps no Figma launch story sparked more online chatter than its original product. Dylan wanted to get the design influencers on board, the people in the community whose voice mattered. He gave those influencers a somewhat controversial idea to talk about: everyone could work in a design file at the same time. Now, it's intuitive, but back then it was considered undesirable to have a hovering art director in your file. That your product manager or your CEO is going to be able to see every movement you're making wasn't necessarily welcomed.

Figma's balance of standing for what design should be while creating a little bit of controversy supplied a narrative that influencers and evangelists were excited to talk about. That kind of tension is what makes a story worth telling.

What is the "screenshot test" you use for product storytelling?

Can the product's value be distilled into one single, self-evident screenshot? At Figma, visuals are just as important — if not more important — than words. "What's the one screenshot that's completely self-explanatory?" While I acknowledge this might be a "superficial" way of thinking, distilling the product's story into a single screenshot or gif or tweet helps arrive at something evocative. You need to show something people want. That's a design problem. That's a storytelling problem.

For Dev Mode, we used screenshots to show how developers can have a diff in their designs with a green and red view that they see in code all the time. To be able to see designs with code underneath is really evocative, because now developers will think, "Oh, now you're speaking my language." If you have to explain what's going on, that's an indication that you haven't made the value proposition simple enough.

How do you keep the product simple as Figma adds more products and features?

Simplicity shouldn't be equated with fewer features. It's about mental models. When you look at a really complicated product, you're like, "I'm trying to do this thing. I know it's somewhere, but I have no idea how to get there." Products only get more complex over time. You still need to pass the screenshot test — you can look at it and quickly parse what's going on. The design should tell you what to focus on. The best product managers can push for that.

I have a worldview that not everything has to start from scratch. I'm more optimistic that I can take an existing product and evolve it, or radically change it, or extend it in really interesting ways. The 1 to 10 product journey is a constant balancing act of building for new use cases while preserving simplicity.