logologo

Find out more about our new Agile Product Management Product Owner certfication -- Click here for more details!


Product Management Library of Knowledge

subscribe:   

« Budgeting to Improve Web Conversions | Main | Working With Difficult Engineering Teams Part 2 »

Working With Difficult Engineering Teams

Working With Difficult Engineering Teams
By Brian Lawley, President, 280 Group LLC

I've had the pleasure of working with some truly world-class engineering teams over the course of my career. Many of them created breakthrough new products and were dedicated to building what customers really wanted. And many of them have been very rewarding to work with as a team - they understood the value of Product Management and bringing the voice of the customer into the process, and they were committed to working together to bring products to market with the highest probability of success.

Of course, some of the engineers I've worked with haven't been of this same mindset and were quite difficult to work with. Oftentimes in the past they had bad experiences with Product Managers or Marketing people who weren't straightforward with them (or were simple incompetent and didn't know what they were doing), and as a result they either didn't see the value added or weren't willing to trust and take a team approach. (Ironically many of the best engineering teams with the most brilliant engineers often end up with this attitude, becoming "Primadonnas" as a result of management telling them that they are the most critical asset of the company).

Since we all as Product Management professionals may end up working with less-than optimal engineering teams at some time, I thought I would write an article that covers some of the "Games Engineers Play". (i.e. the popular book "Games People Play"). Following are a few of my favorites - things that have happened to me and how I might deal with them differently now.

Game # 1: Redefining Alpha or Beta criteria at the last minute

This is one of the oldest tricks in the book. The team is approaching a critical milestone date for having the beta release ready. Management is breathing down their neck to get the product out and not slip the schedule. The team isn't going to make it, so what do they do? When the date comes they go ahead and declare they have reached beta anyway. At this point you may hear things from them like "We only have 3 fatal crashing errors left that need to be fixed" (as if this is a good thing) or "The two remaining features that we left out are really easy to implement, so we decided not to hold up beta and to just slip them in before the Golden Master final release" (as if a Beta release can be ready without being feature-complete).

Probably the most effective technique for heading this off at the pass is to make sure that in your MRD (or PRD) and testing plans you have specific criteria defining what Alpha and Beta are. Put this in writing and get it signed, and make sure that you remind the team about it every few weeks as the project moves forward.

Some of the criteria might include the following language:

  • The following required features must be implemented and working (X, Y, Z)
  • All fatal bugs that crash the user's system must be fixed
  • Product Management, QA and Engineering must all agree that the software is ready for beta release and sign off on it
  • The product must have been tested on the following systems before beta can be declared (X, Y, Z)
  • N customers must have successfully run the software for N days at their sites and must agree that the software is ready to be declared beta
  • Performance must meet the following criteria for specified tasks (X, Y, Z)

The list could go on, but you get the idea. Note: the closer you get to deadline dates, the more difficult creating this list and getting agreement will be.

Game # 2: Product Management gets to choose

This is actually a common sales and negotiation tactic, but Engineers can be masters at it too. It goes something like this. You are approaching the Golden Master date and the team has a ton of work remaining in order to make the release happen on schedule. Around this time you get called in by the lead engineer, Director orVP of Engineering. They explain to you that the release will make the date, but that they would like you to decide which is more important, having X or Y. X or Y in this case could be performance, key features, compatibility, full QA and testing, or a variety of other things. But the point is that you as the Product Manager get to make the call (of course what they are really asking for is your blessing that not everything will be there but customers will still find it acceptable.)

This is a difficult situation, especially if you have a team that you really work with well. You may have to sacrifice some of the hard won respect and close relationships you've worked to form with the engineers. After all, you are being put in a situation where you have to point out that they are not making their commitments (and they may be excellent engineers that you respect and enjoy working with).

The best defense in this situation is to calmly state that the release does not meet the agreed upon goals and that rather than choosing between 2 alternatives that are not at all viable for the market you need to see a plan that gets the release back on track. This probably won't go over well with your team or upper management, but someone has to stand up and be the voice of the customer. Thus is the life of a Product Manager.

Another way to deal with this situation is to turn it back around. Tell both the engineers and the management team that from your point of view there are really three choices: 1.) release a product that doesn't meet market needs 2.) miss the schedule or 3.) ask the engineers to come up with an alternative plan to remedy the situation. I've been amazed by how resourceful my teams have become when uppper management has indicated that they have to come up with a "Plan B". Remember, Engineers are master problem solvers, and they may come up with a completely new way to get the product back on track if you use this approach.

These are just a few examples. In next month's issue we'll cover some other common "Games Engineers Play" and what you as a Product Management professional can do to work around them.


Brian Lawley runs the 280 Group, which provides hand-picked Marketing and Product Management consultants and contractors to help clients define, launch and market breakthrough products. Visit www.280group.com for more information or call 408-832-1119.

This web site, with all of its contents unless otherwise indicated,is Copyright © 1998 - 2016 by AIPMM. All rights reserved. | Privacy Policy | Terms Of Use