Hey Product Managers — Stop Pissing Off The Engineers
So you are the product manager — CEO of your domain — and the go-to person for everything that matters. You help set the strategic framework for where your product and the business are headed and lead a cross-functional team to greatness. You see the big picture and can muck around in the minutiae with the best project manager around. Your brain is evenly split between “blue sky” and “rat hole” and you know when to be where. You are a rational force and a creative artist. You converse with every tribe, including customers, marketing, sales, support, and every other stakeholder group that your product depends on to win in market.
But do you speak engineering?
The intersection between product and engineering is where the magic happens for software companies. And great product management is usually the difference between mediocrity and awesome. While nobody would miss product management if it (and you) disappeared in the short-term, ensuring product alignment with business strategy, market opportunity, and customer need is what superstar PMs do in market-leading companies.
However, the reality is that you need engineering more than they need you. They can continue to crank out product without you (and be happy doing it), but you cannot write a line of code yourself. Engineers are the manufacturing engine that drives the business forward and are the most important non-customer asset in the company. You are overhead.
So why do product people keep pissing off engineering? “I don’t anger them,” you think, but consider the following five common ways that PMs piss engineers off every day. It is a chance to pause and truly reflect. Be honest, which ones do you do? It’s a bit like body odor — self-examination and fearless honesty matter.
Be mysterious What you may think: Engineers are busy and do not like speaking with people. Coding all day is good fun, talking with people is torture. Engineers will just get confused if we talk about product vision and strategy. Plus, what do they know about the market, competition, or customers anyway? My vision is pure and they must follow. It is good to involve them as late as possible, and this level of mystery keeps them interested in what is coming next.
Reality: Building great product is a collaborative process that works well if everyone agrees on the product vision and strategy. Why wait to involve engineering in your roadmap planning until you have set the product direction? Transparency builds trust and trust leads to great effort. Involve engineering early and often, so everyone has a chance to contribute to the product vision and buy into where the product is headed.
Just keep talking What you may think: They do no get out much and while coding is fun, it can be lonely. They trust me to tell them about the real business world and what customers are asking for, so it is my responsibility to tell them all about it. If I just keep talking in my product team meetings and asking for what I need, it will help them build it. And it is hard to detail features, so why bother? Let’s just discuss.
Reality: Write it down. You are a talking head to engineering and prone to flip-flop on priorities based on what the last [fill in the blank with customer, sales, exec] asked you for. It is unlikely that your most recent insight is more important than what they were already working on, so stop jerking them around. Putting a plan in place and articulating features and user stories in detail makes you appreciate the nuances of what you are asking for and what it takes to build it. It also gives the team a way to comment and ask questions, ultimately helping to refine what you are asking for before a line of code is written.
Explain how to do it What you may think: I have been around engineers a long time and know the difference between NoSQL and MySQL. And there is no doubt that I would have been a great engineer if I had learned to program, found it rewarding, and led a ton of open source projects. Thus, it is my responsibility to recommend how engineering should implement what I ask for. The “how” is an important aspect of getting product out the door, and I am going to be right there with them on every important architectural decision.
Reality: You are wasting your time and engineering’s patience. Focus on the “why” and “what” and leave the “how” bits get developed to engineering. And whatever you do, don’t bury yourself a bigger hole by suggesting how hard or easy something is or when the team is going to deliver it.
Hoard credit What you may think: I am a product manager because I thrive in the spotlight. Who else in the organization has the visibility to the executive team as I do? Who gets called more often to close a deal, save a deal, speak to the press, cajole the analysts, or engage with a partner? I am a one-person business force and the accolades are my fuel. Most of our great ideas are mine anyway and I am the one who drives engineering to deliver.
Reality: Great leaders deflect praise and give credit to others. They do this because they know that great efforts are almost always achieved by the team and that deflecting praise builds trust and is the greatest reward for success. Sage product managers always have their heads up, thinking about what is next and how to work in the interest of the team. For when the team delivers, PMs shine. Hand out the praise like they do candy at Halloween in Atherton.
Throw blame What you may think: I have a great product strategy and write perfectly clear requirements. But building great software is hard and unpredictable (no matter what dev methodology we are using). And everyone knows that sometimes things go wrong, regardless of my Herculean efforts. We are even encouraged to fail fast. Just to be safe though, it is always good to publicly highlight what could go wrong with a release. The good news is that when things do go wrong it is typically the software and we all know who creates the software — engineers. With this in mind, it is good to plant the seeds of uncertainty early and make sure potential problems are identified as engineering-centric. I just try to be transparent about the risks.
Reality: You must seek out uncertainty and problems and absorb them. Remember that you love the spotlight of being a product manager so you need to own issues across the product, including with the core software product itself. Understand the nuances of a given problem and learn to articulate any impact and remediation clearly. Explain the different potential solutions and the tradeoffs of each and truly lead. Great PMs deflect praise while in the glorious sunlight and absorb problems in the shadows.
Do you do any of the above? We all do.
Just remember that great product managers operate from a position of knowledge and confidence but are dependent on engineers for product, business, and career success. Your job is to humbly lead with conviction, focus on the “why” and “what” and put your product team and engineering in a position to shine.
