Product Management

Product Management Lesson from the Apollo Program

moon landingA picture a friend posted on Facebook got me thinking. I wanted a comment to be accurate, and since the Dude is getting old, his recall isn’t what it once was, so I looked up the Apollo missions on Wikipedia.

(BTW: I thought it was Apollo 11 that first landed on the moon, and I was right)

However, reading the details of the Apollo-Saturn missions was a mini case-study in product development, and in product management.

When asked about the space program, most people just remember the crappy, yet wonderful, black and white footage of Neil Armstrong walking on the moon. But prior to that event was a deep series of unmanned and manned missions to validate and test the various platforms, technologies, and aspects of the mission(s).

Reading about the progress, it tells a tale of:

Read More

Product Management

When the Wrong People Run Engineering

The Dude has been blessed with (mostly) competent engineering management throughout his career. For the most part, they have been technically competent, and reasonable at negotiating scope and schedule. When that happens, the Dude’s job is much easier, and the Dude is an ally in the battle to get resources.

But, this isn’t always the case. Sometimes a truly awful leader is running the engineering team. Nothing ever gets done, schedules are blown, and without some track record of delivering, it is impossible to wrangle more resources.

To be certain, the Dude will hold his nose and work with these engineering managers, but it is difficult.

Some symptoms of poor engineering leadership:

Read More

Product Management

Sales Discomfort – Product Mix Edition

courtesy of Siddharth Singh

In all the Dude’s years as a product manager with some {explicit|implicit} P&L responsibility for new products, there has been one fact that has really torqued him.

The sales team laments that they can’t meet quota because they don’t have new and exciting products. Yet when we deliver a new and exciting product, sales are glacially slow to start, and suddenly sales of the now legacy products jumps.

Not an isolated instance, but something that has repeated over and over in the past 15 years. This dichotomy has had the Dude massively depressed many many times.

However, today the Dude has a boss, the VP/GM, who has a marketing bent. And this VP/GM manages directly the WW Sales Director. So the VP/GM has put metrics on the sales director that is ensured to increase focus of the sales team on selling new products (or, in other words, a mix of products that is weighted to the new products).

Read More

Product Management

Why does scope creep? (ans: greatly delayed programs)

Why does scope creep? (ans: greatly delayed programs)

The Dude has worked at many companies, with many different engineering and development organizations. Regardless of how great the teams are/were, there are always slips in schedule.

The Dude is puzzled by this. Even when he has a great team, with hugely talented, and highly productive engineers, programs take longer than planned. Perhaps it is because most of his products are hardware and software, and both have different development cadences?

Nah, that isn’t it. Even with complete latitude, and no interference to planning, the programs are late. And not just measured in weeks, but usually quarters or worse.

This leads to the inevitable scope creep, the bane of all programs. The Dude tries to resist this, but alas, as time goes on, the market and the competition do not hold still. They are adding capabilities, features, and changing the game. So the requirements change. Somethings get deprioritized, some are added. All cause heartburn for the dev team.

The scenarios:

  • Your program is to replace a current product, and it is constantly being improved. Good practices are to continuously improve your product. Standing still is a sure way to be destroyed in the market. Your competitors aren’t obliging you by not changing their products, so neither can you. Of course, this create a “Moving Target” for development. The end goals are constantly being redrawn.
  • A new product, or new to you. If you are lucky, you may not have any competition, or you may be defining a market. Yet, a product definition, and a market entry plan always has some time sensitive nature to it. Hopefully, your marketing person (often the product manager) has factored the “time to market“, and the market window timing into the original plan. Miss that, and the game changes, as will the requirements.

Sidebar: In the case of a delay causing a missed market window, one of the responses should be to cancel the program. If you miss it, you may never gain the traction that you expected at the start of the program. Yet this has never happened. See my post on “sunk costs“.

Regardless of the cause of the delay, when schedules slip by “quarters“, it is nearly inevitable that the scope creeps. Product Management does fight this, knowing that feature is the death of programs. That said, the pressure exerted by management who has made commitments to his leadership, the urgent demands of sales who needs just one more feature added to the product, you know, since you are late, you have time to add their pet widget (multiply this by all regions and all sales people and bam, you are outta control).

