What it’s really like to be a product manager at Meta

I’m Naomi Gleit, and I’m the Head of Product at Meta. I’m responsible for leading a lot of work across several teams, all in support of foundational products that cross all of the different Meta apps.

How my career started at Meta

My past self would never have imagined that my future self would be where I am today. I kind of fell into my job, but at the same time, I had a lot of conviction about it.

I went to Stanford University, where I studied Science, Technology, and Society. It was a totally new major at that time. There were similar programs at other colleges, but it was more of an anthropology or sociology of how technology evolves and how it changes the way people interact. For example, how did the printing press impact how communication works? It was something I found incredibly fascinating.

At that time in 2005, Facebook had just come to Stanford campus. Facebook was only a very small website that only a few colleges had. It's hard to imagine now that there are 3 billion people who use our services.

Back in the day, it was only a couple of colleges, and I was one of the first people to use it. I was really interested in it as a college student. It was basically the digital version of the physical Facebook, where they used to pass out a booklet or a pamphlet with all the photos of the people in your year.

So the website was just a name and a profile picture, but people were obsessed with it, including me. And I was also obsessed with it from an academic perspective. I just had a conviction that this was going to be really important.

At that time, there was something called Club Nexus, which was sort of like an early Facebook that was specific to Stanford. My thesis was evaluating why I thought Club Nexus wouldn’t be successful, and why Facebook would be successful.

That wasn’t a given at that time. There were sites like MySpace and Friendster, and it just wasn't clear if this whole social media or social networking thing was really going to take off.

Through the process of writing that thesis, I knew that I wanted to work there. When I graduated, I actually got a job offer from both LinkedIn and Facebook, and I chose Facebook. And I guess the rest is history. Here I am, 17 years later.

Bridging foundational products across Meta’s apps

When I first joined Meta, there was only one product. It was www.thefacebook.com. Over time, our products and services expanded, and we now have Facebook, Instagram, Messenger, and WhatsApp. We also have a lot of investments in Reality Labs around augmented and virtual reality.

Instead of reinventing the wheel every single time to build systems around growth, safety and security, social impact tools, and monetization services, we try to centralize those solutions or foundations so that we can help all of these apps and devices, rather than having them start from scratch each time.

A great example is that we’re currently working on charitable giving tools that we built in Facebook. We thought it’d be great if you could donate to charities on Instagram as well, so we’d build that product and have it be supported by Facebook and Instagram.

The decision to build for infrastructure across different apps in different brands came post-acquisition. Previously, we were all building on Facebook, and the whole company worked at Facebook.

There were only 13 people working at Instagram when we acquired it in 2008, and they had a lot of the same challenges that we had in building Facebook. With 13 people, they were not able to support the infrastructure required for the user base, which was rapidly growing.

So we realized, Hey, this is a great thing that we can help Instagram with. If we’re building an advertising system that works on Facebook, how can we serve the best personalized ads on Instagram as well?

So as the portfolio expanded, we realized that we could get a lot of economies of scale and best-in-class expertise by having the central teams. So if you think about the apps as verticals, I’d think about the teams that I work on as horizontals that work across the verticals.

Pivoting to mobile: The birth of Facebook Messenger

There have definitely been a lot of low points and a lot of high points here at Meta. In general, what I’ve learned is that it’s never as bad as it seems, and it’s also never as good as it seems either. So I've tried to modulate a little bit and not over-rotate in either direction.

When we first launched News Feed, there was such a revolt and backlash from people using the site at that time that we had to put security guards in front of the office because there were protesters outside. It's funny now, but there have been a lot of lows. This isn’t the first hard thing that we've had to do.

One of the other hard times was the shift to mobile. And I think it's well-documented that we were pretty late on that. We were really focused on web development, and www.the facebook.com became facebook.com.

We were adding new features; it was originally a profile picture and the name, and then we added photos, groups, events, and the ability to write on people's walls.

One of the other things we did was add a messaging system so you could message other people on the site. Most people don't remember this, but it was a web first, almost like an email client, and looked slightly like Outlook. You could message your friend, add an attachment, and include an image.

