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

As chief product officer of Shipa Freight, Paul has overseen development of shipafreight.com, a digital logistics platform for small and medium-sized enterprises. Formerly vice president of digital marketing for global logistics leader agility, Paul was responsible for establishing agility’s digital brand, building an online audience, and generating qualified leads. In his 25 year career, Paul has held various product and technology leadership positions with early-stage startups and Fortune 500 companies including Unisys, Destiny, and US Airways. Paul has a Master of Software Engineering degree from Carnegie Mellon University and a Bachelor of Computer Science from Brown University. Paul is based in Philadelphia.

Paul Rehmet

<p>Why are development teams so hard to work with? You&#8217;ve done your part—you have your <a href="https://www.mindtheproduct.com/podcast-roadmaps-okrs-vision-prioritisation-with-bruce-mccarthy/" target="_blank" rel="noopener">OKRs, roadmaps</a>, specs and designs in good shape. You&#8217;ve made delivery commitments to stakeholders. Now you just need to build those shiny new features. But your software engineers are questioning the business value, being non-committal on timelines, and their deliverables are missing the mark. When you raise concerns, they bury you in tech speak and make you feel dumber than a Slackbot. What&#8217;s a product manager to do?</p>
<p></p>
<p>Plenty actually. Here are a few tips to build a better relationship with your engineering team, from a developer turned product leader.</p>
<h2>Appreciate the craft of software engineering</h2>
<p>As product managers, we care about on time delivery of visible features that impact the customer or business. We often pay little attention to what&#8217;s under the hood. Developers, on the other hand, take pride in how their solution is built—the novel algorithm they used or how they were able to reuse components they&#8217;ve developed before. The best engineers excel at this hidden stuff and want to be recognized for it as much or more so than for fulfilling the business requirement.</p>
<p>Even if coding isn&#8217;t your thing, you can build a stronger relationship with your team by showing interest in their technical solution. Ask them to explain how they built the solution, how flexible it is, what tradeoffs they made, and what they are most proud of. Ask them how they improved that performance bottleneck. Have them explain the root cause of a bug and what they did to fix it. You will see that non-communicative developers warm up to you. You might even learn something.</p>
<h2>Help your engineers advance professionally</h2>
<p>More often than not, the engineers on your team don&#8217;t report to you. Although your positive feedback to them is appreciated, it is appreciated much more if it is shared with their managers. With our busy schedules, it is easy to forget to formally recognize a teammate&#8217;s achievements. Since I tend to be guilty of this, I explicitly add this as a step in my product process. Note the intent is not as a way to say thanks to the whole team. Rather it should be specific to individuals, their achievements, and positive attributes they demonstrated. Back your comments with specifics.</p>
<p>Also developers want to garner the respect of the architects and other senior tech people. Help by encouraging them to share their work with their peers. Support their efforts to promote themselves, allow some time for speaking at conferences or publishing in journals.</p>
<p>Make an effort to give them constructive feedback in the context of the work being done. Most will appreciate such tips and advice if it&#8217;s done in the right way, and become stronger teammates. For example I might say, &#8220;Hey so and so, it would be great to hear more from you in our next design session. You bring a perspective that the rest of us don&#8217;t have.&#8221;</p>
<h2>Expose them to your customers and business</h2>
<p>Just because it’s your job to <a href="https://www.mindtheproduct.com/how-to-use-the-5-whys-to-manage-stakeholders/">manage stakeholders</a> and drive the voice of the customer&#8217;s efforts, your developers shouldn&#8217;t be excluded from all such activities. Realistically, your engineers can&#8217;t dedicate their time to all your customer interviews and business meetings. However they will certainly benefit from direct exposure to some of those that your software is serving. Engineers have often told me what an eye-opening experience it is to participate in a customer interview, because— as we product people know—customers never cease to surprise us.</p>
<h2>Involve developers in your solutioning</h2>
<p>I often invite a couple of our senior architects to product brainstorming sessions. Presented with insights from our <a href="https://www.mindtheproduct.com/product-discovery-the-secret-sauce-of-great-agile/" target="_blank" rel="noopener">discovery process</a>, our architects come up with some of the best suggestions on how to improve customer conversion, retention, or other metrics. They help shed light on the technical effort required to solve a problem a certain way, and getting such information early will often streamline our solutioning process. And more than just improving decision making, involving engineers in solutioning sessions gets their buy-in and commitment up front, making the development process go smoother.</p>
<h2>Understand technical debt</h2>
<p>Your developers care a lot about technical debt, the sub-optimal state of the code base after repeated changes are made within typical project time constraints. While technical debt is unavoidable, your developers know how detrimental it can be to the long term health of your product. Your best developers will naturally want to prioritize reduction of technical debt over other things. But like with all prioritization, things aren&#8217;t so cut and dry. Product management techniques can help here.  Acknowledge that some of your dev effort will need to go toward reduction of technical debt. Challenge your developers to follow the same rigor you do when justifying new features. Which areas of technical debt will have the most business impact? How can assumptions be validated? How will key development metrics like number of bugs, developer productivity, etc. change? The bottom line is you need to take technical debt seriously, but elimination of all technical debt rarely makes sense. Work with your developers to find the right balance.</p>
<h2>Collaborate, don&#8217;t control</h2>
<p>Do you like the feeling of taking charge in your meetings with developers? Letting them know what you expect from them? I assure you they don&#8217;t like it. Remember, you are not the developer&#8217;s boss. You are not the developer&#8217;s customer either. There is a difference between telling the development team what needs to be built and telling them what to do. The former is a communication activity and a core part of your job. The latter is command and control management. Engineers seek clarity and appreciate strong communication from your product. However, they want autonomy to work their way. They want to work with you, not for you.</p>
<h2>Perform your role with confidence</h2>
<p>The product management function is often misunderstood, even by developers. Some see the product manager role as a glorified project administrator. Some feel it&#8217;s a job that anyone without any special knowledge can do. Developers see their role as quite the opposite—requiring both an inherent analytical way of thinking and lots of training and knowledge on their craft. So it&#8217;s no surprise that developers often have a certain feeling of <a href="https://www.mindtheproduct.com/the-mindset-of-empowerment-by-laura-scanga/" target="_blank" rel="noopener">empowerment</a>, and in some cases, not so much respect for product managers.</p>
<p>The best way to counter this is to showcase your product chops. Consistently follow your product process. Share the results of your discovery process. Articulate the value proposition of the features you are building. Explain how decisions were reached and share the data driving your decisions. Field product questions from the team with confidence. Once you establish yourself and your role, developers will respect what you do and will welcome your experience and insights.</p>
<h2>Share success</h2>
<p>Finally, remember the end game—getting customers to use your product! Both you and your developers want the satisfaction of having your collective efforts put to good use. Share the success metrics—improvements in monthly active users, better conversions, etc. Even better, share the success stories, the specifics you hear from customers about how the app helped them. We are all human and respond to such feedback.</p>
<p>Your success hinges on the success of your whole team. Try these tips for building a stronger team, and I&#8217;d love to hear if they help you.</p>
<p>Discover more content on <a href="https://www.mindtheproduct.com/category/product-development-process/" target="_blank" rel="noopener">product development process</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-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

Common transformation pitfalls by Marty Cagan

Using principles to make better decisions faster by Martin Eriksson

How to build for creators by Peter Yang

How to navigate tricky work relationships

Organizing around complex products at the intersection of physical and digital by Matthew Cornford

Tips to collaborate better with your development team

Paul Rehmet

Comments

Read next