My commitment to engineering

I don’t enjoy changing program parameters. I don’t do it willy-nilly, or on a whim.

Up front, my requirements will be clear. They will have enough detail to be actionable, yet not so much detail that it is too constraining. I will justify the market segments we are targeting. I will answer your questions about marketing (contrary to popular belief, I do want you to understand the why). I will define what is in, and almost as importantly, what is NOT in a product. I will negotiate with you in good faith. I will apply some Kentucky Windage to your estimates (to give you some wiggle room).

But if you blow the schedule by a lot, then the requirements will change. Deal with it, or get better at estimating, and meeting milestones.

Product Management

Don’t Even Go There – When Engineering thinks they are businessmen

Don’t you love it when in the middle of a meeting, with all the stakeholders, the engineering manager deigns to challenge you on the financials of the program?

Bitch, don’t go there. Sure, you have an MBA from one of the finest remote learning institutes (cough University of Phoenix cough), and you probably understand the equations that go into the NPV and IRR calculations (unlike many MBA’s from top tier B-schools), but that doesn’t mean you can challenge me on the details.

I will destroy you. Unlike you, who are just trying to lob gasoline on a small flame to ignite a conflagration, I DO know all the details and detailed minutia of the program I am working on.

Don’t you dare deflect the piss-poor track record of engineering in meeting committed milestones by pointing at the financial metrics. I am aware that delays increase the costs, lower the long term profitability, and how delays impact the IRR calculation.

Of course, these bomb tossing sessions seem to happen when engineering yet again is missing a milestone, a milestone that they set and committed to, and is looking to drag someone else into the blame game.

Just don’t pick Product Management for that. We know how to fight back.

My advice: Lick your wounds, go back to the woodshed, and refine/improve your estimation accuracy.

Management/ Product Management

Topping Out – Product Management Compensation

The Dude is sitting here, pondering life with a spiked cuppa jo’ this Sunday morning, wondering about compensation and product management.

As he sips again at the dark liquid of life, he recalls a conversation he had with a rising product manager a couple of years ago. This person contacted the Dude to inquire about a job change. They weren’t dissatisfied with their current gig, but they had an offer with a 12% pay raise, and wanted to know what they should do.

Hmmm, this got the Dude thinking on how long it had been since he changed jobs for more money, and that leads to the term “Topping Out”.

The Background

HR (Human Resources) departments at medium to large companies have worked to standardize categorization of roles and capabilities into a series of codes. The one that I am familiar with are the Radford codes. Radford specialized in technology workers, but I would bet my bottom dollar that there is a similar structure for other industries.

These codes are generated via a series of surveys of employers, and the results are distilled into a set of codes that relate to the job title, the skill level, and the pay range.

This is how when they move you from say Phoenix, a relatively low cost area to San Jose, a high cost area, they know that they should give you 17% more pay for that transition (which, I can assure you is not enough…)

