This is a guest post from my friend and Meta’s Chief Information Security Officer, Guy Rosen. All of us in work (and life!) must make and escalate decisions. But decisions usually have multiple options to consider with different tradeoffs. Enter Guy’s “traffic light” approach, which uses the colors red, yellow and green to visually represent and evaluate various options.

Thank you, Guy, for teaching us this method, which has improved our decision-making process and continues to drive better outcomes.

The “Traffic Light” Approach to Problem Solving

By Guy Rosen

Any time you want to proceed with a new product idea, figure out a strategy or decide on a feature, you’ll have a lot of questions to answer: Is it worth it? How will it affect people? Should we build it one way, or another way? Do we have the resources, or the time? Should we proceed at all? How well are the choices we made progressing? Should we shut it down?

These questions need to be resolved. But they don’t exist in isolation: they inform and pull against each other. It can be hard to pin down the right questions to ask, to sort through many valuable opinions, and even harder to know what steps to take, or not take, when the answers and outcomes are ambiguous.

I’ve always found lists of “pros and cons” inefficient. There had to be a better way to frame available options and make a decision with other leaders on my team.

Enter the traffic light! It works like this: every decision or potential decision is color-coded on a matrix as red, yellow, or green. This allows you to see a range of possible futures all at once, and make the best call you can, given what you know. It’s a rubric that has been helpful to me in situations spanning personal dilemmas to product decisions to staffing decisions. While the examples here are product-centric, this approach can be applied to any decision, big or small.

There are three steps to building out the matrix.

• Step One: identify the criteria that you care about.
• Step Two: figure out your options based on that criteria; and
• Step Three: build the matrix, and color-code it, so you can make a good decision. Red — negative for the criteria; Yellow — neutral; and Green — positive for the criteria.

So let’s see this in action:

Step One: Identify the criteria that you care about.

Let’s say you have an idea. Some people will think it’s a great idea, others will think it’s a waste of space. The first step is to lay out all the relevant criteria by which you will judge the idea. Do this by framing the criteria as questions, not statements. They should be inclusive and comprehensive about what the teams care about. And you should number them, so they’re easier to refer to.

So, for example:

Step Two: Figure out your options based on that criteria;

The next step is to address the criteria you’ve identified:

And do the same for all the remaining, various other paths you might decide to take.

You might have more than three variable options. But the matrix loses effectiveness if you have to go to Options D, E, F, G. Pick your top three. Four is pushing it. Five is probably too many. Six is definitely too many.

Step Three: Build the matrix

Using three colors: red, yellow and green, you fill in the matrix so all your options are clearer. Feel free to also consider other color palettes that are more accessible to people with colorblindness.

This will give you a decent overview of the various options in front of you, and the paths you might decide to take. Usually, that’s where the most green is, but not always. The point of this system is to guide you to making the right decision for your organization. You still need to use your best, independent judgment to decide what you’re going to do.

What Comes Next

Once the matrix is built, you should summarize the options and provide a recommendation. This is the most important visual that you’ll share with the group and where most of the conversation will focus. Without even knowing the options you can clearly see which have more “green” and which have more “red” and which criteria tend to trade off against each other.

With the recommendation given, the final thing to do is make a decision. If you’ve done all the previous work, this should be the easy part. Check the criteria and make your call. Document your work, press forward, and make things happen.

In the end, decision making is a process, not a one-time thing. Any complex organization staffed by insightful, smart people will have a lot to offer. But just as important as the right input is having in place the right decision making structure that will not only take into account competing ideas, it will filter out the bad ones, filter up the good ones, and produce quality work everytime.

Helpful Tips

Here’s some helpful advice on how to make this system work for you:

• Always number the criteria; this way people can say, without ambiguity: “let’s talk about about Issue #2”
• Always label the options: A, B, C, and so on. This is so they’re easier to refer to, and won’t get confused with the enumerated criteria (1, 2, 3, etc.)
• Be explicit about what the “better” answer is. A higher value may be good for reach, but it’s bad for complexity. Be specific about judging the criteria with reference to your goals.
• Be inclusive. Even if you don’t accept a team’s conclusions, it matters that their criteria was considered. Don’t dismiss criteria out of hand. Put it in the matrix.
• One way to test if you’ve got the right criteria is to ask: “If we had an option that satisfied these criteria, do we all agree we’d move forward?” If the answer is still no, continue the conversation. You have more criteria to consider.
• Among your various options: be sure to give people all the information needed to be informed about a particular pathway. You might need to build a mock, or give a presentation. People should feel informed.

