#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
That is why the focus of a PM @ Facebook is much more on “Which outcome to target and Why (Vision and Strategy)” and “how to move towards achieving the outcome (Execution)” rather than wondering “What does my leadership wants from me” and “How do I achieve it to make them happy”
So, here are three non-obvious and unique aspects about product teams at Facebook:
#1 : PMs define strategy, not the leadership
…and it makes PM position all the more special. PMs @ Facebook are expected to define Vision of the area they own, explain Why it’s the right vision, How it connects to user needs and How it aligns with business needs.
The next thing is forming partnerships within the organization to drive outcomes. It is tough to achieve your area’s milestones without support/help from other teams. Hence, a lot of time goes into understanding other team’s goals and creating strategies on how a strategy could be win-win for both.
This is unique because in most organizations Strategy is created at management level and then handed over to product teams to execute.
This is not to say that PMs do not have any role to play in Execution. But execution is headless without a good strategy. When it comes to execution, PMs focus on prioritization and process management. But the unique aspect about execution is that it is a team game and hence PMs collaborate with engineers and designers. This brings us to the next point.
#2 Engineers (also) drive outcomes
A typical engineer’s performance evaluation criteria would be something similar to “daily active users should increase by X%”. So as an engineer, would you want your team (including the PM) to spend time on best way to achieve that outcome? or would you want your team to be all heads-down in execution? Mostly, it would be former.
But how can an engineer help the team achieve this outcome? They may have different choices:
Engineer could participate on product decisions
Engineers could free up Product Manager’s bandwidth so that he/she is fully dedicated to find strategies to achieve the outcome
Engineers, Designer and PM could collaborate on how to own parts of “Roadmap” “Project Management” or “Stakeholder Management”
Number 3 is most important to understand. Rather than black and white view like “PM should own the roadmap” or “Engineers should own execution” (and while broadly some structure is followed) … Facebook Product Teams together collaborate to see which task can each of the team members own so that the best outcome is achieved for the team.
Engineers @ Facebook are known to do execution management towards milestone once the roadmap has been prioritized together with PMs. This is why PMs @ Facebook rarely end up creating stories/tasks:
#3 Right questions help discover the best metrics
Now that Meta has become a (too big for itself) social media network, it also comes with downsides. And first time in history, Facebook (and in general Meta) has big questions to answer:
The good thing about knowing the big questions is that it helps you align your vision and goals to solve them. For example, if you were the PM responsible for decreasing fake accounts on Facebook, you wouldn’t be able to make an impact unless first you define how to measure it.
So if we go further into this example, the fake accounts can be detected at three stages:
Before user signs up - fake account is detected
Face account is detected as soon as user signs up
Fake account is detected when user is already on Facebook
So given above, how do you, as a PM, decide “number of active fake accounts on facebook?”
#1 may not be included in your metric since these users never end up signing up and are blocked even before they create an account
#2 may not be included as well since these accounts were never active and were taken down so early. Maybe these “taken down early” can be tracked separately.
#3 is included in active fake accounts on facebook
On top of #3 you need to account for false positives (accounts falsely detected as fake) and false negatives (accounts that are fake but detected as not fake) and some % of other errors possible.
If you want to read more about hard questions and how facebook measures them, this is a good read.
You can email on ProductifyLabs@gmail.com for any comments, thoughts, ideas for case studies or collaborations.
Thanks for reading 🚀 Productify by Bandan! Subscribe for free to receive new posts and support my work.