Cardinal Peak

Minimizing Development Costs on Low-to-Mid Volume Products

My last post suggested ways to reduce parts costs in a low-to-mid volume product. This post explores ways to keep development costs low while still creating a cost-effective product.

You can’t escape the fact that it takes money to create a low cost product. It is estimated that the first version of the iPhone had COGS (cost-of-goods-sold) of around $200. That is very impressive given all of the included features. However, it is also estimated that Apple spent around $150M over 30 months to design the iPhone. In addition to that direct investment, Apple was also able to entice their component vendors to spend huge amounts of money to design custom ICs for the device.

Our clients typically do not have that kind of money to invest in a new product. (Although please give us a call if you do!) And even if they did, it often doesn’t make business sense to invest a lot of money in upfront engineering in order to reduce COGS, unless you have high volumes. So it’s more typical that we are performing a balancing act between the budget available for engineering, and meeting the target COGS that is necessary for a successful product.

Here are some guidelines that we use to keep development costs low and still create cost-competitive products.

• Start with solid requirements definition.

The most successful design projects start with clear product requirements. Starting a project with known requirements (and not changing them during the product design phase) is the best way to minimize development costs. Of course, most projects aren’t so lucky as to have perfectly defined requirements. It usually takes the management team some time to balance the requirements, development cost targets, product cost targets, and project time-lines. Still, the more quickly you can define what the product has to do, the less the engineering team will thrash—and thrashing costs money.

• Keep the schedule short.

This is pretty obvious, but the longer a project takes, the more it costs. We’re big believers in rapidly getting a solid, but perhaps less-fully-featured, product to market. In addition to keeping development costs low, this strategy also allows you to quickly gain feedback from the market and focus investment for an enhancement release on the most important areas.

• Hire an experienced design team.

An experienced design team will put together a more accurate project schedule and budget, is more likely to meet the project deadlines, and is better prepared to overcome the inevitable hurdles along the way.

• Explore the trade-offs between custom hardware design and using off-the-shelf components.

For low to mid-volume products, using off-the-shelf subsystems and components can be a very tempting way to reduce development costs. However, off-the-shelf subsystems (such as single board computers, power supplies, cases, etc) can be quite a bit more expensive than custom designed hardware. It is worth a thorough investigation of what solutions might exist to reduce your design effort yet still meet the product cost targets. Small hardware vendors may be willing to modify their products to fit your application and costs, and may not charge NRE to do this. As with all vendors, negotiating goes a long way towards minimizing your costs.

• Put together a hardware prototype early in the project.

In most product development projects, the software effort is larger than the hardware effort. As such, we structure projects to give the software engineers as much time as possible to work on the target hardware. This maximizes the time available for low level hardware and software bugs to be found and resolved.

• Start with reference designs and evaluation boards where possible.

Most semiconductor products have reference designs and evaluation boards available to give you a head start. For a low-volume product, these designs can be especially helpful to minimize development time.

• Use the vendor Field Application Engineers

IC vendors usually have FAEs that will help integrate their products into your design. FAEs are usually willing to do schematic reviews, help with software drivers, and even help debug parts of the system if necessary. These folks increase the chance of a successful first revision design and can reduce the development time of a product.

• Use open source software where possible.

We are big advocates of open source software here at Cardinal Peak. There is huge opportunity for reducing the development time and costs in a project by using open source modules. However, it is not easy to properly integrate open source software (especially real-time or embedded modules) into a complex product. To properly take advantage of the open-source benefits, a team that has experience with this is imperative.

Mike Deeds is an expert in embedded systems hardware and software engineering, including FPGA design and computer architecture.

Designing Low-to-Mid Volume Embedded Products Cost-Effectively

I take it as a given that when a client approaches us with a new embedded product idea, they will require a very demanding set of features and a minimal price tag. The “minimal price tag” part always applies to the development effort required. For products with a hardware component, it also applies to the product’s cost of goods sold (COGS).

Companies developing high volume consumer products can afford to spend quite a bit of engineering effort to reduce their COGS, since the development costs will be amortized over so many units. However, many of our clients sell low-to-medium volume products—in the range of 1,000 to 10,000 units per year. This volume is not high enough to leverage massive economies of scale, yet a clever design team can still create a very successful and cost effective product if some care is taken during the design phase.

There’s no magic bullet to reduce COGS in the low-to-mid volume range; it’s mostly common sense, coupled with the experience that comes from having built products in this volume range before. Here are some ideas for minimizing COGS:

• Use stocking distributors, but negotiate.

