The worst annual planning I was ever part of went on for months. There were a lot of business units and a lot of engineering teams, each owning a different piece of the system. We never got clear answers to two questions. What were we going to test next year? And of everything we wanted to do, what mattered most?
Nothing was ranked. It was a list of ten things, maybe more, and planning turned into horse trading. My team had it worse. We ran a platform, so we had to find core capabilities that could serve several business units with different strategies. Each of those units was fighting for its own projects and its own hiring, and we were supposed to build something that worked for all of them.
At another company, planning worked differently. The executive team agreed on one goal for the company, and every proposal for the next year got measured against it. The strategy rested on hypotheses that ran longer than a year, so each year’s plan built on the last. And when they said yes to something, they knew what they were giving up.
That company was smaller, and it had one main business instead of many under one umbrella. That helped, but I don’t think it explains it. What mattered more was what the people at the top believed about product work. The first company treated the plan as a promise to deliver everything, whether or not the team had room. The second treated it as a set of bets we expected to learn from.
A lot of the planning advice I see for product leaders is about making a better case in the meeting. That’s useful, but it won’t change what the executives believe.
Plenty of product leaders believe the plan is a promise too. They push back on the plan in the meeting, then go back to their desks thinking they should be able to deliver all of it anyway.
I’d rather be held to how good our bets were and how quickly we learned whether they worked.
Annie Duke’s Thinking in Bets goes much further into treating decisions as bets. It’s worth reading if this idea is useful to you.
