Product Management

What do different groups look for in Product Management?

"The original Winnie the Pooh toys" by Spictacular (talk · contribs) - Own work by the original uploader. Transferred from en.wikipedia to Commons.. Licensed under Public Domain via Wikimedia Commons -

Product Management is a tough place to be. Central to a well functioning organization, the pressures and stressors come from all sides, often driving product managers insane.

Part of the challenge of effective product management is that each organization looks to the role for something different.

Operations looks to product management to define and shepherd successful, buildable, scalable, and well conceived products. they are responsible to ship product (or to ramp services). They need product management to consider manufacturability and supportability early in the process, and to be reactive to the needs of production.

Finance looks to product management for realistic ramp rates, projections of sales, and to define products with a costs/revenue ratio that meets the model.

Sales looks to product management to build what they need to make quota. They need the products, the messaging, and the back end collateral to sell buckets of products. This nebulous requirement can be challenging to create and deliver, more so because regions and segments often have unique twists.

Marketing is special. Often product management is part of the marketing organization, but often a partner in the production of communications, messaging, promotion, and building communities of practice that drive organic growth.

Executive Staff looks to product management as the leaders. Nowhere is the mantra "all the responsibility, without the authority" more clear than in the expectations from the executive staff. Often disconnected from the day to day, product managers are the conduit and source for messaging. Balancing the day to day tactical fire fighting with the gloss that executives expect to hear takes a mighty toll on the psyche of the product manager. Having to portray a positive, glowing message to the senior staff, while mucking around in the messiness of keeping a product running is not fun, and one of the biggest difficulties in the role.

Nobody wants to be seen as an Eeyore in the organization, but often product management is both the truth teller, and the whitewasher in chief.

All the pressure of these demands can really take a toll on the product manager. It is no wonder why many new product managers burn out quickly, and look back to their tenure as the worst time of their career.

Product Management

R&D be like …

The Dude’s team is working on releasing a product. A major redesign and revamp of a product line we have had forever.

The redesign is a completely new electronic control package for an existing system. The Dude, working for a company known for its digital and analog electronics prowess, assumes that this is a recipe for kick ass.

Sigh. Alas, the Dude is poised to be disappointed.

At stake is a replacement for a control electronics package designed in 1998, as the at the time state of the art. It was analog and DSP based, and for its era, it was smokin’.

Starting around 2010 though, after an acquisition by said titan of electrical engineering expertise, work on a new control package was commenced. For a variety of reasons, the program has slip-slided into being way late. But it has all the right aspects to be a winner.

R&D though, hmmm, what was it the Dude’s mother used to tell him? Oh yeah, “If you don’t have anything nice to say, say nothing at all”.

We are in the final testing of this package. It has 20 odd modes of operation, from simple, to fairly complex. However, it is clear that there is an impedance mismatch in how R&D sees testing, and how my application scientists see testing.

R&D be like “Well, we were able to do contact mode imaging, let’s ship it”.

My applications scientists are a little more sanguine. We have a long history, and a mountain of experience, and test cases. We need to do testing on calibration standards, on soft materials, on block co-polymers, on long chain polymers, on freshly cleaved mica, each with its own “criteria” for success. R&D can’t understand why this takes more than one day.

In fact, one of these modes can take 2 weeks to fully test and characterize. At the hairy edge of physics, you can’t rush the process.

Of course, R&D also is scratching their heads over why the individual boards bench test awesome, but when assembled into a system, they fail to meet the specs. Their “ask”: change the specs, because they don’t want to investigate why they aren’t meeting spec.

Yeah, the clock is ticking, and the R&D manager committed that all the work is done, and the design is final (and perfect), but evidence is pointing at another spin of hardware, and the schedule repercussions that entails.

This all gets back to the true definition of done.

The Dude isn’t gloating, but he knows that you don’t declare a program finished until it is tested in final configuration. Bench testing don’t mean dick.

Product Management

Product Management Terror – Grade 10

Fear is a good thing, it keeps you focused, and can keep you on your game. However, like all things there are scales of terror, even in the realm of product management, tied to the pucker factor.

Pucker factor 10

Pucker factor 10

The Dude has experienced all sorts of sphincter clenchers, from the mild (line down, tell the world that it is FUBAR), to medium (we really screwed up and don’t meet specs, oops), but there is one that is a definite 10 on the SPF.

Picture if you will, you are in a nicely appointed conference room. There is a stenographer, and a videographer in the room. You have a suit and tie on.

You are being deposed in a lawsuit. There is the opposing lawyer, and (hopefully) your own lawyer at each side of the table.

They spend an entire day asking you difficult questions. Then they put a page (one of hundreds and hundreds they flash in front of you) that is an email you sent 5 years or so before.

