Product Management Tip: How to Piss Off Engineering

Are you a newbie product manager who isn’t sure how to piss off engineering as fast as possible? Follow these simple steps and you can earn the lifetime enmity and scorn of every engineer you work with!

Don’t listen. As a product manager, you know it all already. Therefore, asking questions or listening to information that others volunteer is a waste of your time.

When you don’t know, just make stuff up. It’s critical that the product manager know everything about everything at all times. Otherwise, how would they have any credibility? So if an engineer asks you a question like “What’s the problem we’re really trying to solve for the customer?” and you don’t know the answer, just make one up and then dogmatically stick to your answer regardless of what the data may show.

Never let the facts get in the way of your opinions. As a product manager, you are gifted with unique personal insight into the needs of the customer and the market. Your “gut feeling” is the single best way to make decisions. So don’t waste time investigating customer needs or market requirements. Just go with your gut.

Make bad decisions now, not better decisions later. You’re busy and don’t have the time to do the research necessary to make an informed decision. So make an uninformed decision now. You can always reverse it later.

Have 100% confidence in the correctness of every assessment you make. How could you be less than 100% certain? You know all the right answers for sure! So when engineering asks you how sure you are of your answer, your response should be the same every time: “I’m sure.”

Say that everything is a priority. All customer needs are important. Therefore they are all a high priority. Therefore prioritization is a waste of time. We have to do it all. Now.

Make sure your pet features get on the schedule. Is there some feature that you’ve just been itching to add to the product? Go right ahead! The customers are guaranteed to love it, and it’s sure to be a major revenue producer.

Impose vague requirements. Make engineering guess so you can blame them for guessing wrong.

Impose conflicting requirements. For example, demand a revolutionary new approach and insist that there be no learning curve or need for change in user behavior.

If you’re not sure it’s necessary, add it in. Determining minimal acceptable solutions for your customers is hard work. So don’t bother. Just cover your backside by making sure you’ve included a feature for every possible need and use case in the requirements. That way, no matter what features are actually necessary, they’ll be in the product. Someday.

Deny all engineering requests for time to develop unit tests. Unit tests are such a waste of time. When was the last time a customer paid us for a unit test? So when engineering asks for time to invest in improving unit test coverage, say no. That way, you can have them build even more features instead!

Deny all engineering requests for time to refactor the codebase. Sorry, we’ve got features to deliver in time for the next marketing checklist. You’ll just have to make do on the existing codebase. Forever. Deal with it.

Don’t document your assumptions. Someone might challenge them or think that the plan is fundamentally flawed. The best place to keep your assumptions is hidden safely between your ears.

Impose release dates based on customer and sales requests and ignore engineering’s input on how long the release will take to build. The only thing that matters is satisfying the customer. Or sales. Or delivering a new feature at the same time marketing thinks a competitor will. Or having something cool to demo at the next trade show. So just impose product delivery dates that were determined by “business and market needs.” It’s engineering’s job to figure out how to put a man on the moon and safely return him to Earth in 18 months. That’s what they’re paid to do!

If you ask engineering for a schedule estimate, cut it. Engineers will take as much time to build a feature or release as you give them. So if you want the work done sooner, just give them less time! They’ll figure out a way to make do.

If engineering puts buffer in their schedule, slash it. Engineers are such wusses. They always want a nice big blank buffer at the end of the schedule. A buffer is wasted space! We could be using that space to start work on new features for the NEXT release. So cut it!

Mis-set customer expectations. This technique is especially clever. It ensures that even if engineering busts its ass and delivers exactly what was asked, customers will still be upset. By mis-setting customer expectations, you’ll keep the customers happy for now. When the next release fails to cure cancer and end hunger, you can apologize, blame others, say there was a miscommunication, and start talking about the NEXT release that will end poverty too!

Underfund everything … except sales. Necessity is the mother of invention. So give engineering one Sherpa, one tent, and one bottle of oxygen and have sales sell 100 tickets to go to the top of Everest. There’s nothing more entertaining than creating demand you lack the resources to fulfill. Engineering loves a challenge!

Commit to a lot of work for the next release at first, then slash the feature list halfway through development. Estimating how long it might take to deliver functionality is hard work and takes time, so don’t bother. Just cram the road map full of a ton of new features and publicly commit to a fixed release date. If your schedule starts to slip halfway through the development cycle, you can always cut features from the release at that point. Engineering can take any half-finished code for the features you just cut and efficiently reuse it as-is when you stick that feature on the NEXT release.

When the schedule slips, blame engineering. It’s not your fault for committing too many features, eliminating the schedule buffer, and slashing the schedule estimates. It’s engineering’s fault for failing to work within the constraints they were given!

Don’t learn the technology. As a product manager, you’re responsible for big-picture high-level strategic thinking. You can’t be bothered with the mundane details of the implementation. That’s engineering’s job.

Don’t learn your own product. Product managers are busy important people. You’re not responsible for knowing the detailed features of the product or what they’re for. Engineering can explain that to you when necessary.

Make best-case assumptions. As long as the plan COULD work, it’s good enough. If it fails, you can blame engineering or sales.

Manage by reacting to crises. Don’t invest in improving the product or preventing problems. Wait for problems to occur and then show yourself a hero by pointing them out and resolving them when they happen.

Live in denial. If people confront you with contradictions or unpleasant realities in the plan, deny them. They don’t get it. You know better.

Tell people what they want to hear. Especially, “yes, we’ll do that in the next release.” It will make them go away happy. Never mind if you can deliver the goods later. That’s a problem for later!

Never evaluate your own performance. Never look back. Only look forward. Have supreme confidence in your predictive powers, regardless of what history may show.

Never apologize. For anything. Ever. An apology would be an indication that you are less than perfect and omniscient. Cultivate a lofty imperturbable self confidence.

Engineers generally dislike BAD product managers, not ALL product managers. By following the above guidelines, you can quickly ascend to the “worst of the worst” category. That will ensure you’ll be retained indefinitely at any large, dysfunctional company!