A Product Manager’s Guide to Developer Diplomacy

Greetings! Shannon the Name.com Product Manager here, talking to you today about the mystical and fascinating creature that is the Web Developer. It’s no secret; I spend a lot of my time in the developers’ den trying to comfort and sway developers into action without stepping on too many toes. It’s a delicate line, and I walk it quite well.

Where other Marketing Agents have fought valiantly and failed, I have succeeded. How? I’ll tell you right now. I have 10 fundamental rules that, as a whole, comprise the “Shannon Brown Theorem of Developer Diplomacy”

1) Write a detailed spec for the project that they’re working on. Make sure you know every nook and cranny of the document and be ready and willing to tackle any issue that pops up. Don’t leave them hanging.

2) Listen to them when they tell you why something cannot or should not be done. This way, when you continue to bring impossible ideas up, and they simply say, “That doesn’t live in the CMS,” you know what they mean. They hate repeating themselves, and they hate the feeling that you’re not paying attention to them.

3) Every so often, visit imgur.com and familiarize yourself with the content. If you see something really good, forward it along. For instance, this is Owen’s favorite GIF. Just thinking about it brings a sparkle to his eye. Yes, they will ask you why you don’t visit Reddit. Just say, “the UI is awful!” and roll your eyes. This works every time.

4) When interacting with 3^rd party vendors, ask them specific questions about the issues they’re running into and then take care of the communication for them. They are here to write righteous code, not tedious emails.

5) Give them beer. Delicious, frothy, amazing beer. From a kegerator. In the developers’ den. Be sure to reference this beer any time that you can get away with it in every day conversation. It also helps to randomly have strong opinions about types of beer, for instance, “this stout is good, but it’s sooo dark. I prefer IPAs”

6) Ask questions like “which is easier to code?” and “how will that interact with the rest of the system?” when they present you with a problem and several proposed solutions to the problem.

7) Ask their opinion about features and functionality before it lands in a finalized spec. This is much easier to say than it is to do.

8 ) Every so often give them a week where they don’t have to adhere to the sprint, and they can work on whatever they want, one developer at a time. You might be surprised at what you get.

9) Test their work thoroughly and provide detailed feedback in a reasonable time frame. Make sure your expectations for remediation are realistic. Don’t push a list of bugs at them and insist that they are resolved in the next 18 seconds. That’s silly, and they’re not going to like it. They’re bummed enough as it is about the bugs.

10) Laugh at their jokes, even if they’re geeky. Don’t kid yourself, they’re funnier than you are.