Fuck. You ask to read it in its entirety. You can’t for the life recall the context. Unlike the majority of emails you send, it isn’t a quick sentence or two, but more of a “two pages of well thought out reasoning” sort of email.

You think to yourself:

  • Wow, I was really articulate at one point. This is very well written.
  • Oh shit, without context, this sounds horrible.

Yep, that is SPF 10 right there. You begin to sweat, you ask to read it again. You ask (in vain) for the referrant, or the response to this (they lawyers NEVER will give you context. They count on an isolated piece of communication to be a smoking gun.

Yep, the Dude has been there, twice. Yes, it sucks. The moral of this story: “Anything you write, type in an IM chat, or even email on your personal email account outside of the work context is likely to be found through discovery. And it can ruin your day/year/career. Even something that in context is innocuous.

Product Management

Stupid things Engineering Says… More Beta Fun

In another meeting today with the same engineering team, the one that really, truly,  honestly said “Beta testing is really just a luxury, today topped that.

When we were discussing the initial builds, the engineering manager prairie dogged from doing email on his laptop and said (I shit you not) “what, why aren’t we doing a beta?”

Dude, 3 fucking weeks ago, out of your mouth, you uttered the words “Beta testing is really just a luxury”. The PM Dude really really needs to bring a voice recorder to these meetings.

He went on to bellyache about how we won;t learn, and how the system will have bugs and glitches.

No fucking shit Sherlock. But that doesn’t change the fact that you and your crack engineering team is over 9 months late on the beta builds, and now, we have sold those beta units.

Beta was originally planned at two sites, 90 days of testing, with 90 days to act on that feedback. That got shrunk to 30 days, and no time to react.  Finally, it was bringing in a local good customer for an afternoon of guided tour, and testing. Now it is gone.

Yes, The Dude’s prophecy that alpha == beta == FCS came true. God dammit, the Dude hates being right.

prodmgmt essentials

The PLC – a Primer


If you work at a startup, or a small company, chances are this TLA is alien to you. However once you graduate to a mid sized company, with multiple products, and, more importantly, multiple divisions, the construct of a PLC is inevitable.

PLC is an acronym for Product Lifecycle. It is usually a 6 – 8 step process with gates or checkpoints to move from step to step.

The concept is simple, in a large organization, with well defined functional groups (i.e. marketing, finance, engineering, sales, production or operations) the PLC ensures that all groups are working towards a common goal or endpoint.

The names of the phase groupings may vary, depending on the consultancy who brought it in (or senior manager's prior experience with it), but loosely they are:

  • **Qualifying Opportunity** – the initial investigation to begin a program. A marketing person does Voice of the Customer, engineering might do some early proof of concept (can this even be done). The output is either a concept form or a “*thin*” MRD. Expect this to cost a little bit of money, a couple of business trips by your Product Manager/Product Marketing team, and a few hours of an engineer’s time tops. The hard gate here is the “Concept”, and the marketing documentation should define what needs to be built, who will use it, how large that market might be, what competition is out there (or for greenfield, who’s bucket will we be stepping in to build a market.

    Additionally, there is likely to be some engineering work to do a proof of concept. This is often needed when the product concept is truly new, and not derivative.

    This is owned mostly by Marketing, with consultation from Engineering.

  • **Development** – Where the real work gets done, taking the prototype, and making it a *product*, learning and refining along the way. This usually is the longest phase, and often has many revisions of the specs and requirements. This has several sub-phases, building a formal prototype, building one or more alpha systems (functionally, look and feel close to the final design) for internal testing, and a formal beta build and test.

    This phase is dominated by Engineering, but as important is Marketing participation in the sub-phases to keep the requirements aligned with the development priorities.

  • **Commercial** – Where Engineering hands off to production, and operations. Ramping up production of products (in the hardware case), or scaling capacities for web services. Engineering is responsible for a clean transition, and production engineering picks up all responsibilities.

    Marketing launches the product, announces it to the world, does promotion, trains sales, ensures that the systems are in place to take and process orders, and begins the sales ramp forecasting.

    Heavy lifting by Marketing, and operations, with cooperation from the Engineering team to drive a smooth launch.

Within each of these high level phases, are a series of smaller groupings of activities. Organizations will adopt, adjust, or alter these macro tasks to fit their needs.

Regardless of the final configuration, the PLC brings rigor and reproducibility to the product development process, and helps guide investment.


The Product Lifecycle provides a convenient, applicable framework to the processes around developing products. As companies get larger, and have distinct product groups, business units, and the like, a PLC process us useful to keep programs on track.

In the next few posts, I will dive into the details of the macro phases, and how I have seen them partitioned.

Product Management

Sales Cycle Oddities

Preface: The Dude is going to rant about sales practices. He knows that sales people are on a spectrum, with some stars, and some flops, and everything in between. He is not disparaging the entire profession. He has traveled with enough sales people to know that he could never do that job. It isn't in his DNA. If you are in sales, and this offends you, the Dude apologizes. However, just like there are boneheaded engineers, miscreant marketers, and product managers who would be better off pushing a broom, there are sales people who just don't cut it.

With that disclaimer out of the way, the Dude was waxing poetically with his operations manager (the dude that gets stuff built and shipped) about sales. This lead to some truisms that both the Dude and his operations manager have observed over their combined 45 years of tech hardware product experience:

The "Hockey Stick"

Looking at the bookings during a fiscal quarter, it looks much like a hockey stick. Close to nil closes in the first month, a trickle of orders in the second month, a ramp in the third month, and about 75% of all bookings in the last two weeks of the third month of the quarter.

Every freaking quarter.

Sales says, "What's the big deal, we met quota …"

Read More

Product Management

Sales Exceptionalism


The Dude is tired. Very tired. Tired of what you say? Tired of the trope that our products are “special” and that demands our sales team to be granted indulgences.

We are a large company, with a well defined, trained, and very proficient sales force. But because our products are so different, and require such a technical sales cycle (Dude rolls eyes) we need our own dedicated sales team.

With its own dedicated CRM tool, completely separate, and not compatible with the corporate tool. And our completely separate marketing team with its own writers, and strategy.

Because we are different.

Bullshit. Sales is sales. The bigotry that our larger, also very technical sales team is inferior to our small team offends the Dude.

As a first step in engaging and widening the knowledge of our products in the larger field sales organization, the Dude, recently recorded a training session to begin the process of training them up.

The Dude got to engage with the team that trains and coordinates the sales team events. And he was impressed. It is a well oiled machine. The wider sales team is motivated by all the factors that Sales everywhere are driven by, making money.

So the wall around our pampered, secreted, and protected sales team is beginning to crumble. Part of this is their own doing, as they have been consistently missing plan and quota.

The Dude is nervous about the change. Not that it will rock the world of the sales team, but it will certainly increase his load to widen the knowledge in the larger sales force. But nothing but awesome comes from this.

The Dude also believes that “marketing is marketing”, however, convincing his Marketing Communications manager to play ball will not be trivial. Another case of leading from the front.

Product Management

Sales Miracles

The Dude’s industry is a bit odd. Scientific instrumentation is somewhat unique. Small-ish market, very high end, and very cool, technology. However, a great year for us is moving 150 systems.

If this screams to you that a few incremental orders can make a substantial difference in your performance, you get the brownie point.

The Dude will relate a tale of a sales “miracle” that seems to be repeated frequently.

The 4th quarter of 2014 was one of these miracles. Orders rained out of the sky like mana from Heaven. All territories, and all sales engineers hit or exceeded their targets for the 4th quarter, and we had our best quarter in about 5 years.

The Sales Director was smug and practically bought out the local Bengay supply to relieve the pain from patting himself on the back. Our group VP was gushing about their performance, and how this was the beginning of a long, sustained growth period.


The Dude had seen this before. What happens is that the sales team, knowing that their year end bonus is on the line, and the accelerators for their commissions is calculated from their performance. So they pull in every order in their funnel that they can. This is often accomplished by additional discounting, tossing in freebies (like software) and calling in favors from long term, repeat customers.

If you can guess what happened in the 1st quarter, give yourself another brownie point.

Yes, this scrubbing the funnel to bring in all the orders in Q4 drained the pipeline in Q1. Q1 came in at less then 45% of plan, far off quota. The sales director as usual was waffling about competition, inadequate products, old products, and not enough “leads” (in typical Glengarry Glen Ross fashion)

The truth is, they ate their seed-corn, and now we will have two very poor quarters in a row until the pipeline is again healthy.

Of course, this tragic performance for two quarters will lead to some staff trimming to “right size” the business, and we will again slow down our development process, as of course the cuts will not come from the sales team.

Lather, rinse, repeat, ad nauseum.

The Dude just wishes that the executives would see through the ruse of the manipulation of the order velocity, and hold sales accountable.

Product Management

Stupid Things Engineering Says

The Dude has been around a long time, and has seen just about every bad behavior. This will be the start of a series of “Did they really say that?”. Today’s candidate is Engineering.


About 2 year ago, a product we had was struggling do to the lack of a major capability. Marketing had always pointed out that this capability was missing, as it locked us out of about 80% of the TAM.

A program was undertaken to add this to the project as quickly as possible. Since it was to be a “rush” project, we didn’t use the program as an opportunity to reduce the costs, making a conscious decision that time to market was more important.

Fast forward

Today, 2 years and 4 months after the “start” of this 3 month program, we are still struggling. Granted, the architecture and base design of our system made this feature a challenge, but somehow a 3 month development program turned into 27 months, multiple missed milestones, an acquisition of a technology partner (ostensibly to “speed” time to market), and we are still not done yet.

In the timeline, we had defined a 3 month “beta test”, and had negotiated with two ideal partners who were excited to get access to the technology early. They were originally scheduled to receive their bets instruments in March 2014.

March of course came and went.

Then the date was June. Definitely, absolutely, positively June.

Of course June 30 came and went.

The next date was August. The 15th to be precise. Engineering, and production both swore up and down that that would be the date.

What happened? You guessed it, August 15th came and went. Marketing stopped making promises to the beta partners. Fortunately, both were understanding beyond belief, but you get to a point where your credibility is shot to hell.

We have had definite, positively can’t slip deadlines of September, November, end of the calendar year, and other dates, all agreed to, and all missed.

We are at a point where we have customer orders that we have shipped, or need to ship (sold without demo or even seeing the system in action), and the beta systems have become first commercial shipments, and first revenue systems.

The last beta system will ship this coming Friday (Feb 27th) to Asia to be our demo instrument, and we are planning on squeezing the local beta test to an afternoon this coming week of inviting the beta partner in. Essentially, the plan for 90 days of beta testing and feedback, possibly reworking any gross issues found, and hammering on the software before launch is gone, and we are going to just ship it.

The Stupid thing

In the weekly meeting, when we were discussing the elimination of the beta test, the R&D manager had the audacity (the balls) to say: “Beta testing is really just a luxury”

Sigh, this product manager knows that to skip beta testing is the equivalent of banana product launch. Releasing an unready product and letting it ripen in the field. And nobody is happy with that.


I wrote this and scheduled it a couple of weeks ago. All was on track, but alas, that was not to be. Tuesday evening, in the last phases of testing, some anomalous behaviors were observed. Upon a safe shutdown, a quick inspection showed a high voltage power supply was burned to a crisp.Oops, I guess we aren’t going be shipping on Friday after all.

Product Management

Looking to the Past

The Dude went to a trade show this week, not a newsworthy item in itself, but he was able to reconnect with a lot of old colleagues and friends.

A job the Dude left in 2009 due to grossly incompetent management, he left behind two major developments. One, a new product offering that was a blend of technology, and “good enough” capability to expand the market, the second was a transition in the architecture of the product control software.

The Dude carefully crafted both sets of requirements to prevent engineering from screwing them up. He was halfway successful…

The hardware

At the time, the company had a new platform. It was kick ass, world beating technology in their space. The problem: It was overkill for the vast majority of the market, and the price was out of reach.

The concept was simple, take the fundamentals, reduce the specs, substitute some adequate, but much much cheaper hardware, and it becomes a general purpose, large audience system.

The MRD was crafted to ensure that engineering didn’t back out of the task (they hated not designing at the bleeding edge) at hand.

The Dude noted the launch, but since he was on to another company, and another industry altogether, he never got to see it up close.

This week he got to lay his hands on it. Wow. He even got to look under the hood. Son of a bitch, they did what he asked, and it is a thing of beauty.

Of course, the marketing team that took over couldn’t help but fuck it all up. They added bells and whistles to it until it is almost as expensive as its bigger brother. Now there is no low cost product, and the difference in price between the high end and this “affordable” model is small.


The Software

When the Dude worked there, the main control package was ancient. It was a DOS program that someone migrated into a Win32 application in the mid 1990’s (it originally ran on Windows NT 3.51 for the true geeks) and it was a mess. About 2005, he convinced management that it was time to architect a new platform. The duct tape and bondo that kept being applied to this long past its prime application was just not cutting it.

A ground up rewrite, with a truly segmented, layered approach and full 64 bit clean code (as our data sets were often approaching the limit of a 32 bit world) was approved.

Late in the project, and too close to the time that the Dude said “Fuck it, I’m out” the UI got serious attention. There were provisional interfaces, but it was almost identical to the original UI, designed for the time when 800×600 SVGA was the state of the art in computer monitors.

The Dude got the acting VP/GM (who was also the Executive VP) to agree to bring in a consultant to guide the process. Truth was, the EVP had worked with a few UI consultants over the years, and was on board with the idea, not too much selling involved.

But they went cheap. Very cheap. Since it wasn’t the Dude’s problem anymore, he just stepped away.

What they developed and launched? Well, it sucked. Frankly, it looks like a ADHD squirrel wrote it. Workflow is clumsy, the analyses are hidden and hard to find. It isn’t intuitive, and it takes longer to do simple tasks that the older software.

This makes the Dude sad. A chance to really make a world class application, to be the benchmark, turned into a turd.


As a product manager, you often kick off a program, giving it the best start possible. However, success requires a steady hand during the development and implementation, with minor course corrections to ensure that things don’t go too far off track.

The Dude has been a few places, and he is proud of his “children” but it does hurt to see how they went wrong.