Product Management is Considered Evil

(I have been sitting on this post, because it is mostly a rant. I actually try to not be negative and sarcastic. Plus this is not about Multicore in any way. Anyhow, it needs sayin’.)

If you are working in a modern company, you have probably encountered “Product Management”. If you have not encountered this modern corporate management marvel, count yourself lucky. I have worked with Product management for 8 years as an engineer and a manager. The honest to God truth is, this emperor has no clothes.

First, some history

The idea of Product Management came from a Harvard Business Review article. The original idea is from the late 80’s. I can not find the link right now.

In any business there are different groups all pulling for the greater common good of the company. Groups like marketing, sales, production (operations) and engineering all come from different worlds, so see the world differently. These different world views cause conflict and friction. We are all trying our best, but attack the problem of business from different sides, and so friction is the result.

Obviously, all this conflict is not good. It hurts the product, especially if one group dominates the others. Sales wants a cheap product with every possible feature, so no customer can toss them out because the product does not do XYZ. Marketing wants something flashy and cool to build campaigns and Super Bowl ads. Production wants consistency, nothing new, just churn out the existing widget. Engineer will create a solution in search of a problem, very cool, if you are a geek and can figure out the menus. So, a battle rages, with a good balance the company produces good products, but that is really hard.

Into the middle of this comes the Product Manager.  From Wikipedia:

product manager investigates, selects, develops, products for an organisation, performing the activity of product management.

A product manager considers numerous factors such as intended demographic, the products offered by the competition, and how well the product fits in with the company’s business model. Generally, a product manager manages one or more tangible products. However, the term may be used to describe a person who manages intangible products, such as music, information, and services.

This person stands in the middle, the hub of the organization. They take in the wishes of sales, the marketing input, understanding of the technology and the competition and produce the idea product that fits the market. Success is assured.

Sounds good, don’t it.

The original idea came from a marketing professor, so this role of great power is a marketing role. That does not really matter, but usually the Product Managers are in the organization chart under Director of Marketing or similar.

Product Management’s Problem

Steve Blank pointed out “Why Product Managers Wear Sneakers“. The idea he presents is the Product Management does not work for a startup the same way it would work for an established company. I argue Product Management does not work. Now you have to ask why I feel it fails.

First, as I described above, the Product Manager is the hub, the man in the middle, making high stakes decisions for the future of the company. That is for your future and mine as fast growing, hugely profitable companies don’t usually do lay offs. You can just see the Product Managers standing on a rocky outcrop, staring into the morning sun, their cape flowing in the breeze.

Unfortunately the people I have known who do this job do not wear capes, and have no super powers. They were all very nice people, and I count some of them as close personal friends. What I am trying to say is the job as described takes a super human organizer and negotiator. So, I have yet to find a truely effective Product Manager in the past eight years of my career.

It is the nature of the position, not the people. The product of a Product Manager is the Marketing Requirements Document, or MRD. Writing requirements is a thankless task. They are never complete, there is never time do get them all right, consistent and testable. Plus, there is no help. With all the new agile methods, requirements are seen as something from the bad old days of waterfall development. Of course when the engineers get hold of the MRD, we rip through it and point out every flaw. It is in our nature, as right brained thinkers. A thankless task indeed.

They must negotiate the fine line of asking for features and solutions, but not dictating the implementation. That is a requirements problem, not just Product Management. They are the ones who must stay on the fine line, making the job harder.

Next is the schedule. Schedule is huge for hitting the market first, training the sales team, and having the big splashy role out and Super Bowl ads. The poor Product Manager does not get to set the development and test schedule. If your engineering management lets them set the schedule, I am sorry to say that you are really in deep shit. We have heard this tune before, they need it next quarter for the 83 Million dollar customer, it will take six months to develop, and then we have to test it, do a beta, and integrate with third party systems.

The poor Product Manager often falls into the role of the Project Manager. They are not the same and should not be. Project Managers manage the project and the schedule. Unfortunately the Product Manager’s future depends on getting the projects done. They have the vested interest, so wind up managing the schedule. The big problem is that there interest is not always in line with the project. As the project evolves into product, the Product Manager wants it done sooner, cheaper. Quality can suffer.

A good friend of mine moved from an engineer job to a product manager job. He told me the biggest headache was being the monkey in the middle. There was little he could do to force other groups to do his bidding. He was in marketing, they were engineering or manufacturing. All he could do was ask, negotiate, and hope. He is a good guy,  who can negotiate and is not shy. Still it was impossible to make his goals the goals of the other groups.

Product Management Never Innovates

The final nail in the Product Management coffin is that they do not innovate. What does that even mean, innovate?

Sales, marketing and product management tend to evolve products. They want to take the existing product and add a clock.

