Welcome to annual planning season
Welcome to annual planning season
Also why are we so obsessed with closing rings?
It’s mid-November, and we know what that means… it’s planning season. Our team is always looking to improve the way we plan, so we are considering a few changes this go-around that I thought I’d share. First, it’s important to note that our general framework hasn’t changed. We use W Planning because we believe that having our entire team intimately involved in the work we prioritize is a superpower and we don't want to lose that:
The framework is made up of four steps:
1. Context: Leadership shares a high-level strategy with Teams.
2. Plans: Teams respond with proposed plans.
3. Integration: Leadership integrates into a single plan, and shares with Teams.
4. Buy-in: Teams make final tweaks, confirm buy-in, and get rolling.
The part where we sometimes get stuck is that second phase—Plans. How do we generate enough possible opportunities/solutions without going into so much detail on each that planning takes weeks and weeks and just starts to feel exhausting? Luckily
came along with another well-timed post, this time an interview with Figma CPO Yuhki Yamashita. Figma’s planning cadence—along with the way they use themes instead of detailed project plans in the beginning phases of planning—really resonated with me:Every year, the leadership team sets high-level company priorities to frame key strategic investments. It’s then up to product teams to chart out the path to reach those goals.
A bigger planning cycle happens twice a year, with product teams revisiting their own goals and roadmaps. Halfway through each half—or in the alternating quarters—teams have an opportunity to adjust those plans based on learnings and new information.
So here’s what we’re considering this time around for our version of W planning…
Phase 1: Context
This is our published product strategy
that the entire team collaborated on. It includes all the strategic context the teams need to make decisions about what to work on.Phase 2: Plans
Instead of detailed project plans (you can see the format we use for project plans here), each team can get together separately before our leadership planning week, and brainstorm the themes they would like to focus on in the first half of the year to meet our goals. Something like this (stolen and adapted from Figma):
The actual problems / themes could be more or less than 3, that specific number is not important. But this way we get the team’s input on the major high-level themes we want to address to meet our goals. In this phase we don't do detailed project plans, we come up with themes of focus, lightly defined.
Phase 3: Integration
During leadership planning we discuss and debate the themes that come out of every team, fold in the context of larger organizational goals, and decide on a combined list of top themes we want to focus on in 2023.
Phase 4: Buy-in
We kick off team planning by presenting the themes to the team, getting feedback, and working towards buy-in. We then move into detailed project plans during our dedicated planning week.
Will this process work better than last time? I hope so, but I’ll let you know! Whatever happens, I know that we’ll keep iterating…
→ As luck would have it, First Round just published a great list of planning frameworks (including our preferred “W Planning” method): Annual Planning in Uncertain Times: 6 Tactics for Rethinking Your Company’s End-of-Year Exercis
What I’m reading
Paul Stamatiou wrote a wonderful post on product quality, simply called Craft. This is such an important point that we often don’t realize:
Quality happens throughout the entire project whether you’re cognizant of it or not. It happens when identifying the customer problem to solve, designing a solution, validating it, building it, maintaining it, and even when you sunset the product. A focus on quality drives a way of working in which you dynamically either embrace constraints when you need to or challenge them when you see an opportunity.
Quality is a vital component of the system that makes up the software development lifecycle—just as much as design or writing code is. Teams need a commitment to things like measurement, SLOs (Service Level Objectives), and integration testing if they want to build quality software. It isn’t something that can get added to a product as an afterthought through manual testing and/or bug fixes.
In the post Paul goes on to list a bunch of things that can affect the quality of a product, including culture, incentives, skills, and tools.
When we surrender the control of our motivation and the judgment of our performance to corporate-owned gamification, however shiny and well-marketed, we need to be damn sure it’s designed for our benefit.
The way to design these things differently is to account for and respect the rhythms that exist in our lives. That means removing streaks from most apps and games: we shouldn’t reward people for running or playing or even writing 100 days in a row. Designers should recognize that people will need breaks and ensure their apps don’t punish people for being human.
“Ensure that apps don’t punish people for being human” is a phrase that’s going to stick with me for a long time. That sentiment also reminds me of something
points out in Mass extinction event—that the thing that really makes social networks successful is an effective exploitation of our humanity:Platforms shape desire through the frustration that they deliver, the conflict and risk and misrecognition they generate, the commercial milieu that animates their stakes, the masochistic feelings of being dominated by them. Our attachments to platforms are not necessarily rational; what we get out of them isn’t all that connected to having or making unilateral choices, even as this is what the interfaces often foreground.
What alternative platforms like Mastodon may require to succeed is not just some critical mass of users or some broader fluency in how to navigate their interfaces. They may also need to facilitate some of the frustration and antagonism that their developers may have aspired precisely to forestall. They will need to seem more useful than they really are, to remind us of possibilities beyond usefulness. They will have to alienate us as much as ground us. They will have to seethe with the contradictions that define what it feels like to belong to a society.
And finally this week,
has some great career advice for PMs in The 3 Stages of a Product Manager's Career:In the third stage, your job is to build a great team. It’s your responsibility to hire people, coach them, and set up processes so that your organization can create winning strategies and ship winning products at a scale beyond what you could do as a single PM.
Some stray links
🍲 Inside Campbell Soup’s overhaul to innovation and how it’s paying off. “I would never go so far as to say we’re a tech company as we are all here driven by our passion for food. But [we’re using] all the goodness that came out of the world of tech, and applying it to food design.”
🤡 Fifteen Ways to Share Your Joke After Twitter Implodes. “Try to join Mastodon. The tweets are called toots, and it looks like you need to know basic programming. Receive a message from someone in Germany asking for donations and explaining that the network discourages viral posts. Yell, ‘WELL, THEN WHAT’S THE POINT, JURGEN?’”
🧓 For my fellow olds: The unbearable lightness of BuzzFeed. “BuzzFeed built a digital media empire in part by aggregating viral content from social media. A decade later, what’s next?”
Some good tweets
We recently revised our product strategy as whole team, together. If there is any interest in that process and how we worked together, let me know and I can write about it!
Would love to hear about how you got the whole team involved with revising product strategy!