If you have thoughts about this system, or your own decision making system, I’d love to read about it in the comments.

I used to think that being different (not being technical, not looking like everyone in the room, not knowing what I wanted to do) was something that I needed to fix. But what if being different is not only ok, but a good thing? What if it’s wonderful? For those of you who sometimes feel you’re not like the others, I encourage you to embrace it and be different.

My story is that when I was a kid, I remember hearing this song on Sesame Street that played during a game where you had to spot which item among a set of four was the odd one out. It was called “One of These Things” and the lyrics went:

“One of these things is not like the others,

One of these things just doesn’t belong,

Can you tell which thing is not like the others

By the time I finish my song?”

And I remember thinking, as I sat on the floor in front of the TV and watched… It’s me. I’m the thing that’s not like the others.

There are a lot of reasons why I felt like this as a kid and often still do. I’m sure this feeling surfaces in different ways for different people. While I wasn’t discriminated against for the ways that I felt different, many are. For me, I grew up between two cultures, which I’ve written about in this piece titled Fully Both.

But on the professional side, I also sometimes feel like a different pigeon; for a number of reasons, but three in particular:

First, I am not a technical person.

I studied Science, Technology and Society (STS) at Stanford which, despite containing the words “Science” and “Technology,” is not a technical degree. I often use the analogy that STS is like the study of water. As Stanford explains it: scientists, engineers and medical professionals “swim” in the details of their technical work, while STS “draws attention to the water” — the “social, political, legal, economic, and cultural environment that shapes research and invention.”

Much to my parent’s dismay, I was not a scientist, engineer or medical professional. They’d ask me: what was I going to do with this “Bachelor of Arts”? I didn’t know either.

When Facebook first became available at Stanford, I was fascinated by it both as a user and an academic. I wrote my STS thesis paper about Facebook and why I thought it would be successful on campus. I knew I wanted to work there, but in July 2005 the team was almost all engineers. Given I did not have a technical background, what could I do get hired?

After knocking on the door until it creaked open, I worked to become and prove myself as a Product Manager, and now I lead the Product Management function. I know that everyone’s story is different, but if I have one takeaway from mine it is — you don’t have to be technical to have a career in tech, including in Product Management.

Second, I am a woman in tech.

In addition to being a non-technical Product Manager — I am also a woman. When I joined Facebook, there weren’t many women at the company overall, and even fewer on the technical side.

Even today, we still need more representation in technology at Meta and the broader industry. I often find myself in large meetings where I look around and see only a handful of other women, or sometimes there are none. This needs to change. As the Head of Product and also the sponsor of our internal Women employee resource group, championing women in technology is a personal mission. I have had so much support from the amazing people I work with and I am focused on making sure that Meta is a place where women in technology can thrive.

Third, I didn’t always have a “Northstar”

I wrote about finding Your Northstar here as your ideal ultimate destination, basically where you aspire to be in the long-term. But the truth is, I have never had a Northstar. Much like my parents, I had no idea what I was going to do after graduating college with a degree in STS.

The good news is it is totally ok. Sometimes it’s not possible to know what you want to do in the future because it doesn’t exist yet. My former self had no clue that my future career was something I could aspire to. The world is changing quickly and the options for our Northstar are constantly evolving.

Instead, I’ve always been guided by doing things that are impactful, with people I can learn from. This internal compass has led me to where I am today — and it’s been better than I could have imagined.

Many of the career conversations that I have are with people on the verge of a big decision. Usually, that decision is between different job opportunities; whether it’s a new hire engineer deciding which team to join, or someone who wants a change from their current role and is evaluating other options.

In these situations, my first question to them is always the same: “What is your Northstar?”

By “Northstar” I mean: someone’s ideal, ultimate professional destination — basically where you aspire to be in the long-term.

If I were to draw your Northstar it would look something like this:

I’ll ask the question directly to you: What is your Northstar?

Try completing the sentence “One day, I want to be…”

For example, you might say: One day I want to be ….

• CEO of a Fortune 500 Company
• Founder of my own company
• Secretary of State
• Retired in Florida
• A stay-at-home parent

Having a clear Northstar for the future makes it easier to make decisions in the present. If you are deciding between different job options, it is important to evaluate each opportunity against your Northstar.

Easier said than done, of course. But there are ways to make progress.

Progress towards your Northstar

Here’s a tool I use to help me: the traffic light approach.

We start by identifying a given role, and then evaluate if it brings you closer to your Northstar.

Of course, everyone’s career path is different. So much is left to chance, or things beyond our control. But regardless of what path we take, we can always try to think about the direction we ultimately want to go.

If we can get a sense of what someone’s Northstar is, my second question in these career conversations is: “What are you optimizing for?” In making a job decision there are many different things that you can optimize for. For example:

• Learning
• Impact
• People
• Project
• Work/Life Balance
• Compensation

For me, I am optimizing for people. I have found that the people I work with are most important, and everything else is downstream.

What if you’re optimizing for more than one thing? You should be 😊.

In addition to people, I am always optimizing for learning. I love gaining new knowledge and skills and the good news is that I learn best from people (vs. say, reading books or studying alone). Finally, of course I hope that I am doing meaningful work that has a positive impact.

Add these considerations as columns to your table and use the traffic light to evaluate each role against them.

Hopefully this helps us make better choices in the short-term, to be where we want in the long-term.

What if I don’t have a Northstar?

In my career, I have not always had a clear Northstar — to be honest, I still don’t. Growing up, I had at best only a vague feeling for what I wanted to do. I wanted to travel around the world, meet people from different cultures, and be a part of the most important societal conversations. Perhaps I could be…an ambassador or sociologist? If you had asked that girl if she could imagine what I would be doing today — she would have had no clue. This is because my former self didn’t know that my future job existed — a “Product Manager” at a “Social Media” company?

Instead, over the years my career has evolved and unfolded somewhat organically. I evaluated the opportunities in front of me against the most important things that I am optimizing for (people, learning and impact). It has brought me to where I am today and where I’m heading in the future.

When I joined Facebook (now Meta) almost 17 years ago, my dream job was to be a Product Manager (aka a “PM”). As someone who did not have a technical background and could not code, I saw this as an opportunity to build products with people.

In my very early days, I did a lot of different jobs (like marketing, sales, project management, and more — as one does at a start-up!) before finally interviewing for and becoming an official, full-time PM in 2006. Now I am Head of Product, which means I am responsible for the PM community at Meta.

If you are not a Product Manager or have never worked with one, you might be thinking: what exactly does a PM do? We get this question a lot 😊.

Being a PM can mean a lot of things and what those things are can differ by team and company. But the best analogy to explain our job is that: being a PM is like being the conductor of an orchestra, but for tech products (more on this analogy later…)

Of course, an even better question to ask than “what is a PM” is “what makes a great PM? A killer PM even?” This is something that I would love to discuss more because Product Management is a relatively new function and is still evolving. Unfortunately, there is no PM University or agreed-upon PM pedagogy (productgogy?), yet.

Everything I know about being a PM I learned either while on the job or from my work teammates. Over the years, I’ve often found myself sharing this knowledge to different PMs on different teams working on different projects. Because I say these things so often, people I work with started calling them “Naomi-isms” and encouraged me to share them with more people. So I wrote down all of my best practices, frameworks and processes about how to be a killer PM and shared them with my colleagues at Meta.

Now, I’m publishing them here for the broader PM community or anyone interested in learning more about Product. My hope is that these Naomi-isms help not just PMs, but anyone working to be better at solving problems. No matter what job we have, we are all in the function of getting things done. Hopefully these best practices will help you do that a little better.

More Naomi-isms:

1. Naomi-isms
2. Understand, Identify, Execute
3. Extreme Clarity
4. Canonical Everything
5. PM as Conductor
6. Simplifiers
7. People and Process
8. Building a Bench

At Meta, we work on many different problems that only become more complex over time.

