Which got me thinking: What if there was a blog about product management entirely written by AI. Would it be any good? Would it be worth reading? How much of the work to make such a blog could AI do?

Over the Christmas break, I decided to run a little experiment and see.

Behold: PM 101 (by AI)

This is a 50-post blog that’s a pretty thorough introduction to Product Management that’s entirely generated by AI.

When I say “entirely generated by AI” I mean:

1. The list of posts was generated by AI.

2. The content of each post was then generated by AI.

3. The title of the blog (and checking of available Substack URL slugs) was generated by AI.

4. The images for each post were generated by AI, based on the content of each post.

5. The script to generate each post and each image was generated by AI.

6. The uploading of the content and images to Substack was done by AI.

I didn’t really know what to expect, but the breadth and depth of the content is pretty good. If I was just getting started into product management, this would be a solid grounding — As an experience PM, I even got reminded of some good IC best-practices that I’ve not recently used.

The big gap - of course - is storytelling. The most compelling content, in my opinion, are the stories of real people, in real situations, and the lessons they learned — this AI generated content is mostly on point, but it’s dry as hell.

Next Steps:

1. Would love to hear what you think about the content.

2. Generate more posts on additional topics.

3. Experiment with AI generating more narrative or experience-based content. Can it rehash other people’s stories (should I even ask it to?!)? Can it generate it’s own anecdotes?

If you have other ideas and feedback, let me know in the comments below.

Note: I’m keeping this personal blog as 100% hand-written and not AI generated in any way. It’s fun to write. And I hope there’s always an audience for authentically human-created content.

Previous reading lists: 2024, 2023, 2018, 2016 pt1, 2016 pt2

I’ve written some version of this post on and off since 2016. It’s become a useful forcing function for me: to step back, reflect on how the role of product changing, and recalibrate what’s worth paying attention to next.

As product managers become more senior, the work shifts in nature. Less feature definition. More decision-making under uncertainty. More power, more trade-offs, more organisational complexity — and, increasingly, more AI.

This year’s list tries to avoid classic “how to do product management” books. Instead, it focuses on systems, strategy, incentives, leadership, AI, and judgment.

Each of these books has been recommended to me by a friend: be that a human one or an AI one ;-)

Here’s my reading list for 2026.

1. Click Here — Alex Schultz

Alex is a key leader at Meta and someone I learned a huge amount from while I was there - both working directly with him, but also by working with the various “Growth Marketers” he mentored and fostered.

Alex & his team basically invested the growth marketing function which today is common - if not de rigueur - at every startup and tech company. And the Growth team, in which this function sat, is basically the reason why Facebook and Instagram operate at the scale they do.

This book distills that rare combo of analytical rigour and practical intuition into a playbook that’s both strategic and actionable. From choosing the right channels, to creative testing, to measuring incremental impact, Alex doesn’t just tell you what to do — he shows you why it works and how top teams actually execute it. Whether you’re leading global campaigns or sharpening your start-up’s go-to-market approach, Click Here gives you the frameworks and stories that turn complexity into clarity.

If you’ve ever wondered how world-class marketers make hard trade-offs, allocate budget with confidence, and decode noisy performance signals, this is the book you’ll return to again and again.

2. Supremacy — Parmy Olson

This book tells the story of the modern AI race — OpenAI, DeepMind, and Big Tech — but it’s not a technical book. It’s about ambition, incentives, speed, ego, and organisational structure.

What I found most compelling is how often the outcomes hinge on leadership decisions rather than breakthroughs. Governance choices, funding models, narrative control, and who gets to ship first all matter enormously.

If you’re a product leader thinking “AI strategy” is mostly about models or features, this book is a sharp corrective.

3. The Unaccountability Machine — Dan Davies

This book gives language to things I’ve seen this first hand in some form at every company, and in every org I’ve ever worked in - but struggled to articulate cleanly.

Davies explains why complex systems can make consistently bad decisions even when they’re staffed by smart, well-meaning people.

The problem isn’t incompetence — it’s diffusion of responsibility, feedback loops, incentives, and procedural fog. Decisions get made, but no one quite owns them.

For senior PMs, this is an incredibly useful framing. Many product failures are not execution problems or talent problems — they’re systemic. This book helps you spot when the system itself is working against good outcomes.

As they say, step 1 in solving a problem is to understand that you have one.

4. The Thinking Machine — Stephen Witt

A fascinating account of NVIDIA’s decades-long transformation into one of the most strategically important companies in tech. What makes this book stand out is its long time horizon — this isn’t a story about reacting quickly, but about patiently compounding the right bets.

As a product leader, it’s a powerful reminder that platform strategy, ecosystem thinking, and long-term conviction often matter more than short-term optimisation. NVIDIA’s success didn’t come from chasing trends — it came from quietly positioning itself underneath them.

If you’re responsible for big product bets with uncertain payoffs, this book is deeply reassuring.

5. Impact-First Product Teams — Matt LeMay

This is one of the most useful “anti-product-process” books I’ve read. LeMay takes aim at the way product management has become overloaded with rituals, artefacts, and ceremony — often at the expense of real impact.

What I appreciated most is that this isn’t anti-discipline or anti-rigour. It’s anti-theatre. It challenges leaders to ask whether their roadmaps, OKRs, and frameworks are genuinely helping teams make better decisions — or simply creating the appearance of control.

If your organisation feels busy but not effective, this book will land hard.

6. The AI Product Playbook — Marily Nika & Diego Granados

One of the first genuinely practical books I’ve seen on building AI-powered products without falling into hype or hand-waving. This isn’t about prompts or demos — it’s about discovery, delivery, risk, and iteration when the underlying system is probabilistic and evolving.

The authors are refreshingly honest about where classic PM tools break down in AI contexts, and how to adapt rather than blindly reuse them.

If you’re leading teams building AI features (or entire AI products), this book helps ground strategy in reality rather than excitement.

7. Reimagined — Shyvee Shi, Caitlin Cai & Yiwen Rong

This book focuses on something many AI discussions miss: experience design. Rather than obsessing over models, it explores how generative AI changes workflows, interfaces, and user expectations.

I found it particularly useful as a way to reframe product thinking away from “features powered by AI” towards entirely new interaction models. The examples are concrete, practical, and grounded in real product work.

For product leaders, the key insight is clear: generative AI’s biggest impact is experiential. Treating it as just another backend capability is a mistake.

8. The Seven Rules of Trust — Jimmy Wales

Jimmy Wales is the founded of Wikipedia so he knows a thing or two about this subject.

Trust is one of those concepts everyone agrees is important, yet few organisations treat systematically. This book stands out by being evidence-based and pragmatic rather than fuzzy or moralistic.

The book shows how trust is built (and destroyed) through structures, incentives, and repeated interactions — not slogans or values posters. That makes it particularly relevant for product leaders designing platforms, ecosystems, or cross-functional organisations.

I came away more aware of how easy it is for product decisions — even sensible ones — to quietly erode trust over time if you’re not paying attention.

9. Power and Prediction — Ajay Agrawal, Joshua Gans & Avi Goldfarb

This is a short, sharp book that looks at AI through an economic lens rather than a technical one. Its central argument is that as prediction becomes cheap, the real value shifts to judgment, data, and organisational power.

For product leaders, this is incredibly useful framing. It helps explain why AI adoption often changes who gets to decide, not just how fast things happen.

If you’re thinking about AI strategy at a portfolio or company level, this book provides a clean mental model for where value (and disruption) actually emerges.

10. Working Backwards — Colin Bryar & Bill Carr

An inside look at how Amazon actually operates, written by long-time insiders. This isn’t a manifesto — it’s a description of mechanisms, habits, and trade-offs.

I don’t think most companies should try to copy Amazon wholesale. But as a case study in embedding strategy into process — especially through writing, decision discipline, and customer focus — it’s extremely instructive.

For senior PMs, the value here is in understanding how operating models shape product behaviour at scale, for better and worse.

11. High Output Management — Andy Grove

I can’t believe I’ve not included this before.

Despite being decades old, this remains one of the clearest explanations of what management actually is. Grove’s focus on leverage, outputs, and systems feels uncannily modern.

For product leaders, this book is a reminder that your job is not to do more work — it’s to create conditions where others can be more effective. That applies just as much to product organisations as it does to factories.

I re-read this every few years and find something new each time, especially as scope and responsibility increase.

12. Seeing Like a State — James C. Scott

A classic in systems thinking, this book explores why top-down simplification so often fails when applied to complex human systems.

For product leaders, the parallels are obvious: over-reliance on metrics, abstraction, and centralised control can destroy the very value you’re trying to create.

This book sharpened my scepticism of one-size-fits-all solutions and reinforced the importance of local context, feedback, and humility in large-scale product design.

13. Thinking in Bets — Annie Duke

I’ve been using the term “bet” to describe the initiatives within my org for some time now. While some things are more risky than others, every investment you make as a product leader or even as an IC PM at the feature level, is a “bet” - it’s a stake of your capacity on something that may or may not pay off.

A bet!

This book is about improving decision quality rather than chasing good outcomes. Duke borrows concepts from poker — probability, uncertainty, and expected value — and applies them to real-world decisions.

For PMs and product leaders, this framing is invaluable. So many product decisions are made under uncertainty, yet we judge them purely by outcomes after the fact.

This book helps separate luck from skill, and encourages healthier post-mortems and decision reviews.

14. Range — David Epstein

A compelling argument for breadth over early specialisation. Epstein shows how many high performers succeed not despite being generalists, but because of it.

This resonates strongly with senior product leadership, where success increasingly depends on synthesis: connecting technology, design, business, and human behaviour.

If you’ve ever worried that you’re “not technical enough” or “not specialised enough” for senior roles, this book is both reassuring and motivating.

15. The Goal — Eliyahu M. Goldratt

Written as a novel, this is an accessible introduction to systems thinking, constraints, and flow. Despite its age, it remains startlingly relevant.

For product organisations, the lessons about bottlenecks, local optimisation, and throughput map cleanly onto modern delivery systems.

If you’ve ever seen teams optimise themselves into worse outcomes, this book gives you a simple, memorable way to explain why — and how to fix it.

So there you have it. 15 more awesome books to add to your reading list for 2026.

If you have other recommendations - please let me know in the comments below.

One of the things he’s known for is a comment he made at a White House press briefing in 2002:

Reports that say that something hasn't happened are always interesting to me, because as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know. And if one looks throughout the history of our country and other free countries, it is the latter category that tends to be the difficult ones.

This statement has even got it’s own Wikipedia page, and inspired the name of Rumsfeld’s biopic.

He made the comments in relation to geopolitics and foreign policy — but I've found this an incredibly useful framework in the field of product management to help make sense of information — or lack of it.

1. Known Knows: Things you know you know

This is the easy one. Lets take core product metrics like revenue, MAU, retention etc. You've likely got these instrumented and on a dashboard. You know where to go to get the latest information. You probably know the numbers off the top of you head. You know you know them.

2. Known Unknowns: Things you know you don't know.

Perhaps there's been a drop in one of your metrics, but you don't know why. You're looking at your retention charts and you know new-user retention is X, but you don't really know why. But you know you don’t know. And when you know you don't know something - it’s easy to identify actions you can to take to remedy the situation.

Perhaps you need to add more logging to plug gaps in your data. Perhaps you need to do some user research to understand the patterns you're seeing in data. And when you take these actions, you’ll turn known unknown into known knowns.

3. Unknown Knowns: Things you don't know you know.

It’s a bit counterintuitive, but I think of this as things you have the data or customer insights lying around - but you’re not using them. A good example is a dashboard built by your old data scientist - or a research deck from before your time as the team’s PM. Or there’s a special cut of your existing data that you’re not using that would reveal some critical insight - like if you looked at a country-cut of your MAU charts. Before you go commissioning new data or new research, it’s best to take a look at what you may already have to save yourself the time and effort duplicating work.

4. Unknown Unknowns Things you don't know you don't know.

This is where the wicket gets sticky. As a PM part of your job is to anticipate and remove blockers. That’s easy with risks you’ve identified — but it’s the unexpected that can really mess things up.

That stakeholder you didn’t know was a stakeholder. That requirement no one told you was a requirement. That legal approval you needed but didn’t know about. That team who’s goals you didn’t realised conflicted with yours. The unexpected release of a product by competitor.

Complacency is risky in any situation. If you focus on the things you know, or the things you know you don't know, what are you missing?

Moving through the Rumsfeld Matrix

As a PM who’s accountable for creating a customer or business outcome, you want to maximise your chances of success by reducing your risks. One way to help with that is to use the Rumsfeld Matrix.

1. Take steps to turn unknown unknowns into known unknowns.

2. Take steps to turn known unknowns into know knowns.

Tackling Unknown Unknowns

What can you to to turn unknowns unknowns into known unknowns? Well, you’ve already done the first step.

….stay with me here….

You now KNOW there are unknown unknowns.

Here’s some activities you can perform to turn unknown unknowns into known unknowns.

1/ The Pre-mortem

We all known what post-mortems are — a retrospective at the end of some project about what went well, what didn’t, and determine what we should do differently next time.

A pre-mortem is exactly what you’d expect from the name: you and your team sit down and thinks about all the things that could badly (or go well!) on a project, and make a plan for handling them. The first phase of a pre-mortem is about identifying things to make a plan for — and it’s the coming together of a group of people with an explicit goal of identifying and cataloging things that turns unknown unknowns into known unknowns. Each person bring a different set of skills and experiences — something which may be a known unknown to them, might be an unknown unknown to the project as a whole.

The 2nd phase, the “making a plan” part, is about turning this list of now-known unknowns into manageable risks, known knowns.

Back in 2020 I was working on a set of projects which were somewhat controversial, which also had a high degree uncertainty in how they’d impact a complicated information ecosystem. While a few folks were fundamentally opposed to what we were planning, the majority of people raising objections were expressing worry that we’d perhaps not fully thought through the implications. So, we performed a pre-mortem. We brought together a multi-disciplinary team - everyone from engineering and design to legal, public policy, and communications. It was this broad group that identified and catalogued upwards of 20 risks. A few of these were previously known, but the exercise threw up a bunch more that we’d not been thinking about. Once we’d written them down, we could put a plan in place to address them.

2/ The Red Team

Security systems are especially vulnerable to unknown unknowns. You can design systems to protect against risks you know about - but what about those you don’t?

A common solution is to perform a red team exercise.

“Red teaming” is where you setup a group of people who pretend to be the enemy. They attempt to gain entry to a secure system (physical, digital, both) by attempting to find weaknesses while avoiding it’s strengths (sensors, triggers etc). The Red Team can then report back on any gaps they find such that the system can be made more robust.

