OEM'ing Software for Product Managers

By Daniel Shefer August 09, 2007

The purpose of this article is to describe the 'ins and outs' of identifying OEM'ing opportunities, successfully negotiating OEM agreements and bringing the deals to fruition.

What is an OEM Agreement?

An OEM (Original Equipment Manufacturer) agreement is an explanation of the rules that manage the relationship between a company that supplies technology or a component of a product (the 'Manufacturer') with another company (the 'OEM') to resell or incorporate it into their product using their own (the OEM's) brand name. The most common OEM agreement is when one company licenses technology from another and adds it to their product to enhance their product's functionality.  This can be in the form of a software driver required for a hardware component, a protocol stack, an embedded database or even an entire application.  Usually this is done in a way that is not apparent to the end user but there are exceptions. For example, we are all familiar with the ?Intel Inside? logo's found on many personal computers, even though the same PC often contains memory chips, disk drives and other components from different vendors.  When both companies? names or logos, appear on a finished product it is most frequently referred to as a 'Co-Branded' OEM relationship.

Why OEM?

Companies OEM technology as a way to speed up the development process by bringing in pre-developed technologies to allow it to stay focused on their core competencies. Manufacturers use OEM agreements to reduce their marketing and sales costs.  Companies also form OEM relationships to quickly address changing market conditions and satisfy customer demands by integrating technologies that would otherwise be too expensive to develop or take too long to develop internally.

Common drivers for OEM agreements include:

  • More business opportunities: By adding features, the OEM can address additional market segments.
  • Competitive pressure: A competitor has a function or feature that you don't have and you need to add it to your product to maintain your position in the marketplace.
  • Competitive advantage: Companies who are able to enhance the functionality of their product beyond that of their competitors, they stand to gain market share faster than their competitors.
  • Time to market: OEM relationships are often set up to decrease the time it would normally take to develop, test and release a new product, or feature. Companies may not have the development skill-set in house. If they do, it may make more sense to have those resources applied to a potentially more profitable project that is closer to their core business.

'There are two keys to successful OEM deals:

  • Aggressively pricing the technology so the channels can make money without cannibalizing your own sales.
  • Licensing the technology that will enhance your own offering. An example for this is Real's licensing of its technology to the caching market. By adding Real Streaming Media technology to their products, the demand for our own servers has actually increased.'

-- Andy Holderness,
Director of Business Development
Real Networks

Why Not OEM?

When OEM'ing technology that is critical to a business, a major concern is that the OEM loses control over this aspect of their business. OEMs become subject to the will, whims and business stressors of the manufacturer.

On the flip side, the manufacturer loses control over how their technology is sold. This causes them to lose control over distribution, positioning, insight into the sales forecast etc.

When Do OEM Agreements Work?

Like any contract, the number one requirement is that both sides sign the OEM agreement in good faith.

The expectations and responsibilities of both parties are well communicated and agreed to both in principal and in writing.

Common goals, objectives, milestones and deliverables are agreed upon in advance as well as any monetary commitment by either party.

Periodical relationship reviews need to be part of the agreement. Both parties need to understand that business conditions change and the nature of the OEM relationship must have embedded provisions for review as well as enough flexibility to keep the relationship healthy.

As in any agreement, there is a difference between adhering to the letter of the contract vs. its intent. When the sides to the OEM agreement adhere to the letter of the contract, they often damage the business relationship. The business relationship is more important than its technical details.

The OEM needs to be staffed and organized as a marketing and sales organization that can push the resulting product into new markets.

The manufacturer has to have the business, development, support and implementation teams in place to support the OEM.

There are mutually established metrics of success that will be used to measure the value of the relationship and maintain it over time. OEM relationships are often managed by new employees who may have no prior knowledge of why the agreement was set up, or how success is to be defined.

'An OEM partnership is only as strong as the assigned project managers on both sides. There are so many things that have to be done to make an OEM deal successful that without dedicated owners on both sides, the agreement will not come to much.'

--Alyssa Dver, CMO
SEDONA Corporation
and Author of 'Software Product Management Essentials'

When do OEM Agreements Tend to Fail?
  • The OEM relationship is not a win-win situation for both sides.
  • The agreements are too complex and hard to implement.
  • One of the sides needs to refer constantly to the contract to get things done.
  • One of the sides is not interested in investing the resources to pursue the agreement.
    • On the OEM side, unless the agreement is core to their business, soon after the honeymoon (i.e. the press release announcing the relationship), the sides may not pour the needed resources into it.  Channels are driven by effort vs. sales ratio and if they do not see the results, they will stop investing in it.
    • The manufacturer fails to properly support the other party with engineering resources, deliverables, training and/or technical support.
  • The OEM underestimates the resources needed to sell the resulting product.  The sales cycle is longer than expected, the OEM doesn't have the pre/post sales resources on staff to do the job etc.

'Product Managers need to be involved in OEM deals from Day One. An important part of their responsibility is to work through the business issues as well as offer a holistic approach to the technology that's being brought in-house. These include everything from the technology's roadmap, branding, support all the way to end of life. After the agreement is signed, Product Managers need to be involved in the day to day of making the OEM relationship work.'

-- Neil Lieberman, VP Marketing
 Interwise

Questions to Ask Before you OEM Your Technology

'Always treat OEM agreements as a business deal. First make sure that you work out the business details and then focus on the technical aspects of the agreement.'

-- David Hochhauser, VP Marketing
Shunra Software

  • What does the OEM bring from the technical perspective? Will they build something bigger and better than the original product (i.e.: 1 + 1 = 3)? If not, they may turn out to be limited to an additional sales channel offering marginal value.
  • Will this agreement really open new revenue opportunities, or simply pollute and dilute the manufacturer's current customer base?
  • Who will manage the relationship? Does this person have the skills and resources to make the agreement work?

'Look at the manufacturer's marketing capabilities. You will need their marketing help if the technology you are OEM?ing comes under attack as not competitive.'

-- Merrill R. (Rick) Chapman, author of In Search of Stupidity: Over 20 Years of High- Tech Marketing Disasters and The Product Marketing Handbook for Software.

General Business Issues

 'Be sure that Biz Dev actually has a contract before you spend efforts developing a product. At a previous company I worked for, we developed a device for a large telecom that would be re-branded as their own. We explained to management that we would have to sell 80K units to cover the cost. Only after two years of development did we find out that the telecom was planning to buy only 50K units and that there was no contract between the two companies in the first place.'

-- Debi Jones, VP Marketing
San Diego Wireless

  • First make sure that there is an OEM agreement in place BEFORE investing any technical resources on behalf of the OEM.
  • On the manufacturer's side, OEM deals should have both a business owner and a technical owner.
  • There needs to be an agreement about how much visibility the manufacturer gives into the product / component's roadmap, what the process is, how feature requests are made, how early they are given insight into the roadmap etc.
  • The agreement should set up a joint Product Forum that includes Product Managers form both companies that meets regularly to discuss customer feedback, product requests, bugs etc.
  • Agree on release schedules and what a point release includes.
  • Auditing. The OEM agreement needs to include a clause that details how and when the manufacturer can audit the OEM's books to verify that they are getting the fair share per the licensing agreement.
  • Renewals. On what terms will the license be renewed? Will it be automatic? With 90 days notice?
  • The OEM agreement needs to clearly state the limit of time the OEM can use the licensed technology.
Sales

'You don't want to get to a point where you have to exercise the 'minimum sales clause?. OEMs always have ANOTHER core business.  This is what got them into business in the first place. The challenge is to seed the channel with a pipeline. Once they taste sales it's much easier.  Whatever timeline you plan for, it always takes more time and energy than you planned to get the forecasted sales.'

-- Alyssa Dver, CMO
SEDONA Corporation
and Author of 'Software Product Management Essentials'

The perfect leverage in an OEM relationship is where the manufacturer sells to an OEM that reaches other segments of the market. The delineation of markets and territories needs to be detailed in the contract.

If the OEM has their own distribution channels, the agreement has to support this.

Agree on if and how leads are collected and handled. Higher commitment agreements tend to have more mutual marketing functions.

If there are other vendors reselling the product you want to resell:

  • Check if any of them have exclusivity rights and if so, what they include.
  • Make sure that your respective positionings do not clash.

As an OEM, the planned margins must take into account your sales costs and any channels that you may be feeding in turn.

OEM'ing a whole product vs. OEM'ing a component can create channel conflict as the original and the OEM'ed products may compete with each other. Sales reps will tend to go after easy targets vs. staying in their pre-defined territories. In addition, customers who want to save money will approach reps from both sides if they recognize that the benefits of the products are similar due to their common components.

Exclusivity

OEMs always prefer exclusivity (but of course would never want to give this to their channels). In reality, exclusivity doesn't work most times. When the OEM gets exclusivity, there is less pressure on them to deliver sales quota per the agreement. A solution to this problem is 'soft exclusivity?. This is basically a gentleman's agreement. As long as the OEM sells per the agreed quota, the manufacturer won't look for another OEM that covers the same market.

Payments

A common pricing model that vendors use includes an up front OEM licensing fee, an annual volume-based fee and an annual support fee. OEMs should try to delay as many of these payments as possible until the product is generating revenue.

The most common problem with payments is not so much that companies try to cheat as they lack the internal controls that lead to failure to pay. The ability to audit the OEM's books is really the only tracking mechanism of the royalties that are owed and should be done occasionally. The OEM agreement should include a penalty for any error in tracking or reporting of related revenue (deliberate or accidental). This provides OEMs an incentive to report honestly.

Regular audits are recommended if the OEM is not known to have strong internal controls.

Branding

The OEM agreement should cover whose brand will be in front of the customer. If the manufacturer has a dominant position in the market, they may want their branding on the final product. The Inside Intel campaign is one such example.

After agreeing on how the product is branded, an addendum to the agreement should address who provides the graphics, in what formats, sizes, how soon does the OEM have till they have to change the branding following a manufacturer's change, etc.

General Technical Issues

The OEM agreement should detail the functionality that the product provides. A PRD (Product Requirements Document) should be an addendum to the main agreement. Performance and other relevant criteria need to be defined in very clear terms. This will act as a reference to the expectations from the manufacturer.

Agree on how the product will install. The installation process needs to be flexible enough for the OEM's installation team to manage, that it does not increase the installation size significantly or negatively impacts the end users in any way such as requiring more rights on their computers. The optimal solution is that both sides use the same installer program and that the manufacturer provides the source code and scripts for the installation. However, this approach is also sensitive to ?attracting? bugs. These bugs are the responsibility of the OEM but the manufacturer will many times be forced to help with.

Agree on the hardware and software platforms that will be supported and the process of how supported platforms will be added and removed over time.

The agreement should include a clause that the manufacturer will not remove functionality without mutual consent.

There needs to be stated provisions addressing what new versions will be considered bug fixes, patches and work-arounds versus an actual new version of the core product.

There should be mutually established and well defined procedures for offering new versions, reviewing, testing and signing-off on the acceptance of these versions.

The exact form of delivery needs to be established. Will the software be delivered by CD, download etc. If the product is large and downloading is the delivery method of choice, the minimum download speed should be defined.

Managing Source Code in an OEM Relationship

When given access to the source code, OEMs can optimize the product. This is basically an outsourcing of sorts of development efforts by the manufacturer to the OEM. The rights to do so and the ownership of the derivative work have to be agreed on beforehand.

Allowing the OEM to make changes to the source code can be a slippery slope. When the OEM makes a change to the source code, they are in danger of creating an incompatible product. The OEM will arrive at a point where a new version from the manufacturer will not be compatible with that of the OEM's. At that point the OEM as two choices. Either invest development resources in the OEM'ed technology or pay the manufacturer for upgrading their version. Note that it may not be in the interests of the manufacturer to offer such a service.

It's highly recommended for the OEM to keep their version of the product in step with that of the manufacturer. This is beneficial to both sides and should be covered in the OEM agreement. From the manufacturer's perspective, having end user's get the 'latest and greatest' removes the pressure to support older versions. From the OEM's perspective, having the latest version improves the ability of the manufacturer to support them but also requires additional resources for managing, integrating and releasing the new versions.

Non Recoverable Engineering (NRE) Charges

When OEMing technology, expect to pay some amount of NRE.  Very few OEM deals are ever made purely on the anticipated return of future sales.  There are always expenses incurred by the manufacturer and the OEM is typically expected to pay for some, or all, of these charges.  It's reasonable to pay for engineering services or customization unique to the OEM's requirements, but OEMs often balk at paying anything beyond the cost of the SDK (Software Developers Kit). After all, they are confident they are going to succeed and the manufacturer should be equally convinced that future revenue and profit forecasts are achievable.

One common approach is that the manufacturer should refrain from development work that does not support their own market objectives. I.e. the results of the NRE need to be leveraged by the rest of their customer base.

NRE costs such as hourly charges for developers, QA and project managers should be agreed upon beforehand. I.e. what the manufacturer will charge the OEM if asked to make changes to the software that are specific for the OEM.

If the agreement allows the manufacturer to sell the results of the NRE to other customers, the OEM that financed the development should be compensated.

The results of NRE need continuous upgrades over time. In addition to establishing a basic support fee structure for the life of the agreement, the agreement must specify who pays for future development and upgrades of the NRE work.

There are two approaches as to who owns the results of the NRE work.

  • The intellectual property (IP) resulting from NRE is owned by the manufacturer. This is done to prevent ambiguities re. ownership and simplify product management. In this case, limitations are usually placed on how the IP will be available to other OEM's. One such limitation can be a time limit where other OEM?ing companies will not have access to the IP for a couple of years.
  • The intellectual property (IP) resulting from NRE is owned by the OEM and the IP will not be available to other OEM?ing companies. This option is the exception rather than the rule.
Support

The support the OEM receives from the manufacturer needs to be clearly defined in the OEM agreement. The agreement should include a clear statement of:

  • Who supports the OEM's developers and who supports the OEM's customers.
  • The support costs the OEM is obligated to. Are they per incident, hourly, or per annum?
  • What problems are covered by the support agreement? For example, if the OEM creates a bug when tinkering with the installation script, is this covered in the fixed price support costs?
  • What are the escalation procedures and turnaround time to get a problem resolved if the OEM cannot resolve an issue? A well structured support system is something that the manufacturer can charge for. OEMs don't like paying for this but they get better support this way.
Training

The OEM agreement should detail the extent and frequency of product training. Some options are per quarter, per release etc. This includes training Developers, QA, Operations, Customer Support, Product Managers and Sales.

Disputing Issues

The OEM agreement should specify that when dealing with technical issues that are not covered by the OEM agreement that people from each side will come to an agreement on the relevant issue.

It is common to include clauses incorporating binding arbitration in the event of a business disagreement to limit mutual financial exposure to expensive legal proceedings.

Termination and Rights of Survivorship

Most agreements include an 'at will' termination clause that allows either party to cancel the agreement with reasonable notice.

The agreement should detail what happens if the manufacturer stops developing or supporting the software or even goes out of business. One option is to agree that the manufacturer will sell it to the OEM or at least offer a first right of refusal to buy the technology. The cost for the former should be predetermined.

When OEM'ing technology, one of the issues that needs to be considered is what happens if either of the sides of the agreement change ownership. For example, what happens if the manufacturer gets bought out by another vendor who competes with the OEM?

Escrow

Some OEM agreements include using an escrow service. An escrow service is used to deposit the source code and is perceived as an insurance policy in case the manufacturer fails to fulfill their commitments. There are several issues with escrow services:

If for whatever reason the OEM ends up with the source code, will they be able to devote the resources to take the code, understand it and start maintaining it?

Escrow services will only benefit the OEM if the code that was deposited is really the code that is needed to compile the product and is up to date. To verify this, the escrow service should provide a verification service where they take the code and the associated build instructions and build the product and do basic testing in their labs. This can incur a significant cost that must be taken into consideration. Without verification, the OEM can't really know what the manufacturer deposited with the escrow service.

With input from Jim Kuciel, Director, Business Development,Peribit Networks, Inc.
jkuciel/delete-this/@peribit.com.
 

This article and its contents copyright (c) 2004 by Daniel Shefer

Daniel Shefer

Daniel Shefer

Daniel Shefer is Director, Product Management at Warp Solutions. Contact him at DS_PM@spamex.com.

Looking for the latest in product and data science? Get our articles, webinars and podcasts.