Engineering Tip: How to Piss Off Product Management

The week before Thanksgiving, we discussed how product management can most efficiently piss off engineering, customers, and the sales force. Out of a sense of charitable fairness, this week we’re discussing how sales and engineering can return the favor. Today we look at how engineering can most expeditiously make product management roll its eyes, grind its teeth at night, and reach for the blood pressure pills every morning.

• Build what you want to work on instead of what the product plan calls for. As an engineer, you have been inalienably endowed with a mystical, intuitive sense for building exactly what customers want. Input from customers, the sales force, or product management can only contaminate the purity and clarity of your vision, so ignore it. Even if that’s not true, you know for darn sure what you’d like to build, and that should come first regardless. If customers or product management have other ideas, they can start learning how to code!
• Add features to the product that were never discussed or agreed to. There’s nothing product management likes better than discovering the company has to manage, document, QA, and support new product features that engineering added to the product without any prior discussion or agreement. It’s true that unapproved product features have to be managed, documented, tested, and supported, but that’s the problem of product management, documentation, QA, and support, not engineering!
• Frequently allude to your greater level of technical knowledge. Product managers may have talked to customers and prospects, gathered their requirements, cross-checked them against the competition, and developed a prioritized product road map. They may even have a C.S. degree and be former developers themselves. So what? If they aren’t coding today, what could they possibly know? Remind them at every opportunity.
• Try to win arguments by citing “technical issues.” When you don’t have a leg to stand on, just pull rank by saying you’re right due to unspecified “technical issues.” When the product manager asks what the “technical issues” are, say they would never understand because they’re not technical enough. When the product manager says “try me,” start getting angry and signal with your body language that you’re about to blow up. When all else fails, condescension and intimidation may get product management off your back!
• Say you’re speaking for the customer when you’ve never even seen one. The fact that you may never have talked to a customer about an issue doesn’t mean you don’t know what they think about it. Remember, unlike the product manager, you have psychic powers of insight into what customers think, want, and need. So never hesitate to state that you’re speaking for the customer. Even if you aren’t, you are!
• Demand extraordinary justification for every feature request. Demand to know precisely which customer or prospect asked for each feature request. Each time you discover a feature request that lacks a specific documented customer or prospect asking for it, comment knowingly with raised eyebrows about the tendency of product managers to pile on work there’s no justification for. Oppose every feature request that lacks a documented customer requesting it even if it fits together with other features in satisfying an identified need. If the product manager does manage to document a customer who’s requesting the feature, say it’s an isolated case and demand more proof. Repeat as necessary. Be disciplined about this. If a product manager asserts that a scuba suit will need an oxygen tank, demand proof, ask which customer requested it, and point out that many divers are good at holding their breath and may not need it after all.
• Overestimate the level of effort for features you don’t want to work on. Customers, prospects, and product managers tend to have their own ideas about what new features they might want in the product. This can get in the way of working on what you really want to work on. So when they request a feature you don’t want to build, discourage them by overestimating the amount of time and effort that feature will take. You may get them to abandon the request. Even if you don’t, it will create extra room in the schedule that will discourage them from making other requests and provide more time to build new features in secret.
• Refuse to attend meetings. Only people who are working less hard on less important things than you have the time to attend meetings. Refuse to attend meetings by citing unspecified “important work” you’re busy with. If you make the mistake of breaking down and agreeing to attend a meeting, decide to work from home that day and “forget” to show up. This will work for a while until they escalate to your manager.
• Refuse to review or provide feedback on user stories, product plans, or product road maps. Product managers often claim to want engineering’s feedback on proposed user stories, features, product requirements documents, release schedules, or road maps. When they say this, they’re lying, so don’t fall for it. Ignore their requests for input. Responding might jeopardize your ability to say “I wasn’t in the loop on that!” later on.
• Always work from home, even if you live only a mile from the office. Talk about how much more productive you are when other people aren’t interrupting you. Remind everyone what long hours you’ve been putting in and how much pressure you’re under.
• Insist on working only the hours of the day that everyone else is home fast asleep. If you show up in the office during the hours of the day that other people are there, you might have to talk to them. Worse still, you might have to listen to them. Worst of all, they might actually expect you to attend a meeting every once in a while or provide feedback on something. The best way to avoid these problems is to insist on working only between 8 p.m. and 4 a.m. That way, those meddling product managers won’t be able to intrude on the perfection of your isolation.
• Discourage communication. When a product manager comes by to get your input, inform them in an irritated tone of voice that you’re busy working on something important and have no time to talk to them and would prefer that they send you an email. Repeat this each time they show up. Typing an email takes more time than asking a question directly, so by requiring them to communicate by email, you’ll be making progress on your overall strategic goal of slowing them down as much as possible. Then, once you’ve convinced them to write you an email, ignore it. When they drop by later to ask if you’ve seen it, say you haven’t and ask them to send it again.
• Be emotionally unstable and prone to blow up. The best way to get product managers to leave you alone (at least the timid ones) is to cultivate a reputation for being difficult, demanding, brusque, and prone to angry outbursts. Keep blowing up at product managers until they decide to communicate by email alone. Then, ignore their email messages. Mission accomplished!
• Silently insert potentially damaging text in the product. For example, put your demonstration partner files in a directory with an unkind name. You never know when you might have to unexpectedly ship the product on short notice and create an opportunity for this text to see the light of day and embarrass the company!
• Build undisclosed Easter eggs. This way, you’ll spend less time doing committed work and more time doing unapproved and unnecessary work that could also cause the product to fail a security review, which in turn could finally get back at those pesky people in sales and product management in a single stroke!

This is only a partial list of the ways that engineers can piss off product management. If you’re a newbie, it will point you in the right direction. If you’re a veteran, it will serve as a refresher course. Fortunately, engineers are renowned for their creativity in all things and above all in their inventiveness when it comes to aggravating product management, so the rest, as the textbooks say, is left as an exercise to the reader!