“You should have just taken an existing product and put aclock on it or something.”

– Homer Simpson

True, no one of us is Steve Jobs and even he did not come up with the iPhone on his own. The idea that pivots your company is not coming from product management or marketing. Once again Steve Blank talks about innovation in a large company. (You should be subscribe to his blog!)

Product Management is trying to make a business case for something new. A huge, incredibly difficult task. Why not take the existing business model and extend it, look at competition, and do something where there are data points to make the ROI easier to figure? It works, the business keeps expanding. Features get added to the checklist. All is well.

All is well until the company gets blind sided. A competitor does a leap frog, or a scrappy startup takes the whole business onto the web.

By the time the path is obvious, it is too late.

How can you help?

If you have a friend who is a product manager, or you are thinking about moving into marketing (it is tempting), is there help? Can Product Management be saved?


Still, you can help. First of all, when you talk to a product manager, ask them if they or your company is a member of the Pragmatic Marketing group. They are the industry group and offer training and seminars. It is no IEEE, but it is all they have.

Second, read the books on requirements. Found here and here. Help get a good MRD. Think of it as enlightened self interest.

Finally, be a friend and help them when you can.


State Machine tools

I have been hunting for a tool that would draw nice diagrams to post some pretty pictures for you all.

This is what I came up with. Not much, only two freely available and easily downloadable to Ubuntu.

Another review of Ragel

Are there more? What did I miss?

I would prefer a tool that is a state machine or even UML specialist. Drawing diagrams in OOo Draw or Word Art is not for me.

Multicore for Power Savings?

That is according to Jim Turley of Silicon Valley consultants SiliconInsider,

I agree with most of his points. Memory is the major bottleneck, and trying to make a sequential program magically parallel fails.

But, power savings? Maybe we can bring back the TURBO button. This time it will actually turn on the extra two cores on the quad-core processor. Cool.

Embedded Linux is Not the Multicore Answer

Sigh, here we go, this is where I say Linux is not all things to all people, and the get ripped to shreds by the whole Internet.

The thing is, in the chat rooms at the Multicore virtual conference, it was assumed that the OS was Linux. Yes, all of the hardware vendors will supply a Linux BSP with their multicore chip. We were working on one at Xilinx for the dual core Cortex-A9.

Linux is great!

There are many reasons to use Linux in an embedded system. It is free to use, the tools are free, there is a huge amount of support available by asking on a mailing list, all good reasons. The one topper reason (in my experience) for using Linux is the system needs a complete TCP/IP stack. If you are doing networking and need to get going quickly, Linux is the way to go.

And, I am a real Linux guy. I am typing this on my Ubuntu 10.04 Dell 17.3″ screen laptop, Big Red. (Because it is big and red, duh.) I put Ubuntu on my wife’s laptop. At work that is where I spend all my time, in Linux, writing code for an embedded Linux system. I have been into the kernel and have working driver code to prove it.

However; embedded Linux is not a one size fits all, use it anyplace and it will be perfect solution.

Motifake Poster

Not everything is bad

Linux, The price of Free is Expensive.

Sometimes the system is too small, does not have an MMU (yes I have built a system with uClinux), or is otherwise not suited for Linux.

One thing about Linux, it is very difficult to get a minimal implementation. A kernel all by itself is not a useful thing. You need at least busy box, and usually more to get any real work done. As packages get added and more features are enabled, the system starts to grow. Type ‘ps’ on an embedded Linux system. Do you know, really know, what all those processes are doing?

Being an insane control freak, that bothers me.

Kernels come out all the time. There are always fixes and updates. Most don’t affect the code in your system. Right? Your sure about that? It is a full time job keeping up with kernel updates and patches. Plus there are the patches for the specific processor architecture in your system. So, what do you do?

Basically you pick a kernel version and start building. The kernel gets updated when there is a real bug. Otherwise it never changes. Some day a major security flaw will make all the systems vulnerable. Hopefully that does not happen on your watch.

I could claim that Linux does not scale for multicore processors. At first, I thought that was the topic of this article. What the research paper really says is there are bottlenecks for most major Linux applications above 48 cores. 48 is a pretty decent number of cores, if you think about it. Most systems today are at 2. A big dollar system gets to 4, and real servers run with 8. We are still a long way from 48.

Why not Linux?

Let’s throw out the old code and start over again. The new stuff will be better, I promise. O, those software guys are just nuts like that.

People who have worked with me know, I have argued,and heatedly, against the big redo. So why am I arguing to start over with a new operating system and a completely new paradigm for applications? It would be better to be the Linux on multicore expert. That would surely get me more gigs in the future.

It is actually simple. If I need a side project, I want to start from the metal and work up. It is personal.