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! 🎉

Are you really understanding your users or going through the motions?

Why can’t we get accessibility right? Claire Bauden (SVP Global Product Design, Global Payments Inc.)

Ditch the PRD template and embrace the PRD checklist

How to price your subscription product: insights and examples

Can product operations and innovation be friends?

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Sunday Rewind: The good, bad, and ugly of OKRs by Jenny Herald

Product Management

Simón Muñoz

<p>A motivated team is a happy team. A happy team is more creative, provides better solutions, and to top it off, it&#8217;s also more productive.</p>
<p>In today&#8217;s post, I would like to introduce some techniques and ideas that I have been refining over the last 20 years focused on motivating product teams.</p>
<p></p>
<h2>Embark them on a mission</h2>
<p><span style="font-style: italic;">&#8220;You want a team of missionaries, not mercenaries.&#8221; — Marty Cagan</span>.</p>
<p>The difference between a missionary and a mercenary is that the former is thereby conviction, while the latter could be there as it could be anywhere else.</p>
<p>The resulting product of having a team made up of one or the other will vary enormously. That is why one of the top priorities of any product manager should be to articulate an inspiring mission so that the team can join it.</p>
<p>To build this mission, we can rely on multiple frameworks. At Voicemod, we use LinkedIn Vision-to-Values, which I recommend. However, regardless of which one we use, the goal should be to answer the following questions on one page:</p>
<ul>
<li>Vision: What do we exist for? What is the aspirational goal of the team?</li>
<li>Mission: What do we do to achieve that goal?</li>
<li>Who we serve: Who are our users?</li>
<li>Priorities: If there are several, which are the most important?</li>
<li>Metrics: How do we know if we are making progress on the objectives?</li>
</ul>
<p>Of course, this document can’t rain from heaven. It’s vital that the product manager does the necessary work to understand the company&#8217;s expectations regarding the equipment and that all of it participates in its definition and preparation.</p>
<h2>Tell them the problem. Don&#8217;t give them the solution</h2>
<p><span style="font-style: italic;">&#8220;If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution.&#8221; — Albert Einstein</span>.</p>
<p>As soon as you speak to any seasoned product team today, one of the messages you&#8217;ll hear the most is &#8220;<span style="text-decoration: underline;"><a href="https://www.mindtheproduct.com/product-management-team-sport/">bring us problems, not solutions</a></span>.&#8221;</p>
<p>And this is, perhaps, one of the most critical challenges for any product manager. Embracing the problem so intimately that the solution seems obvious but simultaneously leaving the spec at a level of detail high enough for the team to assume the solution.</p>
<p>Our job is to guide the team in the problem space, make sure that we consider all scenarios, and validate that the proposed solution will satisfy the user&#8217;s needs.</p>
<p>If we don&#8217;t do it that way and spend our time writing infinitely detailed PRDs with no room for imagination, why would we want a team of product engineers? The engineers who need to work like this work in consulting firms that sell their meat by the hour. They are replaceable. Great engineers demand participating in designing the solution. Surround yourself with these.</p>
<h2>Give them autonomy</h2>
<p><span style="font-style: italic;">&#8220;Control leads to compliance; autonomy leads to engagement.&#8221; — Daniel H. Pink</span>.</p>
<p>The best product teams are self-organizing. They don’t need a paternal figure constantly controlling their work. I have yet to see a motivated product team that’s not consistently delivering at its best. The difference is that they do it in the things that matter.</p>
<p>As product managers, we must never forget that our focus is to derive value from the team, not story points. A team can make 200 story points per sprint and not add any value or even subtract it because it adds fat to the product for the mere fact of producing.</p>
<p>In contrast, a seemingly chaotic team that doesn&#8217;t follow any seemingly logical process may be adding immense value to the company. Believe me. This team is much more critical to the company than the first one.</p>
<h2>Protect their time</h2>
<p><span style="font-style: italic;">&#8220;Time isn&#8217;t the main thing. It&#8217;s the only thing.&#8221; — Miles Davis.</span></p>
<p>Product development is an activity that requires significant periods of work time without interruptions. Protect your team at all costs from unnecessary meetings.</p>
<p>Take advantage of the daily standup to ask the questions you need. It’s better to extend a daily 10 minutes than setting up a 10 minutes meeting in the middle of the day.</p>
<p>Concentrate the meetings in a specific time slot of the day. After the daily standup is a good time to have meetings. Never go over that strip slot. If a discussion goes on for more than an hour, try to cut it short, it is probably not productive.</p>
<p>Declare non-meeting days where the team can focus 100% on product development. No meeting is so urgent that it can&#8217;t wait for the next day.</p>
<p>Protecting the team&#8217;s time doesn&#8217;t mind isolating them from the customer. Your role is not to be a bottleneck and act as a filter for everything that arrives. Your mission is to connect the team to the problem, including putting them in direct contact with users. Those meetings are the ones that truly add value. Encourage them.</p>
<p>If your tech lead or your engineering manager connects directly with the client to solve a question and you only find out days later, you’re doing your job well. The best feeling in the world is when your team is mature enough to disintermediate you.</p>
<h2>Be present</h2>
<p><span style="font-style: italic;">&#8220;Be present above all else.&#8221; — Naval Ravikant.</span></p>
<p>A good product manager is there when you need him. Any member of the team can have a question at any given moment. The product manager must be there to solve it.</p>
<p>If we have done our job of understanding the problem intimately, the answer will be obvious. In those cases where we haven&#8217;t, acknowledge it unambiguously. Sometimes an &#8220;I don&#8217;t know&#8221; gives more confidence than an improvised answer.</p>
<p>Connect with the team constantly to understand their concerns and motivations. Personally, every two weeks, I like to have a 1-on-1s with each of the team members. Understand what motivates them and empowers them. Correct the course on those things that aren’t working. Each team is different. There are no magic patterns. Adapt your way of working to what the team needs and not the other way around.</p>
<h2>Encourage quick feedback loops</h2>
<p><span style="font-style: italic;">&#8220;If you&#8217;re smart, you often want a feedback loop, so you know if what you&#8217;ve done is right.&#8221; — Bill Gates.</span></p>
<p>Always choose the shortest route to validate that what you are doing adds value. As a general rule, investing more than three months in any initiative without taking it into production is a sure recipe for the team to be demotivated.</p>
<p>If something is too big, slice it up so that you can be validating in a month and a half. The perfect is an enemy of the good.</p>
<p>Avoid falling into the <span style="text-decoration: underline;"><a href="https://en.wikipedia.org/wiki/Sunk_cost">sunk cost</a></span> trap. The more time you spend developing something, the more it’ll cost you to abandon it if it doesn&#8217;t work. If it always works, we are not going fast enough. Build small. Validate. Iterate.</p>
<h2>The mistakes are yours, the successes of the team</h2>
<p><span style="font-style: italic;">&#8220;Only those who dare to fail greatly can ever achieve greatly.&#8221; &#8211; Robert F. Kennedy.</span></p>
<p>When you’re successful, publicly praise the team&#8217;s contribution and stand by. When there is a problem, be the first to take responsibility for it.</p>
<p>Fix any issues internally. Your team will respect you if you do it, and they will mistrust you if you hold them responsible for any problem exposing them publicly.</p>
<p>Nobody said this was easy.</p>
<h2>Maintain good relationships with other team managers</h2>
<p><span style="font-style: italic;">&#8220;Succeeding in business is all about making connections.&#8221; — Richard Branson.</span></p>
<p>In an ideal world, all teams would be 100% autonomous and could move forward without dependencies. In the real world, you usually depend on other groups to advance.</p>
<p>Make an effort to meet and maintain good relationships with the managers of those other teams. Engineering, Design, DevOps are the usual suspects.</p>
<p>Maintain fluid communication with them, understand their concerns, and help them in whatever way you can so you can get their aid when the team needs it.</p>
<h2>Set aside time to tackle technical debt</h2>
<p><span style="font-style: italic;">&#8220;Left unchecked, technical debt will ensure that the only work that gets done is unplanned work!&#8221; — Gene Kim.</span></p>
<p>You should set aside at least 15% of the team&#8217;s time to clean up technical debt. If you don&#8217;t, the codebase will gradually deteriorate, affecting motivation and, more importantly, the ability to deliver value.</p>
<p>There are many ways of doing it. I like the idea of ​​setting aside a full sprint for technical debt after each quarter. On the one hand, the team can plan that sprint as any other, choosing the most critical points to grab. On the other, it allows the team to disconnect from the normal day-to-day development pressure.</p>
<h2>Concluding</h2>
<p>The role of a product manager is complicated enough. You don&#8217;t want to face it with a demotivated team. Today we have viewed some ideas on how we could improve the motivation of our teams:</p>
<ul>
<li>Embark them on a mission.</li>
<li>Tell them the problem, don’t give them a solution.</li>
<li>Give them autonomy to decide how to organize themselves.</li>
<li>Protect your time from unnecessary interruptions.</li>
<li>Be present with any questions.</li>
<li>Promote rapid feedback cycles.</li>
<li>Absorb mistakes and deflect success for the team.</li>
<li>Maintain good relationships with other team managers.</li>
<li>Take time to clean up technical debt.</li>
</ul>
<p>In any case, don&#8217;t make the mistake of just applying them blindly. If you spot motivational problems, start by engaging in one-on-one conversations with team members to understand what may be happening.</p>
<p>Usually junior teams will need more support and will be less independent than senior ones. Understand where your team is and help it become a true product team.</p>
<p>For your team. For your company. For you.</p>
<p>Discover more content on <a href="https://www.mindtheproduct.com/category/building-product-teams/" target="_blank" rel="noopener">building product teams</a>. For even more content on a range of product management topics, see our <a href="https://www.mindtheproduct.com/content-a-z/" target="_blank" rel="noopener noreferrer">Content A-Z</a>.</p>
<div class="g g-16"></div>
<div class="g g-16"></div>
<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

Making product magic with cross-functional collaboration by Ebi Atawodi

10 years Wiser: Lessons learned from scaling Wise by Nilan Peiris

Breaking down misconceptions to create healthier teams by Adrian Howard

Creating courageous product teams with Yi-Wei Ang

Mastering perspective – zoom in, zoom out as a product leader by Navya Rehani Gupta

How to motivate a product team

Simón Muñoz

Comments

Read next