Interview with Badrul Farooqi, First PM at Figma

This interview is part of a series revealing the stories of early employees from the most successful tech companies of the past few years. You’ll walk away having learned about what these individuals experienced, what they wish they knew, and the advice they’d give to others joining high-growth startups. Key takeaways are at the top and you can find the full interview below.

This interview is with Badrul Farooqi, the first Product Manager (and 18th employee) at Figma. He spent nearly 5 years at the company and worked on the two largest customer-facing products at Figma: the core design tool and Figma Community. Figma now has over 750 employees and is valued at $10B and Badrul spends his time as an active angel investor. 

Note: If you’re looking for an all-in-one solution to manage your personal finances, Compound can help. We can help you diversify concentrated stock positions, optimize company equity, plan asset allocation, and more. Sign up here and we’ll be in touch. 

Key Takeaways

• On the benefits of being an internal transfer PM – “That’s an advantage of becoming a PM through internal transfer rather than a brand new PM in a new company. Trust takes time to build and there's no way to speed track that. I had that. I earned that from working with them for two years prior.”
• On how he talked to customers – “I talked to customers in my Twitter DMs. I talked to them over email. I talked to them when they wrote into support. I would talk to them in person – I would go to their office or invite them to ours. Different customers resonate with different things and some of them respond better to different things...”
• On learning about customer problems – “There's a ton of market research that I was doing, trying to stay ahead of the customers. You have to understand the problem incredibly well so you can try to do something unique, rather than simply copy from another tool.”
• On knowing when the product worked – “2018 is when the most discerning customers started using our product. If they were on board, great… Once I knew we could satisfy the most demanding customers in 2018, I finally realized this was probably gonna work.”
• On being customer-focused – “I was constantly building out features that displayed that Figma could be as good if not even better as a fundamental experience [for customers] than the product they're using today…. I would ask designers: on a day to day basis, are you very happy? Is this helping you move faster? That was the only thing on my mind. Eventually there was a sentiment change. After building the right features, designers started trusting that we had actually built something insanely complex and demanding on the web.”
• On being emotionally committed to your work – “One of the most challenging things for people joining early stage companies is that if you get too caught up with the financial outcome, you'll end up burning out much sooner – oftentimes too fast to capture the financial outcome that you thought you wanted. Startups require some amount of emotional commitment to the work you're doing and the company that you're trying to build. This sustains you through the highs and also the lows that are part of the startup experience.”

How did you discover Figma? What made you decide to work there?

I joined Figma in the summer of 2016. I joined Figma for two reasons: to work in a true startup environment and to have the opportunity to be a Product Manager. 

Before I joined Figma, I worked at a company called Teespring. While I enjoyed my time there, Teespring was quite a large startup. I was looking for a more traditional startup experience – a small team where we worked hard together on the same problem towards an unknown future. 

While I was at Teespring, I’d been a QA [Quality Assurance] engineer. I thought the skillset I learned would translate well to being a PM and wanted a role with a higher level of ambiguity, some level of problem discovery, and the challenge of actually crafting something from scratch (working with a whole host of people along the way). 

I started my job search by looking at Y Combinator and other venture capital firms talent portals. I actually discovered Figma through Greylock and things moved quickly from there. I got in touch with the recruiter, met the team, and joined them just a few weeks later. 

What was it like being the first product manager at Figma?

So I actually joined as a QA engineer. When I joined, I told Dylan (the CEO), “Hey, I’m happy to join as a QA engineer. But my career ambition is to become a Product Manager.” Dylan didn't make any promises – he just said, “Yeah, sounds good, let's see how it goes.”

I was the 18th employee and at the beginning the team consisted of a lot of software engineers, a few designers, one marketer, and one multifaceted HR/office manager. That was the whole team. 

At the beginning, I had a few roles. First, I was a QA engineer for the whole product. I had to learn a design tool, which is not trivial for someone who's not a designer. Second, I became the customer support person. Everyone at Figma always did customer support–they're a very customer focused company. But there's always some baseline support requests and I ran all of that. Finally, I did all of the backlog planning for non-product work. At the time, the products in flight were a very large rewrite of the front end and the first version of the multiplayer server that gave Figma notoriety. 

The work I did when I joined was, in many ways, similar to the PM work that I did after I officially became a PM – talking to customers, making sure that work is organized, and making sure the product was high quality. 

How did you transition from a QA Engineer to a Product Manager?

First, I was hired to do a job (QA Engineer) and if I wanted to transition to being a Product Manager I knew I needed someone to cover the work that I did. And second, if I did make the switch to be a PM, I’d need to make sure there was enough work for me to do. 

On the QA side, all the companies I previously worked at wanted to have a QA team that scaled with multiple people. But my goal when I joined Figma was to scale out testing into the engineering org so that we didn’t have to hire a large team of QA engineers. I worked closely with the VP of Engineering to make sure that teams were building the right internal tools so that they could own quality end-to-end. Then we wouldn’t need a big QA function. 