The concept of “red teaming” originates from the cold war (blue=USA, red=USSR), and is common in security and integrity strategies, but it’s applicable more broadly.

When you’re developing a product, what are all the ways it could be misused? What are all the ways it could break? Traditional QA is about ensuring what you’ve built works as expected — but the best QAs TRY AND BREAK STUFF. They upload huge files; they hit refresh 50 times a second; they intentionally break the network. They look for unknown unknowns.

Summary

As my old boss once said “assumption is the mother of all fuckups”.

What I like about the idea of unknown unknowns is that once you know about them, you can tack action to turn them into known unknowns — before they come and bite you on the arse.

It’s that time of year again! If people are asking “what do you want for Christmas” or you just want to treat yourself — here’s the books I recommend reading in 2024. They come from a range of personal research and recommendations from other PMs I trust.

Previous reading lists: 2023, 2018, 2016 pt1, 2016 pt2

1. What Got You Here Won’t Get You There by Marshall Goldsmith
   Growth is hard. As you develop in your career, or as your company develops, the strengths and skills you mastered may not be those you need to get to the next level. You might still think of yourself as a product manager, designer, or a software engineering, but the skills you need to run a 10-person product pod are not those you need to run a 100-person organisation. This book does an incredible job of framing this up with examples, and offering practical tips to help you discover what it is that you need to do to get to the next level.

2. American Prometheus by Kai Bird and Martin J. Sherwin
   This is the biography that inspired the 2023 movie Oppenheimer. It’s leadership story about people and technology - and how a clear goal can help diverse groups of people achieve incredible things. J. Robert Oppenheimer was the most unlikely of leaders — untested, nerdy, mercurial - yet was able to lead one of the most ambitious feats ever undertaken. It has so many parallels with product development: uncertainty, the need to prioritise, take risks, handle disagreements, stakeholder management, and the bridging of cultures (in this case the world of theoretical physics and the american military establishment). A long but thoroughly fascinating read.

3. Death by Meeting by Patrick M. Lencioni
   Meetings are not just an inevitable part of working life - they’re important. Even more so when fewer of us are working in offices - meetings may now be the only time many of us have to work together “face to face”. But they can easily be over-used. Death by Meeting sets up a practical framework for the meetings you should have, on what frequency, for what purpose, with whom, and about what topics. I defy you to read this book and not go back to your company and make some changes to how you operate.

4. The Mom Test by Rob Fitzpatrick
   Talking to customers (existing or potential) is a critical part of product management. But how do you know the feedback you’re getting is valid? People don’t like to be brutally honest - it’s uncomfortable - so they’ll lie: they’ll tell you what they think you want to hear. I’ve experienced this first hand, and it created problems for me down the line. This book is about the signs to watch our for that your customer conversations might not be giving you the information you need, and how to tune your questions and actions to extract maximum signal from the noise.

5. Blue Ocean Strategy by W. Chan Kim and Renée A. Mauborgne
   Building a great company is about finding a market and dominating it. This book is about how to think about product and business strategy to “make the competition irrelevant”. A must-read for anyone thinking about product strategy for their team, their org, or their company.

6. Strong Product People and Strong Product Communities by Petra Wille
   I had the pleasure of meeting Petra when she and Arne Kittler invited me to speak at Product at Heart in Hamburg in the summer of 2023. As a product leader, one of your most important products is your team; and that involves growing people — either tackling people’s weaknesses or developing their strengths. Even if you’re doing this well today, there’s even more you could be doing. This book is packed full of practical ideas, as well a signs you should be looking for that not all is well in your org.

7. Six Thinking Hats by Edward de Bono
   One of the reasons meetings or discussions go off the rails is that the participants are not in the same mental space. If someone’s in creative thinking mode while someone else is analysing the last idea, they won’t listen properly to each other. The Six Thinking Hats is a framework to help groups of people be explicit about different through processes, and use that to enable faster, more productive discussions and decision-making.

8. Empire of Pain by Patrick Radden Keefe
   This is the story of the Sackler family, their company Perdue Pharma, and their blockbuster drug: the opioid painkiller OxyContin. It’s a cautionary tale that combines technical innovation, politics, failures in regulation, and greed. OxyContin certainly had product/market fit — but what happens at the limits when the incentives of the product-maker and addiction of the customer result in lives being destroyed.

9. How to Win Friends and Influence People by Dale Carnegie
   It’s insane this was written in 1936, but remains as relevant today as it was then. Some of the examples are, obviously, dates, but the fundamental concepts are evergreen. As a product manager, we have to mostly lead through influence, so ensuring people are open to you and your ideas is critical to success. Even people who think they’re good at this tell me they re-read this every few years to refresh themselves, and counter some bad habits that might creep in.

10. Empire of the Sum by Keith Houston
    Easily the nerdiest book on this list — it’s about the history of the pocket calculator. But it’s a great example of how a technological advance (microelectronics) can find a clear problem to solve (replacing bulky and expensive machinery), and have impact way way beyond its humble origins.

Happy reading!

If you have any recommendations you think should be added to this list, or to my own pile for 2024, please drop me an email at books@simoncross.com.

My wife and I used to spend as much time as we could exploring outside the city. Going up to the Napa / Sonoma valleys, famous for their wines, was a perfect weekend activity, especially when we had friends over.

Someone recommended the Fremont Diner (now sadly closed) on the Carneros Highway. It was a great shout. A rustic place with old neon signs, runny eggs, crispy bacon, strong coffee.

As we sat outside in the sun, I looked over to the right towards a hill covered with vines. Classic wine country. So I took a photo.

But something about it caught my eye - like I’d seen this view somewhere before.

Blue sky, rolling green hills?

It looked a bit like the default background to Windows XP - the most used PC operating system in the 2000’s.

This picture is called “Bliss”. It looks so perfect, I’d always assumed it was computer generated - or at least heavily edited. I didn’t think it could be a real place.

I kept staring that that hill. Covered with vines, but underneath that same curve. It couldn’t be…could it?

Turns out….

In January 1996, former National Geographic photographer O'Rear was on his way from his home in St. Helena, California, in the Napa Valley north of San Francisco, to visit his girlfriend…He was working with Irwin on a book about the wine country. He was particularly alert for a photo opportunity that day, since a storm had just passed over and other recent winter rains had left the area especially green.

Driving along the Sonoma Highway, he saw the hill, free of the vineyards that normally covered the area; they had been pulled out a few years earlier following a phylloxera infestation. "There it was! My God, the grass is perfect! It's green! The sun is out; there's some clouds," he remembered thinking. He stopped near the Napa–Sonoma county line (approximately at 38.249°N 122.410°W) and pulled off the road.
….
He took four shots and got back into his truck. According to O'Rear, the image was not digitally enhanced or manipulated in any way.

Lets look that up a second….

And there it was.

The Bliss photo was taken just up the road, looking at the exact same hill.

It was a real place, and it was right bloody next to me!

It’s such a famous picture, that others have made pilgrimage to the Bliss location, and taken their own pics:

What’s the point of this post?

Well, its nothing to do with product management, but it’s a fun story, and a good reminder to keep you eye out for what’s going on around you. You never know what you might be missing.

One last shot from the Fremont Diner.

The last two talks about clarity in thinking and execution were great, and I want to continue that thread by talking about clarity in communication.

Because it turns our that when your working at scale, at speed, or when the stakes are high, it really matters.

I wanted to illustrate this by telling the story of a product. An unusual product, but a product nonetheless.

This is the Mars Climate Orbiter. It was built by NASA’s JPL in the mid-90s. It was a $330 million dollar program, and the goal was to monitor the weather, temperature and water distribution on the surface of Mars.

Hundreds if not thousands of people worked on this project. They built it, tested it, and on December 11th 1998 they launched it into space.

And then they waited.

It took 286 long days for the spacecraft to travel to Mars.

Finally, they took their seats in the control room to watch as it was due to perform a critical engine burn and enter orbit around another world.

This was all pre-programmed — it takes more than 5 minutes for a radio signal from Earth to reach Mars so you can’t “fly” a spacecraft remotely — you just have to sit and watch, hoping your calculations were correct.

To horror, the signal from the spacecraft vanished from their screens.

Poof, gone.

They scrambled to figure out if they could re-establish communication, but to no avail. Their $330m spacecraft was lost.

As you might expect for something that expensive, there was an investigation to find out what had gone wrong. What they discovered was that there had been an error in the navigation system. When the Mars Climate Orbiter approached Mars, it was way too close to the planet. Instead of going into orbit, it had either burnt up in the atmosphere, or bounced off into deep space.

What was the root cause of this error?

While the bulk of the probe was built by NASA, some key parts were built by a contractor, Lockheed Martin. While NASA worked in Metric, Lockheed assumed they’d be working in Imperial.

NASA, to their credit, were clear: this wasn’t Lockheed’s mistake alone — it was a systemic breakdown in communication.

This is a pretty clear example of how errors in communication - not being extremely clear - can lead to pretty significant problems with projects.

So lets define what we mean by extreme clarity:

Communicating something in a way that leaves
no ambiguity in the mind of the reader such that
they all leave with the same understanding.

But my old boss put it even more succinctly:

“Assumption is the mother of all fuckups”

So today, I wanted to spend some time looking at a few situations that we as PMs often find ourselves in, where clarity matters most, and where I see people often fall short:

1. Data - particularly percentages.

2. Setting Goals - especially metrics-based goals.

3. Making decisions.

Lets take each in turn

1/ Data

Here’s a line from a recent report from one my teams:

Immediately, a question in my head: from what to what? So I asked for clarification.

They came back — 13% to 23% —— but that’s not 10%, it’s 10 percentage points!

This increase is actually a 77% percent increase, not a 10% increase.

That is a HUGE difference in perceived impact — and differences like that could result in very bad decisions being made - just because of a misunderstanding in communication.

The solution is simple. When you’re communicating changes in metrics — include not only the percentage (or percentage point) change, but also the FROM and TO numbers.

2/ Goal setting

I recently asked one of my teams for their dashboard, this is what they sent me.

Yay, we have data, but this doesn’t tell me a lot.

I wrote back: but what is your GOAL for this metric? - can’t we get that on the chart? Here’s what they sent back:

Sure, that’s better, but it’s still ambiguous:

1. is the goal to get ABOVE this line, or STAY BELOW it?

2. when do they need to hit this goal by — how long have they got left?

3. when did they START?

Not at all clear.

The first change was I asked them to extend the X axis out to the end of the half — which is when they needed to hit this goal.

OK, this is better — we can see they’re trending towards the line — but are they on track?

So next, I asked them to change the dotted orange line to meet the metric at the START of the half.

Now you can see…

    1/ when they started working on this 

    2/ where they’re trying to get to

    3/ WHEN they’re trying to get to it

And — critically - that they’re behind where they need to be to hit the goal. This allow you to start having the right conversations — how can we help you get back on track NO AMBIGUITY — IT”S EXTREMELY CLEAR

But what about Guardrail metrics where you need to stay BELOW some number?

In those cases, charts like this are not that bad — there’s no start or end, you’ve just gotta stay below. BUT how far below. Should the team act only if they cross the line, or do they need to start working as they approach the line? When? AMBIGUITY! — NOT EXTREMELY CLEAR

One industry that does this really well is aviation….

Here’s an altimeter. It’s a work of art.

• Green — everything is fine

• Amber — start to panic  and take evasive action

• Red — don’t go here.

Its so clear.

We can apply this same idea to our goal chart. Lets add in an orange line and a red line. Now we can see that the team is trending towards red (BAD) and we have cross the orange threshold at which they start needing to do work to bring it down.

Even better, make them solid.

And boom - NO AMBIGUITY — EXTREMELY CLEAR!

3/ Making Decisions

Making decisions is super hard. That’s because it’s complicated.

• Before

  • What are the options?

  • What factors are being considered?

  • What are the tradeoffs?

• During

  • What are the different team’s recommendations?

  • Who’s actually making the decision?

• After

  • Who made the decision and when?

  • What factors were considered?

So I wanted to share the best decision-making framework I’ve ever used.

It’s not mine - it’s Guy Rosen’s, but its helped me in everything from reviews with Mark Zuckerberg, down to where our team’s offsite should be.

For this example, I’m going to use something that’s on everyone’s mind right now — possibly the most important decision of the day…

What am I going to have for lunch?

All we need is a single slide and a table:

First, lets list out the options.  You would be AMAZED at how valuable that is in and of itself. I often find someone says “actually there’s a 4th way” that had not previously been considered before.

Next - list out the EQUITIES — the factors we’re going to use in making this decision. Again, it’s amazing how many times this teases out a misalignment of what’s important - or that there’s a factor that wasn’t being considered.

In this case, I’m going with cost, healthiness, taste, and… regret.

Now we just fill in the cells — colouring them red, amber, or green based on how they rank against these equities. A cheeseburger is clearly best on taste, but it’s not great on the other dimensions!

A salad, by contrast, ranks highly in some areas, but relative to a cheeseburger, it’s not something I’m gonna write home about.

And a sandwich is somewhere in the middle. 

Now this — relative to many decision-making processes I’ve seen is a huge step forward.  The act of creating this table teases out the vast majority of the disagreements between parties. People end up arguing about whether a cell is really amber or green.

Some people might think this is petty disagreement, but you know what, it’s not. This is the decision-making process. Decisions often don’t stick because people didn’t feel heard, that their opinions were not considered, that their ideas were not debated. This framework is great on it’s own, but it’s the process by which you fill it in that’s the most valuable part.

Ok so how to actually make the decision? Normally its a MEETING!

But going into the meeting, it’s useful to know where the different parties stand — so lets capture that on the slide….

Again, this is adding even more clarity. Instead of spending the first 15 minutes of the meeting dancing around the question of who things what, everyone knows where everyone else stands, and we can skip to the most important part: the debate.

Now hopefully - in this meeting, we’ll make a DECISION!

So we can add something which captures what we chose, and when it was decided.

Of course, it was the SALAD!

You would NOT BELIEVE HOW VALUABLE IT IS to have a record like this. Someone joins your team and is like “why the hell do we do it that way” — you can be like “Well - here’s the traffic light we used to make the decision.

Summary

So we talked what extreme clarity is, and why it matters.

And looked at three areas in which clarity is often lacking, and ways to improve it.

So here’s the key takeaways:

1. Know the difference between % and pp. Include the before & after numbers as well as the % (or pp) change.

