Skip to content

icon picker
Script

info
Just like last year, we made a script for our talk. We didn’t look at it while speaking, so the words may not match exactly, but it’s pretty close. And if you like the template, feel free to copy it and make it your own:
Copy template



TOTAL TIME:
33 mins 38 secs
Shishir
17 mins 5 secs
@
000
2.8
words per second
Yuhki
16 mins 33 secs
@
000
2.6
words per second

Search
Section
Who
Script
🖼️
Category
19
Good morning! Thank you so much for being here at Config and coming to see this talk!
image.png
6 secs
Last year... Yuhki and I were here at Config...
image.png
3 secs
And we gave our first talk ever together, called “rituals of modern product teams”....
image.png
5 secs
...which is based on a ton of research I’ve been doing talking to hundreds of companies about their rituals. I’ve become so obsessed with the topic that I’m writing a book on it.
image.png
12 secs
In last year’s talk, we specifically focused on meetings. We spend so many hours a day in meetings, and yet the overwhelming sentiment around them is that there’s boring and useless.
So, we broke down meetings and said there are really only 3 kinds of meetings...
image.png
16 secs
...and for each type of meeting, we shared rituals we learned from companies around the world... which were uniquely designed to make the meeting vastly more impactful and memorable.
image.png
10 secs
To our surprise, people liked our talk so much that we’re back for the sequel...
image.png
5 secs
and to focus on a different chapter of the book, on Planning.

image.png
5 secs
Now I know people have strong feelings about this topic.

Some people hate planning because it feels like a complete waste of time... I won’t reveal which of my reports actually said this...

image.png
13 secs
Some people see planning as a thing to “win” and can be found celebrating at the end of it, which is arguably a bit strange...
image.png
10 secs
The overwhelming sentiment though, is a sense of frustration that it feels broken.
Yes, this was actually from a past performance review, from Dylan. Thankfully I still have my job, but to be honest, this is the real reason I’m doing this talk, to get Shishir’s take on it since he’s been studying the topic for so long.
image.png
22 secs
Now it’s our feeling that planning doesn’t have to feel that way.
In fact, planning can be incredibly effective and even fun if it can be designed in the right way.
And today, we’re not going to just wow you with planning,
image.png
17 secs
we’re going to make planning wooooooooow!

image.png
2 secs
I know, some of you are like... what on earth is going on? Just... trust us, this will make sense later, we promise.
image.png
9 secs
Yuhki, we’ve had so much fun saying WOOOOOOOOOW. I know we’ll come back to it, but maybe it would be fun for everyone to get in the spirit a bit? Everyone clearly wants to say it. Ok, everyone. When I count to 3, everyone say WOOOOOOOOOW. Ready? 1.... 2.... 3! WOOOOOOOOOW.
image.png
18 secs
We’ve talked to hundreds of companies about their planning process. Interestingly, they all seemed to fit the same pattern. You could fit anyone’s summary into a sentence, kind of like a Mad Lib.

It’s some algorithm your company chooses to run...

image.png
15 secs
at some cadence, every quarter, every half....
image.png
3 secs
and it ultimately produces a particular output.
image.png
3 secs
And you hold yourself accountable to it during execution via some kind of accountability protocol.
At the end of the day, it seems that planning always seems to be defined by their 4 basic ingredients.
So today, we’re going to dive into each ingredient to share some of our favorite lessons and rituals.
image.png
19 secs
3 mins 13 secs
23
Let’s dive into the first ingredient, the planning algorithm.
image.png
3 secs
You’ll often hear about the planning process being described in the shape of a W.
Lenny Rachitsky, who is at Config today, explains this well, that a planning process often kicks off with top-down guidance and context from leadership. Teams propose plans bottoms-up in response; leadership synthesizes these into a cohesive plan, and teams make final tweaks and confirm buy-in.
image.png
23 secs
Some believe it should be more like an M-shape. Oliver, who leads engineering at Coda, believes that before any top-down guidance happens, there should be a moment of reflection from the team bottoms-up on lessons learned that help inform the plan.
image.png
16 secs
We’re not here today to tell you whether M or W is right.
But what we have noticed is, regardless of which direction you choose, there’s one way in which these planning processes are often fundamentally broken.
And it comes back to this sentiment I shared earlier. That there’s this feeling that planning is like a game you have to win. The whole point for some people is to get their project approved. To get more funding, more headcount, than other teams.
image.png
32 secs
In other words, planning algorithms produce winners and losers.
This feeling that planning is something you have to win... is really unproductive and kind of toxic.
image.png
10 secs
So this is what we have to unbreak! How might we make this less about winning, make planning feel less like a zero-sum game? And how do we instead make it about the true purpose of the planning algorithm — to get to a shared understanding of directions and priorities that help the entire company win?
image.png
22 secs
Ok let’s get started with our first ritual.
I really like Gamestorming’s “$100 voting” ritual as one solution to the problem.
Too often you’re in these planning sessions where there are like 20 different project ideas...

