Marketing/ Product Management

Drowning in Data

As I sit in my office, wondering why our latest product introduction isn’t selling as much as I expected (and more importantly, forecasted), I begin to look for potential causes.

Sales assures me that they are beating the new product drum with customers yet it isn’t resonating. Smelling the whiff of weapons grade baloney, I muse to myself “Can I find out how often they are quoting the new product?”

Turns out the answer is yes I can find out how many times they quote the new versus the old product. This leads to today’s sermon from the mount, “Drowning in Data.”

Read More

Marketing/ Product Management

The Challenge of Reforming a Sales Lead Organization

In my line of business, scientific instrumentation, we have a few odd facts and behaviors. An overriding theme is that due to how our industry was created and how closely intertwined with the academic research field, we have a pretty monolithic sales organization. This is best described as “Scientists selling to Scientists”.

It has been successful for a long time, but it has also become a boat anchor. There are many issues, but top of the list is the desire to collaborate with the people you are selling to. This goes way beyond collaborative selling, into more of a partnership.

I don’t mean co-authoring papers, or the like, but more to “Oh, I see, how about we customize the Alpha 3 system to facilitate your bolting on a zeta mark 3 whatchamacallit to it.” Hence, we do a lot of engineering to order.

Read More

Product Management

I Hate it When I am too Smart for my own Good

This has been a bad week for a variety of reasons. A product we have been working on for quite a while is not going well. It isn’t MY project, I am a “hired gun” doing the product marketing for it. There is a formal product manager, and I work with him (a great guy, I have known him for about 16 years, so it isn’t a stranger relationship between us.

About 15 months ago when I began this stint, we were talking about a 3 month beta test program. (actually, he was talking about it, I was listening) And I quipped that that was quaint, a beta program, but that I would bet a dollar that we wouldn’t do a beta test.

Here we are, the program is way late, we just talked today of using our three beta builds as our first customer shipments.

My original statement was: “Mark my words, alpha, will be beta, will be first commercial shipment.” And now, that is the most likely result.

I feel like a schmuck. Banana product management again.

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