Being in the product management / product marketing game a long time, the Dude has some truths that have been constants across his various career stops. Time and time again, there are the same challenges that he’s experienced. He suspects that many of you have similar or related tales. This is by far not a complete list, but it is a start.
Here goes:
Every (tech) hardware project is a software project – Having lived most of my career in scientific instrumentation and semiconductor capital equipment, it is common for executive leadership to completely misunderstand the software contribution to a whole product. Consequently, the software team is usually 1/3 the size it needs to be, and that the formal definition of requirements is usually thin, and generated by the hardware team. This leads to great disappointment in delays and schedule ships that infuriate management, and frustrate the team. Even if you should plan for the appropriate amount of resources, and scope, in instrumentation, it is always the case that the software team is limited in what they can do before they are delivered working hardware. Every time you have to re-spin a board, or change a DSP chip, software can’t start on the development and testing until they get it in their hot little hands. Sure, they often start early, build a simulator, and assume that they are on the right path. But, while that provides some early learning, until you start working with real hardware, you are flying blind.
Faster, Cheaper, Higher Quality – Pick two – an adage from the program management world, but totally relevant here. There are only two independent variables in a project, and three constraints. If you want it done quickly, with high quality, expect to spend a lot of money. More team members, better skilled team members, and often multiple development efforts to throw out bad paths quicker. But much more likely, you are sacrificing either quality, or time. Alas, executives often don’t want to be told that it is going to cost more, or it will take longer, and especially that it will have lower quality. As a product manager, you will not have the flexibility to select which is the dependent variable. It will be thrust upon you.
Launch dates will be dictated – Alas, while we think that we are the gate keeper of when it is ready to launch, that we have control to not launch before something is complete, the truth is that almost universally, someone above your pay grade gets to perturb the system. Perhaps they committed it to the senior executives. Or perhaps they have their bonus tied to launching a product by a certain date. Or one of a myriad other reasons, all too often a project gets to a point and then labor is induced to give birth, ready or not.
I wish I could say that as the product manager I had the authority (explicit or implicit) to stand against such orders, but I don’t, and I never have. Unless you have true P&L responsibility, you don’t get the final say. And I have never had P&L responsibility, even though I have taken product management jobs that advertised that. Of course the general manager, or the group VP can override your decisions. This leads to a mad scramble to salvage as much of the project as possible. But what you launch often fails to delight first the sales team, and finally the customers.
Thus you get into a deep continuous improvement project immediately to address the sacrificed capability. I have a term for this, and it isn’t a pretty phrase: “Banana Product Development”. You launch it to the field, and then you incrementally let it “ripen” by fixing the loudest complaints. Bad idea, but alas, all too often you have no choice.
Engineering will over commit early – time and time again, when doing the up front planning and specification targeting, engineering will bite off more than they can chew. Be it performance specs (speeds and feeds), or software scalability, you can rest assured that their original expectations will not be met.
Yes, I know, they did a proof of concept, extrapolated those results, and felt that they were giving you a fair and reasonable specs to write into the requirements. But, about 2/3rds the way through the program, they will begin to miss performance targets. Perhaps they don’t get the bandwidth of a DSP they designed in, or the ADC’s are slower than their specsheet claims. Or, their simple software simulation doesn’t scale linearly when you add memory and processor cores.
Regardless, you will get into a round-and-round game of pass the blame. By this time you have begun talking to the field, and under NDA with some of your key accounts, so expectations have been set. A wise product manager plans for this up front. You play hardball with engineering, pushing them to the limit, but you soften the commitments outside the group. You also have to manage expectations upwards to the senior management team, as they usually will key on to a specific number they heard, and will repeatedly ask about it. Trust me, those conversations are the worst to unwind late in a program.
Executives will interfere – regardless of the up front market validation, the customer visits, the market analysis that you do in writing the business case and requirements, there will be a senior executive who “has some experience in XYZ industry”, and will tell you that “he knows there is a huge un-tapped market if you just do K,L, and M”.
Invariably, there will be dozens of arguments to make against this refocusing. You are targeting too small of a market. That industry is well served by existing products, and isn’t really ripe for disruption. There is significant IP required to excel there and we don’t have it today, we will have to create it from scratch (or, buy it).
But none of that will matter. You will adjust the requirements, and the scope of the project. You will be forced to sacrifice some key features that were part of your original go to market plan. This is a tough place to be. Product managers like to believe that they are the final arbiter, but the truth is, there are people higher on the pay grade ladder who will get their way. No amount of rationalization, justification, or outright civil argument will dissuade them.
And because they are the ones with the P&L responsibility, you have to do what they want, or they will just replace you with a compliant lackey. Been there, done that, got the T-shirt (and the heart stent). Best bet: Polish your resume and begin the search.
Alas, I could go on for hours, but I have to get back to my plan to force launch a product that is only 75% done, and not meeting the #1 key specification requirement.