Stocking distributors can help reduce both product costs and development costs. Distributors have much higher leverage with IC suppliers than a small company, which can help reduce lead times and solve supply problems. One big advantage is that distributors often give forward pricing or high volume pricing (even at low volumes) that can significantly lower your product’s cost. The big ones (Avnet and Arrow) also have dedicated resources that can suggest technology solutions you might not be aware of. They can also facilitate deals with small 3rd party subsystem vendors, such as display manufacturers. As with any vendor, you must negotiate with these companies in order to see the best prices. They are in business to make a profit, but they can also act as a facilitator in negotiating with the end suppliers.

• Talk with vendors to learn about new products.

IC vendors always have new products in the pipeline. These are usually lower cost and higher performance than existing product. Of course there is risk in using a new product, especially if there is a lot of software support required. You need a close vendor relationship in order to successfully integrate a new product.

• Use ICs that are derivatives of high volume consumer products.

Many high volume consumer electronics ICs are custom designed for a certain customer or retail market. Large IC vendors such as Texas Instruments and Intel frequently offer embedded products that are derived from their consumer products. These are usually low cost, but very high performance products that are guaranteed to be available for many years. One example is the Intel Atom family. The consumer versions of the Atom chipset can disappear at a moments notice, but the embedded versions will be around for at least 7 years after release.

• Try to use stocked parts.

Many component suppliers have wonderful parts that would be a perfect fit for your product, but not all of these parts are actually available in small purchase quantities. Your best chance of a sustainable supply chain is to use parts that are currently stocked. Maxim is a company that is notorious for having lots of great parts in theory, but a much smaller subset of parts that are actually regularly manufactured and available for small purchase quantities. My colleague Todd refers to these types of parts as being made out of “Unobtainium”.

• Negotiate with your vendors!

This is a no-brainer, but one that engineering teams are not always comfortable with. Competition between suppliers is one of the best ways to reduce product costs. A lower cost competitive bid is your best negotiating position.

• Second-source your highest cost components, if possible.

Second sourcing components or subsystem modules creates a permanent negotiating position with your suppliers. A great example is to use a single board computer in a open form factor, such as COM Express. Many vendors supply these modules, with lower cost versions coming out in the future.

• Continue to work the supply chain to drive down costs over time.

Concentrate your efforts on the highest cost components. Unlike high volume products, it may not be worth the overhead cost to squeeze out the pennies.

• Pick a Contract Manufacturer that is a good fit for your product and volume.

If you don’t manufacture your own products, you will need to select a CM; this is an area where “bigger” definitely doesn’t mean “better”. It may be difficult to get and keep the attention of a large CM. It is more likely that a large CM will slip your deadlines in favor of their larger customers. You will be able to push on a small CM when you need to.

These are some of the guidelines we use to minimize costs for low to mid volume products. Part 2 of this article will cover minimizing development costs while still producing a cost-effective product.

Mike Deeds is an expert in embedded systems hardware and software engineering, including FPGA design and computer architecture.

More on Patents

I had intended to give the indemnification issue a rest.  But then the following caught my attention this morning:

One big difference between patents and other kinds of intellectual property, like copyrights and trademarks, is that patent-holders who want to sue someone for infringement don’t have to show that their patents or their products were actually copied by the defendant. In fact, the issue of copying is legally irrelevant when determining whether or not someone infringed a patent. (It is relevant to willfulness—more on that below.) The flip side of that rule is that a defendant company can have a really nice story about they did their own research, invention, and development—but it doesn’t matter one bit, legally speaking. Such “independent invention” stories are no defense.

“No one seems to know whether patent infringement defendants are in fact unscrupulous copyists or independent developers,” writes Lemley. So he and his partner went on a hunt looking for copycats in patent disputes. How much copying did they find? Not much at all.

(Joe Mullin’s whole post is excellent; thanks to Brad Feld for calling attention to it.)

Which underscores my earlier point: Patent lawsuits don’t usually arise because of unethical behavior on the part of the engineering team. And therefore offering indemnity protection against these kinds of cases is not a financial risk that we can or should bear.

I’m not primarily out to agitate for reform of the patent system, but I agree with calls for adding an independent innovation defense. Such a reform would help swing the effect of the patent system back toward its original intention, which was to encourage innovation.

Howdy Pierce is a managing partner of Cardinal Peak with a technical background in multimedia systems, software engineering and operating systems.

Providing Indemnification for Patent Infringement

Cardinal Peak recently had an unfortunate “first”: We chose to walk away from a promising engineering engagement because we couldn’t reach agreement with our customer about an indemnification clause.

Let me give a little background before diving into the issue. “Indemnification” technically is the legal obligation to compensate a business partner for losses that the partner might suffer during the performance of a contract.

To give an example, it’s common for professional services providers such as Cardinal Peak to indemnify our customer in the event of a lawsuit alleging that we copied a third party’s source code into the product we engineered for the customer. In this case, if the third party were to sue the customer for copyright infringement, then Cardinal Peak will be responsible for both the costs of the legal defense, plus the costs of any settlement that would arise. You can read a little more background (albeit with a testing-oriented slant) here.

