Concept Marketing Group Inc.

Close This Window

---

Free Do-It-Yourself Press Release Kit

---

Fill out the information below to receive our free e-book. We'll automatically redirect you to the download area.

First Name: * Last Name: * Company: Email: * Phone #: Are you interested in any of the following? Press Release Writing Services Press Release Distribution Services Notify me of special offers and promotions Subscribe me to the Getting Results newsletter

---

Close This Window

Working with Difficult Engineering Teams Part 3

by: jillian@280group.com on Date: Thu, 8 Jul 2010 Time: 5:17 PM

Ironically as I am writing this article about working with difficult teams I'm working with two excellent engineering teams. This is when Product Management is the best job in the world. As a Product Management professional you'll occasionally end up working with teams like this who are great to work with - they understand the value that you add, are incredibly talented and want to build great products that change the industry. In a future article I'll be writing about what to do to help build winning team situation like this, but for now I'll wrap up this series with a few more of what I call "Games Engineers Play".
In case you missed the first 2 articles in this series, here are the first five games that we covered:
Game # 1: Redefining Alpha or Beta criteria at the last minute
Game # 2: You get your choice
Game #3 Changing Feature Definitions
Game #4 Features, Schedule, Performance: Pick Two
Game #5 Using The MRD Process To Stall For Time
So on to the final two games (and these two I sincerely hope you never have to play)…
Game #6: Sorry, but we have the final word
One engineering VP that I used to work with brought me into his office at one point about halfway through a major project. As with any software development effort, there were several points of contention between Product Management and Engineering. We had been through one of the issues half a dozen times and I had voiced my opinion that the release would fail without a specific critical feature that Engineering had originally agreed on including but now did not want to deliver. The reality was that it was a very hard coding challenge, and would have put their schedule commitments at risk. Nonetheless, it was key for our customers, so I was insisting on it.
After politely explaining his position, the engineering VP informed me that he was "Sorry, but we have the final word on this. You will have to live with not getting what you want". I had suggested several reasonable alternatives - scaled down versions of the feature, pushing the schedule out if necessary and even funding a contractor to work on the feature. But he had made up his mind.
Defeated, I played the only card that I could. I cut the revenue forecast by 80% and let management know to lower their expectations. After all, this was a critical feature to drive upgrades, and without it there was little reason that customers would actually pay for a new version. Luckily I had a signed off MRD and spec as a backup that included the feature, but nonetheless I had been put in a difficult position.
In the end I lost on this one. The product shipped without the feature, and I was still held accountable for the original revenue forecast.
Sometimes there are just some things that are out of your control.

By the way, this is one reason why Product Management should NEVER report into Engineering.
Game # 7: We Don't Talk To Marketing
Long ago when I was first starting my career in Product Management I actually had an engineering team that refused to talk to anyone in Marketing or Product Management. The previous Product Manager had been somewhat of a tyrant, making ridiculous demands, oftentimes having completely disregard for working as a team. As a result the engineers would hold secret meetings to discuss the feature set and ship dates. They would not answer the phone or reply to emails. They would keep documents hidden so that no one outside of the core engineering team could comment or even know what was in the release they were working on.
I have to admit, this was one of the most extreme cases of dysfunction I have had to deal with in my career. Nonetheless, I had to find a way to make it work. Luckily I had a very seasoned manager who supported me (and I also happened to be working on several other products concurrently.)
To solve the problem I pulled the engineering manager aside and informed him that my priorities had been changed to focus on the other products I was managing. As a result, even though I thought what they were working on had potential, I didn't think there was any way that the company would ship it since there wouldn't be any Product Management or customer input during development. I also added that even if it did ship the company wasn't likely to highlight it or market it, so few customers would end up using it in the end.
The product did end up shipping. It sucked. Customers were unhappy.
In the Product Management game you win some and you lose some.

About the Author

Brian Lawley is the CEO and founder of the 280 Group (www.280group.com), and has shipped more than fifty successful products. He is the former President of the Silicon Valley Product Management Association, won the 2008 AIPMM award for Excellence in Thought Leadership for Product Management and is the author of the best-selling books, Expert Product Management and The Phenomenal Product Manager.

Comments

Add Comment