On the product side, we didn’t need dedicated PMs for a long time. Figma is unique in this respect. There are so many design tools in the world that before you can differentiate, you need to build a set of baseline functionality (things like border, pen tools, etc.). Because of this, the engineers and designers were incredibly empowered to build features without a PM just based on customer feedback. There wasn’t a big need for pure problem discovery. 

Eventually the team and company grew and I started doing more product work. The formal transition from QA engineer to Product Manager happened in the middle of 2018, about a year and a half after I started. By the time I made the switch, it was more of a formality rather than a large change overnight. 

At the same time, we were maturing as a company. When you’re larger and you have multiple teams, you need to staff them appropriately so that they can ship products start to finish. After I became a PM, I had dedicated designers and engineers on my team and we did things like bespoke marketing launches for every feature. 

What advice would you give to someone joining as an early PM? 

For me, it came from this endless amount of trying to learn as much as I possibly could. One of the things that I learned first as a PM was that this product was insanely complicated, both from a design standpoint and an engineering standpoint. 

I actually started my time there reading customer service reports which set the tone for what I had to do going forward. It was a very specific kind of focus on what customers need and their problems and learning about those problems in detail. I would look for new things that they would complain about for features that I had never used before in my life, but they were missing from other design tools. 

There's a ton of market research that I was doing, trying to stay ahead of the customers. You have to understand the problem so well that you can even try to do something unique, rather than just copy and paste from another tool. And that's a level of learning that I had to do. 

In my free time, I spent a lot of my time trying to learn how to use Figma and a lot of the other alternatives, just so I can keep up to date. I wanted to meaningful contribute to the engineering and design teams as a strong PM. I also wanted to show I was not above doing any other kind of work, just because I suddenly had some kind of title. If it involved responding to customers or dealing with the backlog of filing bugs, I was open to it. I did just about everything to make sure my team's engineering, product and design teams were able to move as fast as they could. I made sure they were doing the things that they're uniquely gifted at doing, which is either building or designing software. 

The other thing that I had an advantage of when I became a “formal” PM was that these were the same people I worked with for two years. I had a very good relationship with them and I had their trust. That’s an advantage of becoming a PM through internal transfer rather than a brand new PM in a new company. Trust takes time to build and there's no way to speed track that. I had that. I earned that from working with them for two years prior. 

The advice I’d give is that as a Product Manager, you succeed based on your understanding of the problems you're trying to solve with your product and the successful relationships you have with your product team. This means that they respect that you can meaningfully contribute a depth of understanding that they themselves do not have time to do. It's not because they can't, it's just because they're focused on programming or designing. You're going to say, “Here's this problem, it's more important than we think. I know it’s more important from this feedback and these data points.” You can make a compelling reason why they should focus on this kind of work and why this work is meaningful. For the healthiest product teams, they're very empowered. They might even be able to do all of that on their own. But they simply trust you to do it because you've shown that your judgment is good and that you're willing to do the work. They trust your decisions on roadmap items, so that they can focus on engineering, designing, etc. 

Those are the two things I spent almost all my time doing. Talking to customers and becoming as smart as I can about the problem they're facing, what the alternatives are, and in broad strokes, what our solution could look like. And then presenting that to the product design team as the direction we're going and why it’s the right direction. That is the only thing that matters at startups. In larger companies PM work becomes much more complex. But those are the only two things that I think I would advise for early-stage startup PMs to focus on. 

How did you find the best way to talk to customers?

It varied. I would talk to customers in my Twitter DMs. I talked to them in email. I talked to them when they wrote into support. I would talk to them in person – I would go to their office or invite them to ours. Different customers resonate with different things and some of them respond better to different mediums. 

Sometimes you find someone who's willing to give you a lot of time to actually help you understand what's wrong with your product. Those customers are the best because they aren't happy, but they're very productive partners to co-design with or early product access to in order to receive feedback. 

I pretty much worked with customers in every single capacity. I was talking to them all the time. I went from knowing one designer before I joined Figma to knowing just a huge number of designers across the industry because I would talk to so many of them in so many different capacities. It was pretty much what I did all the time – find new designers to talk to you about problems.

Was there a moment when you knew Figma was going to work?

It was sometime in 2018. We kept recruiting great people which was always a great sign. These people were extremely good at what they did. That always made me feel good. 

The other sign was when some of these tough-to-satisfy customers started to use Figma. These were people who were extremely good at their craft (and also skeptical that our tool could be good enough for them). They were on teams from places like Square, Airbnb and Stripe. Once some of these people started converting, it was no longer “almost there”. We were there. These were the best design companies that I knew of – that pushed the needle with their craft with experiences on the web and mobile – and they started saying it’s good enough. 

2018 is when the most discerning customers started using our product. If they were on board, great. There were other things that were still on my mind – I'm happy we made an enterprise product – but those other things are less about the core product working and more about the amount of security and monitoring that's necessary at scale. Once I knew we could satisfy the most demanding customers in in 2018, I finally realized this was probably gonna work.

What was the biggest challenge Figma had to overcome?

