#15: How Facebook does Product Management
If you rank top social networks by number of monthly active users (in billions), Meta takes the cake with Facebook, WhatsApp and Instagram:
Facebook (2.9) > YouTube (2.5) > WhatsApp (2) > Instagram (1.4)
While many teams and individuals have contributed to the success (so far) of these companies that are part of Meta, today I want to capture how unique Product Management is at Facebook. Unique because it goes against or not aligned to well-established product management practices, but still quite effective.
Before we dive into product culture, here’s a cool story on Facebook’s famous metric:
“7 friends in 10 days”
When Facebook reached 45 Million users and their competitor (MySpace) was at 115 Million users, Chamath Palihapitiya (then VP - User Growth @ Facebook) and his team figured out a magic metric. In his own words:
After all the testing, all the iterating, all of this stuff, you know what the single biggest thing we realized? Get any individual to seven friends in 10 days. That was it. You want a keystone? That was our keystone. There's not much more complexity than that.
Except that it wasn’t magic.
The reasoning behind such metrics is cause and effect hypothesis. If you do more of X, then more of Y happens. Facebook observed from their data that users who added 7 friends in 10 days were more engaged with the product than those who did not.
So, the team made it their goal to get as many people to add 7 friends in 10 days. But to be honest it could have been “add 4 friends in 5 days” or something else - it doesn’t matter as long as you have some idea of cause and effect. But having such metrics is great to rally the team together towards a goal.
Then, the next step is often to test your hypothesis “Does X lead to Y or not?”
Now alternatively if the Facebook team found that getting people to add 7 friends in 10 days leads to engagement (hypothesis validated) but the engagement is short-lived and dies in a couple of weeks - because adding random friends (almost strangers?) leads to trash content on user feed, the goal could be changed. A new hypothesis could be formed then: “Get users to add 7 known friends or family members in 10 days”
Now let’s get back to the theme of today’s newsletter.. ..the product culture.
Nothing at Facebook is someone else’s problem
..pretty much defines product management culture at Facebook. This is also why product teams own the problem and the outcome expected.
As a Product Manager you are not ALWAYS expected to do project management, create gantt charts, JIRA tasks and so on. Because the aim is to get best outcomes for the team and not to tick these checklists or end up in a mindset of “Hey, I am doing my job but the engineers/designers are not”.
Same goes for engineers and designers.
Engineers are not ALWAYS only expected to execute JIRA tasks, write code and manage production support. Lastly, designers are not only expected to come up with visuals/wireframes.
If the team is struggling with an outcome, the whole team joins hands in a trifecta. An engineer could come in and fully take up responsibility of executing on product roadmap while the PM hence gets time to resolve inter-team issues on prioritization. Designer could come in and manage the execution plan while the engineers figure out the production issues. In the end, if the team outcome is achieved (and on right track) - it actually didn’t matter much who did what.
While all product team members can help out / get involved on both product discovery and delivery, of-course there are clear expectations from each role in a trifecta similar to definition of an empowered product team by Marty Cagan:
Value and Viability is with PMs
Feasibility is with Engineers
Usability is with Designers