Not to suggest that we take any financial risk lightly, but we are generally okay with providing this type of indemnity protection to our customers, because we control our own actions and we’re confident we won’t behave unprofessionally.

In this case, however, our customer insisted we provide indemnification in the case where we were to unwittingly infringe a third party’s patent. In my view, this is a very risky form of indemnification to offer.

I am aware of too many examples where existing patents cover relatively obvious methods of solving some particular problem. (A portion of our services business involves expert services work in support of patent litigation—so we’re all too familiar with the ugly details, although we can’t speak publically about the cases we’ve worked on.) It seems all too possible that, without any foreknowledge of an existing patent, a competent engineer might independently hit on an already-patented method for solving a problem. And if this were to be the case, the amount of money required to mount even a trivial defense would put a small firm like Cardinal Peak out of business.

There’s also a quirk of the US patent system that is worth pointing out: To my understanding, it is not even theoretically possible to guarantee a priori that you don’t infringe a patent. Even with a complete patent search and the best legal advice, under our system, the only way you can determine infringement is through a jury trial.

So really there’s no way for a firm like Cardinal Peak to be absolutely, 100% certain we don’t infringe a patent.

One way to look at this is that there is inherent financial risk in releasing any high-tech product. The form of risk that first comes to mind is when a high-tech company invests a lot of money in developing a product, just to see it flop when it comes to market.

But market failure isn’t the only form of risk in product development: Liability for unwitting patent infringement is another. (Unfortunately, it seems to be a growing risk!) Just like market risk, patent infringement liability is a risk that should be borne by the company that also stands to reap the rewards from a successful product—and that’s usually not the provider of your engineering services. After all, rarely will the service provider own the intellectual property that results from their work for hire.

I’m not suggesting that Cardinal Peak would never offer indemnification for unwittingly infringing someone’s patent. But there would have to be some upside. It is a risky move for us, and we would want to see some extra return that justifies taking that risk, whether that would be in the form of royalty participation in the product, or IP ownership of whatever is developed.

What do you think? This is an issue that my partners and I continue to discuss, so we welcome your comments.

Howdy Pierce is a managing partner of Cardinal Peak with a technical background in multimedia systems, software engineering and operating systems.

The Cost of an Engineer-Hour

As all good project managers know, there are three dimensions to any engineering effort:

• The features of the product: What does the product do and how does it look? (For sake of simplicity, let’s include “quality” as a product feature.)
• The schedule on which the product is produced: How fast does it get to market?
• The cost of producing the product: How much money does your company have to invest in bringing the product to market?

Before we started Cardinal Peak, my partners and I had all spent many years as engineering managers inside of various companies. To me, it always seemed that I was most visibly measured on the first two dimensions: features and schedule.

To the extent that I was measured on the cost axis, the companies I worked for would normally use “number of heads” as a loose proxy for “dollars spent to bring this product to market”. But I had a lot less control over the number of heads assigned to my team than I did over the other two dimensions, and as a result I believe that perceptions of my success were influenced almost entirely by how my team met our goals in the first two dimensions.

So I guess it’s not surprising that back then I only had a vague idea about how to assign a dollar value to any engineering team’s most precious resource: the engineer-hour.

The somewhat embarrassing truth is that previously I didn’t think about dollar costs too much. I had heard from other managers that an engineer cost my company about $220,000 per year, once you accounted for all the indirect costs like benefits, IT, rent, HR and administrative support. (This specific example comes from Silicon Valley in about 1998, in a relatively high-benefit, high-support environment.)

But I couldn’t really derive the annual engineer cost from any hard data, because I wasn’t directly responsible for any of those expenditures. (I did have a degree of influence over a new hire’s starting base salary. After that, however, everything was relatively programmed: Raises were given within parameters set by the HR department and company management, as was the bonus program.)

I don’t want to make the mistake of projecting my own personal naïveté onto others! But this conversation comes up occasionally, usually from engineering managers for whom it is self-evident that the cost of internal hiring is so much lower than the cost of hiring a firm like Cardinal Peak.

So on an airplane flight recently, I pulled together this spreadsheet, which you can use to compute your own internal cost for an engineer-hour.

I have pre-filled certain cells with reasonable values for a relatively low overhead, mid-benefit engineering team located in Colorado. I’ve tried to model the compensation package given to a competent senior engineer who has 8-12 years of experience. This isn’t your team lead, but neither is it the young gal you just hired with a Master’s degree. Instead, I’m trying to model the engineer who will form the backbone of your team—the  workhorse who will show up on time, focus on work, and reliably crank out features.

Your situation may be different, so feel free to play around with the cell values to see what your own costs are.

Howdy Pierce is a managing partner of Cardinal Peak with a technical background in multimedia systems, software engineering and operating systems.