2. Put goal lines on your charts.

3. Try out the traffic light framework for decision-making.

I hope you found this interesting, and hopefully you picked up one or two ideas you could use in your daily work, starting tomorrow.

• Careers are the sum of capitalising on opportunities.

• The most interesting opportunities often are offered to people who’re recommended for them.

• By thinking about how to improve your recommendability, you may get offered opportunities that could transform your career.

In 2018 I was a mid-level PM at Meta working on a product called Workplace. I had only 6 direct reports, 3 of whom were temporary rotational PMs. I lead a good chunk of the product org, but wasn’t on the leadership team.

One day, I got a call from Guy Rosen, then the Head of Integrity at Meta. Paraphrasing:

Hey Simon, I wondered if you’d be interested in joining the Integrity team in London. We’ve got a team of 10 PMs and we’re looking for someone to lead the team. We’re investing heaving in London as a site - so this is likely to grow even further. Wanna chat?

What? I’ve never worked on Integrity (aka Trust & Safety) before. I don’t know anything about the subject. I’ve never managed a team of 10 PMs. And somehow he thought of me as the person he needed to lead his critical team at this critical moment? He must be mad, desperate, or both?

I’m not qualified to answer which of those states he was in (both?). But what I did come to understand later is that I’d been recommended.

Despite my obvious shortcomings in both management experience and domain expertise, that recommendation had carried enough weight for me to get a call.

The power of recommendation something that’s been studied in business for decades.

Word of mouth is an incredibly efficient way to grow a business: your customers are doing the selling for you. That is why many organisations measure (and try to improve) customer satisfaction.

In the late 90’s, Enterprise Rent A Car employed some consultants from Bain, lead by Fred Reichheld. The metric they developed together attempted to capture in a single number everything about the power of recommendation (and the power of non-recommendation). That metric was NPS - Net Promoter Score.

NPS is a measure of customer satisfaction, driven by the answer to a simple question: Would you recommend X to a friend of colleague? Respondents asked to give an answer on a scale from 0 to 10.

• People who give a 9 or a 10 are “promoters”.

• People who give a 7 or 8 are “passives”.

• People who give between 0 and 6 are “detractors”.

To calculate your NPS score (which ranges from -100 to +100) you look at the difference between the % of promoters and % of detractors:

NPS = % of promoters - % of detractors

While NPS itself has some detractors (see sidebar below), it’s still a widely used mechanism to measure and track customers’ perceptions about their experience with a business.

The inherent risk in recommendation

One thing about NPS that should stick out immediately is that ratings of 7 or 8 which you might naturally think of as “very positive” are neutral in NPS: they don’t count towards a positive score.

Why? Think back to the canonical NPS question:

Would you recommend X to a friend of colleague?

The reason why NPS counts 7’s and 8’s as neutral is because recommending something puts your social capital at risk.

You might think a restaurant was pretty good (7’s or 8’s), but if you recommended it to a friend and they didn’t have a great time, you’d feel bad, and they’d perhaps not trust you again.

As a result, as socially-aware beings, we tend to only recommend things we’re REALLY confident about (9’s and 10’s).

The whole thesis behind NPS is that to earn someone’s recommendation of your product or service, you have to CRUSH IT in their estimation. Not just do OK, but really nail something special.

NPS and You

When I think back to the key moments in my career growth, recommendation of me has either played the primary role, or a key secondary role. But it’s nearly always played a role.

• The story at the top of this post is an example of recommendation as a primary factor: someone asking an open question (“Is there anyone you’d recommend I speak to about this role?”) and the recommender having a strong enough opinion to put forward a name.

• The secondary scenario is likely more common (though no less important): “I’m thinking about hiring X for this position, do you think that’s a good idea?”).

In both cases, the recommender is risking their reputation by putting forward a name, or by validating one. They’re only going to do that if they have an opinion that’s strongly positive.

If you want to grow in your career, you need to be offered opportunities - and often, the best opportunities will find you through recommendation — other people staking their reputation that you are the right person for this role.

And what’s a well-known way of thinking about, measuring, and improving recommendability? Net Promoter Score.

Using NPS-thinking to build your reputation

Reputation biggest weakness (that it’s hard to build) is also it’s greatest strength. There’s few short cuts. Building your reputation and thus your recommendability is the product of hard work, consistently, over a long period of time (as my old boss Guy Rosen used to say).

But I’ve found that using the principles behind NPS can help frame up the kinds of behaviours and outcomes you need to be exhibiting over time.

Recall that to get a high NPS score, you need many more “promoters” than “detractors” — and “promoters” are those who give you 9 or 10s, not 7s or 8s.

And the way you build your score is by performing well across the core of our jobs as people at work in our teams, and our companies:

• Think about that last 1:1 you had with a direct report. How would they rate that 30m meeting with you? 7 or 8? 9 or 10? Lower than 7?

• What about the last team meeting you chaired? Was there an agenda? Was people’s time well-used? Did we make progress on something important? If you could ask them, how would they rate your performance as chair of the meeting? 7 or 8? 9 or 10? Lower than 7?

• What about the time someone came to you for advice about a thorny problem they were working through. Did you give them your time? Did you give them a framework to help them make progress? Did you help them simplify the problem down into 1 or 2 questions that would unstick the rest? How would they rate the advice they received? 7 or 8? 9 or 10? Lower than 7?

The list could go on forever, but you get the point. The world of work is about interacting with people to get things done. Those people, like it or not, are going to form an opinion of you. That opinion is going to impact your recommendability - and eventually, your career.

Remember the “Net” in NPS

The above might feel daunting: how do you get 9’s and 10’s all the time? Good news: you don’t have do.

Reputation is often forged by the accumulation of many smaller actions, not one big one. That means it’s not all over if one thing goes badly: you should be thinking about the net.

If you’re scoring only 7s and 8s, that’s OK, but that’s not gonna move your hypothetical NPS score upwards. And if you have a bad day, and get some 5’s and 6’s - they will seriously drag you down.

But if you’re getting 9’s and 10’s on a few things, that’s gonna really start making a positive difference.

The most common way to have a high NPS score is to be reasonably good at most things (7’s and 8’s) and really good at a few key things (9’s and 10’s) while minimising the screwups (6 and under).

I have seen people succeed by being really good as some things (e.g. public speaking) and really bad at others (e.g. leading a team) — but they’re more corner cases in my experience.

What can you do tomorrow?

Now that you’ve got this “NPS frame” to look through, you can use classic “NPS theory” to start improving your score.

1/ Start by eliminating the detractors. This is the single biggest point of leverage. It’s generally easier to stop pissing people off, than it is to delight them. What are all the things you’re doing that’re causing people to give you a 6 or lower?

• Are you late to meetings?

• Have you not done the reading to prepare for a conversation?

• Are signalling a lack of interest and care?

If you can identify the things that are causing you to score 6 or under, and turn them into 7’s - that’s HUGE. Moving people from the detractor column into the passive column means all the great work you’re gonna do next is pure upside, rather than paying for your mistakes.

2/ Next: identify some opportunities to outperform. Once you’ve stopped scoring 6 and unders, you can start to invest in areas where you can get your 9s and 10s. This will be different for everyone. But here’s some ideas:

• For your next 1:1 with your manager, come prepared with topics you want to discuss. Maximise time focussed on business-impact topics, not just shooting the shit.

• For your next 1:1 with a direct report. Put away your phone and laptop and practice active listening. Offer to help where you can, and ensure you follow through.

• For your next product review, send the pre-read 48 hours in advance instead of 24 (oh, and make sure the deck/content is super-tightly framed).

But in general: remember the NPS formula: You don’t need to be getting 7’s and 8’s on everything, but you need to be getting significantly more 9’s and 10’s than you are 6 and unders.

How do you know you’re making progress?

In short, you don’t, and you shouldn’t worry too much about it. Focus on doing the right things, and the right things will happen to you.

That said, there’s a few signals that suggest you might be making progress.

1. When people whom you don’t know well start to seek out your advice on a topic (especially when they say “Person X said you might be able to help”).

2. When you’re invited to join a cross-functional working group or cross-org project lead by someone outside your org/function.

3. When people reach out about open roles on their team (especially because “multiple people suggested I should talk to you”).

In these situations, people likely had multiple people they could have turned to, but for some reason they chose you. Often it’s because you were recommended.

Conclusion

To be clear, I am NOT suggesting you start running a personal NPS survey of the people you work with. That would be annoying, expensive, and weird.

What I’m sharing is that NPS, flawed though it is, contains some core concepts that might be useful in helping you think about how to uplevel your performance in the eyes of the people around you, build a reputation for excellence, and grow in your career through the opportunities you’ll get by being seen as one of the best.

Sidebar: A word on NPS

I know that in some user research circles, NPS is seen as somewhat discredited. The flaws, as explained to me, include:

1. It doesn’t give you credit as you gradually improve your product/service. Getting people from a 1 to a 5 is a big deal, but your NPS score won’t budge.

2. It measures satisfaction of your existing customers, not how good you are at acquiring people. While NPS may be a useful measure for products/services that grow through word of mouth, it’s less relevant for businesses that grow through, say, performance marketing.

3. It doesn’t help you understand how well you’re doing vs your competitors. You can be crushing it on NPS, but prospective customers are choosing another product or service based on some other property e.g. price or convenience.

These are valid points, although as I’m not a professional researcher, I’m not super-qualified to opine on NPS vs other forms of customer satisfaction measurement.

Even so, it seems to me that NPS captures some interesting core characteristics of use as human beings: that our “average” ratings skews high, and controls for an intrinsic property: that recommendation carries risk.

As such, I think it’s still reasonable to use the frame of NPS as a prism through which to look at ourselves, who we are, how we behave, what people think of us, and how that might affect the opportunities afforded to us in our careers.

1. Circle of Control: Focus your time and energy on these things, as you have direct control over them.

2. Circle of Influence: Do your best to sway things in your favour, but don’t stress if things don’t go your way; you never had the power to choose.

3. Circle of Interest: Follow events, but recognise you can’t control or influence them. Instead, find the subset of things you can control or influence.

In November this year, as I was winding down from my time at Meta, the company announced its first ever round of layoffs. Suddenly, my focus shifted from winding up my projects to helping people process what was happening and why.

Over those last two weeks, I had many many of conversations which followed the same form: Why is this happening to me? What can I do about it? What could I have done to prevent it?

To navigate these discussions, I dusted off an old framework I’d learned about more than a decade earlier: The Circle of Control.

Several folks told me later it was one of the most useful tool they’d used to frame the situation in which they found themselves. It helped them refocus their energy onto the things that really mattered - the areas where they could make a difference.

Not only did it help people in this situation, it’s useful in life in general - so I thought it might be useful to share here.

The technique is to group things that are causing you anxiety or stress into three simple categories. Each one gives you a mental model that helps you modulate your approach - and clear actions you can take to navigate the situation.

Imagine three concentric circles:

1. Circle of Control — These are the things you can directly control. You should worry about the things in this circle because you can control them.

2. Circle of Influence — This is where you place the things you can’t directly control, but you think you can influence. You should do your best to influence them, but if things don’t go your way, don’t waste energy stressing about it — it was never in your control in the first place.

3. Circle of Interest — These are things that affect you, but you can’t influence or control them. Don’t waste energy trying to stop them happening — you can’t. Instead, focus on ensuring you’re prepared if they do; invest your time only on the things you can control.

These three categories are simple but insanely powerful.

Anxiety is often driven by feeling powerless and helpless. What this framework gives you is a way to simplify things, identify what you can and can’t do, and start taking actions accordingly.

Similarly, resilience is about being able to handle whatever gets thrown your way. For me, that’s about having frameworks that turn situations which are messy and complex into ones which are simple and clear. The Circle of Control can help with that.

Let’s look at a few example:

1. Earthquakes. You can’t stop earthquakes happening, and you can’t influence their timing, strength, or location. Earthquakes are firmly in the Circle of Interest. But you’re not entirely powerless. You can control if you live in a seismic area, or you can control if you have an earthquake survival kit ready at home. Perhaps you’re able to influence local government policy to ensure new buildings are earthquake-ready, or mandate people take out earthquake insurance.

2. Layoffs. Unless you’re in senior management you can’t control if your company needs to lay people off. And you can’t, generally, control who they choose to lay off. You may be able to influence the need for layoffs (by building and selling great products), or perhaps influence the company’s decision to keep you on (by being a high-performer). What you can control are things like keeping your resume and linked-in profile up to date, maintaining or growing your network by attending industry events such that in the event that the worst happens, you’re well positioned to find your next role.

3. How you spend your workday. If you’re a knowledge-economy worker you probably have at least some control over your calendar. You might be required to attend some meetings like All Hands (circle of interest), but most you can probably move or decline (circle of control). Some others you might be able to owner the owner to move, skip, or decline if your attendance isn’t required (circle of influence).

