I had an opportunity to share ideas and experience about product cost management and product profitability with Eric Hiller. Eric responded to my post on PLM and Product Cost Management (PCM) and we have shared some great dialogue following that. Eric has some great experience in this area and I asked him if he would like to share it. I hope you enjoy it!
The following is a guest post from Eric Hiller:
Sure, cost is important… but I have a lot of other things to do, too.
I’ve been fascinated by the problem of product cost since 1996. I did my graduate work on the subject, I considered it when I was a young engineer at Ford Motor Company, I started a company that makes product that helps companies make their products more profitable, and I have been a consultant to executives in Fortune 500 companies on the subject of product cost management. I’ve learned a lot of lessons in those endeavors, but one of the most interesting is:
Product Profit is NOT as Important as One Might Think
I know that’s pretty shocking to say, especially for a guy who is fascinated by the subject of Product Profit. But it’s true… or at least it’s true in a relative sense versus other product attributes that the product development team must meet.
The statement above also seems surprising given that we have been taught for years that the purpose of business is to make money for the owners, and money for the owners comes from free cash flow, and free cash flow comes from profit, and profit comes when expenses are less than revenue, and in most manufacturing companies, Product Cost (roughly equivalent to Cost of Goods Sold for the finance types reading this post) is 70-90% of revenue.
Considering my rough Aristotelian logic in the last sentence, why wouldn’t we assume that product cost is, indeed, the most important thing to business? (I’m being a bit facetious in my rhetorical question to prove a point here.) The point is that there are many other things that go into making a successful business, even from the product development-only standpoint. These include:
- product performance
- number of features of the product
- product profitability
- development cost
In product development, most teams have to balance all these goals. We can see this from Tech Clarity’s 2011 report on product development tradeoffs in Figure 1. When you ask the average executive in product development, they are concerned with a multitude of issues. Even the least important category below (Product Sustainability/Green Initiatives) has almost 50% interest from executives. (Note that I consider manufacturability to be a concern that is very closely aligned and/or drives product cost.)
Figure 1 – What Product Development Executives are Concerned About
But, which of these goals is that the MOST important goal. Michelle Boucher at Aberdeen Group gauged the sentiment of product development executives in November 2010 on this question. Here are the results that she found (Figure 2), when she asked 312 respondents to pick “The top business pressure driving their company to have better insight into decision-making during product development.”
Figure 2 – What is the MOST important concern to product development managers?
Source: Aberdeen Group
I particularly like this survey question, because it forces the respondents to pick the most important. There’s a couple of interesting things here. First, if we look at the results of this survey versus similar questions asked in the past, we will see that the focus on product cost and profitability is less than it was a year or two ago. Hopefully, this is indicative that the economy might just be starting to show little signs of recovery. Second, notice that when the survey forced the respondents to rank the importance of goals in an ordinal way, the focus of PD executives is still fairly balanced across the different goals that we discussed in the bullets above. In fact, if we combined “customer demand for lower product costs” and “need to lower development costs” together, the total focus on cost or profitability of the organization is about 27%, which makes it almost identical to the other four focuses.
This data matches my own experience in talking to hundreds of customers over the last eight years. In the highly unscientific and intuitive statistics cruncher in my brain, if I combined all the feedback (direct and implied) that I have gotten to the same question, I would say the ordinal ranking of the average product development organization, whether spoken or unspoken, is as follows:
- Safety/compliance (required to sell product at all!)
- Product performance
- Number of features of the product
- Product profitability
- Development cost
In fact, when I asked the question directly to several product development executives, this is almost exactly the order they gave me, although often they will not list every one of these attributes in their answer.
So what does this mean?
Does it mean that product cost and profitability are unimportant things? No. It simply means that sometimes they may be less important than other goals. So how do we make progress in product development and delivery of corporate profitability, given that product cost is the least favorite subject of many design engineers?
I suggest the following simple framework:
- Set the required level needed for each of the other attributes, except for product cost / profitability
- Set a minimum level target for product profitability, but think of product profitability in your mind as the variable you are optimizing.
- Execute on meeting the goals for the non-product cost attributes actively first, while monitoring product profitability and evaluating each choice made about a non-cost attribute, asking “Will this decision make my product profitability go up or down?”
Those of us who come from a background of optimization probably remember that it is very hard to optimize on more than one variable at a time. Therefore, the typical way to make progress practically on a optimization problem with multiple goals (which is exactly what product development is), is to set some hard constraints (Attribute Targets) for all the variables but one, and then run the optimization to maximize or minimize that last variable of interest (in this case product profit or cost, respectively).
A simple conceptual graphic of this framework is shown below. In the green ovals we show lines of equal product profit. We’d like to climb the hill to maximum profit, but there are real world constraints on the level of our other product attributes (e.g. time-to-market). This leaves us a tan shaded region where all our non-cost targets are met. In my suggested framework, the team first works to get into the shaded region and then starts making choices to meet (and optimize) the last target of product profitability. The axes represent two choices the team is making, but we know that the team will really be making thousands of choices (it’s just hard to represent that in 2D).
Figure 3 – Graphical Representation of meeting product development targets as constraints, while optimizing product cost and profit
This approach may sound like common sense to some people, and if so, great! However, don’t let the point pass you by without internalizing it a bit. One of the blinding flashes of the obvious from David Allen’s book Getting Things Done is that the human brain just can’t let go of something important until it is written down or handled. So, one of his first rules is that you have to “write it down.” Similarly, instead of letting Product Profitability be that nagging voice that keeps distracting everyone, companies can simply “write it down,’ too. That is, they should set a maximum product cost target and keep checking it in the rear view mirror, while keeping the immediate goals of Safety/compliance, Time-to-market, Quality, and Product performance, etc. in the front windshield view.
This may sound like a nuance, but I still often get the question “How do I balance my product cost targets with all the other targets I have in product development?” Years ago, I was perplexed what to tell the questioner other than “Make product cost your top priority.” That was not a realistic solution to the real concern. Eventually, after thinking through the problem and observing the culture of product development, I came up with the simple framework we are discussing. When I have explained this framework to product development teams at past clients and customers, it seems to make people feel much more at ease and helps people regain a sense of control.
Obviously, one could change the framework to make any product development attribute or target the ‘to be optimized’ variable, just as easily. But given the immediacy of the challenges of program timing, quality, and performance, it seems that making product cost the optimization variable works best for most product development teams. Sometimes, we just have to learn by experience.
(p.s. I still think Product Cost Management is really important!)
So that is what Eric has to say, I hope you found it interesting. Are we really too busy to care about cost? Do we just believe that profitability is more about top-line issues by having the right product? Let us know how you feel about it.