image.png
13 secs
...and somehow, every one of them....


image.png
3 secs
end up being P0s.

Now, how do you whittle it down? Lots of discussion. And of course it’s natural that people just advocate for their own team. After all, they are trying to “win” planning right?
So you end up with all this endless discussion. And after hours and hours, what happens?
image.png
19 secs
Success: you can mark one of these projects as P1
A huge win, right?
image.png
5 secs
The “$100 voting” exercise works exactly like it sounds. You give everyone $100, and you ask them to pretend they are the boss and they own the budget — how would you distribute those dollars across these different initiatives?
image.png
14 secs
It really works! It’s a bit like voting, but you get a feeling for how much people want one idea.
But that’s note the main point: The key is that it forces them to take off their team hat, and wear the CEO hat. It’s a real budget, with real constraint. And they forget about having their team win, and focus on what’s right for the company.
image.png
24 secs
We use this technique at Coda all the time. Our head of eng, Oliver, esp loves it. He’s German and he told me there’s actually a German word for it — he’s kept trying to teach me to pronounce it correctly but I’m not going to try on stage.
In any case, next time you see your planning process stuck with each team trying to “win”, try out $100 voting and see if re-orients everyone back to the company mindset.
image.png
29 secs
Airbnb has a different ritual that similarly encourages people to think beyond the confines of their own team and their own ideas.
They call it crafting the “11 star experience.”
So let’s start by imagining the 1 star experience. You get to your Airbnb, and no one’s there, and you can’t get in.
image.png
20 secs
Let’s skip to a 5-star experience. It’s one where everything worked as expected, with people answering the door and showing you around.
image.png
9 secs
A 6-star experience might be that you get in, you’re welcomed with a tour, there’s free wine, toiletries, and more.

image.png
8 secs
A notch above that might be that the host offers you to let you use their car, or they knew you’re into surfing and booked you some lessons for you.
The image of a guy in a tuxedo carrying a surfing board might be my favorite DALL-E creation.

image.png
18 secs
Chesky describes a 10-star experience is that you get off the plane, and it’s like the Beatles came to town. 5,000 high-school kids are cheering with your name written on your card welcoming you to the country...

image.png
14 secs
And maybe 11-star experience is Elon Musk showing up and saying “you’re going to space.”
(Though maybe that’s a 1-star experience for some of us!)
The point for Brian Chesky is that an 11-star experience may not be feasible. But if you go through the exercise, there’s some sweet spot between “they showed up and opened the door” and “I went to space”. And suddenly some of the things in between that felt hard feel right, and important to do.
And when you’re thinking so audaciously... you’re not thinking about your own idea winning. You’re focused on something so much bigger.
image.png
38 secs
And it’s not just Airbnb that anchors teams on these audacious goals.
Kennedy: “Man on the moon”
YouTube: Billion Hour Goal
Stripe: Increase the GDP of the Internet

So next time you’re trying to orient your team to plan without just focusing on their own team, think about stepping back and defining your version of the 11-star experience.
image.png
22 secs
And finally — there are many companies, like Uber, that ensures that anyone coming into planning has truly worn their customer’s shoes.
At Uber, there is a program to encourage employees to go out and drive for Uber, because it’s the one part of the experience that you can’t fully understand or empathize with unless you actually try it.
And as someone who drove 60 Uber trips myself, I can tell you...
image.png
28 secs
...it’s a really stressful experience!
This was a recording from my first drive ever! Suffice it to say I was not a 5 star driver.
The point, though, is that ... it’s only after you’ve truly internalized that end-user experience that you win the right to decide priorities for customer you’re building for.
Android_Edits_v2.gif
20 secs
So, what do all of these rituals have in common? They are all designed to help people wear different hats, to think beyond their own individual teams winning. By making them act like leaders. By making them think about planning via the customer’s eyes. By anchoring them on such audacious goals that you’re forced to think beyond the confines of your team.

