Every software product in development has a Product Owner who is in charge of supplying the requirements, and it is often misunderstood how important this role is. You can have the best engine in your car (the development team), but if you steer in the wrong direction, you’re not going to get to your destination.
Here are seven tips to make sure you’re doing this job well:
Represent the business
As the Product owner, it is your job to take requirements from any other business stakeholders, your own direct manager, feedback from the developers, and also the actual users of the software, and order them into a single funnel of prioritised work for the development team to work from. This is called the product backlog and is the main tool through which you can influence the success of the team.
Talk to the stakeholders
As well as taking requirements from the business, you also need to be able to report back to your various stakeholders with what the progress of the project is, and potential ETAs for features that they’re waiting for.
Maximise business value
Backlog prioritisation is all about making sure that the development team is always working on the most important thing that will provide the most business value. You can use a two dimensional matrix to help you with this decision. Think in terms of urgent vs important, and work in the following order.
- If a PBI (Product Backlog Item) is urgent and important, work on it 1st
- Work on important but nor urgent PBIs next
- Then urgent but not important
- Finally work on the PBIs that are neither urgent nor important
Since new work will constantly be coming in from feedback and other new ideas, if you follow this rule you will often find that your team almost only works on category 1 and 2 above, meaning you’re never working on unimportant work. Often you’ll find that if a PBI is urgent but not important, it will either no longer be urgent after a little while, or else it will become important.
Think in terms of Minimum Viable Product (MVP)
As a Product Owner, you have to be able to say when a feature is good enough for the team to stop polishing and adding bells and whistles, and instead move on to the next feature down the list.
This is especially important when budgets are tight (i.e. 90% of the time) to make sure that the business gets what it needs before you work on what it wants.
Be aware, however, that there is a slight cost in this, as if you want to come back to it later, you will have to let the developers get re-accustomed to that area of their code.
Manage Technical Debt
Technical debt is code or documentation that builds up over the course of any project, where some parts become legacy or shortcuts that were taken earlier cause headaches for work done later. Even diligent teams often find themselves with a buildup of technical debt as best practices change or new technologies emerge.
The solutions for this are varied, and include re-architecture, adding more measures such as unit tests or automated UI tests, and, most commonly, refactoring. Creating and prioritising these PBIs is one of the hardest things for Product Owners to do, as only the development team really knows extent of technical debt in any project, and often they won’t speak up about it because they caused the issue. See my other post about trust in teams to make sure you get full transparency in this.
My advice is to have a little bit of technical debt reduction in each sprint, as well as in your Definition of Done
Have a vision for the product
As well as taking requirements from others, the Product Owner should be in a very good position to have a holistic overview of the long term goals of the product, and this is known as the Product Vision. Keep this vision in mind as you’re shaping the product, to make sure it’s heading for a good destination.
Motivate and empower the team
There are plenty of ways for a Product Owner to impact the productivity and motivation of a team.
- Show gratitude for work well done or particularly useful features delivered
- Share the team’s success with others… always giving the credit to the people who did the work
- Be available throughout the sprint for clarifications to PBI Acceptance Criteria (i.e. the requirements)
- Try not to change your mind on priorities and requirements part way through a sprint as it can ruin the flow of a team that is on a roll
For a whole lot more, check out SSW’s Rules to Better Product Owners.
[This post was originally published at https://ulyssesmaclaren.com/2016/08/25/seven-tips-to-being-a-great-product-owner]
Leave a Reply