When I joined the company in 2005, there were one million college students using what was then “the” facebook dot com. One of my first projects was to expand our community beyond just .edu email addresses and make it so high school students could join too. This was very controversial at the time 😊.

Today, there are over 3 billion people using our family of apps (including Facebook, Instagram, Messenger and WhatsApp), our devices (Portal, Quest, Ray-Ban Stories) and new metaverse products (like Horizon Worlds). I lead the team focused on serving everyone who wants to use our products, no matter where they live, what language they speak, the quality of their mobile phone or internet access, or whether they can afford a data plan.

Of course, every problem big and small is different, but I have found that their solutions share some things in common, a general framework I call: Understand, Identify, Execute.

Understand, Identify, Execute means:

1. Understand the problem space
2. Identify the levers to achieve your goal
3. Execute on those levers perfectly

This sounds simple enough, but it has really helped me and my teams structure how we solve problems. Like any good framework, Understand, Identify, Execute has stood the test of time. Before I adopted it, I would go straight to throwing spaghetti at the wall to see what sticks, which is not a winning recipe. Over the years, I find myself (and many others) coming back to it.

So, let’s walk through each phase in more detail:

1. Understand

In order to solve a problem, you need to understand the problem space.

Often, the answer to a question or the solution to a problem is not a mystery. There are clues everywhere, if you know where to look. My friend and coworker Alex Schultz summarizes this sentiment well: “Why guess when you can know?”

That’s why I always start with the Understand phase. First, I collect all of the relevant information I can get. This includes quantitative data like analysis and modeling and qualitative data from interviews and focus groups across both internal and external sources.

“Understanding” the problem space can be more broadly interpreted beyond acquiring traditional kinds of data. To explore all of the dimensions and perspectives of a problem, I’ve seen teams do everything from blue sky brainstorms to pixel perfect designs; anything works, as long as it helps you literally or metaphorically gain a better understanding of the issues.

As William Gibson famously observed “the future is already here, it’s just not evenly distributed.” I take this to mean: we can learn a lot about the future if we look at the world around us, and focus our magnifying glass on the right country or demographic or product. We can try to predict the future, but again — why guess when you can know?

I cannot overstate the importance of taking your time in this first phase. I’ve seen too many projects trip at the starting gate because the people involved, however enthusiastic, did not do the work to really understand the problem space. This kind of work is never time wasted.

2. Identify

After you’ve worked to understand the problem space, step two is to identify the most important levers you can use to solve your problem or achieve your goal.

If the Understand phase is about casting as wide a net as possible, the Identify phase is about pulling out only the most important threads; finding the “signal in the noise” that allows us to focus our limited time and energy on the most impactful things.

To get started on this path, I ask questions like:

• What are the opportunities you can pursue to solve your problem/achieve your goal?
• For each opportunity, how does it impact your goal?

At this point, I should have a list of opportunities ranked by importance. Then I need to figure out how to address these opportunities. So then I ask the next logical questions:

• For the biggest opportunities, what are the best ideas?
• For the best ideas, what is their likelihood of success?

If you can understand the problem, you can begin to identify solutions. The best ones to pursue are the ones with the biggest impact on the project. And for those, not only do you need to list out your best ideas, but you should focus on the best ideas that are also most likely to be successful.

Overall, I find that the best ideas come from people brainstorming together, and often are nothing like the ones you originally had in mind.

3. Execute

Once you identify the biggest opportunities and your best ideas to address them, you need to execute these ideas. This is the “just do it” phase of the work.

In my experience, teams often fail at the Execute phase. Just like I’ve seen people get stuck when they can’t understand a problem, or can’t find the best solutions, I’ve also seen people come up with great ideas but fail to put them into practice.

That’s because: it’s never quite enough to “just do it.” You need to “just do it, perfectly.” I overcorrect by emphasizing not just execution, but perfect execution. Even if you identify the right things to do, it doesn’t matter if you don’t perfectly execute them. (More on that in a this note 😊).

Example

To illustrate the Understand, Identify, Execute framework, let’s use an example from the early days of Facebook.

The product team responsible for the Facebook registration flow was trying to solve a problem where people were not confirming their accounts. This team wanted to increase account confirmations, which is important not only to deter spam and bots but also improve account security generally.