More important is the level within the job code (sometimes is is like “Marketing Manager I, through Marketing Manager IV” or it is novice, intermediate, expert. That is often a specific HR departments contribution to the implementation, something to “make it theirs”.

Each one of these job code and job level will have a minimum, median, maximum pay scale. If you are below the median, adjusted for your locale, and your industry, you can expect regular pay raises.

However, once you hit one mil over that median, you are pretty much assured to not get annual pay raises. The median is the salary they will pay someone else to join to take your place when you quit. (I am sure hrnasty would argue this, but at the last three companies I was at, when I was managing employees, this was the explicit policy from HR to managers.)

Im many ways it is a good thing to have some normalcy in HR, and classifying your staff.

Where does this leave Product Management?

I am getting there. First, there isn’t really a “Product Management” role (nb: It has been a few years since I had access to a current Radford survey, I had a really cool HR person once), likely due to the nebulous definition of the role. So it gets grafted into something that sounds similar. The closest I saw was “Product Marketing”, but the description for that was much more of a marketing communication role.

Of course, for the absent minded HR person, it is all too easy to just call them “Project Manager” and be done with it. Groan. Unfortunately, while some of the “herding cats” part of product management sound like project management, it is a lot more than project management. And project management pay scales are way too low for a quality product manager.

If you are lucky you are likely a “Marketing Manager”, or something above “Product Marketing”, and you have pay scales that make sense.

Assuming you are mid career, you are probably at level 2 or 3, and you are getting consistent pay increases. You stop worrying about it. Until you get that promotion to level 4 (or whatever the top level is). Suddenly the pay increases slow, or even stop. And you wonder what the hell happened. You are still getting good reviews, and you know you are doing a great job. but you have hit a wall.

Escape From The Edge

I have been above the midpoint, in the highest code for product management since 2007 or so.

Yes, that means that (apart from this relocation), I have not had a pay or salary increase since 2007, even though I have changed jobs 3 times since then.

So when someone wanted to know whether they should take a new job because it was a 15% pay increase, I really had no good advice, having given up on ever expecting to see a pay increase.


The global financial crisis certainly had some bearing on this practice by companies, the fear of being unemployed would keep employees content to not have a pay increase. However, the codification, and formulaic approach to pay and HR practices have been underway since the 1990’s.

If you find yourself topped out, and if your manager is an ally (not always the case) you might find a path to a different code. Or thy might be willing to go up to bat to increase you beyond the midpoint, but regardless, you will eventually need to move to a different role.

This is when many good product managers make the jump to consultant.

I could probably go on for many thousands of words on how rigid HR policies damage the progress of a product manager’s career, how it measures the wrong things, and praises the (easier to measure) worthless attributes. Product management as a role is still a slippery entity to categorize rigidly. Different companies have different needs, and a great product manager is a master of adaptation, bringing success at all stages.

It is this uncertainty in definition and practice that leads to the ambiguity of the management of product management.

Product Management

Faith Based Product Development

Something I have experienced far too often is something I call faith based product development.

It is not religion, per se, but it has a lot of similarities. Mostly, it is a combination of unrealistic expectations from senior management (like: It will be done in July, and we will be shipping in volume by September) mismatched with the reality on the ground (hence: ohmyfuckinggod, we can’t solve this killerproblem, and unless we do, we won’t sell any of them). This impedance mismatch would be funny if it wasn’t so painful.

Read More

Product Management

Teaching Sales to Fish

get-off-my-lawnOne thing that has never ceased to amaze me is that no matter how much effort you put into making information available, sales will continue to ask you the same questions over and over (and over it seems).

We have data sheets, spec sheets, detailed product description text, and even “gasp” manuals that have things like weights, dimensions, and performance limits. Is it too much to expect them to go look it up?

Apparently it is. It seems that about half my inbound emails are questions that are answered with a quick referral to the documentation (that ALL sales gets during training, and have access to on the servers). As I pull my hair out, trying REALLY hard to not lash out, I try to think back to when I was a clueless noob. And you know what?  I never was. I knew where to look (even before Google existed), and I never asked petty questions to the people. It was always far better to learn to fish, than to have a fish handed to me.

But today? With enormous volumes of data at your fingertips, the new generation can’t be bothered to seek the knoweldge, but they expect someone to be on hand to dish it out (me that is).

GET OFF MY LAWN, dammit.

Marketing/ Product Management

Dammit Jim, I’m not a Surgeon, I’m a Product Manager

Being a product manager is not for the faint of heart. We never get credit when things go well, but we sure catch hell for every slight that goes on. Today is one such day.

A sales engineer (and I use the term “engineer” loosely) sends a message. We are competing for some government bid, and because we don’t have a specific specification listed on our printed collateral, we are at a disadvantage. And he has the gall to throw the competitor’s brochure in my face (as if I had never seen it).

Read More

Product Management

Unrealistic Expectations from Sales

I am in deep product launch mode. Planning for a roll out in the next 6 weeks. The culmination of almost 4 years of engineering and design effort, we are finally within sight of the goal posts. A good feeling, even if I am staring at a chaotic period coming (note: I will probably not be drafting any blog updates until this is in the bag).

Yesterday, we had a meeting with the sales leadership to outline what they expect to see in our training and education efforts. Not surprising, they have unrealistic expectations of what we will and won’t be at launch. It isn’t as though we have not attempted to manage expectations and curb unrealistic exuberance during this lengthy development program. But alas, it has fallen on deaf ears.

Read More