Frugal Engineering

7 Jun 2010 Sandeep Mehta
In the same theme as Reverse Innovation and may be Borderless Innovation, Strategy + Business has an article on The Importance of Frugal Engineering.

The central tenet behind every frugal engineering decision is maximizing value to the customer while minimizing nonessential costs. The term frugal engineering was coined in 2006 by Renault Chief Executive Carlos Ghosn to describe the competency of Indian engineers in developing products like Tata Motors’ Nano, the pint-sized, low-cost automobile.

Typically, when a well-established automaker designs and builds an inexpensive car, the company’s thinking is biased by decades of practices and procedures, and by its relationships with employees, customers, and suppliers. The approach reuses existing designs and relies on existing components. In essence, these companies start with a more expensive car and focus on ways to make it cheaper. That may count as a form of cost cutting, but it is not frugal engineering.

Instead, frugal engineering is an overarching philosophy that enables a true “clean sheet” approach to product development. Cost discipline is an intrinsic part of the process, but rather than simply cutting existing costs, frugal engineering seeks to avoid needless costs in the first place. It recognizes that merely removing features from existing products to sell them cheaper in emerging markets is a losing game. That’s because emerging-market customers have unique needs that usually aren’t addressed by mature-market products, and because the cost base of developed world products, even when stripped down, remains too high to allow competitive prices and reasonable profits in the developing world.

Clearly, going after new markets and new customer demographic can be better achieved with a clean sheet approach.  Of course there is also a cost associated!  It is expensive to start with a clean sheet.  Each R&D organization will need to balance between disruptive and sustaining R&D.  The article suggests three main ingredients for disruptive projects:
  1. Cross-functional teams
  2. Non-traditional supply-chain
  3. Top-down support
I think I would add one of my own: Processes, tools and Metrics to ensure disruptive projects do not disrupt all the R&D.  What do you think

One thought on “Frugal Engineering

Leave a Reply

Your email address will not be published. Required fields are marked *