Plan quarterly objectives
why problem-space planning avoids fantasy roadmaps 2025-07-01 #product #management
- Quarterly objectives ←
- Premature solutions
- Product tsundoku
Software development teams can get stuck working ‘the way we’ve always done it’, while struggling with a planning approach that doesn’t make anyone happy. They suffer from a kind of development capture: the planning approach locks the team into a failure mode, and captures software development capacity.
Unfortunately, a team that has the agency to decide how they build software, from day to day, cannot necessarily influence how management plans their work, from month to month.
Problems
A common picture: everyone working on something different, and little impact. The team doesn’t align on which problems to solve, fails to focus, and makes little progress in any particular direction. Instead, the following trap prevents focus:
❌ This looks like a good idea, so we should work on it now.
Focusing on one high-level problem at a time resolves this. It lets you say, ‘while solving that problem would add value, we currently choose to focus on this problem.’
Plan to work on business problems. Make sure to work on customer problems, or other customer-focused opportunities. Don’t make internal problems (that customers don’t care about) the only business problems you work on.
Strategy
A typical management discussion: customers like the product, but it doesn’t make enough money. Changing business strategy might help – trying a different way to achieve the business goal, but only when the product team works on problems that align with the new strategy. If they don’t, the investors will realise that they don’t care about what the team has decided to work on, and the team will eventually lose its funding.
Understand the company’s business strategy. When you understand the company’s strategy, you can plan to work on customer problems that contribute to it. This matters, because you can solve more customer problems if you stay in business.
Options
Most software teams’ roadmap resembles the Lausanne metro map:
The Lausanne Métro M2 has one line, with no branches. Once you know your direction, it can only tell you what comes next. An actual roadmap gives you many roads to choose from: options for navigating a whole landscape, to take advantage of what you learn along the way.
When your product roadmap doesn’t identify options, you risk getting stuck on the first option to emerge. Without options, it looks like you have already identified the most valuable thing to work on next. Worse, the longer you leave it, the harder it becomes to add alternatives.
Identify options for future focus. While working on one objective, you can identify options for what to work on next. Capturing what you learn during product development as candidate objectives helps you delay choosing the next one. And delaying the decision for as long as possible makes it more feasible to add new options and take them seriously.
Books
I’ve worked for more than one organisation that tried to adopt quarterly objectives and key results, failed, and abandoned the effort. Too few people had the shared understanding that you get from reading a few good books:
- Who Does What By How Much?, Jeff Gothelf & Josh Seldon
- Radical Focus, Christina Wodtke
- Succeeding with OKRs in Agile, Allan Kelly
- Epic Alignment, Nils Janse
Plan quarterly objectives, but only after more preparation than reading a blog post or two.