And also around that time in 2012-2013, there was this huge shift to mobile. But we were still building for college students who were at their computers all day.

And the infamous story is that Mark Zuckerberg said, “Guys, this trend is happening and we’re behind. We don't even have a mobile app or a mobile experience. I'm not going to talk to anybody who brings in a prototype that's based on web. It has to be based on mobile.”

So the lore is that he kicked people out of his room if they were coming in with web prototypes and web mocks instead of mobile prototypes and mobile mocks. That just gives you a sense of how we really had to pivot. All of a sudden, the mobile team, which was previously a very small team, became the whole company.

All of a sudden, everyone had a phone in their pocket and was texting. I was using iMessage at the time, and that was really easy and simple. It was one function, one icon on your home screen, you clicked on it, and you texted someone. And because they also had a phone in their pocket, they responded immediately.

It’s very different than email, which is a 24-hour response time. With iMessage, you’re not adding attachments or trying to include all kinds of rich media. You’re just saying, “Hey, you here?” and someone will respond. We have to take that product and make it a mobile-first, SMS-type, mobile-to-mobile messaging system.

We’d gone down this road of something more interoperable across email, and now we had to now convert into this single-use mobile-to-mobile, very responsive product, and that required a lockdown.

We took the team and went into a room and said, “How can we completely reimagine this?” And we built what was called Messenger 3.0. Messenger 1.0 and Messenger 2.0 were really web focused, and here for the first time, we were building this app.

We did face a really important challenge. It was a messaging system that was inside the Facebook app, and as I mentioned, there are so many different features and functionalities of the app. If I went on there, I could have 10 notifications, where one is maybe a message response. And I wouldn't see it because there was just so much going on in the Facebook app.

In order to have a truly great mobile-to-mobile experience, we had to have a single use case there that we did really well. That led to the creation of the Messenger App, and today we know this as Facebook Messenger.

But the process of getting millions of people to download a separate app that was only focused on Messenger? Talk about backlash. All of a sudden, everyone's messages on Facebook were in a different application. But we felt like this was necessary in order to make it a great messaging system, rather than it being one of 10 things you could do in a much more fully featured Facebook app.

So during that time, there was a lot of user feedback. ‘We don't want to download this new app. Why are my messages no longer here?’ I would say though, with hindsight, that has significantly increased the utility and adoption of Facebook messaging in general.

One of the hardest things is that oftentimes when you're trying to do a pivot, you don’t just need to pivot the team, sometimes you need to change the team. And obviously, that’s very difficult. The skill set that we might need for building a mobile messaging product might be different than the skills we need for building a web-based email client.

The other thing is that criticism is really, really important and good. So obviously, we want to listen to user feedback.

I’d separate criticism into two buckets. There's feedback that’s given in good faith and feedback that's given in bad faith. It's really important to be able to isolate the feedback given in good faith, that people are really trying to improve the product, highlight things that we're not seeing, and contribute to the product development process, versus people that just aren’t going to like it no matter what.

It’s about separating out the signal from the noise. What should we really respond to? How we need to adapt and evolve based on feedback is also a hard skill when it just seems like blanket criticism. But we've done a lot of hard things.

I talked earlier about launching News Feed. I think if we were to take away News Feed today, there might be protests outside because this is a feature that people really want. And similarly, we have hundreds of millions of people using Facebook Messenger today. I think if we were to potentially kill that app or move it back into the Facebook app, that would also be very upsetting.

So it’s all about prioritizing and categorizing the feedback.

The data and product-driven development cycle

As a product manager, I remember the early days of growth. We asked ourselves, “What do we think people are going to want?” We went in a room and brainstormed, and it was the throwing spaghetti at the wall period of my product management career.

Back in the day, we were college students building a product for college students, so in some ways that worked. It was like, “This is a feature I’d like on Facebook. I'd like to be able to upload photo albums, and I'd like to be able to comment on and like other people's photos.”

But as we've grown, there are so many different people that use our products now, and we have many different products. I remember the first time that my grandma got on Facebook; she’s a totally different person who’s using our apps for many different reasons.

