Last week, a Product Owner reached out and asked for help with executing a new project. He and his team had been working at this new product idea for months and had created a list of requirements. Everything was documented, from basic functionalities, to all the possible features they wanted to include in the final product.
What this team was trying to do was to start execution. Every Product Owner likes to build – otherwise you wouldn’t do this job, right? 🙂 And execution is such an important -and often rewarding – part of our job.
Yet, what this team was confusing was execution for planning. See, there is nothing wrong with planning. We need planning. Otherwise we wouldn’t have a direction, a goal, an objective. Leaving everything to improvisation or chance does not feel like a recipe for success. So, at some level, we need planning.
We should also look at what execution really means. Often, new product ideas come from a stakeholder – or your boss. They have this new idea, and they go to the Product Owner and say “I’d like for you to build this thing next.” They put the Product Owner straight into execution mode. Now, one of two things typically happen:
In one situation, the Product Owner takes the “marching orders” from the stakeholder or boss, and starts executing as he or she was told. They were given an idea and were asked to execute on it, so this seems the path of minimum resistance. The Product Owner may feel proud of having executed quickly on what was asked (but was it the right thing?)
In another situation, the Product Owner may get into planning mode. They create accurate plans before building anything. This can take the form of a long requirement document, or a roadmap, or a fully estimated product backlog. Or maybe a plan for the next 10 sprints with details on what will be done each sprint. Either way, the planning phase takes time. And once planning is started, it feels there is never enough confidence in the results, so the Product Owner keep working at the planning, trying to make it more and more accurate.
Ever seen any of these? You are not alone.
It’s good to be in execution mode, but what does that really mean for a Product Owner?
It comes down to the main responsibility of the Product Owner. And that is, build the right product. It’s not build the product on time, build the product in the right way, or build the product following the right processes. All these are important, but if you think about it, we don’t need a Product Owner for these (e.g. the Developers can do it, or a Project Manager can do it).
What we need the Product Owner for is to build the right product. What is the right product? Is a solution to a customer’s need that delivers outcomes to the customer (and as a consequence to the business). While there are many activities that go into building a solution (and yes, execution, planning are part of it), the focus of the Product Owner should be on the outcomes.
Consider these questions:
- What outcomes are the customers looking for from us?
- Is our solution delivering these outcomes?
- If not, how do we pivot?
These are the questions that the Product Owner keeps asking about their product. And these questions should drive validation, not planning. To build the right product, the Product Owner needs to validate ideas, plans, solutions. Do this as frequently as possible. Rather than creating a plan for the full solution, what can you execute on to validate the first part of your idea? What will you validate next?
So when the stakeholder or the boss comes back with their next idea for you to build, your answer should be: “Great, I’ll start working on it, and the first thing I’m going to do is to validate this idea with our customers and understand the outcomes.”
So, if you are a Product Owner and you find yourself spending too much time in planning… Stop planning, and start validating.