So, taking the framework one step at a time:

1. Understand: We analyzed data on the registration flow by breaking it into steps. We wanted to understand what was happening at each step in the flow and where we were losing people along the way. This is called a “waterfall analysis,” where we measure the number of people who land on the registration page, fill out the required registration fields, click “sign up”, attempt to confirm their account, or successfully confirm their account.
2. Identify: We found that around 1/3rd of people who started registering an account did not ultimately confirm their account. 23% of them did not even try. This was a huge opportunity if we could work out the best way to address it.
3. Execute: After some brainstorming, we decided to proactively nudge people that hadn’t confirmed their accounts by sending an SMS with a confirmation code when they logged into Facebook.

I really like this example because it illustrates all three parts of the framework in action:

1. We gathered data to understand the problem (the registration waterfall);
2. We identified the biggest opportunities (⅓ of registrations don’t confirm)
3. We perfectly executed our best idea (a reminder SMS)

In the end — account confirmations went up by almost 10% and Understand, Identify, Execute worked.

I’d love to hear from anyone with a similar experience in the comments. Do you have examples of when you’ve used this or another framework to solve a problem?

More Naomi-isms:

1. Naomi-isms
2. Understand, Identify, Execute
3. Extreme Clarity
4. Canonical Everything
5. PM as Conductor
6. Simplifiers
7. People and Process
8. Building a Bench

In this post, I’ll focus on tactical suggestions for how to achieve Extreme Clarity in presentations and meetings. This is what I’ve found works well over time and from personal experience.

So, you might be asking: what is Extreme Clarity? Extreme Clarity is when everyone is on the same page. It does not mean that everyone agrees about what to do — it means that everyone shares the same understanding of the facts. Everyone knows, “Our goal is X, our options are 1, 2, 3, and our next steps are A, B, C.”

Extreme Clarity means eliminating that inevitable, “Oh, I thought you meant …”

As PMs, we need Extreme Clarity so we can focus all our energy on solving the actual problem, which is hard enough on its own.

Without Extreme Clarity, we would waste time talking past each other, disagreeing about things we actually agree on, and making decisions in the absence of full understanding.

Instead, by aiming for Extreme Clarity, we can far more effectively talk, disagree and ultimately decide — at every step of a project.

Here are my top ten best practices for achieving Extreme Clarity in presentations and meetings:

1. Docs: I use Google Docs, not because it’s necessarily better than other options out there, but because it’s very accessible and it’s important that everyone on a team use the same format.
2. Slides: I always use the most minimal white template. The less flashy design/formatting and more clean white space the better. For the same reasons as I use Google Docs, I usually use Google Slides.
3. Lists: Number your lists, rather than using bullets. This allows people to refer to a bullet by number, for example “I disagree with #2.”
4. Links: Always put links behind a “here.” Writing out the full link with the document name does not convey additional information and creates visual clutter.
5. Font: I personally use Calibri size 11 for normal text. Other people prefer Arial. What matters is consistency.
6. Bold: I usually only bold the beginning of a sentence or a header (see why?) I try to avoid excessive and ad hoc bolding.
7. Italics: I usually also avoid Italics. I think they add more of a visual cost than benefit.
8. Visuals: A visual is another tool that you can use to make sure everyone in your meeting is on the same page, and I like to have a visual on screen in every meeting. Your visual can include the agenda, decisions and next steps from the meeting.
9. Agenda: All meetings should have an agenda. If you’re presenting, highlight the current agenda item in your presentation so that it is easy for people to know where in the meeting you are. If a person is late to your meeting, they should be able to know what you are talking about and what they missed.
10. Real-time Editing: Always document decisions and next steps in front of everyone before a meeting ends. I literally write them down by editing the presentation or doc in real-time. Sometimes, people disagree with what I wrote, and that’s great because it facilitates a process to get clarity and alignment. This also prevents people from having different interpretations of what was decided. There’s nothing worse than ending a meeting only to ask yourself: wait, what did we just agree to do?

There’s always more to improve! If you have thoughts on how to achieve Extreme Clarity, I’d love to read them in the comments 😊.

