1. Understand your client's pain and needs
Upgrade the user, not your product. Don't build better cameras - build better photographers. - Kathy Sierra
Your (future) customers do not come to you for your product. They want something that will improve their own lives - the advancement it offers. You need to focus on understanding your customer's pains, desires, aspirations and problems if you want to build a great product that delivers value.
The empathy map is a great tool to put yourself in the shoes of the customer and his or her pain and needs. We have a template available for this that you can apply immediately. You can find this at the bottom of this blog.
2. Make delivering value a team effort
Delivering a valuable product is teamwork! As a Product Owner, you must ensure that the entire Scrum team understands how we deliver value to our customers and the company. You do this by actively involving the Scrum team in discussions to decide what is the right thing to build to achieve the best results.
You get back what you give. Involve your team in your decisions and they will feel involved which will increase the stakes. If you don't do this, you create distance and the team will care less about the outcome.
3. Create an environment where it is safe to make mistakes
"If failure isn't an option, then success isn't." - Seth Godin
With every sprint there is a chance that your team will fail. The way you treat the team in times of failure is essential to success. Failure should be okay, provided we learn something from it to help us succeed in the future.
The five dysfunctions of a Patrick Lencioni team model show why psychological safety is essential to creating a high-performing team. Psychological safety arises when team members feel safe to take risks and dare to be vulnerable.
The 5 dysfunctions of a team model are supported by research from the Aristotle project at Google. They found that psychological safety is more important than having a team of superstars.
Psychological safety is essential for Scrum to work. A process framework can only lead to a better work process if there is a basis of psychological safety that allows for experimentation and failure.
4. Focus your efforts on doing the right things
“Simple can be more difficult than complex: you have to work hard to clarify your thinking to make it simple. But in the end it is the worth it because once you get there you can move mountains. - Steve Jobs
I would say that the main job of a Product Owner is to create focus. You have to eliminate what doesn't matter so that what matters most stands out. Otherwise, the things that don't matter reduce the value of your product.
Scrum helps Product Owners to focus naturally by requiring a clear Sprint Goal for each Sprint.
Working with Sprint Goals is not enough. There must be an overarching product vision and product strategy to ensure coherence between the different sprint goals.
5. Start with onresearch before je starts delivering
Most companies are still stuck in factory mode and cheer when teams release new features. Resist the temptation to start building a new function every time someone asks for it. Research first and build later. Prioritize research and learning so that you understand the importance of that position and what it actually takes to make it a success.
Conduct experiments and gather evidence so that you know as much as possible about what the customer needs before building a feature. Strive for less but better. Sometimes it makes sense to build and learn at the same time. Make a conscious decision first if the best way is to increase the chances of building the right way.
Once a feature is included in your product, how likely is it that it will be removed? Once the function is in place it almost always requires maintenance. That is why you do well to choose consciously when building new functions. Start by making a hypothesis and evaluate along the way whether you have achieved what you wanted to achieve.
6. Keep your Product Backlog card
Be aware of the items you place on your Product Backlog. You want to avoid cluttering your Product Backlog with ideas or things you probably won't pick up. Treat your Product Backlog like milk: have just enough for the foreseeable future, but no more. Otherwise, your Product Backlog will get old and it will take effort to make it fresh again.
7. Be lazy writing Product Backlog Items
Many Product Owners spend a lot of time writing Product Backlog Items. My tip: don't do this! It is a big waste of time and it is not the way to add value to the Scrum team. An extensively described product Baclog Items helps to build the function properly, but not to build the correct function. Based on my personal experience, a Product Owner should only spend 20% of their time on delivery, 80% on discovery and validation.
Focus on understanding the problem you are trying to solve and pass this information on to the development team. Then create the Product Backlog Items together. In this way it is a working product of the entire Scrum team, instead of just you. By working together on this, everyone will understand the same and remember what needs to be done to improve the product.
In the end, it doesn't matter what is written in the Product Backlog Item: The most important thing is that the Development Team understands.
8. Remove unused and non-value adding functions
Each function must add value to your product and pay the membership fee. Features that don't pull their own weight reduce the value of your product. Unused functions are like parasites that burn money to stay alive: infrastructure costs, costs due to production problems, and maintenance costs to run them on newer versions. You cannot respond quickly to changes when all these parasites slow you down.
Hence, get rid of these features quickly as it frees up capacity to work on more valuable things and saves a lot of money over time.
Removing unused functions is difficult for two reasons:
9. Let the team come up with the solution, but challenge them!
As a Product Owner you must focus on explaining the problem you want to solve. It is not your job to come up with a technical solution. Your job is to ensure that the technical solution delivers the most value. Challenge your team if you think they are coming up with a solution that is too complicated to make sure all that complexity is really needed. Solutions should be as simple as possible, but not simpler.
10. Don't manage your customers, get them involved
Unhappy stakeholders can make life difficult for your job as a Product Owner. That's why it's very important that you find a way to keep them happy. The best way to do this is not by managing your stakeholders, but by involving them. An easy way to engage your key stakeholders is to invite them to the next Sprint Review.
1. Understand your client's pain and needs
Upgrade the user, not your product. Don't build better cameras - build better photographers. - Kathy Sierra
Your (future) customers do not come to you for your product. They want something that will improve their own lives - the advancement it offers. You need to focus on understanding your customer's pains, desires, aspirations and problems if you want to build a great product that delivers value.
The empathy map is a great tool to put yourself in the shoes of the customer and his or her pain and needs. We have a template available for this that you can apply immediately. You can find this at the bottom of this blog.
2. Make delivering value a team effort
Delivering a valuable product is teamwork! As a Product Owner, you must ensure that the entire Scrum team understands how we deliver value to our customers and the company. You do this by actively involving the Scrum team in discussions to decide what is the right thing to build to achieve the best results.
You get back what you give. Involve your team in your decisions and they will feel involved which will increase the stakes. If you don't do this, you create distance and the team will care less about the outcome.
3. Create an environment where it is safe to make mistakes
"If failure isn't an option, then success isn't." - Seth Godin
With every sprint there is a chance that your team will fail. The way you treat the team in times of failure is essential to success. Failure should be okay, provided we learn something from it to help us succeed in the future.
The five dysfunctions of a Patrick Lencioni team model show why psychological safety is essential to creating a high-performing team. Psychological safety arises when team members feel safe to take risks and dare to be vulnerable.
The 5 dysfunctions of a team model are supported by research from the Aristotle project at Google. They found that psychological safety is more important than having a team of superstars.
Psychological safety is essential for Scrum to work. A process framework can only lead to a better work process if there is a basis of psychological safety that allows for experimentation and failure.
4. Focus your efforts on doing the right things
“Simple can be more difficult than complex: you have to work hard to clarify your thinking to make it simple. But in the end it is the worth it because once you get there you can move mountains. - Steve Jobs
I would say that the main job of a Product Owner is to create focus. You have to eliminate what doesn't matter so that what matters most stands out. Otherwise, the things that don't matter reduce the value of your product.
Scrum helps Product Owners to focus naturally by requiring a clear Sprint Goal for each Sprint.
Working with Sprint Goals is not enough. There must be an overarching product vision and product strategy to ensure coherence between the different sprint goals.
5. Start with onresearch before je starts delivering
Most companies are still stuck in factory mode and cheer when teams release new features. Resist the temptation to start building a new function every time someone asks for it. Research first and build later. Prioritize research and learning so that you understand the importance of that position and what it actually takes to make it a success.
Conduct experiments and gather evidence so that you know as much as possible about what the customer needs before building a feature. Strive for less but better. Sometimes it makes sense to build and learn at the same time. Make a conscious decision first if the best way is to increase the chances of building the right way.
Once a feature is included in your product, how likely is it that it will be removed? Once the function is in place it almost always requires maintenance. That is why you do well to choose consciously when building new functions. Start by making a hypothesis and evaluate along the way whether you have achieved what you wanted to achieve.
6. Keep your Product Backlog card
Be aware of the items you place on your Product Backlog. You want to avoid cluttering your Product Backlog with ideas or things you probably won't pick up. Treat your Product Backlog like milk: have just enough for the foreseeable future, but no more. Otherwise, your Product Backlog will get old and it will take effort to make it fresh again.
7. Be lazy writing Product Backlog Items
Many Product Owners spend a lot of time writing Product Backlog Items. My tip: don't do this! It is a big waste of time and it is not the way to add value to the Scrum team. An extensively described product Baclog Items helps to build the function properly, but not to build the correct function. Based on my personal experience, a Product Owner should only spend 20% of their time on delivery, 80% on discovery and validation.
Focus on understanding the problem you are trying to solve and pass this information on to the development team. Then create the Product Backlog Items together. In this way it is a working product of the entire Scrum team, instead of just you. By working together on this, everyone will understand the same and remember what needs to be done to improve the product.
In the end, it doesn't matter what is written in the Product Backlog Item: The most important thing is that the Development Team understands.
8. Remove unused and non-value adding functions
Each function must add value to your product and pay the membership fee. Features that don't pull their own weight reduce the value of your product. Unused functions are like parasites that burn money to stay alive: infrastructure costs, costs due to production problems, and maintenance costs to run them on newer versions. You cannot respond quickly to changes when all these parasites slow you down.
Hence, get rid of these features quickly as it frees up capacity to work on more valuable things and saves a lot of money over time.
Removing unused functions is difficult for two reasons:
9. Let the team come up with the solution, but challenge them!
As a Product Owner you must focus on explaining the problem you want to solve. It is not your job to come up with a technical solution. Your job is to ensure that the technical solution delivers the most value. Challenge your team if you think they are coming up with a solution that is too complicated to make sure all that complexity is really needed. Solutions should be as simple as possible, but not simpler.
10. Don't manage your customers, get them involved
Unhappy stakeholders can make life difficult for your job as a Product Owner. That's why it's very important that you find a way to keep them happy. The best way to do this is not by managing your stakeholders, but by involving them. An easy way to engage your key stakeholders is to invite them to the next Sprint Review.
It is our mission to help customers get their change ambitions to come true.
Our location in Amersfoort is located directly opposite the main entrance of the NS station and is therefore easily accessible by public transport.
If you come by car, it is best to park at the Q-Park P+R Barchman Wuytierslaan, approximately a 5-minute walk from our office.
