As a product manager, our engineering team is the single group of people that we interact with the most. Thus, cultivating a harmonious relationship with our engineering team will help boost our productivity tremendously while saving us a ton of chronic headaches. This blog post contains useful tips that could hopefully help product managers work more effectively and efficiently with their engineering team.
I can’t claim to be the most successful product manager ever. My motto is to “stay hungry and humble” (never let the ego-to-talent ratio out of whack). But I’d still love to contribute my tiny slice of personal experience to the topic. I hope my stories could add some value or at least a fresh perspective to help you improve your craft.
#1. Do the Homework
As product managers, we don’t have direct authority over the engineering team. Some of my old friends from college or high school thought the word “manager” in “product manager” meant I was the boss and I could fire anybody on a whim. I wish I could be that powerful. But in fact, that’s not even slightly true. A product manager is not a boss or manager in the traditional sense.
As a product manager, our authority doesn’t come from the job title but from the insights we bring to the table. It could either be a visceral understanding of customer pain points, business acumen, design intuitions, alignment to the company strategy from the very top level (C-suite), user data insights, technical know-how, etc. And how to acquire these insights? It’s simple: do the homework beforehand.
In my early days as an Associate Product Manager (APM) around 4 years ago, I used to come into meetings with engineering teams empty-handed. People could sense this lack of preparation miles away. When confronted with thorny questions, I was frustrated and hesitant to give a straight answer. Because I simply didn’t know any better.
But soon afterward, I finally realized the power of doing the legwork beforehand. I knew that there was no other easy way to earn the trust of my engineering team other than proving my value to them. And I could add value to my team in the three most important areas: [1] customer insights, [2] technology, and [3] business context (I'll discuss these areas of knowledge in details in the next tips). From that point on, I never stepped into a product meeting without doing the homework first.
Why preparation pays off exponentially? Because preparations create an aura of "I've got this" around you as a product manager. In other words, better preparations help you establish a reputation of an expert. And everybody loves to work with experts whom they can trust and respect. Lenny Rachitsky included this quality in his "14 Habits of Highly Effective Product Managers" tweet below. I've definitely recommended reading it.
#2. Be the Voice of the Customer
The biggest component of the "I've got this" aura that is usually expected from product managers is being the voice of (real) customers. When we bring customer perspective to the conversation, it usually helps eliminate a lot of ambiguity thus speed things up.
There are many ways to gain customer insights but I picked three approaches that were most suitable to my situation at the time: [1] product demos, [2] interviewing end-users regularly, and [3] helping Customer Success (CS) with support tickets.
Product Demos
When I was the Product Owner (PO) of a Scrum team (prior to APM), I rarely talked to the customers and end-users. All so-called “customer insights” I got were just hear-say. When I came to realize this serious problem, I went overboard on customer engagement. One particular channel that I could add value was product demos.
Usually, a group of technical sales engineers in conjunction with a salesperson were responsible for all product demos. So I talked to them about new opportunities in the sales pipeline. The first few demos were not to my utmost satisfaction. But later on, they got smoother and smoother. I learned how to better articulate our product values, tailor the product values to the customer's unique situation (customer benefits), and how to demonstrate product capabilities in real scenarios. And the best part was learning how to answer tough questions directly from customers. Oh boy, they were always surprising.
Interview End-Users Regularly
Besides product demos, another way for product managers to glean customer insights is to interview end-users directly. Some of the B2B product managers don't have this luxury because the direct sales team will seize all customer interactions. They are overprotective of the customers and usually want to tightly control customer relationships. This happens for a reason. But most of the time, product managers are able to reach out and talk to customers, either by email, phone, Zoom or face-to-face.
For me, I was able to gain customer insights by syncing with our internal user groups. LogiGear has an interesting dynamic: besides selling test automation tools, LogiGear also provides QA services to clients around the world. These service delivery teams are a good representation of our user base thus a valuable source of insights.
Since service teams are first-hand end-users of the tool (TestArchitect), syncing with them on a weekly basis helped me understand how the product was used in real life. These interactions provided me with wisdom nuggets here and there. For instance, I was surprised to find out that one of our UI dialogs was so badly designed that users could not rearrange the order of test execution. They got to cancel the run and create a new run from scratch if they wanted to move a test case up or down. I immediately added the fixes to the very next release.
Support Tickets
Lastly, the most accessible source of customer insights for product managers: support tickets. The sales team can monopolize other communication channels with the customers but not this one. Now it only comes down to whether the product manager has the time and energy to immerse themselves in the feedback of end-users.
For several months, I put in the extra effort to read each and every support ticket on the customer support portal. Doing so helped me directly feel the pains of users -- described in their own words. It could sound like sidelining the Customer Success team and undermining their value to the organization. At first, I faced a certain push back from the Customer Support Manager but later on, we got along just fine. The lessons I've learned from reading and replying to support tickets are:
- We could exercise our "customer empathy" muscles & refrain from judging too soon.
- And above all, the product manager can practice "falling in love with the problem, not the solution".
It's a dangerous trap for PM to work backward from a preconceived solution. Customers usually posted a ticket dictating the solution they needed. But actually, once we dig a little deeper, there are always more nuances behind the scene. If product managers mindlessly take whatever the customer says and put it in the roadmap, we’d encounter tremendous opposition from the engineering team and eventually hurt the business by diluting the team’s focus.
Most importantly, we're not empowering the engineers. No engineering team wants to be treated as a "feature factory" -- mindlessly churning out preconceived solutions but not solving business problems. The best way to empower engineers is to give them a problem and provide a business context (guardrails) then let them figure out the best way to solve it on their own. You'll be amazed by the creativity of your engineers.
#3. Develop Passion for Technology
Engineers respect people with technology prowess, period. They will immediately flip their “bozo bit” if we can’t make heads or tails of an object, a property, and a class. Or if we cannot tell the differences between static site generator, single page application (SPA), progressive web app (PWA), and a normal web page. And once lost, it’s arduous to change their mind and regain their trust later on.
As product managers, if we want to get into the “inner circles” and be considered “equals” by engineers, we must brush up on our technical skills. I know some business-focused product managers would scream otherwise. But hear me out, we don’t need to get down to every line of code. Understanding technology at the conceptual level is good enough.
To give a little background, I’m a technically inclined product manager. In the early 2000s when I was 11 years old, a co-worker of my mom gifted me her old computer (an Intel 80386 with 256 megabytes of HDD). It was not much but it opened up a whole new wonderful world in front of my eyes. Twenty years ago in a third-world country like Vietnam, having a computer was truly a privilege. I was fascinated by the old computer. I loved how easy it was to give the computer a command and it obediently executed without any questions.
That’s why I started programming in Pascal at an early age compared to my peers. Then I got into a program for “gifted” kids specializing in Pascal programming. When I entered university, programming courses were just a breeze thanks to the early head start. Thus, I graduated as a Valedictorian majoring in Software Engineering. I’m forever indebted to this angel lady.
Backgrounds in programming, software engineering or computer science are a big advantage when communicating with engineering teams. But that’s not to say, non-tech backgrounds cannot do so. IMO, the key is to be a sponge that soaks in as much technical knowledge as possible day in and day out. For instance, I subscribe to technical newsletters like The New Stack, Techmeme, Tech Crunch, etc. and frequently listen to podcasts like The New Stack Makers, a16z, Syntax, Recode Daily, Cyberwire Daily, Changelog, Test Guild, Tech Stuff, etc. Constantly immersing myself in tech helps me keep up with the mega-trends as well as understand the tradeoffs and limitations of certain technologies.
#4. Provide Business Context not Solutions
A software engineering background helps me a lot in discussing technical problems with my Engineering team. But it’s also a big disadvantage when it comes to business acumen. Compared to an MBA, I got zero confidence in providing business insights to the team. Engineering teams are technical geeks (in a good way). They excel at building software and solving problems. But they need to know for sure that they are not only building things right but also building the right things. They totally rely on the product manager in this regard.
Providing the business context including market dynamics, competitive analysis, the business outcomes that the organization is pushing for, etc. is a key value-add of product managers. When presenting to the team, we have to make sure we highlight system thinking behind every product decision. For instance, if we prioritize metrics like increasing Acquisition, we’ll inevitably hurt Retention. A trade-off has to be made. We can’t have it both ways.
Since I cared about my job and I wanted to be better every day, I made a commitment to learn more about business. I took online courses like Creating a Business Plan, Financial Modeling for Non-Financial Managers, Advanced Product Management, Digital Marketing, etc. on Udemy and LinkedIn Learning. I taught myself useful models like Porter’s 5 Forces, SWOT Analysis, Positioning in Marketing, etc.
Among these topics, I found that Marty Cagan’s framework of Product Discovery was the most useful. To Marty, the core of product discovery is that we have to de-risk the four major risks:
- Value risk -- Is the product useful (providing value) to the customer?
- Usability risk -- Is it easy enough to use?
- Feasibility risk -- Can we build it in a cost-effective way?
- Business viability risk -- Are the customers willing to pay so that we can sustain the business?
I won’t dive into the details of this framework since it’s out of the scope of this blog post. If you want to learn more, check out Marty’s book -- Inspired: How to Create Tech Products Customers Love. 100% recommended.
Disclaimer: No affiliation whatsoever.
#5. Always Take the Fall
I’d like to think of product managers as the last line of defense for the product. When everybody else leaves, the product manager is the last one to fight the last battle. A product leader I know had an excellent articulation of his own:
Product manager is the one to catch everything falling through the cracks.
Both ideas mean a product manager should never say “this is not my job”. Everything is the product manager’s job since we are ultimately responsible for the success of the product. No one else.
Along the same line of thinking, when something goes wrong, a product manager cannot say “that’s not my fault”, “that’s because the developer made a mistake”, “oh that’s because a test engineer forgot to verify a bug fix”, etc. It’s a big no-no.
If something bad happens, we must take the fall. If a developer makes a mistake, it’s because the product manager has not been specific enough in his/her product requirement specifications (note that developers are creators so they love specific details like what to show when the returned data is blank…). If a test engineer forgets to cover a test case or verify a bug fix, it’s because the product manager fails at user acceptance testing.
Conclusion
I hope the tips above help you collaborate more effectively with your engineering team. Working with the engineering team is never easy. But it’s fulfilling and rewarding. As a product manager, what energizes me to get out of bed and go to work is the mission of connecting what the team is doing with a higher purpose. Bring meaning to the daily work of the team brings me joy and utmost job satisfaction. I hope you also feel the same. For more inspirations, check out videos and blogs from famous product leaders like Marty Cagan, Gibson Biddle, Ken Norton, Eric Berg, Hiten Shah, etc.