Product Management: 5 Lessons Learned While Working with Engineers
There is probably no more important relationship for a successful product manager than the one with your engineers. — Marty Cagan
It went by so quickly, but it’s already been 10 years since I started working with software engineers (the last 3 years as a Product Manager), and it’s hard to disagree with what Marty Cagan says above. Let’s say you have a million-dollar idea, but your idea will remain just that, an idea, unless of course it reaches the market. This is why figuring out how to effectively work with engineers is a skill worth not only knowing, but mastering if you’re a product manager (PM) in the tech industry or want to become one.
Even though I originally graduated as a software developer, I barely worked as one. Despite this, I still found myself often collaborating with talented engineers from all across the world. In this article, I’d like to highlight some of the lessons I’ve learned while working with all of these different software engineers through the past decade.
1. Apply a personal approach
As maybe you’ve heard, the stereotypical opinion of software developers, is that they are introverts by nature, rather quiet and not overtly seeking for social interaction. Does this stereotype actually hold water or is it just a myth? To find out, I sought out research (1,2) on the subject and discovered that the studies that have been conducted found no real correlation between software developers and introversion. In fact, the majority of the developers that participated in the studies were found to rather be extroverts.
Like anyone else, a software engineer’s personality will vary from person to person and by extension will also vary in their preference for collaboration. Some are, indeed, more introverted and prefer to keep discussions to only what is necessary. Others love to participate in the early product discussions and be a part of customer interviews. Getting to know your teammates and understanding the way they operate is a more than a worthy investment to make, as it allows you to apply a more personal approach to each person and therefore also make teamwork more pleasant and efficient.
As can be expected, not all personalities will match and some friction is nearly inevitable between PMs and engineers, but as mentioned above, this is a relationship worth taking seriously and acceptance plays a huge part. A desire to find common ground (which often means admitting to your own flaws) will widen the spectrum of talented engineers a PM gets to work with. This same desire will also help to foster a more enjoyable working environment despite the contrasts in personalities you might encounter.
2. Gain trust
Simply carrying the Product Manager title isn’t going to make engineers trust you. In my experience, most Engineers are sharp, rather skeptical, and more than capable of sensing bullshit. They usually dislike talk that is vague and prefer data over statements like “I think customers will love it”.
Understanding customers and grasping their pain points is what most PMs strive to be experts on. Communicating the why aspect to your whole team and continuously offering both qualitative and quantitative forms of evidence shows that you not only comprehend the product market, but it also helps engineers to trust your instincts. With a clear picture in mind, they will be motivated to invest their time and skills towards the next product idea knowing that they’re solving real customer problems instead of just building another “cool feature” nobody needs.
Another facet to gaining trust is through honesty and openness. Like most of us, engineers appreciate this candid approach rather than dealing with overconfidence and boasting. Rather than feeding your ego and wasting everyone’s time, it’s much better to simply admit when you don’t know something and if poor decisions are made, own up to them early on. Show that you can listen, and accept the fact that you need your team’s help in coming up with the best solution.
3. Share vision and customer insights
We need teams of missionaries, not teams of mercenaries. — John Doerr
This quote above really got me thinking. I realized that a big portion of my motivation comes from understanding the problems our users experience and the way our product helps to overcome them. How can I expect engineers to be committed to a project when they may lack the knowledge behind why we’re doing it? I doubt I’d feel passionate about something if I was told to do it without fully understanding why it’s being done.
Engineers who truly understand the business context of the product, the long term vision and how their work impacts company objectives rarely need motivational speeches to be engaged — they already feel accountable and driven to solve problems for their customers. With this in mind, it’s good to remember that teamwork isn’t a one-way street and both sides can learn from each other. In fact, engineers who really know the product tend to be a great benefit toward a PM’s quest to build a better product.
Building a team of missionaries first starts with the Product Manager. It’s crucial to share customer knowledge openly with the whole team and engage them in product discussions. Sharing things like — results from completed research, discoveries from usability testing, impact on KPIs from recent changes, snippets from interviews, and customer feedback or quotes is a great way to nurture a dedicated product team and help to develop empathy for a customer.
4. Value engineers’ time
Just like PMs prefer to work on tasks related to product management, engineers also prefer to focus on their own expertise. Make sure your team doesn’t need to waste extra time working on the side tasks if they can be avoided.
Here are a few suggestions:
- Figure out which way your team best understands a task description and stick with it. This will save time by reducing the amount of double-checking that is needed and, in worse case scenarios, it helps you to avoid having to re-build things because of a requirement being misunderstood.
- Report bugs rather than asking for them to be fixed. Why add more things for engineers to remember and thus risk perhaps more important things getting forgotten? Just document that damn bug and let engineers focus on what’s important at the moment.
- Eliminate blockers. Organize work in a way so that missing designs, copy or anything else doesn’t prevent product development.
- Investigate edge cases. While creating requirements, take time to discover edge cases and leave fewer surprises (some are bound to happen) for later.
5. Invest in team spirit
There’s ONE thing that all of the engineers I have worked with during the past decade have had in common. Despite different personalities, ages, genders, and even music preferences, every single engineer I worked with truly appreciated a great team vibe, including inside jokes and a sense of “all being in this together”.
As a PM, I’d recommend doing everything you can to nurture a strong team spirit as it produces a tremendously positive impact on the work atmosphere. Team events, as well as non-work related conversations, help to create a better connection and release social barriers. You’ll notice when your team starts to sync with each other when they naturally begin caring for each other.
Going through challenging moments is much more fun when you do it as a team, supporting each other. One of my most vivid work memories is related to a crazy two-day troubleshooting experience which I would never want to exchange for a more “work as usual” event. That’s because this is the time when I really appreciate my team the most and realize that a great team vibe is so much more than just joking around. Collaboration is a powerful thing and it’s built on relationships.
