10 things you must do to build high-performing Scrum Teams as a Product Owner

Product Owner Feb 17, 2020

Including 25+ must-read resources & follow-up articles to learn more so you can do it yourself.

How a Product Owner interacts with a Development Team is crucial for their performance. A poor Product Owner can easily run a high-performing team into the ground.

Over the years I have kick-started many different teams at different companies. If a team wasn’t performing, they often would be assigned to me to fix and improve. As a result, I researched and discovered what are the most important things I could do as a Product Owner to build high-performing Scrum Teams.

I will share the 10 must do things for building high-performing Scrum Teams based on my personal experience. I will also provide 25+ additional resources to help develop a deeper understanding so you can take first steps towards doing it yourself.

1. Understand your customer pains and needs

Upgrade your user, not your product. Don’t build better cameras — build better photographers.
— Kathy Sierra

People don’t want your product. They want how it will make their own lives better — the progress 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.

Further reading:

  1. Jobs To Be Done theory helps you to create better products.
  2. LinkedIn Gets Jobs to be Done.
  3. A Script to Kickstart Your Jobs To Be Done Interviews.
  4. Jobs to be done personas.

2. Make delivering value a team effort

Delivering valuable products is teamwork. You need to make sure the whole Scrum Team understands how we deliver value to our customers and the business. You need to actively involve the Scrum Team in discussions to decide what is the right thing to build to achieve the best results.

Treat your team like a Feature Factory and you will get a Feature Factory: focused on churning out features that may or may not deliver value.

Further reading:

  1. Stop talking so much about the different Scrum roles.
  2. Scrum sucks without solid Product Management.

3. Create an environment where it is safe to fail

“If failure is not an option, then neither is success.” — Seth Godin

Each Sprint there is a chance your team will fail. The way you treat the team in times of failure is vital for success. Failure should be okay, provided we try to extract lessons to help us succeed in the future.

Patrick Lencioni’s 5 Dysfunctions of a Team model shows why psychological safety is essential for creating a high-performing team. Psychological safety happens when team members feel safe to take risks and be vulnerable in front of each other.

The 5 Dysfunctions of a Team model is backed up by research from project Aristotle at Google. They discovered that psychological safety is more important than having a team of superstars.

For Scrum to work, psychological safety is also essential. A process framework can only lead to a better working process if there is a foundation of psychological safety that allows experimentation and failure.

Further reading:

  1. Lencioni’s 5 Dysfunctions of a Team.
  2. re:work: research from Project Aristotle at Google.
  3. If you are not flexible, you are not doing Scrum.
  4. Valuable Failures.

4. Focus your effort on the right things

“Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” — Steve Jobs

I would argue the most important job of a Product Owner is to create focus. You need to eliminate what doesn’t matter, so that what matters may stand out. Otherwise the things that don’t matter dilute the value of your product.

Scrum naturally helps Product Owners to focus, by demanding a clear Sprint Goal every Sprint.

Working with Sprint goals is not enough. An overarching Product Vision and Product Strategy needs to be present to ensure coherence between the different Sprint Goals.

Further reading:

  1. WTF is Strategy?
  2. What is Product Vision?
  3. The only thing that matters when planning a Sprint.
  4. Apply FOCUS to set great Sprint Goals.
  5. The Sprint Goal.

5. Do discovery before you start delivery

Most companies are still stuck in feature factory mode, celebrating when teams churn out new pieces of functionality. Resist the temptation to start building a feature when somebody asks for it. Learn first and build later. Prioritize learning so you understand what is actually needed for that feature to be a success.

Do experiments and gather evidence, so you know as much as possible about what the customer needs before you start building a feature. Aim for less but better. Sometimes it makes sense to build and learn at the same time. Make building something first a conscious decision if it is the best way to increase the probability of building the right thing.

Once a feature ends up in your product, how likely is it to be removed? That’s why you should be extra careful when building new features. Start by creating a hypothesis and then evaluating along the way whether you achieved what you set out to achieve.

Further reading:

  1. 14 Signs you’re working in a Scrum Feature Factory.
  2. Professional Scrum UX.
  3. Here is how UX Design Integrates with Agile and Scrum.
  4. Agile vs Lean vs Design Thinking.

6. Keep your product backlog short

You shouldn’t pollute your Product Backlog with ideas or things you likely won’t pick up. Treat your Product Backlog like milk: have just enough for the near future but no more. Otherwise, your Product Backlog will become stale and it will take effort to make fresh again.

Further reading:

  1. 4 Steps for Agile Product Backlogs that are Too Big.
  2. A large Product Backlog is pointless.

7. Be lazy with writing backlog items

Many Product Owners spend so much time writing Product Backlog Items. Don’t do this! It’s a big waste of time and it’s not how you add value to the Scrum Team. It just helps building the thing right, but not building the right thing. 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’re trying to solve and convey this information to the Development Team. Then create the Product Backlog Items together. Now it is a working product of the whole Scrum Team, instead of just your mind. By doing it together everybody will have the same understanding and remember what needs to happen far better.

In the end, it doesn’t matter what’s written down: what the Development Team understands is what matters most.

Further reading:

  1. Great Product Owners write awful backlog items.

8. Remove unused and non-value adding features from your product

Every feature must add value to your product and pay its dues. Features that aren’t pulling their own weight dilute the value of your product. It’s even worse than that. Unused features are like parasites that burn money to stay alive: infrastructure costs, costs due to production issues and maintenance costs to keep them working on newer versions. You can’t be agile with all these feature parasites slowing you down.

Kill these feature parasites swiftly, as it will free up capacity to work on more valuable things and save a lot of money over time.

Removing unused features is hard for two reasons:

  1. It is tough to figure out which features in your product really matter, especially if you lack understanding of how you add value to your customers.
  2. People hate losing things, much more than gaining new things. This is called loss aversion. So even if just a few customers use a very unpopular feature, they might get super vocal about it, because people hate losing what they already have.

Further reading:

  1. How Loss Aversion Dominates Your Life.

9. Let the team come up with the solution, but challenge them!

As a Product Owner, you should focus on explaining the problem you want to solve. It’s not your job to come up with a technical solution. However, you should make sure the technical solution delivers the most value.

Challenge your team if you believe they are coming with an over-complicated solution to make sure all that complexity is really necessary. Solutions should be as simple as possible, but not simpler.

Further reading:

  1. Why Product Owners should challenge technical solutions.
  2. It’s not my job to write requirements.

10. Don’t manage your stakeholders, include them

Unhappy stakeholders can make your job as a Product Owner impossible. Therefore it is really important that you find a way to keep them happy. The best way to do this is not by managing your stakeholders, but by including them. A simple way you can involve your most important stakeholders is by inviting them to your next Sprint Review.

Further reading:

  1. Stakeholder Management.
  2. Leveraging the Sprint Review to simplify your stakeholder management.