post

Footer About

Footer Contribute

Footer Get Involved

Footer Links

Mind the Product

Product Management

What your workflow needs is bespoke AI: This week’s product news

Artificial intelligence (AI)

Growing a unicorn: Inside DeepL (Justyna Walkowska, Product Director)

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

A deep dive into internal product management

Lessons from my first year as a Prod Ops Manager

It’s the Strategy, stupid – Andrew Martinez-Fonts (VP Product, Honeysales)

Poll results: What tools are product managers using the most?

Leadership coaching: 5 reasons why you should do it

<a href="http://www.linkedin.com/in/kunalspunjabi/">Kunal Punjabi</a> is a Product Leader with 15+ years in product (consumer B2C, B2B SaaS marketplaces) and 7 years of people management experience (managing teams of up to 4 PMs). He has held executive positions in Product management and led the conception, execution, go-to-market and growth of products at companies like Cerebral, Xerox PARC, Achieve (Freedom Financial network, Freedom Debt Relief, Freedom Plus, Bills.com), Shutterfly and others. 

Kunal has built and grown products that have generated tens of millions in revenue and has extensive hiring and management experience of IC PMs. He has operated at small (&lt;30) and large (3,000+) organizational scale, navigating teams through hyper-growth, layoffs, and shifts in company direction. He also has been a Continuing Education lecturer in Product management for Stanford Continuing Education since 2018. Kunal received his Masters in Electrical and Computer Engineering from Georgia Tech and has spoken at conferences like Product Camp Silicon Valley. 

You can email him at kunalspunjabi@gmail.com and follow him on <a href="http://www.linkedin.com/in/kunalspunjabi/">LinkedIn</a>.

Kunal Punjabi

