OEMing For Fun and Profit (Part One)
Mark Hoover, President, Acuitive, Inc.  

I consider myself to be an expert in the strategy and tactics associated with OEMing because I have done it often, from all roles and perspectives, and have invariably screwed it up.  So let me share with you some of my thoughts on when and how to OEM for fun and profit.

My discussion is specifically relevant to only a certain kind of OEMing.  My insights are not relevant to the OEM processes where a chip supplier supplies a device that goes on a board, or a board supplier provides a board that goes into a subsystem, or a subsystem supplier provides a subsystem that goes into a system.  Those are the traditional and time-tested forms of OEMing that will endure forever. Instead, my thoughts are totally oriented towards a trickier OEM situation - one where one systems vendor OEMs a complete systems product to/from another systems vendor.

I have different comments to direct to the three constituents of such an OEM process – the systems company that OEMs a product from a supplier, the supplier of the OEM product, and the ultimate end user of the product.  I have a lot to say on this subject (because of my rich and varied history of mistakes in this area), so I am breaking my thoughts into three Musings. This first one speaks to companies considering OEMing other company’s products.  The other two will speak to the other constituents of an OEM process and will be published in upcoming Musings.

To Systems Vendors Who Think They Want To OEM

1.    Clearly understand your motivation.

Why do you want to consider OEMing a product from another vendor?   There are several possible motivations, some of which I consider to be legitimate and others that lead to failed programs.  In addition to filtering whether you should seriously consider OEMing or not, understanding and internally clarifying your motivation can radically impact the approach and strategy you take to OEMing.  

Generally, the motivation to consider an OEM program is to fill out your product line so that you can be a single source of complete systems for your customers.  But the fundamental question you have to ask yourself is, are these products strategic and core to the value we deliver to our customers, or are they commodity and driven by the need for “completeness” rather than value?  The way to separate these two vastly different motivating factors is to ask yourself the following questions:

• Due to the lack this product, am I missing opportunities to be invited to the table for critical strategic planning activities being performed by potential customers?

• Am I receiving requirements from my customers that I can’t fulfill with my present products, including upgrades and new products currently under development, even if I had infinite resources?

• Would the inclusion of this product in my product line allow me to reverse price and margin erosion that is occurring with my present product set?

“Yes” answers to these questions are a clear indication of a strategic product program, which must be addressed very differently from a “completeness-oriented” program.   In either case, even if you are clear about your motivation, mistakes can be made in execution (as I well know).

2.     Try to avoid these mistakes when realizing a strategic product:

The issues and tensions related to OEMing a strategic product are almost always related to the fact that in a fair and just world, these are exactly the products that you normally would want to focus your internal R&D resources on.  The fact that you are considering sourcing the technology externally already means you’ve already made a mistake.  You’ve probably been caught flat-footed due to not anticipating a market need or due to the failure of an internal development program.  In either case, there is a lot of internal tension and a variety of different points of view about “who is at fault” and who should drive solving the issue.   There is probably also not even an across-the-board agreement on the importance of the “missing” capability.  This is generally not the best environment to make clear-headed decisions in.  It’s up to the upper management in this case to get the right set of people together and grant them “indulgences” for past mistakes, clearly establish the strategic need for the capability, and empower and motivate the team to work together to make the best decision for the company going forward. 

• Don’t outsource a strategic product as a tactic.

Companies will often consider OEMing a product from another vendor as a quick fix until an internal development can be launched and completed.  My experience is that this approach almost always fails.  It is difficult to manage both an OEM program and an internal development project for the same capability.   One or the other must suffer.  There generally is a lot of customer and internal confusion about your strategy, tension with your technology supplier, and huge customer migration and product transition problems when (and if) the internal product sees the light of day.  My advice is that if the market pressure is so great that you need to OEM a solution as a quick fix, you’ve already missed the window for development. So instead of launching an internal development program, you should view the outsourcing program as the test of a supplier, to get to know them better with the eventual target goal of acquiring the company.

• Don’t outsource if insourcing is viable.