4. Diet. One of the areas you have most agency over is what you put in your mouth. This is very clearly in the circle of control. If you’re going to a friend’s for dinner, and if there’s things you don’t like you could ask them not to cook them for you (circle of influence). Or your attending a conference and there’s buffet lunch. You can’t control or influence the selection (circle of interest) but you can choose what you eat. If you have very specific requirements (e.g. a nut allergy) perhaps you anticipate this and bring your a packed lunch of your own (move this problem back into the circle of control.

5. Roadmapping. Your latitude here will depend on your role & level — You perhaps can’t control or influence your company’s planning cadence and timeline (e.g. quarterly) but you might be able to change how the process runs (circle of influence), and you can likely determine how your own team will roadmap (circle of control).

6. Remote Work. You might not have any say over your company’s approach to remote or hybrid working (circle of interest), but perhaps you can decide which days you go into the office (circle of control), or which days your team agrees everyone should go in (circle of influence).

What goes in which circle depends a lot on who you are, what your role is, and the powers you have available to you.

But I cannot tell you how many times this framework has helped me (and many others) get my head around a stressful situation, and distill it down into:

• Things you can control,

• Things you can’t control but can try and influence,

• things you can’t control or influence — and identify the things you CAN do to prepare.

You are very rarely powerless.

Being able to speak to large audiences of people has, for me, come in very handy. It’s a high-leverage way of sharing information, or influencing and persuading people round to your point of view.

But it’s also scary. It’s unnatural. It’s rare. Even for extroverts, it can be a challenge. For introverts, public speaking can be counter to every fibre of your personality.

Overcoming these fears (or at least managing them) requires practice, self-control, and finding the right mindset.

I’ve worked with lots of people for whom public speaking is a new experience, but an essential part of their growth. Perhaps they’re an engineer who’s been asked to talk about their work at the next team meeting, or a data-scientist who’s been asked to present at a conference.

In these situations, there’s two bits of advice I give – which people have told me really helped them to overcome their fears.

1/ Everyone in the room wants you to succeed.

New public speakers can make the mistake of thinking the audience is cold, hostile, unfriendly – in most cases that couldn’t be further from the truth. 

When people go to a meeting or a conference - they want to have a good time. They want to be entertained. They want to learn something.

Very few people will be thinking: I really hope they screw this up. Actually, they’re rooting for you.

Once you realise this, a room of people becomes a tailwind, not a headwind. You should imagine them infusing you with confidence and energy. You should know that they’ll laugh at your jokes, and forgive your mistakes.

Now, there are cases where this isn’t true: a courtroom, for example, or when you have to give a room of people news they don’t want to hear. But these cases are rare, and not the kinds of situations novice speakers often find themselves in without a lot of support. 

But in the vast vast majority of cases, the audience is rooting for you. Remember that every time you step out on stage.

2/ You know more about your subject than anyone else in the room.

Someone asked you to speak. They chose you for a reason. Perhaps you put yourself forward? Well, then someone accepted your request.

They didn’t have to do that. They could have picked someone else. They could have said no. But they didn’t and now here you are. You are where you are because you deserve to be.

You might not think you know everything about your topic but, in general, relative to the audience, you’re the expert. 

Feeling this way is normal. Acquiring knowledge is like climbing up a ladder. You take each rung at a time, but it’s only when you look down that you realise how far you’ve come. 

The speakers I worry about the most are those that think they know it all. Complacency is the enemy of success. You might not feel like an expert but if you’ve been asked to speak, it’s because you are.

—

There’s obviously a lot more to successful public speaking than that, but if you’re struggling for confidence. Remember these two bits of advice, then go out there and crush it.

1. Decisions you know you can make → communicate.

2. Decisions you know you can’t make → escalate.

3. Decisions you’re not sure you can take → give leaders an opportunity to “throw an exception”.

Making decisions is one of the most important activities in business.

Great organisations are really, really good at quickly making good decisions that stick, unblocking progress and enabling teams to move fast. The benefits are non-linear, they compound.

The most frustrating orgs I’ve worked in are those that don’t have a strong decision-making culture. You’ll have seen the symptoms: a tendency to involve lots of people, lack of clarity as to who the actual decision-maker is, requests for “more data” before we decide, lots of meetings/discussions but little progress. Meanwhile, your competitors (who have their shit together) are making decisions and moving onto the next set of problems. They’re pulling away from you.

There’s lots of reasons why orgs end up with bad decision-making cultures (e.g. fear of failure) but one problem I’ve observed is that often people don’t know what decisions they can make, and what decisions they can’t — so they default to the safest option: not making a decision.

But this isn’t a trivial question to answer - it’s hard (often impossible) to write objective, declarative rules as to what decisions a team can make and what decisions they need to escalate.

One solution I’ve seen work really well is to not consider this as a binary thing, and instead classify decisions into three buckets.

1. Decisions you know you or your team can make.

2. Decisions you know you or your team can’t make (i.e. you know you need input from leadership).

3. Decisions you’re not sure you or your team can make.

#1 and #2 are fairly obvious, but #3 is the fun one, and where a lot of things get stuck.

Let’s look at each.

1/ Decisions you know you can make.

These are things you’re confident you have the power, capability, or mandate to decide. You may know it from experience (we’ve made decisions like this before) or because you’ve been told you can (“anything under $10k you can approve on your own”).

In this case, your approach is to make the decision and then communicate it.

Decision-making is inherently exclusionary. Not everyone can be involved, and not everyone will be satisfied. So your job in this case is to communicate:

1. What was the problem / situation / decision to be made?

2. What were the options you considered?

3. What were the competing equities and tradeoffs you considered?

4. What was the decision, and what’s the rationale for that decision?

In my experience, when there’s objection to a decision, it’s 9 times out of 10 because the objector didn’t understand all the factors used to make the decision. By communicating your process and rationale, those objections fall away. People may still disagree with your decision, but at least they understand it.

2/ Decisions you know you can’t make.

These are things you know you need to escalate up the leadership chain for resolution. This may be because:

1. Your leadership team has told you they want to make this decision, or;

2. This is a high-stakes or 1-way-door decision and you want explicit approval, or;

3. There’s a disagreement you can’t resolve within your team (or between your team and another team) - so you need more senior people to break the tie.

Your approach in this case is to escalate.

Escalation generally involves putting together a document (doc, email, deck etc) which describes the problem, the options, the tradeoffs, and the recommendations of the various interested parties - and then probably having a meeting about it (where ideally the decision gets made!).

Some people see escalation as failure (“we couldn’t figure this out ourselves, we must be bad at our jobs”) - but escalation is good; it’s healthy. If you’re taking bold decisions, it’s inevitable you’ll find conflict. Organisation hierarchies exist to make ever-higher-stakes decisions.

As someone who’s both escalated things, and been escalated to — I can tell you I’d much rather a team escalate early and often than get stuck in the mud, unable to make progress.

Big plug for the Traffic Light Framework from Guy Rosen, which is the best decision-making framework I’ve ever used. It’s especially powerful in escalations where you need to distill a decision down to it’s critical elements to enable a leadership team (who’ll have less context than you) to quickly form an opinion.

The big upside of escalations are that (ideally) you get a clear decision that sticks. The downside is that it takes time and effort.

3/ Decisions you’re not sure you can make.

#1 and #2 are the “easy” options - it’s clear what to do.

But in my experience, it’s not always obvious if you can make the decision, or if your leadership team would want or need a say.

If you get it wrong you either:

1. Get reprimanded by your leadership team who feel they should have been consulted or…

2. Waste your time and your leadership team’s time preparing and driving an escalation when you could have just made the decision yourself and moved on.

In this case, I advise my teams to make the decision, but give leadership the opportunity to “throw an exception”.

“Throw an exception” is a term from software engineering. You run some code, but if there’s a problem, the code “throws an exception”; it stops running and triggers something else to happen instead.

Here’s what you do:

1. Document the decision as you would in #1 or #2 (what’s the problem, what are the options, what are the tradeoffs).

2. State your “recommendation” — the option you want to go with.

3. Email this to your leadership team (include a traffic light!)

4. Tell them you’ll move forward with this decision unless you hear otherwise in some time period (typically 48 hours).

   1. If you don’t hear back, the decision is made.

   2. If you do hear back, you can go into “escalate” mode.

You would not believe how effective this is!

1. Teams are empowered to make decisions without everything being a costly escalation.

2. Leadership is empowered to intervene if they’re worried about the direction the team is headed in.

3. The team learns, over time, which decisions they can take (#1) and which need leadership involvement (#2).

However, if you’re on the leadership team - you’ve gotta watch your inbox. If a decision comes across your desk that you don’t agree with and you don’t “throw an exception” then you’re tacitly approving the decision.

It’s important to note that this tactic may not work well in every company. You need to be in a culture where teams are empowered to make decisions, and leadership trusts their teams to pull them in where needed (vs where leadership expect to sign-off on every decision). In this case, my recommendation would be to talk to your leadership team and say something like:

We’d like to move faster by talking more decisions within the team. We think this will be better for our customers and our business. We’d like to make sure you’re involved in the big decisions, but for some decisions, we’d like to start emailing you with the decision, and giving you 48 hours to let us know if you disagree. Here’s some example decisions we’d make using this process. Does this sound right to you? Can you give us any guidance of the kind of things you’d like us to escalate to you vs make ourselves?

Then, at first, use #3 (throw an exception) liberally — both to get your team and the leadership team used to it, and so both sides can fine tune their understanding of where line between #1 and #2 really lies.

But in the organisations I’ve worked in, I’ve found this works really well. In very few cases have I or my leadership team thrown an exception — but in the cases they did, it saved significant thrash on both sides.

How do you decide between #1, #2, and #3?

The lines are often blurry - otherwise why would I have written this post! It also depends a lot on your team, what you’re working on, the culture of your organisation, and the trust you have between you and your leadership team. There’s no formula.

And even in cases where there is some objective formula (like the budget example above), there’s sill cases where you may need to move fast (#2 is best) but are outside those rules (#1 technically applies). What if, for example, you need to make an urgent payment out of budget to prevent something breaking, or prevent a security incident? In these cases, #3 is also your friend.

The real answer is: talk to your leadership team. It’s their job to empower you, but their it’s also their job to be responsible stewards of the business. If teams within their purview are acting recklessly, that may not be acceptable to their leadership team.

Conclusion

This is a very simple framework, but in my experience it works wonders. Teams get to move fast, and leadership get a way to ensure they’re aligned with what their teams are doing, without significantly slowing things down.

Next time you’re making a high-stakes decision, offering your leadership team the opportunity to “throw an exception” should help you move faster.

I tried really hard to find a word that meant the same as “throw an exception” that ended in ‘-ate’. Then we’d have had communicate, escalate, somethingelse-ate. But I came up dry. If you can think of a word that fits, please let me know, it would make me very happy, and this blog post 33% better!

Thanks to Shachar Meir and Tim Adnitt for reviewing early drafts of this post and for their excellent feedback.

Today, I want to dive into the design details of the Beosound 9000.

What the hell are you talking about?

The Beosound 9000 is a CD player made by Bang & Olufsen, a Danish manufacturer of high end audio and video gear. They have a long history of making unusual and distinctive products — and this is one of their most recognisable. It’s been called “the most iconic music system ever designed”.

It was designed by Dave Lewis, launched in 1996 (peak CD) and made for 16 years until production ended in 2011.

In world where most CD changers looked like this…

…the Beosound 9000 certainly stood out….

Unusually, it could be vertically or horizontally wall mounted, stand mounted or placed on a flat surface. Unlike most hi-fi which hides away the gubbins, the Beosound 9000 takes the CD changer mechanism and puts it front and centre.

This is clearly a confident piece of design all-up, but it’s in the details that the quality of the design thinking really shows through.

I wanted to highlight three things that

What I love about these is that none of them are “features” — things you’d market to the user to get them to buy your product — no, they’re just details that, if they were not there, would make the 9000 less, awesome. These details are in the background

Here’s three examples.

1: The discs always finish playing the right way up

The 9000 makes a point of putting your CDs on show - especially if you’ve hung it on the wall or a stand. Part of the product’s appeal is that it’s a way for the owner to make a statement: “these are my favourite albums” or “here’s what I’m listening to at the moment”.

But most CD labels have an orientation — they’re meant to be read one way up — and I can attest that when you load in a disc, it’s natural to place it to be read through the glass.

But a CD player has to spin CDs to play them — and wouldn’t it look messy if, after being played, they ended up arbitrarily rotated?

Whelp: the designers thought of that!

When the Beosound 9000 picks up a CD, it remembers the orientation it was it, and returns it to that orientation after playing. Check it out….

Let’s see that again close up:

That’s really not very easy to do. It took more than strong design thinking - that took engineering work, and likely required specialist components that increased the cost of the device. I don’t know of any other CD player that needs to remember which way to put back a disc. But this one does.

2: The rotatable logo

As I mentioned above, the 9000 can be placed on a table top, or hung on the wall. If hung on the wall, it could be mounted vertically or horizontally.

The B&O logo only appears in once place (typically understated) on the 9000, the CD player head. But the orientation of the logo would depend on how you’d mounted your device, and that might look a bit funny, mightn’t it?

Whelp, the designers thought of that!

The circular surface on which the logo sits it rotatable. You can turn it to match the orientation of your 9000 so the words “BANG & OLUFSEN” are always the right way up.

Tiny detail, utter class.

3: The rotatable control panel & display

The 9000 has a control panel hidden under a flap so those unsightly buttons don’t ruin the sleek lines of the device.

But like the logo and CDs above, these buttons have orientation. And the 9000 was designed to be mounted all kinds of different ways. It’s suck if the buttons were the wrong way up right?

Whelp, the designers thought of that!

The control panel is reversible — not “you’ll need a screwdriver to do that, mate” reversible, you can just lift the whole panel off it’s magnetic mounting, turn it round, and put it back in. While the device is turned on.

And what’s more — and this is genius — when the 9000 detects you’ve turned the control panel around, the dot matrix display also flips 180 degrees so its orientation matches that of the buttons.

Check it out:

Again, this is super not-easy to do. The control panel needs a special connector, and the circuitry needs to handle the buttons being ‘hot-swappable’ — which would have required work (and additional components) in the engineering stage.

I’m sure there were arguments about this. Is it really needed? What is the impact? How do we know how many people will need this feature? But on this product, and at this company, I doubt this was a data-driven decision. This was about intuition, craft, and conviction. Perhaps they did some users testing — I’d love to know.

Summary

Was the Beosound 9000 a “successful product”?

I think so. It was manufactured for 16 years across three versions. And here I am three decades after it was designed writing a blog post about it. It was never designed as a mass-market product. It was and is expensive.

But part of the reason people paid so much for it was not only because of the statement design, but because this was an object so thoroughly thought out.

There are great products which are cheaper, and more widely adopted — but these surprising design details are what give the Beosound 9000 a place in my heart (and, now, in my home!).

1. something I’m naturally passionate about,

2. where the leadership team is based in EMEA.

I started DJing, believe it or not, when I was 8. My dad ran a school and by 10 I was running the school discos there and at my youth club. While I was a pretty rubbish young piano player, at 12 I found my musical calling: the drums. Cue years of being in bands, performing around the UK and occasionally abroad. At university, I did student radio and had a DJ residency on weekends.

Music and technology are the twin passions that have shaped my life.

Which is why I’m beyond excited that today I’m joining Soundwide as their Chief Product Officer.

Soundwide is the company that brings together some of the most influential and respected names in music tech: Native Instruments, iZotope, Brainworx, Plugin Alliance, and SoundStacks.

Many of the songs you know and love were created or mixed using their technology, as well as your favourite TV shows and movies. The use cases range from restoring old audio recordings, to empowering the most cutting edge creators, producers, and artists at work today.

These brands have a long and illustrious history, and it’s beyond an honour to have the opportunity to work with the talented and experienced people behind these products.

And after 12 years working mostly with teams 8 hours and 5000 miles away, I’m excited to be working with our teams that are closer to home in Berlin, Langenfeld, London, and Boston.

I’m excited and nervous. There’s lots to be done: bringing these companies and their products together, accelerating the rate at which we ship new features, crafting the next leap in hardware, and moving the music creation world from its 20-year home on the desktop toward the web, mobile, and the cloud.

I plan to continue blogging right here when I can find the time. I’ve enjoyed getting back into writing in my three months off — and I hope the experiences and ideas I share here are useful to even just a few people.

Wish me luck!

• “Precision” is a measure of the accuracy of a detection system. Improving precision is to reduce your false positive rate.

• “Recall” is a measure of the coverage of a detection system. Improving recall is to reduce your false negative rate.

When I joined the Integrity team at Meta in 2018 (often known elsewhere as “trust and safety”) I’d come from ~3 years building enterprise communication products. I had a LOT to learn, and fast.

Two words I kept hearing a lot were “precision” and “recall” - which, at the time, I didn’t understand. Googling resulting in lot of hits about search result pages. What did that have do to with keeping people safe online and upholding our Community Standards?

Luckily, we had a badass PM, Eng, and DS team who gave me a crash course — and the goal of this post is to be the article I wish I could have sent myself back in 2018 when I realised these were concepts I needed to understand fully, and fast.

Once you know what precision and recall are, you’ll see them everywhere. Policymaking? Policing strategies? Netflix recommendations? Digital marketing? Kids birthday party invites? All precision & recall problems. Seriously.

Let’s imagine you want to find all the “bad stuff” on your website that lets people upload their own content. Let’s also assume we have some definition of “bad” that’s been lovingly crafted by your policy team (or perhaps imposed by your local government).

Sadly, there’s no checkbox when people upload new content that says “this is spam” or “this is a fake account” — so you have to go find it yourself.

But even if you could magically scan through everything being uploaded now and everything that’s ever been uploaded in the past (extremely non-trivial), then how do you actually determine what is good and bad?

While some nudity, for example, is clearly sexual in nature (let’s assume that’s in the “bad” camp). But what about people’s beach holiday snaps where there’s perhaps a lot of flesh on show? Visible male nipples may be OK, but female nipples may not be — but what about someone breastfeeding? or men with gynecomastia? Or people in gender transition? Or things that look like boobs but aren’t. Context matters.

It’s tempting to think of detection systems as binary — but nearly all are actually probabilistic. When a detection system looks like it’s giving a binary output (bad or not bad) then what’s likely happening behind the scenes is that someone has picked a threshold above which we say “bad” and below which we say “good”.

This gives rise to two very important properties.

• what is predicted (or detected) as good or bad - as determined by a detection system that can operate at scale (e.g. automation, human reviewers etc)

• what is actually good or bad — as determined by some expert analysis (“ground truth” e.g. a trained professional or a court of law).

This leads us to something known as “the confusion matrix”. It’s called that for good reason because it messes with your head — but stare at it enough and eventually it will click:

In the ideal state you want to be in a state such that:

1. Everything you detect is bad (high true positives, low false positives) → we call this precision.

2. You detect all the bad stuff (high true positives, low false negatives) → we call this recall.

Let’s use an example:

In this example, our system has detected 9 items, 8 of which, upon deeper evaluation are actually bad, and 1 of which is actually good (or more properly, “not bad”). This rogue item is a false positive (something we detected as bad that was not actually bad). This gives us a precision of 88% - not too shabby. Still, that one person that got (for example) their Twitter account disabled is gonna be, understandably, super pissed.

But look, we missed a TON of bad stuff — 12 bad things are still out there. This means our recall was only 40%. For every bad thing we take down, there’s on average nearly another that we didn’t find.

So lets try and capture more of the bad stuff by re-tuning our detection system to be more “sensitive”…

Yay, we’ve now detected all the bad stuff (recall is 100%), but at what cost? Our system now thinks 30 items are bad, but only 20 actually are — the other 10 are false positives. That means for every two bits of, say, hate speech we’re detecting and taking down, we’re taking down one bit of legitimate speech (precision 66%). Not awesome for freedom of expression. Is that the right tradeoff? Depends on your point of view.

While it may be temping to view things as both binary (good or bad) and always accurate (detected good = actually good, detected bad = actually bad) — in reality, things are much more complex.

The unary concept of “accurate” doesn’t even cover it — to describe these systems properly we need the twin concepts of precision and recall.

Now that we’ve clearly explained these two concepts you’ll see them everywhere…

1. Fire alarms — you want them to go off when there’s a fire (recall) but only when there’s a fire (precision).

2. Fraud detection — you want to block all fraudulent transactions (recall) but not block legitimate payments (precision).

3. Party invites — you want to ensure all the fun people are there (recall) and all the people there are fun (precision).

Trading off precision and recall

While the ideal state for any detection system is high precision (no false positives) and high recall (no false negatives) this is impossible to achieve in practice.

As the designer of a detection system, one of your critical tasks is to pick an operating point — set the parameters and thresholds of your system that are reasonable for your particular use case. But this always means trading off precision and recall.

To make and informed choice about this, we can plot the “precision-recall curve” of our detection system on a chart:

Note: creating a chart like this isn’t trivial either — you need to take your detection system, and have it run over a set or known-bad and known-good items at a variety of thresholds.

To understand this chart, lets pick a couple of points at the extremes of the curve:

1. At point #1, we have a precision of ~98%, but a recall of only 10%. That means when our detection system trips, it’s right 98% of the time — but still wrong 2% of the time. But we’re only catching 1/10th of the bad stuff. For every one bad things we find, there are 9 still out there!

2. At point #2, we have a recall of ~95%, but a precision of only 30% — so for every one bad thing we detect, we’re detecting 2 good things.

Neither of these extremes is likely acceptable; but the appropriate point on the curve depends on the problem you’re solving, and your point of view.

In general terms, high-recall low-precision is favoured when the cost of acting is low, but the cost of not-acting is high. And vice versa.

Examples that favour precision over recall:

1. Justice systems: the principle of “innocent until proven guilty” along with the requirement for majority (sometimes unanimous) jury verdicts aims to minimise the number of mis-convictions. But this is at the cost of recall — someone who did indeed commit the crime may “get off” due to lack of evidence (false negative), which is deeply frustrating to victims. But this is generally because the penalties courts administer can be severe (loss of liberty, death) so there’s a desire to keep precision high to ensure punishment remains legitimate.

2. Social media moderation: Social media allows people to express themselves online - sharing things with family and friends, or publicly. Freedom of expression is something people expect in real life and thus they expect that in their digital communication tools. When people feel their speech is being unduly impinged upon, it can cause deep resentment and anger. More broadly, there are, let’s say, historical examples of why censorship is problematic. As such, most social media companies generally hold a high bar for precision, at the cost of some recall. Some may see this as unacceptable (“you’re letting all this bad stuff happen!”) but if they could see the precision-recall curves, perhaps those critics would be more aghast at the freedom-of-expression implications of operating at a different point on the curve.

Examples that favour recall over precision:

1. Fire alarms: A fire alarm that doesn’t alert you of a fire is not much use. While false alarms might be annoying, they’re far less annoying than dying. Fire alarms thus normally favour recall (go off even when you burn some toast) over precision (where there’s smoke, there’s not always fire).

2. Initial cancer detection: Successful treatment of cancer is dramatically more likely if detected early. Doctors will therefore likely order diagnostic tests when they’re even slightly worried a patient may have cancer. While these follow up tests (biopsies etc) are high-precision and high-recall, the cost of these tests is low, but the cost of missing cancer early is high (dramatically lower survival rates).

Key task #1 - Pick the operating point

Given a system with given precision-recall properties, someone needs to pick the threshold at which it operates.

This isn’t often a technical job — it’s one of POLICY. What’s the right balance of FPs to FNs? What is acceptable to your stakeholders? How do you defend your choices? Policy folks, of course, would rather not have to make this decision because engineering have devised a perfect system with no precision-recall tradeoff.

Key task #2 - Improve the precision and recall of the system

In automated systems this generally is the job of the engineering & data-science teams. In human-driven systems it’s generally the job of the operations managers. There are choices to be made here too:

1. Do you focus first on improving the precision part of the curve or the recall part of the curve (again, likely depends on your use case).

2. Perhaps there are subsegments that you want to get better at more urgently that others (e.g. is it more important to have high-precision, high-recall detection of hate speech in some languages vs others?)

Some ways to improve precision & recall

1. Refine your definitions of what’s good and bad. The performance of a detection system is fundamentally dependent upon the definition of, well, what you’re trying to detect. If the definition is wooly, then it’s hard for anything (human or machine) to separate “good” from “bad”. If you can make your definitions clear and objective, it’ll be easier (although not easy!) to build a high-recall, high-precision detection system.

2. Chain systems together. A common way to improve the overall precision and recall of a system is to combine different detection methods that have different precision-recall properties. For example, a machine learning classifier has the benefit of being able to run all day, in milliseconds, on every piece of content (CPU cost allowing!) - something a human reviewer can’t do. So you could have your automation running at a lower threshold (lower-precision, higher-recall) to create a “shortlist” of “potentially bad” items which you then put in front of a well-trained human reviewer (high-recall, high-precision, but slow and expensive) to make the final decision.

   

3. Apply new technology. In content moderation, early systems were keyword based, but these are easily avoided by bad actors. Today, social media companies use machine learning that can weigh many more factors. Machine learning technology itself has improved dramatically over the last 5 years and continues to evolve.

I hope you now have a solid grasp of the basics of these important and widely applicable concepts. Getting this stuff clear in my own head was critical when I worked in online safety, but I’ve found them to be useful more generally at work, and in life more broadly.

I’m a product person, not a data-scientist or a machine-learning engineer — and there is a LOT more depth behind these topics than I’ve explained here - but this is the post I wish I’d been able to read when I realised these were things I needed to quickly understand — and I hope it’s been useful for you too!

Further reading:

• Wikipedia: Confusion matrix

• Wikipedia: Precision and Recall

• Doug Steen: Precision-recall curves

• Meta AI blog: Here's how we're using AI to help detect misinformation

• Wikipedia: F-score

I worked at Meta for over 12 years. Meta’s offices have a solid poster game. If you’ve ever visited one you’ll know what I mean. The walls are covered in posters bearing maxim’s to live work by.

This tradition started, the story goes, when the company approached 150 employees (Dunbar’s number). A designer, Ben Barry, realised that as the company grew, it would be harder to infect new joiners with the principles and tenets that the first employees organically shared. A screen-printing enthusiast, he made up some posters and stuck them around the office. People loved them, and this idea developed into the Analog Research Laboratory - a space that started in Facebook’s HQ, now replicated in Meta’s major offices around the world.

Now, you may sniff about “corporate propaganda” or “employee brainwashing” - but company culture is important — it helps people understand what to do and how to behave at work. As someone once said “culture is what people do when no one’s looking”.

Some of these posters didn’t resonate with me, but some really did, and often helped me at pivotal points in my career or development of a product — so I wanted to share some of my favorites with you, explain what they mean to me, and show how they might work for you.

1: “Done is better than perfect”

This is about two things: A) improvement through iteration and B) opportunity cost.

A/ Iteration

Building things is fun and safe. Shipping things is scary. When you ship, you lose control, and risk the embarrassment of your decisions and assumptions being proven wrong. As a result, there’s an intrinsic pressure to keep iterating; to try and anticipate every need and iron out every kink.

But perfection is impossible to reach. And you’re not solving anyone’s problems if the product is still in the lab. Often the best way to travel the asymptote toward “perfection” is iteration — get things into people’s hands, see how they react, and make improvements based on the feedback.

Of course this is not an invitation to ship shitty products. In fact, in the last few years at Meta, there was somewhat of a backlash against this value, with “build awesome things” being added to the company’s values in response to a perception that some teams were shipping lower quality product than leadership would have liked.

But I still believe “done is better that perfect” is a valuable frame. It’s a reminder to overcome your fear of shipping - and force you to be humble about receiving and acting on user feedback — rather than trying to chase perfection.

B/ Opportunity Cost

Recall the 80:20 rule - the idea that 80% of the value requires 20% of the work, with the last 20% of the value taking 80% of the time. Is that last bit really worth the cost? Sometimes yes (e.g. regulatory compliance or privacy where edge cases are important), but often, no. If you’re spending a ton of time on things which have limited value (the last 20%) then that’s time you’re NOT working on something else of high value.

If your job is to maximise value, you’re doing your stakeholders (customers, investors etc) a gross disservice by not calling something “done” and moving on to more impactful things. For completer-finisher types, this can be frustrating — but we’re here to have impact and create value — not make ourselves feel better.

This is similar to Steve Jobs’ “Real artists ship” or “perfection is the enemy of the good”. But I love the simplicity of “done is better than perfect”.

Takeaways:

• What is actually BLOCKING you from shipping? Most of the things on your backlog are likely nice to have’s, not essentials. If so, why are you not shipping sooner? Done is better than perfect.

• Are you spending your time discussing product details where the decision won’t have much impact on the user base? Is this a decision that can easily be changed later? Done is better than perfect.

• Are you discussing features where there’s not a blazingly obvious user need? Done is better than perfect.

2: “Don’t mistake motion for progress”

We’re all busy, we all have a lot to do — but just because we’re doing things, doesn’t mean we’re actually making progress. There’s meetings to attend. Emails to reply to. But is this actually having impact? Does this clearly move you toward having impact?

Now meetings and emails are necessary, but they’re not sufficient for success. I used to work at an organisation where you could literally coast for 30 years just by writing emails and attending meetings. People were not being held accountable for creating business impact. There wasn’t a culture of questioning if what people were spending their time on was impactful, or clearly driving progress toward future impact.

A story:

Back in 2011-12, I spent a bit of time in developer advocacy & developer marketing. There was a lot of excitement about events. Flying around the world, going to cool places, asking developers to use our stuff. It was BUSY. We had to write presentations, build sample code, get people to attend, rehearse, and ensure everything went well.

But was it motion or progress? At the time, I remember thinking we were having impact! But our very smart manager did something unusual in the world of developer marketing: they built a data pipeline to track event attendees, and their later engagement with our products. Ideally, people who’d attended our VERY EXPENSIVE events would be more likely to adopt, and more likely to be successful with out tools.

Turns out, over many events and many months, we couldn’t see any real uplift from event attendees vs regular developers.

We thought we were measuring progress: # of events run, # of attendees — but we were actually just measuring motion - things we thought were important, but didn’t have any clear connection to business outcomes.

Sean Byrnes has written about this eloquently and persuasively. He offers a simple framework:

Activities that are internal to the business are motion. These include: Implementing new tools; Implementing new processes; Building a new report; Attending regular meetings.

Activities that affect your position in the market are progress. These include: Adding new customers; Improving customer satisfaction; Making money; Hiring new people; Layoffs.

The Breaking Point

Don’t Confuse Motion with Progress

It’s so easy to be busy. There are meetings to attend, reports to write, emails to send and planning to do. You also need to be active on social media, build your network, catch up on podcasts and read newsletters (hello!). All of that activity easily fills your day, and you are so busy it feels good. But are you productive…

Read more

3 years ago · 8 likes · 2 comments · Sean Byrnes

“What was the impact?” is the single most powerful question in management. If you (or the person your questioning) can’t immediately explain the business impact — or how this thing clearly moves us toward creating business impact (progress): you have a problem.

3: “What would you do if you weren’t afraid?”

When you assess situations and make decisions, you do so with inherent biases based on your beliefs, principles, and past experiences. You can’t eliminate bias, but you can try and identify them, and control for them.

Fear is a powerful biasing factor. Most us are wired to avoid risk and maximise self-preservation. This poster is a reminder to check yourself against the intrinsic fears that are holding you back.

In a work context, these might be things like:

1. Giving up on a product that’s not succeeding for fear of being seen as a failure.

2. Fear of a big redesign because you’re worried about losing existing loyal customers — even though you know you’ve hit a limit with your current design.

3. Not taking a new job because you know you can succeed in your current role.

4. Not speaking up in a meeting because you’re worried you’ll reveal your ignorance or lose credibility.

This poster’s message is powerful because invites you to identify (like, actually write down) the things holding you back. And once you do, you’ll often you find they’re not things which should hold you back at all.

Take my list above:

1. There’s no prizes for continuing to invest in a dead product - so why are you still working on it? Admitting you need to change course might hurt your pride in the short term, but clearly better for everyone in the long term.

2. Many products have had massive redesigns and kept their customer base, you just need to think about how to help your existing folks learn the new ropes. If you don’t change you can’t grow!

3. People change jobs all the time. In fact, moving between companies is the best way to grow in your career because you’re exposed to so many more situations. Again, some short-term pain for long-term gain.

4. If you have a question in a meeting, I can guarantee other people in the room have the same question. By speaking up a) you’re gaining credibility with them, and b) you’re highlighting something that’s not clear — likely enabling the thing you’re questioning to be improved.

