How to reduce product development costs in your company

product development costs

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 scale. When you sell a hundred product 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.

3 Cost reduction strategies that don’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 cost is using low cost knowledge worker resources.  Interns, students and consultant that charge below market rates, are all example 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 rational 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 cost 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’s 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 increasing cost and risk. Often, these low cost knowledge workers never successfully completed the work.  

Even in the cases were the work was completed, there was some other flaws in the product that prevented the work for being used. For example, itwas 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 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: time when workers have nothing to do
  • Increase in bottlenecks: 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 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 studied had product development budget that charged 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 that 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 where 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” have 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.  

3 Cost reduction strategies that work in business

  • Using true experts
  • Using reference design
  • Working with teams that have a 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 too. 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 these 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 cost and risk 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.

Read more:  How to uncover massive business opportunities on LinkedIn free

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 us 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 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 a reference design.  Instead, assign the task of finding the reference design and do not allocate 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 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 a 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 project per year and are learning quickly.  They have well developed procedures, cultures and communication system.  It is not realistic to expect a small company to build the same kind of infrastructure on a 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.

About the Author:  Steve Owens, Founder and CTO of Finish Line Product Development Services, has over 30 years of successful product development experience in many different industries and is a sought after adviser and speaker on the subject. Steve has founded four successful start-ups and holds over twenty five patents.   Steve’s insight into the product development process has generated millions of dollars in revenue for start-ups and small businesses.  

I am Adeyemi Adetilewa, a copywriter and a B2B/B2C writer with a passion for all things business, finance, marketing, and technology. I am also the founder and editor-in-chief of IdeaPlusBusiness.com, a B2B/B2C community for entrepreneurs.

Site Footer

27 Shares
Share8
Tweet
Share19
+1