I have observed that many outsourcing programs are motivated by the lack of trust that many product management and business management people have for their own development teams.  The driving issue here is that when working with internal development, business people have direct insight into all of the ugliness and chaos of the wonderful process called product development.  Technology product development is hard, and if you’ve worked with a development organization long enough, there are bound to be lots of disappointments.   This often leads to an attitude that other Engineering teams are better or more efficient than your own.  But that’s rarely the case.  It’s more that you only get to observe other Engineering teams from afar; airbrushed, made-up, and marketed to create a halo effect to external observers like you.  Believe me, internally these Engineering teams exhibit all the ugly reality of your own– because doing complex stuff is simply hard. 

The legitimate cases where another company’s engineering team is better suited to do the job than your own are either when (a) the other company has specific Intellectual Property and engineering team DNA that your company does not, or (b) they have a significant (6-9 months or more) head start.  If one or both of these are not the case, think long and hard before you go about outsourcing, and if you do decide to outsource, as I said above, think of it as a step towards acquisition rather than a tactic.

• Clearly establish your value-add.

In general, strategic products are complex and constantly changing.  When one company sources such a product from another company and then re-sells it to their customers, there is usually a “value-subtract” related to the point product itself due to confusion in customer support, delays in getting fixes and new releases through the pipeline between the companies to the end customers and other inefficiencies that crop up whenever a “middle man” is inserted between the original source of technology and its eventual consumer.  Before you acquire the company you are sourcing from (which I believe should be as soon as you have validated the capability of their technology and engineering team), you have a responsibility to create a value for your customer that more than offsets such value-subtract.  This can take many forms, including guaranteed cross-product interoperability, integrated network management, integrated help desk, systems integration, unique systems-level features requiring support from both your products as well as the outsourced product, and coordinated interoperable pre-standard function releases.  Defining and achieving such value-add requires some significant focus and energy.  Customers generally see right through superficial or band-aid attempts at a value-add proposition. If that happens to you, it can completely undercut what you were trying to achieve in executing on an outsourcing program. So you must put some real energy into these areas, which is why I tend to call such programs “partially outsourced co-development” programs rather than “OEM” programs.

• Don’t even use the term OEM and don’t underestimate the cost of outsourcing.

When realizing a strategic product, don’t even use the term OEM.  It sends the wrong message to your internal engineering, test, purchasing, manufacturing, marketing, training, customer support, and other organizations.  Somehow they feel that they need to support OEM programs on a shoestring.  In reality, if this is a strategic product, you need to do all the things you would do if the product were internally developed, and perhaps some more to build an efficient interface to the sourcing company and to establish your value-add. 

I remember once when I was working at AT&T, a peer of mine, Kevin Kennedy, who has since gone on to greater fame at Cisco, did an excellent study of a large number of product outsourcing programs, to determine what makes some successful and other not.  He found that, on the average, the resources required to support an outsourcing product were about 70-75% of those required to support an internally-developed product.  This included engineering, QA, technical and sales training, manufacturing, product management, marketing, customer support, documentation, contracts, purchasing, etc.   The largest reduction can be Engineering resources but even that is not as much a savings as is usually believed   The number Kevin derived was for a variety of programs, some for components, some for systems, some for strategic products, some for commodity items.  I believe that the worst case is strategic systems products, which is what this section is all about, and therefore the resources required might be as much as 80-90% of an internally-developed program.  Most people don’t appreciate this.  This is far less efficiency than they expect to get when “all we are doing is buying someone else’s product.”  As a result, people tend to massively under-resource strategic “OEM programs,” which leads to a high percentage of failed programs, whereas if you called them what they really are -- partially outsourced co-development programs -- you’d be far less likely to under resource the program (and you’d raise the bar for decisions to initiate such programs). 

• Don’t become jealous of your outsourcing partner.

One of the very human characteristics that can seep into a strategic outsourcing program, especially when a larger, established company is outsourcing from a start-up, is the belief that the larger company is making the people in the smaller company rich.   My view on this is that when outsourcing projects and partners are chosen carefully, this should always be true.  It’s a clear symptom of success!  If the ultimate strategy (as I believe it should almost always be) is to acquire the smaller company, the larger company should be glad that their partner is becoming stronger and more viable, even though their price is going up.  On the individual level, I believe that the sourcing company needs to get for all of the employees supporting the overall program, to make sure they get compensated more than fairly if the outsourcing program is successful and if the start-up company’s value increases significantly.  This is the best way to get all parties to view that their financial upside are coupled to one another.