So these are the ideas for unbreaking the planning algorithm.
image.png
28 secs
6 mins 57 secs
26
Ok let’s move on to the next ingredient in our Mad Lib.
image.png
4 secs
So you ran your planning algorithm, how do you know when you’re done?
Every planning algorithm has some output that is really the final result of the planning algorithm.
image.png
10 secs
We’ve seen a lot of different outputs of planning, but they tend to fit in one of 3 buckets
The first group of teams focus on just getting to a list of priorities - sometimes those are called Big Rocks.
The second group starts to break apart the list of priorities into distinct responsibilities — sometimes called OKRs.
And the third group isn’t done with planning until there’s a budget spreadsheet.
image.png
25 secs
Interestingly, it’s possible to go “too far” in each model.
I’ve seen teams go from 3 big rocks to 20.
Teams cascade OKRs but end up with an unmanageable hierarchy
Or teams take a straightforward budget, and produce a full matrix trying to assign percentages of people to every submission.
TODO: Make this funnier?
You know what I think when I see this? Ugh, this is exhausting.
image.png
23 secs
So that brings us to Lesson 2: Exhaustive is Exhausting!
The key to setting the right outputs is to pick the right level of output for your team
image.png
10 secs
Let’s start with the absolute minimal set of outputs that your planning process can come up with.
Who here has heard of Big Rocks?
(wait for hand raises)
For those of you haven’t, this concept was introduced by Stephen Covey in First Things First.
image.png
16 secs
Simple idea: Imagine you describe your priorities as Big Rocks and Little Rocks

image.png
5 secs
If you fill your jar with Little Rocks first, no room for Big Rocks
image.png
5 secs
So the principle is to fill with Big Rocks first
If you do, there’s still room for Little Rocks, but you’ve assured that the Big Rocks go in first.
So this tends to be the first type of output your planning process can create - a list of clear Big Rocks. The must-do priorities that should be resourced and handled first.


image.png
21 secs
It’s worth noting that there’s lots of debate on how many Big Rocks a team should have, and how much of your jar they should take up.
My personal view is that you should have no more than 3-4 Big Rocks and that they should take up less than 50% of your jar. The reason is that once you cross 50%, you see people start to feel really bad about not working on the Big Rocks, so you start to rename Little Rocks to become Big Rocks so everyone is “mentioned”. But then you’ve lost the point.

image.png
35 secs
One company that does this in a particularly unique way is Meta. Even from the early days of Facebook, they were famous for their Lockdown ritual. When Zuck sensed a big challenge that needs to be addressed immediately, he calls for a Lockdown. For example, when Snapchat had started proving that the Stories format was something users really loved, Zuck declared a Lockdown in response and worked to get their response out quickly.
You can think of this like having a single Big Rock for a short period of time. Not something that you can do for long periods of time, but incredibly clarifying when you need it.
image.png
39 secs
That was Big Rocks.
The next level more detailed output that a lot of companies use is OKRs, which is commonly used at Google. As a fun fact it was actually invented by Andy Grove at Intel.
image.png
14 secs
OKRs start pretty innocently enough. Take, for example, this top-level OKR, like increasing the number of weekly active users. Good goal, and straightforward, right?
image.png
9 secs
Now, as different teams start to fill out how they’ll support this top-level goal... as you go deeper and deeper, you start to see OKRs like this one:
Increase average design systems usage from 39% to 42%. It’s technically measurable and good and everything, but I look at that and don’t really understand what the team is trying to do.
In fact, it’s probably one of those OKRs where someone on the team isn’t thinking about it every day, or every week. And just something you measure at the end of the quarter and hope you hit the metric. And if you don’t... maybe you get a slap on the wrist but it doesn’t even feel existential to the business.
I think these are the kind of OKRs that cause people to lose trust in the OKR system.
image.png
52 secs
At Figma, I thought about different ways to combat this. But one thing started emerging in our planning FigJam files.

We have a tradition of doing all our company planning in one singular FigJam file. There’s something nice about seeing everyone’s work at once, and there’s something fun about collaborating in this really visual way on planning.
One key thing about FigJam is that it’s unstructured, and it encouraged people to express what they care about in really different ways.


image.png
31 secs
And I noticed teams starting to share different visuals that they care about, that they’re obsessed about. Maybe it was a customer tweet that they wanted to see. A chart with a metric they were really focused on. A mock that showed the experience they were trying to achieve. Or a embarrassing screenshot they were hoping to fix. And these were the easiest way to understand the team’s true north star.

This reminded me of, when we were at YouTube, Shishir would have us write two-pagers for our plans and share that “one visual” that we’re obsessed about. What I loved about it is that it avoided the need to focus on a contrived OKR, and was way more expressive and flexible in describing what the team really cared about.
image.png
50 secs
For some of you, Big Rocks will not be enough, and even OKRs will still not feel like the true output of planning.
For many teams planning isn’t really done until the dreaded budget spreadsheet is filled out.
In some ways this is practical - after all there’s usually some universal constraint on resources, and it’s important to know how they are allocated.
But clearly you can go too far. Before you know it, you’ve got a team staffed with tiny fractions — I once saw a project with 10.283 people allocated to it.
image.png
33 secs
So at YouTube we had a ritual built to combat this: we called it Hoodie Squads. Here’s how it worked.
First we started with a list of people on the team and started allocating them to projects.
image.png
14 secs
Some are straightforward — most of Team 1 may be on Project A, etc
But then we would get to someone who just has to help multiple projects and you split them into some percentage.
image.png
12 secs
This is where the Hoodies come in.
Like many companies, we often had teams design swag for their teammates, and Hoodies were a common type of team swag.
image.png


