How to Get the Respect of Development

When starting at a new company, even the best product manager finds herself in an awkward position -- the position where most of the developers don't listen to her and disrespect her. While this is a temporary condition for the successful product managers, some are never able to dig out from this living grave. 

So, let the Cranky Product Manager help.  Gather 'round and sit at the feet of the CPM whilst she bestows her big-league wisdom upon your sweet little ears. Wait with baited breath as she whispers in your ear the Secret of Gaining the Respect of Development.

Step 1: Stop being an Asshole. 

For some of you, this might require a personality transplant. The CPM recommends you request a personality that is neither overly extroverted nor excessively introverted, easy to get along with yet somewhat stubborn, detail-oriented yet able to see the big picture, market-minded yet technical, diplomatic yet daring, a risk-taker but ultimately sensible, a visionary yet pragmatic. 

In other words, get yerself a personality that excels in its middle-of-the-road-ness.  A  personality that has reached the pinnacle of mediocrity in all respects and revels in it.  A personality that, lacking any strong characteristics, resembles tepid water in its complete nondescript-ishness and ability to go with any meal.

Don't feel bad if you need a personality transplant. It won't shock you to learn that the Cranky Product Manager needs one too. In her cranky old age she's become too likely to say exactly what she thinks, much to her development team's (and her boss's) chagrin.

Step 2: Become an expert in the current customer base.

First, before the Pragmatic Marketing folks jump down the Cranky Product Manager's throat and start screaming "be a MARKET EXPERT not a CUSTOMER EXPERT, you effing IDIOT," let the CPM explain: You gotta walk before you run. 

Before the Code Boyz  (and Grrlz) will accept the Neophyte PM's market expertise as gospel, they first need to believe that the NPM actually knows the names of some customers.  Because, for some reason, the Code Boyz/Grrlz assume that Product Managers have no clue about customers. This is because the average developer or development manager thinks it's OBVIOUS what the customers want. After all, they actually MET two or three customers once, and maybe they even fixed a few bugs at a customer's request.  And if you, the Neophyte Product Manager, disagree with the "obvious" course of action... well, then, it must be that you don't know anything and are pulling requirements out of yer ass.

This is called "projection" in psychiatric circles.  The Code Boy/Grrl who pulls requirements out of his/her posterior quarters or "gut" or whatever accuses the Neophyte Product Manager of doing the same.

The way out of this quagmire?

Learn WAY more about the current customers than the development team.  Then, prove it to those hateahs beyond a shadow of a doubt.  Club them over the head with your wellspring of customer knowledge.  Until no one can deny you know yer shite.

Fortunately, becoming a customer expert does not take that long if you really concentrate on it. But the CPM is tired. Worn out from dealing with a screaming infant all day. And she's not talking about her beloved spawn. Nay, she's referring to her (usually) favorite sales engineer who has a major case of whiney-itis.  (a story for another day)

So, tune in next time for the CPM's "100-day plan for Becoming a Customer Expert and Proving it Again and Again and Again to Development". Coming out sometime in the next 6 weeks. Promise.

Happy Halloween and Peace out.

Comments

[Ron Kaplan]

CPM,

Once again, you make terrific points. Something to consider: too often the PM is rendered irrelevant. Among other reasons, this happens, because he/she is not in alignment with management - yes there are many other reasons, but let's stay on target with management. Often, the PM is not driving the business. So, without this strategic support, even customer-driven requirements will go no where. Developers will see this in the form of constantly changing direction and requirements.

So, my advice is to focus on the value prop. Really work hard to put a Dollar-value on your requirements. If you add this element to the product plan, developers will be less distracted by short-term fixes and feel empowered to leap forward (instead of walking). They will become partners with the PM and not antagonists.

Thank you.

[Steve Johnson]

"Jump down your throat" you say? Never! What have I ever done to make you think such a thing!?!?

Indeed, you make a stellar point: get to know customers. It's an easy way to begin and builds instant credibility. And customers typically love to see you. We at Pragmatic Marketing do indeed advocate spending time with customers--they are the source of recurring revenue and we love 'em.

But don't be content with customer visits. Customers will give you clever improvements but they rarely give break-through ideas; they suggest evolution, not revolution.

For truly innovative ideas, learn how non-customers are living without your product.

Remember, your opinion, while interesting, is not relevant. Use customer and non-customer market facts to drive product decisions.

Cheers,
Steve

[NPPM]

The non-profit - too optimistic for most peoples liking - product manager thinks the CPM is right about knowing the customers. But has always found tricky the situation where developer x has developed a friendship like customer support email / phone thing with one or a few loyal customers and constantly uses their quirky needs to deflect, complicate changes. Have you dealt with this situation cranky!?

[Saeed Khan]

Great post. I totally agree with #2. #1 should be a given! :-)

But to speak from the developer's perspective, what you wrote is not always the case.

i.e. This is because the average developer or development manager thinks it's OBVIOUS what the customers want. After all, they actually MET two or three customers once, and maybe they even fixed a few bugs at a customer's request.

I've met my share of Dev Managers who fit this category, but I've also met my share of PMs who don't have a clue about customers, talk in generalities, write requirements in very abstract and general terms and expect the Dev team to fill in the gaps.

If I were a Dev manager and had to work with a PM like that, I'd seriously wonder why he/she is on the payroll as they are really not adding any value at all.

Dev managers want us to do our job, just as we want them to to theirs. Seems like a reasonable set of expectations on both sides.

Saeed