<p>Product management is a cool job, arguably one of the most sought-after roles in business today. But, if you&#8217;ve been at it long enough, you inevitably end up hearing some version of this phrase at one time or another:</p>
<blockquote><p>God only knows when my product is going to be shipped!<cite>Frustrated Business Person (or product manager)</cite></p></blockquote>
<p>Or some version of the converse&#8230;</p>
<blockquote><p>Product managers&#8230; they&#8217;re always giving us more sh** to do.<cite>Frustrated Engineer</cite></p></blockquote>
<p>I&#8217;ve heard some variant of these phrases more than once. In my darkest hours, I might have even muttered a mild version of one of these under my breath.</p>
<p>Of course, these feelings are normal, even healthy, in moderation. Product management and engineering needs to have a constant push-pull for progress to be made. Too much of it at once, and the string breaks because of the tension. Too little, and the string goes slack, and nothing gets done. So how do you make sure the string always has the right amount of tension, doesn&#8217;t go slack, and never breaks?</p>
<p>While I don&#8217;t consider myself an expert (and never will&#8230; I think it&#8217;s important to cultivate a learner&#8217;s mindset), I believe I have learned the &#8211; in some cases, hard-earned &#8211; lessons on how to effectively work with, communicate with and motivate engineers that could be useful to other product management leaders as they look to improve velocity and time-to-market of their (hopefully agile) teams.</p>
<p>Here are some of the things to keep in mind when working with engineers that I’ve gleaned from my experience. When in doubt, these should serve as your North Star.</p>
<h3>Start With Why</h3>
<p>Product managers own the &#8220;what&#8221; and &#8220;why&#8221;; engineers own the &#8220;how&#8221;.</p>
<p>If you hire smart engineers and simply tell them what to build without explaining the business case or potential impact your product or feature is going to have (in other words, if you don&#8217;t start with the <em>why</em>), you:</p>
<ul>
<li>Risk demotivation (leading to delays, or worse) if the engineers don’t understand the value of the product or feature you want them to work on</li>
<li>Lose time by over-building (or worse, building the wrong solution) because, had the engineers understood the problem being solved, they might have had a better (or quicker) way to solve it</li>
<li>Risk being misunderstood on one or more details (or even a bigger portion) of the product, which could have been avoided if the why had been made clear up-front</li>
</ul>
<p>Starting with why is the single biggest thing you can do to motivate your engineering team (in fact, your entire team) in charging forward toward a common goal.</p>
<h3>Be Open to the &#8220;How&#8221;</h3>
<p>This especially holds true for product managers from an engineering background, or those who have been accustomed to being entrenched in the weeds/implementation.</p>
<p>In general, once a problem has been identified, it can be solved a number of ways. Don&#8217;t dictate &#8216;the how&#8217;. Have a discussion with the people in the engineering team who will work on it, and ask them to make recommendations on the how so that you can pick from the options (by evaluating the trade-offs on implementation cost and business impact). This will help find the best solution for your customers AND save on your team’s time.</p>
<h3>What to Do With Success and Failure</h3>
<p>When you succeed, thank them. When you fail, look to yourself first. This has two parts to it:</p>
<ol>
<li>Deflect praise</li>
<li>Absorb blame</li>
</ol>
<p>As a product manager, expect your successes to be recognized. Understand that executives will often praise you for the team&#8217;s successes &#8211; it always pays off to be humble and deflect praise across the entire team. Not only will doing this make executives respect you more, but it will also have the effect of building your team&#8217;s trust in you, which is critical to your team&#8217;s future successes. Besides, doing the opposite will only backfire and make you appear a power-hungry attention hog.</p>
<p>The flip side to this coin is the occasional outage or failure. When something fails, be the first to step up publicly and take the blame. If it is obvious that it wasn&#8217;t your fault and someone on your team messed up, call it out as a failure on &#8220;our&#8221; part, and as the leader of the team, take immediate ownership of fixing the problem. Never redirect the accusations that are aimed at you.</p>
<p>Whatever you do, make sure you send shout-outs and give credit to the engineering team when things go well.</p>
<h3>Sweat the Small Stuff &#8211; be Detailed and Specific</h3>
<p>No detail is too small. Many product managers leave the technical details (or worse, details of the product) to the engineers, using &#8220;it&#8217;s not my job&#8221; as an excuse. But understanding the technical details will help you understand what&#8217;s hard, what&#8217;s easy, and make better trade-offs. It also has the effect of making the product better and earning the respect of the engineering team, which isn&#8217;t easy to come by. Both are value-adds that make you indispensable to the team and organization. Remember that as a product manager and leader of the team, the onus is on you to keep a record of every detail in writing. Just don&#8217;t make your specifications so wordy that nobody bothers to read them.</p>
<h3>Always be Transparent and Involve Engineers Early</h3>
<p>Engineers are highly analytical, but many also understand sound business and product strategy. On top of that, they&#8217;re also highly sceptical &#8211; the best ones question everything (in a collaborative, constructive fashion). Involve engineering early and often, so everyone has a chance to contribute to the product vision and buy into where the product is headed.</p>
<p>Transparency builds trust and trust leads to great effort. The worst thing you can do is maintain an air of mystery when decisions are made. Remember, building a great product is a collaborative process.</p>
<h3>Never Commit Without Them</h3>
<p>You should never &#8211; I mean <em>never</em> &#8211; commit to dates, make estimations of effort or communicate project schedules without consulting your engineering team. Again, product managers who come from an engineering background are especially susceptible to this, but it&#8217;s easily fixable by ensuring your engineering lead is looped in before any major commitment is made to any of your stakeholders.</p>
<p>That said, it&#8217;s okay for you to challenge estimations (internally with your engineering team, and with sound reasoning), before communicating project schedules to stakeholders. Just make sure that you are aligned with your team before you reach that point.</p>
<h3>Unblocking Your Engineering Team is Always Your Highest Priority</h3>
<p>As product owners, we&#8217;re frequently swamped with things to do and requests from our stakeholder teams, including business development, account management, marketing, and so on. However, it should always be your top priority to answer a question for, or help test a feature that would help unblock, your engineering team (especially if they are working on a task for you in a Sprint that has already been set in motion). Responding to stakeholders and customer requests should always come second.</p>
<p>In the end, it comes down to respect. What&#8217;s more important, your time or the collective time of everyone on your engineering team?</p>
<h3>Respect Their Time</h3>
<p>How would you feel if you were in the middle of a long but important math calculation, and you were asked to drop everything to look at an email someone just sent you? That&#8217;s basically the life of an engineer, times 100.</p>
<p>Don&#8217;t be <em>that</em> person.</p>
<p>Whatever an engineer is working on is probably more important than what you need right now. Ask yourself, how critical is this, and do I need it now? Is it worth the productivity loss this request is inevitably going to cost the team? Can I get someone outside the team to help, or better yet, can I do it myself?</p>
<h3>Know (and be the Voice of) your Customer</h3>
<p>Always remember that the company is in business to make sure customers are happy. That should always be your North Star.</p>
<p>So, it&#8217;s your duty to be prepared with information (whether that be qualitative or quantitative) on how the client or customer thinks about things, what their needs are, and ideas to make their lives better. This is a great way to motivate your engineering team and earn their respect.</p>
<p>In the same vein&#8230;</p>
<h3>Align Perspective With the User</h3>
<p>Often, the winner is the HiPPO (highest paid person&#8217;s opinion), but that&#8217;s not necessarily the best way forward when it comes to building great products. If you make the customer or client the most important person in the decision-making process, agreement and alignment across the entire organization (not just with your engineering team) becomes much more attainable.</p>
<h3>Set Expectations Through Experimentation</h3>
<p>When it comes to making decisions, experimental data makes for a much better conversation starting point than opinions.</p>
<h3>Validate Demand to Build Consensus</h3>
<p>Nothing motivates an engineer more than a quick (or sure) win. To that end, you could use experiments to clarify and validate the demand for a product or feature before a single line of code gets written. And when you do, look at what the data tells you, and use it to your advantage when making your case.</p>
<h3>Use Designs Only as a Tool for Mutual Understanding</h3>
<p>This ties back to my earlier point about involving engineers early. As long as it&#8217;s not taking them away from productive screen-time, engineers appreciate it (and are more easily bought into an idea) when they are included in emails/discussions/early mockups of concepts. In the same vein, designs, when first shown to the engineering team, should not be set in stone.</p>
<p>Ideally, designs should be used as a tool to explain a possible solution to a customer problem that you can all talk through. If designs are always &#8220;locked and loaded&#8221; and rarely tweaked after you show them to engineering, you’re probably not involving them in the process early enough, and therefore, doing it wrong.</p>
<h3>Always be Testing (ABT)</h3>
<p>ABT typically refers to a culture of experimentation and continuous discovery about your customer, but I like the acronym enough to use it here as well.</p>
<p>The best product managers consider testing (or &#8220;Product Sign off&#8221; or &#8220;Product Acceptance&#8221;, whatever you may call it in your workflow) to be an important part of their job. A separate QA function is important, but it’s also important that the work of testing not be something you just leave for others. And while testing the product, be sure to think about whether the solution that your team has built will work for your customers &#8211; and if it doesn&#8217;t, what needs to be changed to make it so.</p>
<h3>Cut Process Down to a Minimum</h3>
<p>Nobody likes process, certainly not engineers, especially when it leads to wasted time and unnecessary roadblocks. Keep tracking software or spreadsheets, status reports, and cross-functional executive update emails down to a minimum. Better yet, eliminate them. Here&#8217;s what I have found typically works well for most agile teams:</p>
<p><strong>Bi-weekly:</strong></p>
<ul>
<li>Backlog grooming sessions<br />
Sizing / estimation sessions<br />
Sprint planning sessions (factoring in velocity, and including a <a href="http://agileforall.com/learning-with-fist-of-five-voting/">&#8220;Fist of 5&#8221; confidence vote</a>)</li>
</ul>
<p><strong>Daily:</strong></p>
<ul>
<li>Standups</li>
<li>Evaluation of sprint progress</li>
<li>Above all else, find ways to collaborate and work more closely together on a daily basis.</li>
</ul>
<h3>16. Focus on Building Strong Relationships</h3>
<p>This extends beyond building relationships with just your engineering team. While it&#8217;s important to maintain boundaries, it also helps if you don&#8217;t separate your personal and professional lives too rigidly. Besides acknowledging and appreciating others&#8217; work, ask people how their weekends were. Schedule the time to listen and understand. Give people the benefit of the doubt. If you&#8217;re managing a team, make sure everyone takes the time off they need to be healthy and happy (which indirectly translates to productivity and team success). Or, as Ken Norton likes to say, &#8220;Bring the Donuts&#8221;.</p>
<h3>Be Realistic With Expectations, but Push Them</h3>
<p>Engineers are grounded in practicality. While it&#8217;s important as a leader of the team to demonstrate that your plans are realistic and can be executed upon, they also need to be challenging. We wouldn’t have the successful SpaceX rocket launches had Elon Musk not pushed his engineers to exceed beyond what they thought were their limitations.</p>
<p><strong>Above all else:</strong> appreciate your engineering team, respect them, communicate with them frequently, and you&#8217;ll be golden.</p>
<p>Credits: A few of the ideas were inspired by Ken Norton&#8217;s <a href="https://www.kennorton.com/essays/how-to-work-with-software-engineers.html">sardonic blog post</a> and Megan Berry&#8217;s <a href="https://medium.com/the-mvp/9-tips-for-better-product-collaboration-with-engineering-c5927d9eb526">blog post</a> on the same topic.</p>

core/freeform

Reduce risk, fail faster: Experimenting across the product development lifecycle

A Guide to Collaborating With and Motivating Your Engineering Team

Kunal Punjabi

Read more

Comments