It’s as simple as that. It’s like an A3 therapy session: and it’s amazing how many things you can either discard, or at least identify and then start talking about with your team.

4: “It isn’t prioritisation until it hurts”

Resources are not infinite. You don’t have unlimited people, money, or time. You need to choose what do work on. Prioritisation is thus a key skill in product development - but almost universally, I find teams are unwilling or unable to prioritise hard enough.

What you often see is people doing “obvious” prioritisation — de-pri’ing a feature that’s clearly only valuable to a few customers, or marking as P3’s the things you’d like to do, eventually. Why do we do this? because it’s easy. And easy things are fun to do.

But this isn’t where you should be spending your time — you need to be up the other end of the roadmap looking at your P1’s.

If you only de-pri the easy stuff, you’ll end up with many high-pri things to do — each of which looks important and urgent — because because you’ve not had the hard, frank conversations required to really really tease out what matters most.

Prioritisation is hard because, as Steve Jobs once said, it’s about “saying no to good ideas”. This means prioritisation conversations should be hard. They should feel tense. There SHOULD be very smart people on both sides of the argument. When you make a decision to pursue X over Y — you SHOULD feel some pain, risk, or worry.

You are going to piss some people off. That’s a signal you’re doing it right, not wrong.

Things to think about:

• Stack rank: As a team, ask yourself the question: if we could only do ONE of these two things, which would we do?

