6 Practical Ways to Reduce Product Development Costs in Business

Photo of author
Written By Steve Owens

Big companies have the luxury of scale. When you sell millions of a product, even a few dollars per unit is a big product development budget.

Small companies in niche markets do not have a scale. When you sell a hundred products per year, even $100 per unit is often not enough margin to pay back product development costs. 

Small companies need to implement strategies that keep product development costs to a minimum without increasing the risk of product failure. Some strategies work and some do not.

By “work” we mean the strategy reduces cost without increasing development risk. Just reducing cost is not enough.  

Product development is risky, and if the product does not make it to market, then all development cost is lost. The trick is to choose strategies that reduce risk and cost.

Our work with hundreds of small companies over more than a decade has shown us that some cost reduction strategies work, and some do not.

Product development costs: 3 cost reduction strategy that doesn’t work in business

  • Using low-cost knowledge workers
  • Doing everything in-house
  • Skipping steps in the product development processes

Strategies that won't work in business

1. Using low-cost knowledge workers

A  common strategy small companies use to reduce product development costs is using low-cost knowledge worker resources. Interns, students, and consultants that charge below-market rates are all examples of this strategy.

You would think that the old adage of “if it sounds too good to be true…” would be sufficient to ward off any consideration of this strategy.

But alas, it is much more common than common sense would predict. More than 90 percent of a study group had tried this strategy at least once.

There are all kinds of the rationale for believing in this strategy:

  • I have no overhead, so I can charge a lower rate
  • People earn less in (China, India, etc), so we can charge less
  • I need the work experience, so I am willing to work for less
  • Our students are learning as they work, so we do not need to charge

Work knowledge is a commodity subject to the laws of economics no different than any other commodity. The price of a commodity is dictated by what the market is willing to pay not how much it cost to produce.

The law of supply and demand would dictate that any arbitrage (a price below what the market is willing to pay) would be small and short-lived.  

A barrel of oil cost the same regardless of where it is manufactured. Low-cost producers don’t say “hey, only costs us $4 a barrel, to produce, so we will only charge $8”.

Nor can a high-cost producer tell the market, it cost me $100 a barrel, so I need you to pay me at least $200. If someone offered services below what the market is willing to pay, then demand would quickly rise.  

They would be overwhelmed with work and raise prices as a result of this increase in demand. The supply and demand would come into equilibrium through market pricing.

It is true that some people run into luck. They find an amazing deal. Luck, by definition, is an outlier, not a strategy you can choose.  

If you find luck, then good for you. However, odds are (literally) that you will find equal portions of good luck and bad luck. Luck is not a strategy, and anyone trying to convince you that it is your lucky day should be viewed with great skepticism.

Focusing on a strategy of finding substantially lower-cost knowledge workers is a strategy of luck. It is wishful thinking.

In our study, paying less than the market rate for knowledge workers always resulted in increased cost and risk. Often, these low-cost knowledge workers never successfully completed the work.

Even in the cases where the work was completed, there were some other flaws in the product that prevented the work from being used.

For example, it was the wrong thing to do, not documented, did not meet the requirements, was too unreliable, etc. Instead of trying to find the lowest cost, small companies should focus on the highest value.

2. Doing everything in-house

In our study, a substantial number of small companies chose to never outsource anything. This strategy correlated strongly with an increase in cost and risk when compared to those small companies that chose to outsource all product development or a combination of in-house and outsourcing.

This correlation should come as no surprise. It is very difficult for a small company to have the resources needed to be world-class in product development.  

Small companies typically have long product turns. That is, they develop new products every five or 10 years as contrasted with every year, or less, with larger companies.

This lack of frequency means:

  • Less opportunity to learn: less mature processes and decision making
  • Less likely to attract top talent
  • Underutilized resources: the time when workers have nothing to do
  • Increase in bottlenecks: the time when one worker has too much to do
  • Less innovation: smaller, less diverse team when compared to outsourcers

When surveyed about their reasons for keeping everything in-house, the three most common responses were:

  • Maintaining confidential information
  • Cost
  • Believing no one understood their product and/or technology

Keeping your information confidential is important. However, in our 15 plus years of working with small companies, we only know of one instance where confidential information was compromised, and the culprit was an employee, not a vendor.

In a matter of days, the company was able to get a restraining order, and very limited damage was done if any at all.  We are unaware of any systemic problem in the US with the theft of confidential information, especially in small companies.

Furthermore, we are not aware of any study that shows that only giving access to employees is substantially less risky than including vendors.  Often, small companies have very unsophisticated cost accounting systems.  This is especially true when it comes to product development in small companies.  

Indeed, many of the companies in our study see the product development budget as only including the external cost, ignoring the cost of the knowledge worker (the employees) that make up 99 percent of product development cost.  

When employees believe they are “free”, they are unlikely to decide to outsource anything for any cost. The best small companies in our study had a product development budget that charged the true burden cost of employees to the projects.  

Many small companies believe that no one can possibly know what they know about their industry and/or technology.  

No doubt this is a true statement – especially for small companies in niche markets. The fallacy comes about when they extend this thought to “therefore, no one can help us”. 

Products are made up of technologies that are unique to a company/industry and many that are not.

Many products share common technology, even if they have a few that are completely proprietary. For example, UI, power supplies, enclosures, sensor, firmware, WiFi, etc.

Further, developing products, as in the management of product development, is a technology in and of itself. No one can be an expert in everything.  

