Failure is Yours, Success Belongs to the Team by Tessa Cooper "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs May 05 2018 True Communication, Conflict, product management team, product teams, ProductTank, ProductTank London, Retrospective, Stakeholder Management, Team Alignment, Team Leadership, Mind the Product Mind the Product Ltd 925 Product Management 3.7

Failure is Yours, Success Belongs to the Team by Tessa Cooper

BY ON

Summary: A  ProductTank London talk that advises you accept that you are part of any failure that happens and be specific about the issues that you face. This helps you to work through them as a team and sets an example for others to follow. When success does come, make sure you expose the specific actions of people that led to it so that the team can reproduce them.

Take Ownership of Failure

It’s easy to see when a thing has failed – we’re very happy to call that out. What we struggle with is accepting the burden of knowing that we’ve personally failed and taking responsibility for that situation.

“We’ve tried it before and it doesn’t work”

This type of response clearly shows that no single person has accepted direct fault for the outcome of a project. This means that you’re much less likely to try it again as you won’t know what to change next time.

“We’ve tried that once, but to be honest I think I’m sometimes too stubborn and can find change difficult”

If we can reflect on a situation or outcome that was less than ideal, and understand our influence on that failure, then we open up a whole new conversation. This is a productive exploration of the facts and gives people more agency and confidence to try a different approach next time. In order to get to this stage, we need to make time and create an environment for people to really look at themselves, their actions and outcomes.

Examine the Root Causes of Failure, or You’ll Repeat Them

In a lot of instances, a lack of communication is the underlying cause of problems. It’s easy to try and tackle this by talking about Jira tickets, burndown charts and team velocity. However, this rarely gets to the heart of the issue – which is often a lack of respect for other members of the team and their skills.

Put simply, this inability to work through personal problems together means that you’ll never be able to come up with solutions for more technical issues.

Accept That you are Part of the Problem

In any situation you will have made mistakes. Nothing is perfect, which means that every decision you have made won’t have been 100% “on the money”. By understanding and opening up about where you might have done better, you allow the space for others to do the same.

“We’ve tried that once, but perhaps I didn’t quite understand the purpose of doing it. Maybe you could help me do it better next time?”

By politely asking for help, you put yourself out there and at the mercy of someone else’s personality. This is a scary thing to do, but if you can manage it, you’ll build a bond and understanding with someone which means that you’re much less likely to fail again.

Set an Example and Others Will Follow

There are at least two people in any relationship where there is friction. As such, there will be issues from each side and things that both people could be doing better. If you find yourself in this situation, take responsibility for your own failings and apologise up front with the other person.

“I’m really sorry that I’ve been making this project stressful. I haven’t given you the trust you deserve and have been making things harder by not talking directly with you. How can we move forward?”

By opening up like this, it sets the foundation for a more constructive conversation moving forward – where you can get to the root causes of the issue more quickly. This doesn’t mean the conversation will be easy, but it does improve your chances of avoiding failure in this relationship again.

Be Specific in Owning Your Failings

If we use generic language when discussing failings or issues, then that’s just another way to avoid talking about the root causes. By wrapping the issue up in generic language you are avoiding direct conflict, which means you are avoiding direct solutions. The end result of this is hidden, unspecified failures that are owned by everyone. These are extremely difficult to change, improve and avoid in the future.

“I could’ve been more productive this sprint if I’d realised earlier that there weren’t enough front-end stories for me and organised a second planning session”

Retrospectives often contain more generic statements of failure as everyone wants to avoid offence. We of course should avoid being rude to people, and the way to do this is by taking responsibility for our own specific issues and presenting solutions, which then helps others do the same.

Success is the Team’s Success

In order to build a successful team, you need to purposefully attribute success to others. It’s really easy to accidentally take credit for other people’s work if you’re talking to stakeholders about products. All the progress gets attributed to you and this can leave other members of the team feeling dejected. You should be using these as a way to point out the specific things that your team did to help achieve this success.

“Sandra did a really great brainstorming session to get the team to think big about our project vision”

This not only recognises and enthuses the individual who has helped, it shows other members of the team what is valued and helps you be successful as a group.