10 secs
So we used a simple litmus test: imagine you asked everyone in the company to come in tomorrow and wear their team’s hoodie.
image.png
8 secs
Which hoodie...
image.png
-
would they wear?
image.png
1 sec
So rather than a budget spreadsheet, we started with a people spreadsheet and added a column for Hoodie Squad.
Now the process felt different. We were going through the teams and just deciding which hoodie each person would wear.
After that process was done, we could still output the total number of people on each Hoodie Squad, but it made us focus on what each person was really going to feel their team was on.
image.png
27 secs
It’s worth noting that it wasn’t always possible to really get down to a single hoodie per person.
At the time, we had about 2000 people working on YouTube and we generally had about 20 people that needed multiple hoodies.
So we added a Secondary Hoodie column and thought of it like a baby hoodie.
It was sort of the exception that proved the rule to everyone. Since it was an exception, we would watch for it and minimize it.
And for those individuals, it was very helpful to tell them which hoodie was primary. Not only so they knew which one to work on first, but also which hoodie to wear on hoodie day!
image.png
41 secs
Ok so as you think about designing your planning output, you can think about all 3 of these levels.
Sometimes you can just focus on your top priorities — and I’ve found Stephen Covey’s Big Rocks framework to be the most clarifying. If you put your Big Rocks in first, you’ll still have space for Little Rocks, but it doesn’t work if you do it the other way around.
If that’s not enough, teams generally move on to naming commitments for each team. OKRs are a common framework for that and can result in tangible numeric goals. But I’ve like the flexibility of Figma’s ritual for That One Visual. It allows for teams that may struggle to find a single numeric view of their goal, and it can also be much more motivating to keep the picture in mind.
And if that’s not enough, you may find yourself ready for the Budget Spreadsheet and all of a sudden you’re fractionalizing each of the teams. Before you do that, consider trying what we did at YouTube — assign which Hoodie each person will wear on Team Hoodie Day.
image.png
1 min 8 secs
9 mins 24 secs
24
Ok let’s move on to accountability protocol.
image.png
3 secs
I love to ask people this question: what is the goal of planning?
I’ll get lots of answers:
Aligning on direction
image.png
7 secs
Allocating resources
image.png
-
But really, I think there’s a much clearer answer:
Executing the plan
image.png
4 secs
I’m sure you’ve all seen this happen before.
You spend a ton of time planning and getting to the perfect output.
But then you forget about it and dust it off again when it comes time to plan again.
image.png
14 secs
Ok so back to our WOW framework, we’re ready to add the O’s.
Don’t worry, we’ll get to the rest of WOOOOOOOOOW soon.
Anyways, one way to think about this is that as part of every planning system, there’s an Accountability Protocol to regularly check on progress.
Some way that you’re going adjust your execution process so you don’t just set and forget your plans.
image.png
23 secs
So how do you design a good accountability protocol?
We have a very simple lesson: think about it the other way around. Don’t design your planning algorithm and then come back to your accountability protocol.
Start with how you’ll stay accountable, and work backwards.
image.png
16 secs
A really great example of working backwards from designing the accountability protocol is Zynga’s ritual, which they call Blue Sheet.
The idea is simple — during planning, you come up with project ideas, and you write down what you believe the expected outcome is. Maybe its daily active usage of a new game, or the amount of money you’re going to make from a new feature.

image.png
25 secs
You then have a review every other week, where you’re going to check in on these projects.


image.png
7 secs
And the interesting thing is, every time you record the actuals. The Day 1 actuals.

image.png
6 secs
The Day 7 actuals in the next review.
image.png
3 secs
The Day 30 actuals.
And by the end of it, you have score card of how right or wrong you were, how your investments are paying off.
The rigor and the accountability that this ritual created was so intense that a former PM we talked to said he still gets the shivers whenever he hears the term “blue sheet.”
And the key here: the Blue Sheet ritual happened during execution. But because everyone knew it was going to happen, they adjusted their planning algorithm to fit.
image.png
33 secs
Here’s another great accountability ritual from Toyota.
If you walk into any Toyota factory, you would see a board like this. It’s called the Andon board.
You’ll notice that some of the numbers are lit up and others aren’t.
image.png