More Naomi-isms:

1. Naomi-isms
2. Understand, Identify, Execute
3. Extreme Clarity
4. Canonical Everything
5. PM as Conductor
6. Simplifiers
7. People and Process
8. Building a Bench

Every time I get involved in an existing project, I ask one question to get ramped up: “Where can I find out what I need to know?”

Ideally, information this basic already exists in one place. But most of the time, I get different answers from different people. Or, no one knows. I should not have to play detective in order to learn the goal of a project, different areas of work, or where to go to learn more.

All this not only makes it hard for new people, it also means that everyone on the team does not have Extreme Clarity. We are not all on the same page because this page literally and metaphorically does not exist.

So, whether I’m jumping into an existing project or starting a new one, I always want to have on hand the “one and only” document that has all the basic information everyone needs to know. I call this the “canonical” document, as in: the official document, the one that belongs in the canon.

Canonical Doc

A Canonical Doc is the one doc to rule them all. It has all the basic and critical information about a project, with access to all the other downstream and detailed information linked to from there.

It’s a hassle to have to find all your different documents. By linking out to them from a single Canonical Doc, everyone will only have to bookmark one thing to quickly get all the information they need.

Canonical Workstreams + Owners

Your Canonical Doc should list out the logical and discrete areas of work for your project. Each workstream should have an owner. To keep things organized, for every workstream, write down who owns it:

Sometimes, workstreams are so large that they need to be broken down further into sub-workstreams. Each sub-workstream or “track” should also have an owner. Write it down.

Canonical People + Process

Your Canonical Doc should also answer this simple but important question: “Who are the people working on this?” List out everyone on the working team and leadership team.

These people should communicate with each other through a canonical email list, canonical chat thread, and canonical meeting series. This is important to avoid conversations happening in parallel, missing context, and various times when people are accidentally left off emails/chats/meetings.

If you’ve ever been left off a message chain, it’s not a great feeling! More importantly, it slows down the work.

One of the most important lessons about “Canonical Everything” is recursion — Canonical Everything recurses! Meaning, every workstream has to have its own Canonical Doc that is linked to from the overall Canonical Doc.

Canonical Nomenclature

I’ll sometimes hear people use the same words but mean different things, or use different words to mean the same things. This leads to confusion and misunderstanding. Clear communication requires a shared vocabulary; a commonly held list of words and definitions. (Of course, this extends beyond words, to frameworks and visuals).

Setting a good example, I would define each of the following three concepts as:

1. Canonical Nomenclature: the vocabulary to talk about a problem
2. Canonical Framework: a way to think about a problem
3. Canonical Visual: a way to visually represent that framework

For example, in the early days, I was in a meeting where the terms “consistency” and “accuracy” were being used interchangeably. These words mean very different things. We were happy that consistency was high, but not if we were consistently making the wrong decision.

So we wrote down what we really meant:

• Consistency: the % of the time content reviewers agree on a decision
• Accuracy: the % of the time we make the right decision

As a result, our ability to communicate with Extreme Clarity improved.

On a final note: it is especially critical to establish canonical nomenclature when you’re working on new projects, where there is no common jargon or mutual understanding yet.

Canonical Framework + Visual

A Canonical Framework is a way to get everyone to think about a problem in the same way. A good framework is enduring and survives for years because it remains the right way to think about that problem. Of course, what’s the best way to make sure that everyone understands the framework? Visualize it.

To celeberate my 15th “Faceversary”, my team got me a poster that says “Canonical Everything”, it now hangs in my office with some of my other “Naomi-isms” 😊.

What canonical frameworks and visuals do you use?

More Naomi-isms:

1. Naomi-isms
2. Understand, Identify, Execute
3. Extreme Clarity
4. Canonical Everything
5. PM as Conductor
6. Simplifiers
7. People and Process
8. Building a Bench

As I said in my intro post: when I joined Facebook (now Meta) almost 17 years ago, my dream job was to be a Product Manager (aka a “PM”). I did a lot of different jobs (like marketing, sales, project management, and more — as one does at a start-up!) before finally interviewing for and becoming an official, full-time PM in 2006. I mentioned that being a killer PM is like being the conductor of an orchestra. What do I mean by this?