• Sequencing: If you have two things that are clearly important — ask yourself, is one more urgent than the other? If feature A is as valuable if built next half as it is this half, but feature B is more valuable if built now, then build B before A. Remember (and say to yourself and your team!) that just because we’re down-pri’ing thing X, doesn’t mean it’s not important and we’ll never do it — it’s just less important RIGHT NOW — it may well be the most important thing next planning cycle.

• One in, one out: When someone asks for “just one more thing” in the roadmap: ask them: which of these other features would they’d like you to drop? If they can’t identify one, you’ve already done your job well.

Read a more thorough exploration of this idea from the wonderful Ami Vora.

5: “Move Fast and Break Things”

This is probably the most famous; and most misunderstood.

Later iterations in included “move fast with stable infra” (awkward) or just plain “move fast”. Some people took the original framing to encourage recklessness — to operate without thought for consequences. But it never meant that to me. Let’s break it down:

A/ “Move Fast”

The ability to react quickly to new information is, I think, one of the most important predictors of successful teams. That’s because product improvements aren’t linear — they compound. A team that can ship 50 iterations a quarter is going to pull away from a team that can only ship 10.

Moving faster might seem obviously valuable, but it’s hard. Inertia is everywhere. It’s easy to stand still - keep doing what you’re doing, or wait until you have more information to reduce risk.

A story: When I joined in 2010, Facebook released code (to the web tier) weekly on a Tuesday (with smaller pushes for bug fixes on other days). In 2017 they moved to continuously deployment. Once an engineer committed a diff, it was going to production in 5 hours or less whether they liked it or not! The company grew more than 50x in terms of employees over that time. Normally things slow down as companies get bigger. At Meta, they sped up.

Now, this increase in speed wasn’t accidental - it was intentful, It took WORK. A lot of work. And created risk — potentially making it more likely for a bug to takedown one of the worlds largest communication platforms on whom billions of people relied.

So why did the company invest in reducing commit-to-production latency? Because speed enables success. It enabled the company to better serve it’s customers. Teams could react to changes in user behaviour within the day! When bugs were found, they could be fixed within the day! It enabled teams to launch orders of magnitude more experiment variations than they otherwise would have. The benefits of speed compound.

B/ “Break Things”

Some people have read this as “cause disruption without thought for the consequences” - but to me this means something more subtle: have a healthy disrespect for the status quo, and a willingness to question why things are they way they are.

Progress comes by changing things: seizing an opportunity that didn’t exist before. But changing things often means “breaking things” — that doesn’t mean laws, or regulations - but it might mean established user behaviours or business practices.

Some things are the way they are because that is, indeed, the optimum. Other things are the way they are because they were designed in the past with different constraints (e.g. technical, financial). This poster reminds us to question which is which.

A story:

Before 2006, the home page of Facebook was your own profile. In 2006, they developed News Feed - a stream of updates which saved you from having to visit each friends’ profiles individually. Testing showed this was dramatically more engaging. People who had Feed spent more time on site and engaged more deeply, which benefited everyone through the network effects. Yet upon the launch, there was uproar: “how dare you change my Facebook” and “bring back the old Facebook” etc. The team could have backed down, reverted to the old design — but they didn’t. They stuck with it. They heard the user feedback and implemented some changes, but they had the conviction to hold course. They lived up to the poster on the wall.

Today, we can’t imagine a world where the default view of a social app isn’t some kind of feed. Facebook, Instagram, TikTok, heck even LinkedIn.

Break things doesn’t mean “be reckless” and it certainly doesn’t mean “break any laws” but it, to me, does mean: have confidence to push for something you believe is better, even when lots of people might be telling you its’s not.

There’s a lot more posters where those came from, but these are the ones that have stuck with me.

What other posters have you seen that have impacted how you approach your craft?

1. Scorecards are a way of setting goals and tracking progress…

   1. before you’ve launched (and no one is using your product,

   2. before you’ve got regular product metrics stood up, or,

   3. when you need to aggregate progress across a broad portfolio where there’s no unifying metric that everything ladders up to.

2. Approach:

   1. Create a table that captures the key dimensions of what you need to deliver, and create a scoring system (e.g. 0, 1, 2, 3) for each cell.

   2. Compute your “score” by summing the value of the cells — and track that score over time.

   3. Set goals based on increasing the value of the scorecard over time.

The best way to measure the impact and performance of products is through metrics. Ideally, we define the goal (the real world outcome we want to create) and then define a metric which represents the closest operable proxy for tracking your progress to achieving that goal.

This often means metrics like monthly active users, messages sent, impressions, retention rates, engagement rates, transaction rates, or revenue run rate.

But to have metrics like this you need two things which are not always possible: 1) a product that people are using and 2) an implementation of the metric itself!

• What if your product is pre-launch; there’s no one using it yet? How might you track your progress in getting it ready to launch?

• What if measurement takes a long time to setup and validate? How do you track your progress to having logging setup, pipelines running, curves calibrated, movements understood, and dashboards rendered?

• What if your product space is diverse, and you have many metrics which aren’t directly comparable, or don’t ladder up to a single top-line value (e.g. revenue)?

How might we track progress in these cases?

One tool I’ve found very effective in these cases is the scorecard.

Scorecards are a way of tracking progress over time that’s granular enough to goal against when:

1. you don’t (yet) have traditional product metrics (e.g. user activity like visitation, clicks, impressions etc) setup, perhaps because you’re pre-launch or still need to build out those metrics, or;

2. you need a way to aggregate progress across a broad portfolio where there’s no single unifying metric that everything ladders up to.

I’ve used this framework again and again across multiple projects, and it’s worked for me both at the feature level (one PM, ~6 engineers), all the way up to the org level (~20 PMs, 180 engineers).

Let’s get into some examples!

Example: Workplace Invites

I worked for a time on something called Workplace, an enterprise communication and collaboration tool. We were working on a version that could be organically adopted by users and teams self-serve, rather than being setup and deployed by a company’s IT department. This meant we need to make it easy for people to invite their co-workers by email address.

Workplace was based on Facebook (Post in Groups in Feed, plus Chat), and a Workplace “instance” was essentially an empty, private version of Facebook for you and your company.

But Facebook, has never really been empty. All the inherited user invite typeaheads (e.g. add user to a group) were built to let you search for one of the 2+ billion existing Facebook users. There were some big product gaps:

1. We didn’t have a way for people to invite coworkers via email,

2. we didn’t have a way to send those invites with secure links,

3. we didn’t have a way for the recipient to follow the invite link, sign up to the same instance as their inviter, and

4. we didn’t have a way to notify the inviter that their invitee had accepted the invite and joined the instance - critical to enable them to then communicate with each other and built trust in the reliability of the product, especially as it was generally an async process.

To make matters worse, there were invite surfaces (invite to the whole Workplace instance, or invite to a specific group) and there were multiple platforms (web, iOS, Android, m-web etc). Multi-platform support was critical as the invitee could be on any platform, and we wanted to make it easy for them to join AND easy for them to invite the next wave of coworkers.

Not having a bulletproof invites mechanism is clearly a showstopper for a product that relies on organic growth, so we considered these gaps launch blocking.

Our goal was to get XXX,000 users using the product by the end of the half, but we couldn’t even get our FIRST user until we’d made it possible to invite their co-workers in the right places.

So how can a team measure it’s progress toward this primary goal when we have all this work to do before we can even start counting users?

Quick reminder: why goals matter.

1. They unify a team (or org) around a common objective. Everyone can (or should!) understand what they goal is, why it matters, and how their work (as a team, and at an individual level) ladders up to achieving that objective.

2. Tracking progress towards goal is important because it helps everyone have the same understanding as to if they’re on track to meet it. And everyone having that same understanding increases your chance of success.

   1. Read some more of my thoughts on the importance of how to clearly track progress toward a goal in The Perfect Chart.

Back to the example: Enter the scorecard

So we had multiple invite sending and redemption experiences to build, on multiple platforms, so we needed a way to track granular progress towards shipping all those features before we could welcome our first user.

We created a table with rows for invite type, and columns for platform or notification type. Then we started tracking the state of each cell in our daily standup. In the first, simple version, we’d turn a cell green when the code was in production and had been tested and passed by QA. Done done.

Here is a screenshot of the scorecard as it was on 28th Jan, 2017…

And here’s the scorecard just three weeks later…