So it's really important that we look at how people are using our products and learn from that. And that's what I’d call a data-driven, product-driven development cycle. That's what I think our approach has been, and that’s what I think has made us very successful.

When I say data-driven, I don't just mean quantitative data. Yes, we should be logging things. Everything's a funnel, so how many people are coming in? How many people are coming out? What are they doing when they're on the website? But also it’s about qualitative data: looking at people's comments, having focus groups, and doing user research. All of this is so important.

Sometimes I go around saying, “Why guess when you can know?” A lot of times, the answers are already there.

Another thing I like to point out is that when we do this understanding process and we look at the data, the future is already here, it's just not evenly distributed.

There are often times when products are taking off in certain countries, different communities, or other demographics, and we can really look at how that’s working. What are teens doing these days? Or what's happening with Line or KakaoTalk in some of the Asian countries?

It's just not evenly distributed, so there's a lot we can learn from what we see in terms of adoption and usage of our products, but also in the industry in general.

Promoting diversity in Meta’s product management

We build products for the diversity of 3 billion people. In order to do that well, our team needs to reflect the diversity of the people who are using our products. So that's why it's critical that teams are diverse.

One way that we’ve pioneered this data-driven, product-driven development cycle is that it's not just product managers or engineers. We have a very cross-functional circle of people that all contribute to building products. That includes PMs, engineers, designers, data analysts, local people in the region, and researchers.

It takes a very cross-functional team to build something.

I think there's this misconception that it’s just engineers that are creating things. No, it's a huge group of legal, policy, comms, etc.

Sometimes when I talk about being a PM, I talk about being the conductor of an orchestra. There are so many different musicians in your orchestra that are playing so many different instruments, and what you need to do is get them to play together beautifully.

The other thing that I'm personally focused on is the community of women in product. It's a small community, and I really want it to be bigger. We've had women who’ve been in our product program, and they've actually gone on to be CEOs of other companies. I think that's great, but I’d also like our group of women at Meta to be larger and also take huge roles here.

I think the most important thing that we're doing in order to improve this is just getting out there. I think it's really important to be involved in the women in product community, and also show that I'm a female Head of Product.

I look pretty different from other product managers just by the fact that I’m a woman. I’m also not technical. I don't have a technical computer science or engineering degree, and yet, I'm still able to run the product management function or be the leader of that function at Meta.

It’s really important to show other people that you can be in product and be a woman, and also be non-technical.

How I took the leap from marketer to product manager

The first Facebook office was actually above a Chinese restaurant. Everybody was in one room, Mark was still coding, and I was one of the few people not committing code on my computer. And then we moved right across the street to a larger office that had two floors.

On the top floor was the business side of the house, where the people like me worked. I’d originally interviewed to be Sean Parker's personal assistant, and then I ended up working in marketing. Marketing, finance, legal, policy, and comms were all the people on the top floor, and on the bottom floor were all of the engineers.

I really wanted to be a product manager. I don’t think I even knew what it was. But I wanted to move from the third floor to the second floor because that's how I felt I could be closer to building products. I was really excited about what they were doing. I knew I couldn't code myself, so I thought, How can I be a conductor in the orchestra of people that are building these products?

So what I would do is go downstairs every day and see if they were working on anything that I could help with.

One of the first projects that I worked on was helping to allow high school students on Meta. At the time, you had to have .edu college email address.

A lot of really fundamental decisions were made. We decided not to create a separate site called Facebook High. We were going to have one Facebook network, and everyone was going to be connected on that network. We could have had Facebook College, Facebook High School, Facebook Germany, and Facebook Teens. But we decided, no, this is going to be one global network.

So I started helping out with that, and over time, I started helping out with other projects. As I mentioned, we were college students building a college site, so we didn't have a new user experience. I learned how to use Facebook by looking at the person sitting next to me on their laptop.

I worked on building a new user experience. For example, step one, upload your profile picture, step two, connect with people that you know. These are things my grandma didn't intuitively know how to do when she joined Facebook.

So just by virtue of adding value and helping out informally, I formally applied to be a product manager.

