post

B2B product management

Artificial Intelligence (AI) & Machine Learning (ML)

Building Product Teams

Business Strategy

Data Driven Product Management

Digital Transformation

Diversity and Inclusion

Minimum Viable Product

OKRs

Prioritisation

Product Design

Product Research

Product Development Process

Product Ethics

Product Discovery

Product Leadership

Product Management Career

Product Strategy

Stakeholder Management

🌎 <a href="https://www.mindtheproduct.com/world-product-day/" style="color:#FFFFFF;text-decoration:underline;">Happy World Product Day!</a> Be sure to celebrate product, yourself, and your peers today! 🎉

Successful product management in companies where it’s least understood

Measuring critical user journeys – Javier Andrés Bargas-Avila (UX Director, Google)

A new way to look at applied experiments

Product survey findings: Only 15% of users are embracing AI features 

Building high-performing product teams: The PDLC approach

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Guest Post

Overcoming the 20% feature usage challenge

Product Management

Three product leaders to learn from at #mtpcon inside Pendomonium

I've been in the digital industry for over 10 years and have worked across small and large charities, as well as my own freelance projects. I am now Director of Digital at the sector leading creative agency William Joseph. 

Having been at Cancer Research UK for the last four years, I have been able to work on high volume, high profile campaigns such as Race for Life, Dryathlon and the much-quoted #nomakeupselfie. 

In that time I helped drive forward the charity’s digital product and marketing capabilities to be some of the most respected and successful in the sector. 

I'm always excited to work with other organisations, share expertise and swap cat gifs. Give me a shout!

James Gadsby Peet

<p><strong>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.</strong></p>
<h2>Take Ownership of Failure</h2>
<p>It’s easy to see when a thing has failed &#8211; 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.</p>
<p style="padding-left: 30px;"><em>“We’ve tried it before and it doesn’t work”</em></p>
<p>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.</p>
<p style="padding-left: 30px;"><em>“We’ve tried that once, but to be honest I think I’m sometimes too stubborn and can find change difficult”</em></p>
<p>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.</p>
<h2>Examine the Root Causes of Failure, or You’ll Repeat Them</h2>
<p>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 &#8211; which is often a lack of respect for other members of the team and their skills.</p>
<p>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.</p>
<h2>Accept That you are Part of the Problem</h2>
<p>In any situation you will have made mistakes. Nothing is perfect, which means that every decision you have made won’t have been 100% &#8220;on the money&#8221;. By understanding and opening up about where you might have done better, you allow the space for others to do the same.</p>
<p style="padding-left: 30px;"><em>“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?&#8221;</em></p>
<p>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.</p>
<h2>Set an Example and Others Will Follow</h2>
<p>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.</p>
<p style="padding-left: 30px;"><em>&#8220;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?&#8221;</em></p>
<p>By opening up like this, it sets the foundation for a more constructive conversation moving forward &#8211; 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.</p>
<h2>Be Specific in Owning Your Failings</h2>
<p>If we use generic language when discussing failings or issues, then that&#8217;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.</p>
<p style="padding-left: 30px;"><em>“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”</em></p>
<p>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 <em>do</em> this is by taking responsibility for our own specific issues and presenting solutions, which then helps others do the same.</p>
<h2>Success is the Team’s Success</h2>
<p>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.</p>
<p style="padding-left: 30px;"><em>“Sandra did a really great brainstorming session to get the team to think big about our project vision”</em></p>
<p>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.</p>
<div class="g g-21"><div class="g-single a-170"><a class="gofollow" data-track="MTcwLDIxLDEsNjA=" href="https://www.pendo.io/pendomonium/"><img decoding="async" src="https://www.mindtheproduct.com/wp-content/uploads/2024/06/MTP-Footer_ad.png" /></a></div></div>

core/freeform

Product Management Skills

How to keep your head about generative AI (when everyone is losing theirs) by Claire Woodcock

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

James Gadsby Peet