Skip to main content

Move beyond the automatic responses and empower your teams to think for themselves.

Drive value, and avoid the negative impacts of micromanagement.

As a Product Owner, you have a vision of what you want to put into the hands of your end users. You understand the benefits of the final deliverable, whether it’s: generating revenue; cost saving; improving efficiency; or improving the end user experience.

But to actually deliver that value, you have to work with the team responsible for delivering that vision.

Given you are responsible for ensuring the overall success of the project (at least in Scrum), you might be excused for being a bit eager and “hands on” with the team, telling them not only what to do, but how to do it. If you fall into this little trap, you’re overlooking one of the most valuable resources you have available to ensure the overall success of the project – the delivery team.

Where does the Product Owner role start and end?

Product Owners should be involved in the project from the very beginning at inception, all the way through to the product being delivered and beyond (value validation is often overlooked as part of the product life cycle!).

So if the PO role covers the entire lifecycle of a project, does their role really end? 

Yes! 

It ends at the point where the definition and understanding of what needs to be done transitions into how the project will be delivered. So the first step in enabling delivery teams is to understand that engineers, coders and testers know how to do their jobs, so you don’t need to tell them how to do their jobs.

Trust your team

You can take this one step further with the assumption that every member of the delivery team is the perfect person for the job. Depending on how you approach this, it can be a big step in telling the team that you trust them, and you trust their abilities. A team that feels trusted and in control, will spend less time second guessing every little detail, and more time actually delivering the work.

This isn’t to say that mistakes won’t be made, and that changes to your vision/plan might need to be considered. Failing fast and responding to change are key parts of any Agile framework. And it doesn’t mean that as Product Owner you should throw your vision over the fence to the delivery team because your responsibility ends at that point. As the Product Owner and vision holder for the project, you are an integral part of the day to day operations of the team, whether it’s: identifying the MVP (Minimum Viable Product); prioritising the backlog; answering questions from the team; engaging in a discussion with the team; or providing feedback on what the team have delivered, remember it’s what has been delivered, not how it has been delivered.

Team working around a table

How to Enable the Team in the Day to Day

Once the boundaries between roles are understood by all involved, what steps can you take as a Product Owner to actively encourage the team to do their best work?

Well these tools and tips are a great place to start:

  • Be present and be attentive.
    • This means that you should attend the team ceremonies. But not just turning up to Stand Up 5 minutes late and using it as a time to catch up on emails and messages. This is a time when you should be listening to what is being said. If you are more attentive, you will feel more informed, and the team will feel listened to.
  • Be responsive.
    • Whether it’s in team ceremonies or responding to messages, if you make time for the team to answer questions and to provide clarity, the team can better align to your vision. This takes a lot of guesswork out of delivery, and should cut down on the number of surprises that you encounter when it comes round to review or “show and tell” meetings.
  • Encourage the team to ask you questions.
    • Again this feeds into being responsive and gives the team confidence that you are there to help them. This could also open up questions about the value of the work, and if there are opportunities to derive more value. What more could a Product Owner ask for!?
  • Ask your own questions.
    • Now this shouldn’t be used to turn a 10 minute Stand Up into an hour long meeting, but asking relevant questions of the team shows them that you’re paying attention to them. It opens up a two way dialogue that can help the team to understand your wants and needs.
  • Provide constructive feedback.
    • Providing feedback is good, but providing constructive feedback can make all the difference. Feedback tells the team if you’re happy with what has been done or not, constructive feedback provides a direction to go in to ensure the best results. Putting the time in to give constructive feedback is again vital in telling the team that you’re engaged with them, as well as confirming that you’re all working towards the same goal.
  • Be aware of the team’s overall wellbeing.
    • You might not be involved in the overall management of the team, but being aware of their capacity, and what is causing stress within the team, means you can support the team better. It’s a contentious topic whether a Product Owner should attend retrospectives or not, there is a chance that your presence could impact how open the team are in the retrospectives, and that isn’t something to take offence to. But checking in with the team before asking them to deliver a new project before the end of the month certainly wouldn’t hurt.
  • Let the team make decisions.
    • This is a big step, and one that can be quite daunting to take. But by letting the team make some decisions on their own, you are encouraging them to do their best work. You can start small with decisions around how things are implemented, after all, every member of the delivery team is the perfect person for the job.

The closer you are to the team, the more comfortable you should be that the team can make decisions on what is being delivered. And if something isn’t quite in line with your vision, you can always provide constructive feedback to get it back on track.

Increasing engagement and enabling team volition

The aim is for the team to think for themselves and not just nod along to your requests without understanding the ask. The delivery teams you are working with are a fantastic resource that can often be overlooked. If you can enable them to ask questions, to be open to answer questions, to take onboard feedback, and to make their own decisions, you’ve got many brains trying to deliver against your vision, instead of one brain trying to guide a team to create a vision they might not understand.

If you need any help getting started, or helping your teams to be the master of their own destiny, then get in touch.

Authors Bio

Greg Horsfall, Senior Business Analyst at Nimble Approach 

Greg has over 10 years of IT delivery experience in a wide variety of industries. He has a passion for enabling delivery teams to realise and deliver real value, through effective communication, process adoption and leadership.