I remember the day that I actually got the job. I walked down from the top floor to the bottom floor with a box of all my stuff: my laptop, my keyboard, and my notebooks. And when I came down, Boz, who's actually our CTO, was leading the entire floor of engineers in a standing ovation. I started to cry. It was so amazing, and it was an opportunity to prove that PMs can add value.

This also wasn't necessarily a given back in the day. Sometimes you had engineers who said “What are you doing here? Why are you slowing me down? Are you creating process? You don't code, so what value are you adding?” So it was incredible that I could personally contribute and add value as a product manager.

Back then, I think I was one of the first product managers, Now, we have almost 2,000 product managers at Meta who are adding a tonne of value. And I’ve now taken the role of being able to be the spiritual grower for this function because I believe in it and care about it so much.

Essential skills to be a successful product manager

There are a few skills that I look for today when hiring product managers, and what I see in the best PMS.

One is someone who wants to do what's best for the company. We're often in the position of having to negotiate between a lot of different teams and local incentives, so we do a lot of the cross-functional work. And so your north star really has to be doing what's best for Meta and best for the bigger picture.

The second thing is simplifiers. I’ve noticed that this is a very rare skill among people. I think PMs have an opportunity to come into a really complex situation and break it down in a way that everybody can understand.

Sometimes I'm not on the same page as an engineer who really understands all of the details. In order to communicate across different functions and different teams, we need to be able to communicate clearly and simply.

I think there's a lot of power in being willing to do whatever it takes. Sometimes we look down on some of the execution work that we do, whether that's project management, program management, setting up meetings, or following up on tasks. In contrast, I think there's a lot of power and leverage in being able to do that.

I believe in perfect execution because if you don't perfectly execute the strategy, you don't know if it was right or wrong.

PMs are responsible for perfect execution, and sometimes that means you're doing some of the busy work. You're making the PowerPoint decks, you’re scheduling the meetings, and chasing down tasks. And I know that sometimes it doesn't seem like that big, broader, visionary product strategy work, but I’d say it's equally important.

Another thing that I’ve seen is low ego. In terms of teams, you work with a whole cast of characters. Some people are easy and some people are difficult, so being the conductor of an orchestra is really, really tough.

As the conductor, you're not the star of the show. It's not about you as the product manager. I think sometimes people think, I want to be the PM. I can be the face of everything so I can be like the CEO. You’re only successful if your team is successful. When the orchestra is playing beautiful music, that's when you're successful, not if the spotlight’s on you.

Scaling impact through team building

The biggest lesson I’ve learned in my career was when I made the transition from an individual contributor to a manager. If I really zoomed out and asked myself what the most leveraged, most impactful thing is that I can do to help the company, it's not by doing everything myself. That’s capped. There's a ceiling there. I'm just one person.

For seven years, I was the only PM on growth. And when I talk about growth, I'm talking about removing barriers that are preventing people from joining. I talked about allowing high school students, and then we allowed anyone with an email address like my grandma.

We've also worked on projects like translating the site into different languages so people who don't speak English can use Meta.

Not everyone has an iPhone. Sometimes people are using lower-end devices and feature phones. They're not always on high-speed internet, so how do we develop experiences for those people?

Sometimes people can't afford a data plan, so how do we make access to Facebook free? These are the kinds of things that I was thinking about as the only PM on growth. That's a lot of stuff to think about.

It came from me being a single point of failure, almost. In some ways, I was probably being a bit territorial: I get to product manage that, and I'm the only growth PM. As I said, now we have 2,000 PMS working at Meta, and it really took time for me to realize that the best thing that I can do to help growth and help the company is to build an incredible team of people.

And there might actually be someone who can work on various aspects way better than I can. For example, let's hire a person who lives in India that uses feature phones every day and can see the pain points that people are having around using them.

So it took me a while to really accept and realize that in order to scale, I needed to hire an amazing team, and that was the best way I could contribute a lot.

These days, a lot of the work that I do is managing managers and making them successful. I still have a few projects that I'm deeply involved in, but I'm finding that helping the leaders that I have in place with the 5% of things that they need help with is really the most important thing I can do, rather than doing 100% myself.