Look at all that sweet, sweet progress (note the extra mWeb column, we realised we also needed to add invites on mobile web too as as in testing, lots of users were opening the invite links on their phones before they’d got the app installed.

The team’s goal was simple: turn every cell green by the end of Q1 2018.

I, as the PM, kept track of this in that well known project management tool: Keynote! (It was literally a keynote slide).

• We had a printout of this on our team’s whiteboard (remember, this is pre COVID when we were all in the office).

• In the daily standup, we’d use a sharpie to update cell state. After, I’d go back to my desk, update the Keynote deck, and print out a new version ready for tomorrow.

• We’d attach a screenshot of the scorecard to our team’s weekly status reports so our leadership team could see EXACTLY where we were at.

Modifier #1: Tracking progress to goal

This was great for capturing state, but what about progress? How do we know if we’re ahead or behind where we need to be?

Solution: track the SUM of the scorecard over time!

There’s 28 cells, the goal is to go from 0 green to 28 green by the end of the quarter. By just counting the number of green cells, we can plot a chart over time in Excel…

Following The Perfect Chart’s rules - the x-axis was pushes out to Q1-end from the start - so the whole team could see how much time we had left.

Yes, this is basically a burndown chart in reverse, but instead of tracking “tasks done”, we are tracking functional milestones reached. Progress, not motion.

Modifier #2: Getting more granular

One of the big drawbacks of this basic approach was a cell only goes green at the end of the design→build→ship→validate pipeline. There was no way to visualise or reward progress through that pipeline.

A modification (used on later projects) was to track granular state of each cell. Instead of a binary red/green, we could have used a framework like:

• 0: Cannot invite a user from this platform.

• 1: We have designs, we’re ready to code.

• 2: Code as been committed and pushed.

• 3: Code is validated as working and user-ready (done!).

Then the scorecard would have looked something like this:

Modifier #3: Weighting

Another limitation of the framework for this project was that each cell had the same significance: shipping email invites on iOS was given the same value in the system as email invites on mWeb, despite the former being nearly an order or magnitude more important than the latter.

A solve here is to add weighing. Lets say iOS and Android each have 5x the users of the other platforms, just 5x the scores for those columns. This should incentivise the team to focus on the most impactful work first

Hopefully you can see how a simple scorecard, and tracking the sum over the cells over time turned something hard to measure (are we on track to launch?) into a clear goal, and clear way to track progress over time.

Scorecards for Managing a Portfolio

In the example above, we were using a scorecard to track the progress of a pre-launch project — our journey to build the features necessary to launch.

But scorecards can also help when you’re managing a portfolio of efforts, where there’s no single unifying metric.

Trust and Safety is a good example. These kinds of problems are notoriously hard to measure.

1. Variable measurement maturity: Prevalence measurement (a metric that tracks “how much bad stuff is there out there” - the gold-standard of trust and safety measurement as used by Meta and YouTube) is hard, expensive, and time consuming to stand up. It requires intelligent, representative sampling; Labelling (for which you need many many humans, trained in the details of your policies); And constant iteration in response to shifts in adversarial behaviour. Some areas might be mature in their measurement, others may be nascent or non-existent.

2. Lack of a common currency: The measurement of different integrity problems is not often comparable. Viewership harms (e.g. hate speech, nudity, some forms of bullying) are denominated in impressions/views. Other harms like fake accounts are often counted as a % of active users. Interaction harms like scams and grooming are often counted in terms of unique victims. Representation harms might be counted through discoverability measures e.g. % of violating search results. You can’t just add these numbers together like you can when multiple teams are driving a revenue ($$$) number. There’s no universal currency.

3. Multiple apps/platforms/services. If you run a suite of products, you might need to understand how you’re doing on each of them — another dimension of complexity.

4. Relative weighting: Some harms are more severe than others which often needs to be factored into goaling and prioritisation.

Again, the idea state is that all harms of all forms and severities would be combinable into a single metric that represents “how much bad is there” and “have much less bad is there now vs last quarter” — but this is just super super hard to do.

The scorecard could help here too.

Imagine giving each of your areas a score based on their measurement maturity - say “0” for unmeasured (the default), “1” when basic tracking is in place, “2” when a data-science-approved prevalence metric exists, and “3” when the team has proven they can repeatably move that metric as they make changes to detection, enforcement, or content distribution systems.

You could then make statements of the form:

Across the portfolio,

• 3 areas are still at 0 (unmeasured), -20% y/y.

• 5 areas are at 1 (basic), +40% y/y.

• 6 areas are at 2 (measured), +50% y/y.

• 15 areas are at 3 (mature), +0% y/y

You could then set goals of the form:

“In H1, we’ll move 3 areas from 0 (unmeasured) to 1 (basic), and 5 areas from 1 (basic) to 2 (measured)”.

This turns something extremely complicated, into a form that more senior folks (who can’t be involved in the details) can easily understand and rationalise.

I’ve seen this technique used in multiple product domains - and it’s highly effective for understanding state, and tracking progress across a diverse portfolio of related but distinct efforts.

Again, the ideal state is where each team has a metric that’s a close, operable proxy to their goal, and those granular metrics ladder up to a single, universal metric that represents the ultimate goal for your org or company.

But when that’s not realistic or possible (yet!), the scorecard is here to help.

As well as the careful choice of metrics, the decisions we make in how to present data are also powerful levers for improving a product team’s performance.

Bad charts can cause confusion and, worse, apathy. But a well-designed chart can rally a team around a goal and encourage them to excel.

Over the years I've developed a few simple rules for how to make charts awesome. I've applied these again and again on product after product and they're highly effective in getting across maximum information, with minimum overhead.

Together these rules make up The Perfect Chart.

Let's start with the kind of thing people throw on a dashboard all the time.

OK, we have some sweet, sweet data. But how do we interpret this? The metric is gently wiggling around with no spikes (that's probably good).

Let's assume this metric represents our team's primary KPI. OK, but what's the target for this metric? What's the goal? Rather than having to look elsewhere (like a roadmap doc), wouldn't it be better if we just displayed the goal on the chart? Of course it would:

Yay! OK, great. This dotted orange line represents our numerical goal. (I personally prefer metrics in blue and goal lines in orange -- it's what Meta's internal tools default to and I've got used to it).

But the x-axis of this chart ends on the most recent data point: today. Let's assume we want to get the wiggly blue line above the dotted orange line (more on that assumption later), how long have we got left to achieve that objective? Were we supposed to hit that goal last week? Or have we got more time? It's unclear.

Good news, we can make it clearer just by extending the X-axis out to the end of the reporting period like so:

Sweet. Turns out, this team plans in half-yearly cycles, so by extending the x-axis out to the end of June, we can see we've got three months left to hit the goal -- no need to panic (yet).

But there's still many questions this chart doesn't answer:

1. When did we set this goal? Is it something we've been working on since the start of the half or longer? Are we 50% of the way through our goaling period, or 75% of the way through?

2. Is the team on track to his the goal or not? Will we be successful if we keep doing what we're doing or do we need to change things up? You can kinda squint and see the trend, but two people might see that differently.

3. Is the aim to get the blue line above the dotted orange line, or is it to keep it below it? (Not everything is supposed to go up and to the right -- perhaps this is fraud rate, and the aim it to keep it under control).

We can make the chart answer all of these questions with one simple change: lets make the goal line start on the value of the metric at the start of the half, and end at the target we're aiming to hit at the end of the half:

Would you look at that - It's a thing of beauty. We can now see that:

• We set this goal at the start of the half.

• The aim is to increase the metric, not decrease it.

• We have three months left to hit it.

and crucially...

• That we're not on track to hit it!

This is the kind of view that suddenly makes a team realise that that might need to change things up. Perhaps we have the next big thing up our sleeve that'll bend the curve. Perhaps we don't.

I find this view to be extremely motivating for a team. It's suddenly extremely clear that we want to be ABOVE the orange line, not below it - and that we're not on track. Everyone can see the problem, and it forces the right conversations: are we OK with where we are? What needs to change? How do we get back on track?

But this chart could still be better. While the x-axis is now pushed out to the end of the half, we're only seeing 3 months of historical data. It makes it hard to see if the team's efforts this half are significant given the historical baseline.

Solve: pull back the x-axis to include data from the full previous half:

Boom. There we have it The Perfect Chart! This chart contains SO MUCH more information that the first version. We can see where we started, where we're going and where we came from.

We can now see that this metric was declining, and the team's efforts are bending the curve upward towards an ambitious new target. It's not essential data, but it's useful context that can help a team understand the relative impact of their work.

So here are those 3 simple rules for the perfect chart:

1. Push your x-axis out to the end of the reporting period - not the date of your most recent data point.

2. Plot a goal line, and ensure your goal line starts at the right date and value for when the goal was set, and ends at your target date and value.

3. Pull your x-axis back to show the entire previous reporting period.

Bonus round: Guardrails and counter-metrics

Earlier I mentioned that not all charts are supposed to go up and to the right. It's common for teams to take counter-metrics or guardrails -- parameters you must stay within while you attempt to hit your goal.

Take this example:

Again, without additional context, it's hard to know what this means. Is this good? Bad? OK?

Lets add in a goal line:

Let’s assume the chart title tells us this is a guardrail metric which probably means we need the blue line to stay below the orange line.

But the blue line is trending upward. Should we be worried? Should we panic?

I've seen a lot of charts like this -- we're trending toward the guardrail (bad), but we're still below it (good). One person on the team might look at this and thing "no problem" but another might start to freak out. Who is right?

In these situations, it's best to agree on what the difference between A'OK, mild peril, and total disaster.

One industry that does this really well is... aviation.

This is an airspeed indicator - and it clearly shows a green area (all good), an amber area (maybe start to worry) and red (don't go here)!

We can apply this same principle to our guardrail metric chart:

Uh oh! We're above the orange line!

This allows you to define a playbook for what to do and when.

For example, if you cross the red line, you have to file a SEV and drop everything to get it back down. And if you cross the amber, you perhaps open an investigation into what's going on.

What's great about this is that it's extremely clear what's not OK (crossing the red line) and when we should start as a team to react to an upward trend (crossing the amber line).

An alternative way to represent this which I think is even better is to take inspiration from the airspeed indicator:

So there you have it - another form of chart that makes is super clear what's going on - and allows everyone in the team to have the same understanding.

Key takeaway: just a few small changes to how you present data and goal metrics can have a huge impact on your teams and how they execute.

In my 12 years at Meta, I’ve spent a lot of time in performance mashups and calibrations discussing people’s performance and readiness for promotion.

And as a manager, PMs on my team have often asked “what is expected of me at my level?” and “what do I need to do to get to the next level?”.

These are important but tricky conversations.

Product management is a discipline that’s notoriously hard to define; what a PM does may differ greatly between teams, who they’re working with, the domain they’re working in, or the maturity of the problem. In my experience, this can make it hard for managers to give clear guidance, or to calibrate PM performance across teams and orgs.

To help with this, I’ve ended up developing a simple framework that does a pretty good job of explaining the big, common differences between what should be expected of junior PMs vs mid-level PMs vs senior PMs.

I’ve shared this verbally hundreds of times, and multiple people have told me they found it helpful to build their own mental models. I finally got round to writing it down and sharing it within Meta, but I think it may also be valuable outside — hence sharing here.

First, lets define the core job of the PM:

1. Problem: Understand user or business problems and rally people around the idea that they need to be solved.

2. Solution: Explore the potential solutions to the problem, and identify the most promising opportunities.

3. Execution: Bring those solutions to market to realise business impact.

Then, here’s broadly what PMs do at different levels.

• At the junior PM level, the problem is clear, the solution is clear, and the PMs job is mostly to drive execution. This is not to be sniffed at: driving execution is HARD. You’ve got to balance competing equities (time, cost, quality), keep people motivated and focused, anticipate and remove blockers, and keep stakeholders informed about progress.

• At mid-level PM, the problem is clear but the solution is not clear. Mid-level PMs should be able to take hard problems and develop strategies and novel solutions to solve them. They’re expected to drive consensus around these plans with their peers and org leadership. Then, they’re expect to drive execution and realise the impact.

• At the senior PM level, the problem isn’t clear, so neither is the solution. The key difference between mid-level and senior PMs is their proven ability to identify new problems that are not being solved, and build consensus a) they exist and b) they should be solved, and secure the resources needed to do so (e.g. by pivoting their team in some new direction, or acquiring additional resources). Then, they can do all the things other PMs can do: identify the most promising solutions, and drive execution.

• Super-senior PMs can do what senior PMs can do, but on multiple projects, in extremely ambiguous problem areas that typically cross org boundaries.

Here’s a diagram that captures this mental model:

This framework is pretty simple and high-level, but time and again it seems to be an “ah ha!” moment for people who’re struggling to build a mental model of what’s expected of them, and the kind of things they need to do to be considered to be operating at the next level.

Some notes:

• Non-canonical: There are other ways to become a senior IC PM — for example, at large organisations like Meta, just executing cross-company projects is a specialist skill, so much so that there’s a “Captain archetype” that IC7 (super-senior) PMs can aspire to.

• This is for ICs, not managers. PM managers’ expectations should include a whole other set of things: can they build and develop a great team? Do they show care? Can they manage underperformance?

• Incomplete: There’s more to each level than this - for example, this framework doesn’t include other ways PMs add value: interviewing & recruiting, mentoring, creating forums for information building and intra-discipline socialising.

• Meta-levels: At Meta, Junior was equivalent to IC4. Mid-level is equivalent to IC5, and Senior is equivalent to IC6. Super-senior means IC7. Different companies will have their own levelling mechanisms - hence using the more generic junior/mid/senior frame here.

Thanks to Nam, Jenny, Jess, and Maxime for reviewing early drafts of this post, and encouraging me to write it down and share it more broadly.

My current employer, like most large companies, is pretty data-driven. At scale, metrics are often the only way to rationalise about what’s happening in the community and track product progress.

Which is why it’s so important to ensure that we’re being extremely clear when describing metric movements. Getting this wrong might mean over- or under-estimating your team’s work, or some customer trend — leading to poor decision making, incorrect prioritisation, or misattributing credit.

In my experience, there’s no more common mistake than confusing the difference between percentages and percentage points when describing metric movement.

Getting this wrong can result in the reader leaving your communication with a VERY different understanding of the situation than you intended.

Example time!

Consider this line from a product team's recent weekly status report:

We increased click-through rate by 10%!

But digging in, this was a misleading statement. The problem is that click-through rate is a metric that’s already expressed as a percentage. Their baseline was 13% and their new CTR was 23%.

This isn’t a 10% increase. It's a 10 percentage point increase. A 10% increase would mean CTR had increased from 13% to 14.3% (13*1.1).

Now, you can also express that as a percentage increase, but it’s not "10%", it’s 100*(23-13)/13 = 77%!

10% vs 77%: That’s quite a difference - and if two readers have two different understandings of the same thing, and those understandings differ by such a wide margin, you can easily see how this might lead one to make very different decisions. Over time, this may compound to drastically different outcomes.

So in this case, it was wrong to use the symbol "%" - the correct articulation should have been:

We increased click-through rate by 10 percentage points.

But this also is somewhat problematic: it's missing context.

Moving something from 1% to 11% is likely a big deal (10x!). Moving something from 80% to 90% is perhaps less impressive.

To deliver extreme clarity, you really need to say BOTH (or include the from & to for context).

So ideally, this should have been articulated as:

We increased click-through rate by 10pp (13% to 23%).

or

We increased click-through rate by 10pp (+77%).

Gives both clarity and context, and leaves no room for ambiguity in the mind of the reader (note that of these two, I personally think the former is the clearer/better articulation).

Another Example

Consider the following line from another recent product team’s status report:

Over the half we reduced prevalence by 24%, 3.5% of which can be attributed to our classifier improvements.

3.5% of 24% is just 0.84 percentage points - and implies 96.5% (100-3.5) of the impact was driven by efforts others than classifier improvements - doesn’t look great for the classifier work!

But upon deeper digging, what they actually meant was 3.5 percentage points of the reduction was attributable to the classifier improvements. This means 14% of the impact was driven by the classifier work. That’s 4x more of a contribution than my reading of the original statement!

Now, another problem here is that I’m now suspicious of if there really was a 24% reduction in prevalence. The only thing making me thing that might be right is that a 24 percentage point reduction in prevalence is unlikely given that VPV prevalence, for example, is usually expressed in basis points (i.e. 1/100th of a percentage point).

Ideally, this would have been written in a way that’s extremely clear:

Over the half, we reduced prevalence by 24% (43 bips to 32.6 bips), 3.5 percentage points (14%) of which is attributable to our classifier improvements.

Again, SO MUCH CLEARER - and no room for ambiguity in the mind of the reader. Everyone can understand, unambiguously the contribution and the context of this work.

So, when referring to a change in a metric that’s already expressed as a percentage

• Make sure you’re not using “%” when you should be using "percentage points", "p.p." or "points".

• Ideally include both the % and pp movement — or, even better, the before & after value of the underlying metric.

As ever, XKCD got there first:

It’s that time of year again! If people are asking “what do you want for Christmas” or you just want to treat yourself — here’s the books I recommend reading in 2023. They come from a range of personal research and recommendations from other PMs I trust.

1. Good Strategy / Bad Strategy by Richard Rumelt
   How many companies have said: “Our strategy is to become #1 in the market”? Not a strategy! This book is an incredible primer on what strategy is and is not (and especially the latter!). Strategy development is a core part of the PM’s job - so if you’re not doing this, you’re doing it wrong. Spoiler: Strategy = an opinion about the future AND a credible plan to get there.

2. Empowered by Marty Cagan
   Another classic from the OG PM writer. A solid tutorial on how to set product teams up for success by empowering them to own the problem, not just deliver your solution.

3. Take Back Your Power by Deborah Liu
   Deb was my old org lead at Facebook, and is now CEO of Ancestry. In her time at Meta, she built TWO billion-dollar businesses (Mobile App Install Ads and Marketplace) — very few people get to build just one. She’s a solid product leader, and has a few things to say about woman in the world of work. A must-read for male and female PMs alike.

4. Becoming the 0.1% by Gareth Timmins
   A curveball. Not a book about product at all, but a book about the extreme hardship, sacrifice, and dedication it takes to become a Royal Marines Commando. In the book, Timmins takes his learnings, and translated them to be relevant in a business context. Building products in an ambiguous space is scary — you’re not sure you can do it. Reading this helped remind me that great things require persistence, belief, and grit, especially when you think something may be beyond your capabilities and self-doubt starts to creep in.

5. Billion Dollar Loser by Reeves Wiedeman
   An uncompromising take on the rise and fall of WeWork and the cult of the founder. There’s a fine line between a charismatic leader having an ambitious vision that convinces people to invest their time (employees) or money (investors) to back them — and that vision being so ambitious as to be unrealistic. A cautionary tale (as was Theranos) that it’s sometimes hard to tell the difference between what doesn’t work, and what doesn’t work yet.

6. Leadership on the Line by Ronald Heifetz
   People often aspire to be “leaders”, but it’s not always as fun as it might seem from afar. Leadership is having opinions, making decisions, and winning people round to your point of view — and often when the “right answer” isn’t at all clear — if it was clear, it’d not be leadership. In this book, you learn how to lead, but manage the risks inherent in taking a stand.

7. The Pyramid Principle by Barbara Minto
   As PMs it’s our job to think clearly, reason objectively, and communicate our thinking crisply. This book offers a framework that may help up-level your thinking.

8. Build by Tony Fadell
   Mr iPod. Mr Nest, and an OG from General Magic. Tony Fadell has had a ringside seat, or been in the ring for some of the most important digital & physical products of the last 20 years. Here, he tells his war stories, and lays out his philosophy for how to build great things.

9. Outliers by Malcom Gladwell
   An oldie, but still a goodie. What makes people successful? Spoiler alert: it’s both expertise and timing. The two compound to enable people with the right skills to take advantage of the right opportunities to produce uncommon results. Unlike some business books (that should really just be a pamphlet), this is almost a page-turner of a novel in comparison. Super compelling and easy to read.

10. Project Hail Mary by Andy Weir
    From the author of The Martian, it follows a similar style: solve one problem, then another. While the premise is far out (man meets alien in deep space) the subtext is one about ingenuity and persistence. Both things every PM needs to have in spades.

11. Secrets of Sand Hill Road by Scott Kupor
    Money is what enables founders to built the future. Sand Hill Road is (still) the epicentre for venture funding in Silicon Valley, and thus the world. What makes these places tick? What are they looking for? This book helps you understand how VC’s think. This isn’t just applicable if you’re trying to raise money — the principles apply all over - for example, how might your lobby your VP or Director for more resources?

12. Eccentric Orbits - the Iridium Story by John Bloom
    Before Elon’s Starlink, there was another upstart internet satellite constellation. It was audacious, technically incredible, and, back in the late 90’s a terrible business. This is relevant to PMs because it’s a classic story of product/market fit, timing, customer positioning, and competitive differentiation. Makes you think a lot about not just what is possible, but when is it viable?

13. Not Nice by Dr Aziz Gazipura
    As a brit, I find it hard to be direct and candid. It’s hard! This book makes the case that being candid and speaking up might not be “nice” but it’s “kind” — meaning good for them and good for you in the long run.

Happy reading!

Note: As an Amazon Associate I earn from qualifying purchases.

TL;DR:

1. Extreme Clarity means communicating something in a way that leaves no ambiguity in the mind of the reader such that all readers ultimately leave with the same understanding.

2. Extreme Clarity helps prevent misunderstandings, conflict, overlaps, or gaps in execution, and thus the time wasted resolving those issues.

3. Shorter is generally (but not always) better. Avoid acronyms. Use numbered lists. Deep link. Use absolute numbers along with percentages. Qualify your units. Highlight changes in state. Proof read before sending.

Note: This blog is a version of a post I shared internally at Meta that’s received over 520 likes, 66 comments and 73 shares. People ping me several times a week to tell me they’ve found it useful, so I thought I’d share it here too.

Communicating the progress of a product team is an essential part of a PM’s job. Leaders and stakeholders need to understand your progress and your problems. You need their support and guidance. Success depends on everyone having the same understanding of what’s going on.

But in complex areas (like, say, a high-scale digital product), it’s easy to get lost in the details. This is bad. How can leadership help you if they don’t understand what’s happening? How can teams make decisions if different people have a different understanding of the situation?

In my old org at Meta, we about striving for “extreme clarity” in how we communicate. There’s strong culture of ensuring documents and decks are written in a way that enables people to really understand the details of something, especially if they’re not steeped in the context.

I’ve had the great fortune to learn from some of the best PMs in the business. My own writing has improved as a result, to the point where I have my own tips to share.

What does Extreme Clarity mean?

Extreme Clarity means communicating something in a way that leaves no ambiguity in the mind of the reader and that all readers ultimately leave with the same understanding.

Extreme Clarity matters because ambiguity requires follow ups to resolve disagreements and misunderstandings (wastes time). If people leave with a different understanding, there’ll be gaps or overlaps in execution that may result in bad outcomes.

Extreme Clarity is hard. It takes more time to make a document or a post extremely clear, but it’s worth it — particularly as teams grow, and we work with people separated by time and space.

Let’s work through an example together.

Here’s a weekly status report from an entirely fictional integrity (aka trust & safety) product team dealing with potentially fake accounts. While fictional, this example is very similar in style to a genuine update I recently got from one of my teams.

SIP is integrated with XFAC. 20% of global detections that have 95%+ precision are XFAC-ed and there is an overall 4% conversion-rate; meaning we are getting to harm faster and curbing review workload substantially. 13% of user reports are routed to SIP’s queues. With no automations applied, the action rate is 16% for reports and 28% for feedbacks. Feature-logging completed this week so we can ramp up this percentage further and start building automations. Manually reviewed 130K and auto-disabled 105K dormant profiles for likely-PCI profiles.

When I read this, there were immediately a bunch of questions in my brain. Let’s annotate where they appeared:

SIP is integrated with XFAC [1][2]. 20% of global [3] detections [4] that have 95%+ precision [5] are XFAC-ed and there is an overall 4% conversion-rate [6]; meaning we are getting to harm faster [7] and curbing review workload substantially [8]. 13% of user reports [9] are routed to SIP’s queues. With no automations applied, the action rate [10] is 16% for reports and 28% for feedbacks [11]. Feature-logging completed this week so we can ramp up this percentage further [12] and start building automations [13]. Manually reviewed 130K and auto-disabled [14] 105K dormant profiles for likely-SIP profiles [15].

Whoa. From reading just four sentences, I had fifteen questions!

1. What’s SIP? What is XFAC? I might know, but will every reader?

2. Has it always been this way or has there been a change of state? Do you mean “…is now integrated…”?

3. Global? Do you mean “all systems”, or “worldwide”?

4. What volumes are we talking about here? How many per day? Per week?

5. Precision, relative to what? Relative to labelling? Ground truth?

6. Overall conversion rate? Does this mean across the whole funnel, or conversion rate of one step? And over what time period are you calculating this number?

7. How much faster? What reduction in latency have we observed? And while we’re at it, what harm?

8. Curbed workload substantially? From what to what?

9. 13% of ALL user reports??! (that sounds like a lot) Or just some subset, and if so which one(s)?

10. What is the definition of action rate?

11. What’s the difference between “user reports” and “feedbacks”? Isn’t a user report a kind of feedback. Are these different, or is one a subset of the other? Why would the action rate differ between the two?

12. Which of the previous three percentage stats are you referencing? The “user reports” number (13%), the “reports” % (16%) or the “feedbacks” % (28%)? Or all of them (did you mean “these percentages”)? And increase them from what to what (even ballpark)?

13. What kind of automations? Auto-close automation or auto-clear automation? Both?

14. Hang on, I’m confused — how can you auto-disable things you’ve manually reviewed?

15. What time period do these numbers refer to? a week? the last week? something else?

If I was close to this team’s work, I could perhaps extrapolate to the correct meaning — but few will be close enough to the team’s work to unequivocally understand this, and that will create problems.

Extreme Clarity would be communicating in such a way that there are no questions left in the mind of the reader, and the writer isn’t relying on the domain-knowledge of the reader for them to answer their understanding.

Let’s try re-writing that same product update with Extreme Clarity in mind:

1. The Spam Team (SIP) has started (as of 15th June) enrolling likely violating accounts into the Cross-app Fake Account Checkpoint (XFAC) at 95% precision.

   1. In the last 14 days, they enrolled 79k accounts. Since launch, 4% of accounts enrolled cleared XFAC within 7 days, in line with expectations.

   2. Previously, suspected spam accounts were sent for human-review and, if found to be violating (high-precision), were direct-disabled with appeals via Contact Forms (high friction).

   3. This has reduced our p50 actioning latency from 8 hours to 1.4 hours (-82.5%) and saved 150hrs/wk of human-review workload (~7% of overall Ops utilization).

2. Separately, 13% of users submitting feedback or reports on spam accounts are now (as of 28th June) being routed to SIP’s queues. Previously they were handled by Generic Review.

   1. With no auto-close automation applied, the action rate is 16% for reports and 28% for feedback. Hypothesis: action rate is higher for feedback because report stats are skewed by abusive reporters who (sadly) have higher intent than regular users, and thus get further down the funnel.

   2. Feature-logging was completed this week so we can ramp up the 13% further (targeting 50% by EOW) and start building auto-close automation to further increase human-review efficiency.

   3. In the last week, we manually reviewed 130K likely-SIP accounts above a 0.6 classifier threshold, of which we went on to disable 105K (equivalent to 80% precision).

What a thing of beauty!

While this version is more verbose, it’s extremely clear. It prevents all those questions arising in the mind of the reader, and leaves no ambiguity.

Now, instead of the reader having to ask basic questions like “what does that mean?”, they could ask useful substantive questions about strategy and next steps.

How can you write with Extreme Clarity?

A few simple rules can make a big difference:

1. Shorter is (generally) better than longer. The more words you use, the more opportunity you have to introduce ambiguity – not to mention lose the reader’s attention. Sweat the details. What are you saying in three words that could instead be said in two? What are you including that’s irrelevant?

   1. Yes, this was a long post — but that’s because I’m trying to engage you with narrative. To compensate, I included a crisp TL;DR.

   2. And yes, the example above got LONGER not shorter — but that’s because the purpose of a product status report is to update someone who’s likely unfamiliar with the day to day of your space in a standalone way. That requires more information inline to provide clarity. Denormalisation.

   3. But generally, shorter is better. “I didn’t have time to write a short letter, so I wrote a long one instead” — Mark Twain.
      

2. Avoid acronyms. Where you want to use them (because you’d otherwise have to repeat some long-form text multiple times) then use the expanded form first, then use the abbreviation e.g. use “Three Letter Acronym (TLA)” the first time, then you can use TLA subsequently. Even Elon Musk has banned them, except, it seems, when they’re part of his son’s name.
   

3. Use numbered lists, not bulleted lists. Numbered lists allow the reader to know where they are. It lets people quickly and unambiguously reference a point (“in 2a you say…” vs “In that bullet about X you say…”). It forces you to be clear about ordering (despite what the HTML spec says, there’s no such thing as an unordered list!).
   

4. Represent statistical changes in both absolute and percentage forms. Using either the absolute (e.g. “saved 150 hrs/wk”) or relative (e.g. “saved 7%) forms in isolation makes it impossible for the reader to understand the real value of any change. 7% could be a tiny amount top-line workload, or could be a massive amount. Similarly, 150 hrs/wk might be a tiny amount of top-line workload but might represent a heroic improvement for this team. Only with both numbers can the reader compare between teams AND understand the significance of the impact within the team.
   

5. Deep Link. Where it adds too much weight to explain something inline, deep link to a post, doc or deck that explains your point or concept in more detail. Readers that get it can read on. Readers that want more have somewhere to go to get the context. If you’re communicating via slides, including the details in the appendix is a functional equivalent.
   

6. Qualify your units. A common mistake omitting the timescale over which the presented data is calculated. (“we enrolled 50k accounts” – what? per day? per hour? per second?!). I often see HPMs say something like “we saved 100 hours of workload”. I know from experience that they likely mean 100 hrs/wk — but another reader may lack that intuition. Extreme Clarity demands you qualify your units.
   

7. Highlight changes in state. Often, I’m reading updates which highlight the great work some team has done to make something work in a new, better way. People within the team will inherently know why the old way was bad and the new way is better – but someone outside the team likely lacks this context. In order for the reader to understand the impact of this change, the writer should explain what the new thing is, AND what the old thing was — and, critically, why the new thing is better than the old thing.
   

8. Proof-read. Before you publish, stop and take a few minutes to read everything you’ve just written. Try an imagine how someone outside your team would read it — would they understand it? Is it full of inside baseball? Is every word the right word? You’ll be amazed at how much you want to change upon second reading.

   1. Even better, peer-read. Ask someone outside your team to read your post/doc/email/deck and ask them if they have any open questions after reading it.

If you’re working in a growing org or company, it’s a certitude that there’ll be fewer people that are closer to your work tomorrow than there were yesterday. If we communicate in a way that requires the reader understand the details of your space, you risk creating gaps, overlaps and misunderstandings, and that’s bad for everyone — especially your customers.

Communicating with Extreme Clarity doesn’t come for free — it takes time and practice, and, as evidenced by the example above, sometimes requires more words.

But hopefully the tips above help you understand what I mean by Extreme Clarity, and give you specific, actionable advice to improve your next code comment, task title, email subject, Google slide or Workplace post.