There is evidence to suggest that it is unwise to outsource core activities. Those activities define your competitiveness and for which you can be world-class.

However, products are composed of core technologies and non-core technologies. Trying to be world-class in everything will eventually result in being world-class at nothing.

3. Skipping steps in the product development processes

As part of our study, we developed root causes for failed projects. More than ninety percent of the root cause of product development failure was a direct result of skipping some part of the product development process.  

Many of these failed projects did not have a requirements document.  Few had completed a formal Design Verification Test before launch. Further investigation into why steps were skipped:

  • Lack of knowledge on the product development processes
  • Believing that skipping steps will reduce cost
  • Believing that skipping steps will save time

As stated before, small companies have long product cycles. So long, the team that completed the last development has moved on. At the very least, the “lesson learned” has long been forgotten by the time a new product is on the table again.  

All of these results in a difficult continuous improvement program. Often, the same mistakes are made over and over again. A decision to skip steps in the product development processes almost guarantees that all the work after this decision will need to be repeated.

Product development costs: 3 cost reduction strategy that works in business

  • Using true experts
  • Using reference design
  • Working with teams that have mature development processes

Strategies for business success

1. Using true experts

It should come as no surprise that a person with a lot of experience, education, and proven ability is going to outperform a novice.

True experts, even if they charge more per hour, will reduce cost and risk.  

Our study showed a strong correlation between project success and the willingness to seek out and use experts.

One subtle point:  Product development management is a discipline as well.  For a small company, it is likely the most important expertise to have access to.

Every project needs to be staffed with a product development expert just as every sports team must have a coach. One common error in working with experts is using them for tasks that they have no expertise in.  

Experts, by definition, have very narrow and deep knowledge. That is, they understand one subject very well, and rarely have even average skills in the other subjects. But, they are often happy to opine on this subject as if they are.

They can also suffer from the “if you’re a hammer, everything looks like a nail” syndrome.  Experts should not be given the responsibility to choose the concepts that will form the product solution.

Bring them in the project after completing requirements and conceptual design. Experts are good at doing, but not so good at deciding what to do.

2. Using reference design

One of the easiest ways to decrease development costs and risks is to use reference designs. 

References designs are pieces of other products that have already been proven to meet the requirements of a new product. Using reference designs can be like starting half done.

No surprise, we found a very strong correlation between the use of reference design and project successes. Most small companies in our study had no issues with choosing this strategy but have more difficulty with actually finding these designs.  

Here are some places to look:

  • Non competing companies who have products with reference design you could use in your product
  • Product development companies. Look for ones that specialize in small company product development
  • Reverse engineer other products

Many engineers are reluctant to use reference designs. They are very good at rationalizing away the benefits of the reference design.  The industry even has a name for this syndrome: NIH (Not Invented Here).

Culturally it is difficult to overcome this syndrome, but here are a few points:

  • Do not expect to assign a design task to an engineer and then expect him to switch to reference design.  
  • Instead, assign the task of finding the reference design and do not allocate a budget for a new design until it is clear this task will fail.
  • Reward team members that are successful in finding and using reference designs.
  • Incorporate reference design owners into the team
  • Communicate the true cost of developing the design and the economics/ROI of the development project to the team.  
  • Define success as a monetary return on investment and not technical achievement

3. Working with teams that have mature development processes

The highest correlation to project failure in our study was a failure to manage the product development processes.  

Many small companies in our study attempted to develop products with a single engineer working in isolation. Most missed key opportunities to reduce costs and risk simply because they did not have stage gates to discover these opportunities.

It is often difficult for small companies to develop teams with mature processes. They just do not get enough opportunities to create and practice these processes.  

Even “seeing” the value of these processes was difficult for many in our study group. It is not uncommon for these companies to view product development more like an artist creating a painting than business processes with measurable outcomes that have defined economic value.  

Some companies in our study had made attempt after attempt without success and still cling to the same old ideas. Past behavior is the best indicator of future behavior.  

If you want to be successful at any endeavor, find a team that has already produced this success. Ideally, one that has been successful over and over.  

The converse is also true. If your team has never produced success, then it is less likely they will do so in the future. Here are some tips to help find and build successful teams:

  • Resist the temptation to switch teams. Product development is risky and no team can win every battle, even if they win every war.   
  • Starting over every time something goes wrong is not a winning strategy. Learning from each experience is all you can realistically ask of any team.
  • Identify and build a bridge to a outsource product development company that specializes in small companies. These development companies are doing dozens of projects per year and are learning quickly.  They have well-developed procedures, cultures, and communication systems.  
  • It is not realistic to expect a small company to build the same kind of infrastructure on one project every five-year schedule.
  • Hire for your core. The one thing you can be best in the word at. You are much more likely to get world-class long-term employees which is a key necessity in building good systems for product development. 

Disclaimer. The views and opinions expressed here are those of the authors. They do not purport to reflect the opinions or views of IdeasPlusBusiness.com. Any content provided by our bloggers or authors is of their opinion and is not intended to malign any organization, company, individual, or anyone or anything.

For questions, inquiries and advert placements on the blog, please send an email to the Editor at ideasplusbusiness[at]gmail[dot]com. You can also follow IdeasPlusBusiness.com on Twitter here and like our page on Facebook here. This website contains affiliate links to some products and services. We may receive a commission for purchases made through these links at no extra cost to you.