Better Product Managers, and Product Management

While at PCamp Silicon Valley last weekend, I overheard a number of conversations bemoaning “the difficulty of getting our engineers to do [what we ask]“.

Some of these product managers may have been legitimately frustrated with problems caused above their pay grade (such as VPs who overschedule engineering and make threats if deadlines aren’t met; this leads to bugs, incidentals, and new priorities being ignored and it destroys morale).  But product managers, at least some of you are the problem.

1) You over-specify the solution.

Are you telling engineers how to do their jobs?  It’s easy, in the interest of being thorough, to try and leap ahead and specify a solution.  But that often comes at the expense of under-specifying the problem that needs to be solved.  Engineers are problem solvers; figuring out the tools and implementation is what they do — much, much better than you.

Yes, you should list constraints (“40% of our traffic is viewing our site on iPads so we can’t use Flash” or “Our top 3 customers require that we use X technology because they’re already integrated with it”), but be clear when they are business requirements.

And yes, it can be helpful to say “in the past, we solved a similar requirement in this way” – but that’s a suggestion, not a requirement. (There might easily be a reason why this case is not as analogous as you think.)

2) You are wishy-washy.

You have two potential opportunities, so instead of picking one, you ask for extra flexibility “so it’ll work for both”.  This is harder to build, harder to QA, and frankly, is probably going to result in a worse user experience for your customers.

Be specific.  You can’t have two #1 priorities (well, actually, your boss may be telling you that you do, and if so, that speaks volumes about your company and your boss.  Get out as soon as you can.)

3) The last product manager blamed everything on engineering.

This one is (sadly) incredibly common.  Most engineers I’ve worked with have been burned by a bad PM in the past.  And it’s not always someone who deliberately badmouthed engineering.  It’s often that the product manager was complicit in allowing higher management to put the blame on engineering.

A deadline was missed, or the software quality was poor, and the VP of Products says “well, my team did their job” — and the product managers breathe a sigh of relief instead of coming forward and saying, “Actually, we kept increasing scope / should have done more customer research / changed priorities midway…”

This one isn’t your fault, but it is your responsibility to win back trust.  You’ll need to go out of your way to give credit to engineering for ‘wins’ and to shoulder the blame for ‘misses’ to make it clear that you are working together instead of competing against each other.

4) You don’t know when they’re making excuses.

You ask for something.  Your engineering coworkers give you an excuse why they can’t do it (maybe out of malice, but probably just because right now they’re really busy or tired) — and you fall for it hook, line, and sinker.

Their first response is going to be “Whew, I got away with it!”  Their next thought is going to be, “I can’t believe he actually fell for that.”

If you haven’t learning enough of the basics of how your programming language works / how your database works / what things are easy to change vs. hard to change to know when engineers are bluffing, they will have no respect for you.   Start asking: why is that hard?  Is this impossible or just really tedious/time-consuming/hard to test?  If I wanted to solve X, how else could we go about it?

5) You don’t negotiate.

Something unexpected will come up.  It always does.  But you hold fast to your list of requirements: 100% of this has to be done by this deadline, no exceptions.  Maybe you even say, “you’ll just have to work harder to get it all in.”  (My god, I hope you don’t say that; if you do, you deserve everything you get.)

You have to be willing to give some things up or accept alternatives.  As in #2 above, not everything is your number-one priority.  It doesn’t make you wishy-washy to cut some of your previous requirements, it makes you pragmatic.  “OK, we absolutely have to have X, Y, and Z.  How can we rework the rest of these requirements to absolutely get those things, and try to get as much as possible of the others?”

You may have read this far and be patting yourself on the back because none of these apply to you.

Don’t be so sure.  It’s awfully easy to fall into bad habits – the engineers I work with will happily point out that, despite my best intentions, I sometimes do one of these.  Be aware, and everyone will be much happier for it.

Popularity: 16% [?]

Popularity: 16% [?] blog comments powered by Disqus