Imagine that a company is a great concert hall and that your team is a talented orchestra. Like an orchestra has different sections (i.e., woodwinds, brass, percussion, strings, and keyboards) your team is composed of different functions (i.e., legal, policy, comms, product, and data) in the same way.

When a team is working well together, I’ve heard people describe them as being “in the zone” or performing “at its best.” For me, a well-performing team feels like an orchestra playing beautiful music. When a team is really thriving, I can almost hear it more than feel it. This is why I rely on (and I’ve noticed that many others do too) musical concepts and vocabulary to describe how we work together. For example, when a team is moving too slowly, we say they need to increase the tempo. And when team members are not getting along, they are not in harmony and need to get in sync. Or when everyone is complaining about a particular function, the string section probably needs some feedback 😊.

Like a conductor, a killer PM is responsible for controlling the cadence of a project, ensuring each section is playing correctly, and overall working to unify the many musicians that make up the orchestra. The PMs are also not the star of the show. The spotlight belongs to the orchestra, with flashes of brilliance from the occasional principle or soloist.

I like this metaphor so much that for several years I gifted the PMs things like a metronome (to increase the tempo of their teams!) and conductors’ batons (well, just to jokingly wave around.) It was cheesy but made the metaphor real.

Over time, I’ve also learned that this metaphor goes both ways: some conductors have drawn the connection between the concert hall and the office building. For example, Benjamin Zander, the famed conductor of the Boston Philharmonic, is also an inspirational speaker and uses “the metaphor of the orchestra” to help people “overcome barriers to corporate productivity.” Corporate productivity!

Much of how Benjamin Zander talks about his role as a conductor resonates with how I see my role as a PM. For example, in his TED Talk, he describes this “amazing experience,” when he says:

“I was 45 years old, I’d been conducting for 20 years, and I suddenly had a realization. The conductor of an orchestra doesn’t make a sound. My picture appears on the front of the CD — But the conductor doesn’t make a sound. He depends, for his power, on his ability to make other people powerful. And that changed everything for me. [I] realized my job was to awaken possibility in other people.”

I love this quote because of the way he encapsulates the power of people who awaken abilities in others. I didn’t get into being a PM from a technical background, I never learned to code. But I knew I could still build products by working with people and helping them work well with each other.

Finally, how do we know if we’re doing a good job? Well, as Benjamin Zander says:

“You look at their eyes. If their eyes are shining, you know you’re doing it.”

Here’s to shining eyes.

If you have thoughts about the role of being a killer PM, or about conductor-like roles in general, I’d love to read about them in the comments 😊.

More Naomi-isms:

1. Naomi-isms
2. Understand, Identify, Execute
3. Extreme Clarity
4. Canonical Everything
5. PM as Conductor
6. Simplifiers
7. People and Process
8. Building a Bench

At Meta, every day we are solving hard problems full of nuance and detail in a highly cross-functional environment. Which is why, I think one of the most valuable skill sets someone can have is to be a “simplifier.”

A simplifier is someone who can take a complex situation and explain it in the easiest way possible for everyone to understand. They don’t oversimplify; details and nuance still matter, but they can introduce and unfold things in a way that makes practical sense, and puts everyone on the same page.

One way to be a simplifier is to start with basic organizing principles or building blocks. From there, you can logically and sequentially build on top of them like a “School Pyramid.”

The “School Pyramid”

Imagine that you’re a Math teacher about to walk into a class. What you are going to say will depend in large part on the level of sophistication of your students.

Understanding starts with the most basic building blocks at the top of the pyramid, and gets more detailed and comprehensive as you move down.

I sometimes find myself in meetings where we’re discussing things at a Level 5 depth, but not everyone there is a “PhD student.” Usually, the presenting person or team has the best understanding of a given topic, while everyone else has varied levels of understanding. Ideally, everyone would have a shared baseline understanding in order to have a productive discussion. Also, it’s not great to feel lost in a meeting where it seems like everyone knows more than you and you are afraid to ask questions (I feel this way a lot!) In order to avoid these issues, the presenter should be able to explain a given topic at everyone’s level, from PhD to Kindergarten. They should be a simplifier.

