Good product management often talks about the need to focus on outcomes over outputs. And, its sometimes difficult to know what that actually means and how you can apply it. Let me share a story of a team I coached earlier this year as an an example.
Quarterly Planning Take 1
The first week I was working with the team was quarterly planning. There were some good discussions, and an engaged team. There was a focus on how we would know if the features they were delivering were valuable to customers. Some great ideas for metrics we could track, and even ways we could deliver a major feature first as a beta ‘MVP’ feature to get it to market sooner.
Everyone was excited at the end of the the quarterly planning. They had a clear plan of what they wanted to achieve for the quarter, with a rough idea of which epics they would work on in each sprint, and when they expected to deliver the first version of each feature. Planning was a success…. if the goal was to create a gantt chart of what they would deliver for the next quarter.
But they weren’t working in that world. They were in a startup that does not yet have product market fit, they were still guessing which features would actually make the product a success. They focussed on outputs, in a world where no one cares about outputs any more.
Optimising for the wrong thing
As I worked with the team over the quarter, I noticed something. They thought their goal was to deliver to what they had committed to in the quarterly planning. Their process optimised for delivering what they promised. It’s not surprising, most of the agile teams optimise for predictability. It’s what their managers and leaders have been telling them is important.
But here’s the truth. Nobody knew if the features they had decided to build in quarterly planning would actually make a difference. We were making assumptions based on customer feedback and market trends and GUESSING. The team needed a way to get better at evaluating their guesses a lot faster and more cheaply. We started talking about how we might optimise for iteration speed instead. They didn’t need to be predictable, they needed to figure out quickly which features were game changers. They needed outcomes. Like better user engagement, higher retention of customers and better conversion rates.
Quarterly Planning Take 2
Fast forward to the following quarterly planning. We discarded the gantt chart (and yes the team needed reassurance that was okay), and instead focused on the problems to solve for their customers. We picked 2 key problems to solve and brainstormed a bunch of quick (a few days at most) experiments we could do to learn more and see what would have an impact on these problems. Then we talked about how we would build customer feedback into their dev cycle so that they could test ideas with customers within the sprint, before they even released features to production.
At the end of quarterly planning I was a bit nervous about how the team would share their plan in the general feedback session, but they nailed it. They shared the problems they are focussed on, the reasons they chose those problems, and the approaches and ideas they planned to try. They committed to an outcome, and had several different ideas to explore to help them achieve it. That’s what successful outcome based quarterly planning looks like to me.
Your turn?
How about your team? Does your quarterly planning focus on predictable outputs or on customer outcomes? What are your processes optimised for, and how is that serving you? Let us know your thoughts in the comments. Or if you’d like some ideas on how to planning differently drop us an email.