3.     When filling out your product line to achieve “completeness”, avoid these mistakes:

OEMing for product line completeness is a completely different situation than OEMing strategic product.  In this case, you want to make sure that the overall costs are as low as possible. That generally means that the products you OEM need to be mature and simple to sell and support.  Even when that is the case, internal resources are needed to manage the relationship with the supplier, negotiate and manage contracts, manage forecasting and procurement, manage product returns, execute on internal and external marketing and training, etc. etc. So – it’s never free to execute on these programs.  Given that by definition the product is not strategic (or you wouldn’t be reading this section), one has to ask, why OEM in such situations at all? 

My advice is to do as little of this type of OEMing as possible.  Curb your appetite.  You’ve got to be real sure that your customers really need to see these items on your company’s price list.  Often, the same goal can be achieved just by training your sales force on who to reference customers to for these products rather than taking a P.O yourself.  That way you get the “brownie points” from the customer without taking on all the hassles of supporting a low margin product on your price list.  If the motivation to OEM is coming from your sales force, make sure it is a real customer requirement rather than just a desire on their part to retire some quota by selling these products. If the desire is sales force driven rather than customer driven, you might instead be able to SPIF them for successful reference sells in a way that would be less of a cost burden on you than actually taking revenue for the product (and your partners will love you).

If, however, you need to do some of this type of OEMing, here is some other advice:

• OEM from OEM-oriented sources.

I think that the biggest mistake many companies make is OEMing from companies whose primary business is selling to end users.  This can create channel conflicts for one thing. But even more so, it means the company you are sourcing from has mixed channel models internally, and probably haven’t aligned themselves to fulfill the unique requirements of an OEM customer.   I wouldn’t OEM from anybody unless they can identify to me 2-3 other OEM customers they have that I can talk to. 

• Avoid OEMing products that don’t exist, if at all possible.

Don’t OEM promises.  Only OEM a product if it exists, is shipping, has lots of customers who can validate its functionality, and exactly meets your needs as the product stands today.

• Shy away from OEMing complex products.

OEMing a complex product is almost always a losing proposition.  Complex products tend to change rapidly and thus you always lag in the features in your version of the product, your training, your marketing collateral, etc.   This almost always leads to customer dissatisfaction with purchasing the product through you that is completely at odds with your initial motivation to OEM. 

• OEM programs tend to be loss leaders.  You can’t fight that.

It is rare that an OEM program can be managed to profitability.  As mentioned above, significant resource is required for a successful OEM program unless the product is very mature and very simple.  The cost of supporting programs can only be paid for via the slim margins associated with OEM programs.  Margins are always slim because the OEM supplier must make a profit.  Their product becomes your COGS.  In general, it’s hard to justify a huge mark-up in price, which would be needed to regain margin.  So count on 10-25 points of gross margin, which usually means net loss.  Thus, to be useful, an OEM program must have considerable value beyond the point product – the marketing value of delivering a “whole product” or increased sales velocity of other higher margin products, as examples.

•  Don’t get yourself into situations where success is failure.

Because of the slim margins associated with OEM products, you can get yourself in a situation where selling too many of them is a bad thing because of the effect on your overall margins.  That’s pretty un-motivating for all parties involved in the program. Make sure you have a sliding scale on pricing from your supplier so that your cost goes down as the volume of products you sell goes up. 

•  Deal with channels conflict up front.

Ideally you would be sourcing from a company whose entire business is OEMing, which reduces the channel conflict possibilities.  But assuming their channel has some overlap with yours, you may want to be pro-active to ensure that tension doesn’t result from that.  The simplest way to do that is to work out a program where both company’s sales forces get compensated in some way when product gets sold into overlapping customer spaces, regardless of which company achieved the sale.  If you get that right, you can get your OEM suppliers sales force to actually help your sales force to win deals and take POs.

(volume 4, number 4)