Now, that doesn’t mean everything has to be explained at its simplest level in every meeting. We can explain Level 1 information upfront or as needed to new people who join a project. However, it is still important that information (i.e. the curriculum in the school pyramid) is available for everyone, at all levels, enabling people like me to get up to speed.

A few years ago, Shirley Sun (who is a wonderful PM and former colleague) shared thoughts on how to be a simplifier from James Clear, the author of Atomic Habits, and it really resonated:

• Beginner = ignorant simplicity
• Intermediate = functional complexity
• Advanced = profound simplicity

That is to say, when you’re a beginner, things are simple because you don’t know enough about them. When you learn enough to be intermediate, they can seem complex. Only when you’re advanced can you explain a complex topic to both a kindergartner and a PhD; you have the mastery of skill to see profound simplicity in the complexity.

How important is being a simplifier in your experience?

More Naomi-isms:

1. Naomi-isms
2. Understand, Identify, Execute
3. Extreme Clarity
4. Canonical Everything
5. PM as Conductor
6. Simplifiers
7. People and Process
8. Building a Bench

Over the years, I’ve had the opportunity to help teams with projects that were not thriving and needed additional support. I would often find that the problem was actually what I call a People and Process problem, which means it can be fixed with a People and Process solution.

People

If a project isn’t succeeding, it could be that you don’t have the right people in the right roles.

Here’s my go-to list of roles that every project needs:

• Single Threaded Owner (STO)
• Quarterback (QB)
• Working Team
• Leadership Team

Taking these one at a time:

• Single Threaded Owner (STO): The STO is the person ultimately responsible for the project, who has the most accountability and as a result the most authority. There are lots of different names I’ve heard people use to describe this role, whether it’s the Directly Responsible Individual (the “DRI”) or (much less acceptably as) the “throat to choke.” Either way, the point is: the buck has to stop with someone, and that should be the STO.
• Quarterback (QB): The QB is the person responsible for daily project management, implementing the processes described below, and overall perfect execution. Unlike an STO (and unlike in football!), every project doesn’t need a QB. But it is best to have one, particularly for complex projects. An STO can lead a project, but they often don’t have the time or sometimes even the skillset to stay on top of the work each day and drive it forward.
• Working Team: This is the team of people doing the hard work each day. In addition to the STO and the QB, the Working Team includes representatives from each underlying function, e.g. people from: Design, Policy, Marketing, Legal and any other relevant role, depending on the project.
• Leadership Team: This is the team of senior people who oversee and give feedback on the work. This group includes leaders from each of the several functions represented on the working team.

Now that you have your key roles identified, ask yourself do you have the right people?

Process

Even if you have the right people in the right roles, it won’t make a difference if they’re not working well together.

I always create a mailing list, chat thread and meeting series for both the Working Team and Leadership Team. For example, this could look something like:

Working Team — channels for the Working team to communicate with each other:

• Email List
• Chat Thread
• Meeting Series

Leadership Team — channels for the Working Team to communicate with the Leadership Team:

• Email List
• Chat Thread
• Meeting Series

Now that we’ve established People and Process, it needs to be captured in the Canonical Doc.

Perfect Execution

Finally, with People and Process in place, teams are more free to focus on execution. I like to aim for what I call: perfect execution. This is when the strategy is fully realized in it’s best form.

Perfect execution is critical because if you don’t execute perfectly on the strategy, you don’t know if the strategy was right or wrong. This results in the worst of all worlds — you failed but haven’t learned anything.

You can break down this dynamic into four quadrants:

1. Right Strategy, Perfect Execution (you win, best case scenario)

2. Wrong Strategy, Perfect Execution (you fail, but learn your strategy was wrong)

3. Right Strategy, Imperfect Execution (you fail, but don’t know why)

4. Wrong Strategy, Imperfect Execution (you fail, but don’t know why)

I know not everyone will execute perfectly every time, but we should try 😊. Have you ever experienced one of the scenarios above?

More Naomi-isms:

1. Naomi-isms
2. Understand, Identify, Execute
3. Extreme Clarity
4. Canonical Everything
5. PM as Conductor
6. Simplifiers
7. People and Process
8. Building a Bench