For quite some time, people were skeptical that the product could be good enough. Every single customer was already a designer. It's not like they weren't doing their design work before our tool. They were already building great products. They were just using other tools. 

These tools are kind of an emotional experience for designers. They identify with their tool very closely. They use it for four to eight hours a day. Now there's a new tool. And it's a totally different paradigm than what they've experienced coming from Photoshop, Fireworks, Sketch or Adobe XD. They're all fundamentally native apps. It’s hard to trust a web-based design tool that can even live up to your existing experience on a native app.

I was constantly building out features that displayed that Figma could be as good if not even better as a fundamental experience then the product they're using today. This is what I was focused on. I would ask designers: on a day to day basis, are you very happy? Is this helping you move faster? That was the only thing on my mind. 

Eventually there was a sentiment change. After building the right features, designers started trusting that we had actually built something insanely complex and demanding on the web. 

How did Figma develop a high degree of trust among team members?

Everyone there – across all teams – was incredibly transparent and very open to feedback. You always knew, at any point, what everyone’s working on. You could give feedback across teams and they would take it. You also have to respond to feedback, take it seriously and not dismiss your teammates’ feedback. That made it so that everyone felt comfortable sharing work. Because feedback was given in good faith, people took it very seriously. 

If you wanted to dive deep on another team's work the communication patterns were open. I don’t think there was ever a secret project at Figma – everyone was out in the open. Design crits were open to anyone who wanted to go, it wasn’t only for designers. 

Product Managers were not authoritarians. We were on the same sphere as engineers and designers. The culture at Figma facilitates the best ideas to emerge, rather than ensuring that Product Managers have some kind of overt authority. That's what works – I give feedback on design and they give me feedback on my product plan. If they felt it was important to give me feedback, then I should take it seriously. 

What is the best advice you would give to an early employee that’s different from advice you’d give to a founder?

You need to know the ambition of the founders you’re working for. What are their actual goals? What are their ambitions with this company? From day one, Dylan [Field] never changed his opinion. He wanted to build a well loved product with a large business. There was only one outcome he was hoping for, which was to be a public company and be the next best design company. There was never any other goal he was interested in. 

The detail behind that is that every single thing we did was long-term oriented to achieve that goal. The kinds of hires he made, the kinds of product plans – it all was focused on the goal. Much of the challenge at early stages is that there are no metrics. But you would make good strategic bets. Dylan would commit to doing something for a long enough time such that you could actually determine if it was working or not. So the first question I would ask is, “What are the founders goals?” and “Do you believe them?”

The second thing I would look for is the quality of the team. I was super happy with everyone. The engineering teams were incredibly good. The Director of Engineering, the VP of Engineering – everyone they hired was great. At a minimum, I was excited to work and learn from these other people as a baseline to have a good career, regardless of the financial outcome. 

Lastly, you're just gonna be thinking about the startup all day, every day for as many years as you stay there. It can consume your mental space, even if you're not there. It's such a small team and there's so much emotional investment. You have to be interested in your work in some capacity. 

One of the most challenging things for people joining early stage companies is that if you get too caught up with the financial outcome, you'll end up burning out much sooner – oftentimes too fast to capture the financial outcome that you thought you wanted. Startups require some amount of emotional commitment to the work you're doing and the company that you're trying to build. This helps sustain you through the highs and also the lows that are part of the startup experience. 

And there are lows at a startup. It could be that company is struggling; it could be that you didn’t get the job you wanted. The only thing that gets you through it is some emotional commitment that you still care about the work. It's not just the paycheck. 

Is there anything you would’ve done differently?

I would’ve asked for help more. I wish I was more candid about moments where I was not satisfied with how things were going. In general, people produce their best work when they're happy. If you're going through challenges, there's support that you can find in a good team so you can get through whatever challenge you're going through. Then you can start producing good work again because you're recommitted. 

One of the things I tried to do was be a hero. If I would’ve asked for help, I could have learned faster and produced better work. I could have solved more problems.

Did you ever consider leaving Figma earlier?

I always asked myself: how different is the next year gonna be than the previous year? Every year I was there, it was so different so I decided to stay. Even in 2018, we were going to launch the enterprise tier and I wanted to see what would happen. 

I also had the luxury of working on multiple different products every year or year and a half. I worked on the editor. Then I worked on plugins, which is a very different product. Then I worked on community and had no idea how it was going to go, but I wanted to figure out it. By the time I left, I'd shipped multiple brand new products.

In my time at Figma I gained the skills to level up as a product leader. I needed a different environment to continue growing. The skills you need as a PM at a small company compared to a large company are very different. By the time I left Figma, we were so mature. We had a user research team, a data science team, a sales team, a sales ops team, a marketing team, and a large product team. A lot of the problems that I was solving early on were no longer problems I had to worry about. 

Once I learned how to work with these teams, I wanted to experience something different and I didn't think Figma was going to be extremely different going forward for me anymore. Overall I’m pretty grateful now in retrospect for my time at Figma.

‍