5 Reasons Why You Have No Credibility with Engineering

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.

21 thoughts on “5 Reasons Why You Have No Credibility with Engineering

  1. spot on Cindy. I enjoy reading your posts every week but this one resonates well. If you don’t mind, can I share this on a few PM linkedin groups? will be very valuable for PMs who might not be following your blog regularly

  2. Where I have been effective and where I have seen really effective Product Managers is when the PM takes two different roles – The voice of the customer/market to Engineering/team and the voice of the Engineers/team to the rest of the company (especially MarCom and Sales). This role provides what each part of the company needs from the PM and leads to respect and great cooperation.

    The other trait that has been very effective is when PMs take the responsibility to look ahead in the road for potholes and try to fill them BEFORE the team gets there. When a project gets done and it just fills too smooth, that often has to do with a PM that anticipated and took care of issues before they became issues.
    One problem with this is that great PMs can lack receiving recognition becuase everything just seemed to go so smoothly. If PMs feel that way, I have seem them shift from fixing the potholes before the team gets there to rescuing the team after they have fallen in – lots more recognition but far less success for the product and company.

  3. I have fallen for the over-specify the solution many-many times. But I usually change my conversation depending upon the engineers response – some like the scope of the solution baby feed to them and delay the problem if research or cross-communication is involved. Where as others, just love do due diligence for each task.

    Very good write. I would love to see another write up on role of VPs cramming feature sets and pushing it down to engineering throats and having PM do the damage control.

  4. Great list, Cindy. I’ve fallen to #1 far too many times. Often times you feel like you’re helping the team but in reality you’re making naive assumptions and ultimately making your engineering team’s job a lot less interesting.

  5. And if you’re working with more junior engineers, they may believe that “well, if this is what she’s asking for, she probably has a good reason, I’ll just shut up and implement it” —

    and then they fail to bring up very *good* pushback like “it’s possible but it would take half the time if I used this technology” or “this will work fine as long as we never plan on exceeding X users…”

  6. Exactly! I always encourage engineering to be blunt and honest during sprint planning and retrospective meetings. The harsher the feedback, the better. :)

  7. Great post.
    I am constantly monitoring my behaviors to keep these at bay.

    One thing that irks me is that I have in my DNA your #1. I early on learned to not over specify or try to solve the problem for engineering. However, I have found that sometimes engineering wants to be told exactly how to solve a problem. I usually turn it around, and question their motives. It often comes back to a case in the past where a prior PM used #3 as a tactic to avoid being tarred and feathered.

    I have been burned by #4 too often. I am losing faith in our QA team, because every question is answered by “6 weeks” for the amount of time. It is so reflexive, and also so wrong, that it has almost become a running joke.

  8. I think I enjoyed the negotiation point the most, but since you need to both understand the technology and create a level of trust, they really tie together nicely. I wonder if others have examples of PMs who are more or less technical, and how this creates or solves tension with engineer? Are you seen as a marketing talking head, or an engineering has been that couldn’t cut it at coding? Ideally, it’s about tying business with technology.

  9. I would say that the #1 reason would be that the product manager and engineering team are not actually working together as closely as they could. When engineering team members are involved in the exploration of customers, when product managers are involved in the day-to-day of product engineering, a lot of these problems tend to take care of themselves

  10. I’ve worked with developers who want the solution down to the last detail (Reason #1). This tends to happen when 1) there is no one responsible for (or skilled at) UX, 2) there is no product architect or 3) you are working with offshore resources. Too often product managers are expected to fill the void.

  11. Cindy, I really enjoyed this post. Some great observations and advice.

    On #1 specifically, I too have struggled, as it appears many have, given the comments in this thread.

    Sometimes, for a variety of reasons, it’s helpful to delve into the “how” something might work. Strictly speaking that’s not the province of product management, as engineers love to remind us. And generally speaking, they are right.

    But sometimes the “how” matters. Maybe developers demand it as Sally Duda mentions (definitely seen that). Sometimes it’s a technology constraint that manifests itself as a business requirement, as you noted. Sometimes it shows the necessity of changing the technology status quo which development may need help evangelizing among their peers (I found that most recently as GM of a team at Myspace where doing UI rendering completely client-side via Javascript was verboten, even though it was two orders of magnitude faster and SEO wasn’t a concern).

    Either way, I’ve found that when there’s too much of a distinction between who’s responsible for “what” and the “how” it’s a symptom of what Jason Yip mentions below: the engineers and product managers aren’t communicating enough. The “what” and the “how” are like yin and yang: they may be distinct, but they cannot and should not be separated.

    One technique I’ve found to be very useful – and this technique belongs as a conversation, not in a written document – is to go into detail on the “how” as a product manager envisions it, but then be very clear that it’s a possible INSTANCE of a solution, not dictating THE solution. By doing it that way, engineers can “get inside your head” a little (and you theirs) to truly understand what it is you’re getting at. The difference between how the PM thinks it works and how it really does work may or may not be material, but at least this way you can have a conversation about it.

  12. Great writeup Cindy. The benefits of cross-functional team collaboration cannot be overestimated. When a team can work together to solve problems (instead of simply implementing solutions) the level of trust skyrockets. With increased trust comes greater investment in other disciplines and understanding of each other’s challenges which ultimately leads to higher quality products.



  13. This is fantastic.

    Regarding #4, I have one CTO I work with who always says, “Anything is POSSIBLE. Some things just take a really long time.” I love that attitude, because he will never come back and say, “We can’t do that.” He’ll just give me a reasonable estimate of how long he thinks things will take and which parts of the implementation are the hard bits. It’s then my job to work around the stuff that will take too long or decide the ROI is high enough to do it as designed.

    Getting engineers who will do that makes designing and product managing so much easier!

  14. Coming from an engineering background, I’d have to say the ones that have had the biggest impact in places I’ve worked have been #2 and #5.

    Having multiple top priorities is *terrible* for morale, and leads to a sense of firefighting and never being able to do well enough. Not negotiating to me is deeply interconnected with the problem of ballooning scope. As a project moves along, you always figure out more things you’d like to do with it, or even need to do with it to make it work. That is normal, it comes from thinking about the problem more and seeing intermediate stages. The problem is when all of those new things are expected to be added without any change in schedule or compromise on the initial set of features. Either delay the new things until the next release, extend the deadlines, or be willing to drop some of the initial feature requests!

  15. Nice summary. I even printed it out. However, in my experience “friends” build products, “enemies” write documents and watch out for the pitfalls you have in your list. Item #4 is especially depressing and is a clear indicator that all is not well with the team.

  16. I am a product engineer.  I am just reading this for the first time.  Truly, it brought tears to my eyes.  Working with a bad product manager is hard.  I cannot forward this to him, because it might make matters worse.  The bad marketer’s mantra: “Engineers are an obstacle to selling more products for less.”

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>