Design Features for Next Generation Technology Products

Related Tools & Articles
  • Discussion Forum
    "The Massachusetts Institute of Technology (MIT) has posted another FREE open courseware offering regarding innovation - this one is entitled "How to Develop 'Breakthrough' Products and Services"..."

    Contribute to this Discussion

    By Prakasan Kappoth

    Abstract

    Today's industries, particularly those that relate to high-tech products, needs to undergo changes because of the variety of external fluctuations – the complexity of a global market. Changing customer requirements, fluctuating market trends and market segments, integrating several technologies, and linking with multiple industries to create a bigger consumer spectrum has made the traditional way of conceiving product features difficult.

    Technology advancements in the telecommunication, wireless and electronics industries are changing the way the automotive industry satisfies its customers. Customer requirements of security, comfort, and resource optimization are forcing these industries product companies to design unique features catering to multiple user needs in more than one market. This case study focuses on a process to identify innovative features using the Theory of Inventive Problem Solving (TRIZ) techniques – navigating through design for a telematics and fleet management product.

    The specific TRIZ techniques used include:

    Background and Introduction

    Product development is becoming more important, even for service organizations, across the globe. Companies, especially in India and China, are playing an important role in bringing products to the marketplace faster. Technology companies, including start-ups, outsource portions of design and development to service companies. The expectation from these organizations is to provide the services for identifying the suitable market segment and creating new features in every phase of a product's conceptualization.

    Some characteristics of technology service companies include:

    The present approach used by service companies for product realization revolves around the technical knowledge and expertise of individuals using traditional product requirement design tools and processes. This involves discussion, research and heavy interactions with industry experts to identify product requirements and define the marketplace.

    The technical background and scope of this project follows:

    Challenges

    Multiple Technologies and Market

    The product companies in the telematics/fleet management (and related) space offer innovative products catering to specific, set customer needs. Many of them are for location tracking, infotainment, security, theft and espionage prevention, and parking assistance. A plethora of new technologies, like satellite navigation, telecommunications (GSRM, WCDMA, WiFi, WiMax), weather forecasting systems, intelligent traffic management and remote diagnostics impact the product features customers expect. Additionally, the convergence of technology is bringing about integrated features, saving costs and increasing usability. As the customer requirements are fast changing along with technology, defining next generation features for a product in this space requires an understanding of emerging technologies and the knowledge about present market opportunities.

    Limited Time and Knowledge About Domain

    The second important challenge from a service organization perspective is limited time and knowledge about the domain. Understanding current and emerging technologies, existing market players, consumer and technology trends, and then realizing the new features, consumes too much time if attempted in a typical product requirement design framework.

    Cost Reduction

    Cost reduction is an important phase of product design. Apart from deriving new and innovative features, their implementation of them – without cost increase – is critical to a product's lifecycle. The causes of cost are many – hardware, components, tools, service and support from third party vendors. The big challenge is to reduce the cost of hardware and components that constitute the product as this is the deciding factor in producing large volumes of the product.

    The other common requirement of present day product design is keeping multi-functionality. Adding more functionality often means adding hardware and software complexities. Contradictions arise when scaling up functionality while simultaneously keeping the costs low. Addressing these contradictions in traditional product development processes is challenging.

    Product Architecture: Reconfigurability and Modularity

    The present trend is to have various flavors of the same product so that it can be sold to satisfy slightly varying customers needs while retaining the same basic architecture. This brings the challenges of modular architecture that fit with all customer needs in the telematics/fleet management market. As cost is an important consideration, designing multiple products for a varied customer base is not possible.

    Approach

    TRIZ offers several techniques to aid structured creativity and innovation. The following TRIZ systematic innovation techniques are most suitable for this project and enabled a process flow to work toward overcoming the previously mentioned challenges.

    1. System operator (9-windows)
    2. Ideal final result (IFR) and laws of technology system evolution2
    3. Contradiction matrix

    Although this case study is based on the implementation for a telematics/fleet management product requirement design, this process can be generalized and applied to any product requirement design in a service organization.

    System Operator (9-windows)

    The system operator helps think about time and space in a simple manner. The 9-windows technique identified several elements associated with user needs, the current market, technology, user constraints, and also identified various resources available around the system. Nine windows was applied in two phases, each time identifying an actor associated with the product and determining the need and perspective.

    The following actors were identified based on the expected product usage and the market in which the customer wanted to sell their product:

    1. Vehicles: There are different automotive market segments that use telematic products. From a preliminary background search for the existing products and companies, combined with information on the company's target market, the most important vehicle categories:
      1. Trucks and trailers: The need for monitoring the fleets on the ground by the fleet management company has pushed the telematic product sales in the recent past. This segment requires capabilities ranging from a GPS-based navigation system to advanced on-board remote diagnostics. Another requirement is security monitoring of the goods being carried. Sensors-based products are available for monitoring the goods from the start to end of the journey.
      2. Rental cars: Many rental cars are already equipped with GPS navigation systems, infotainment systems and other services associated with passenger comfort and security. Remote customer assistance services, such as OnStar™, are becoming a trend in the rental car segment.
    2. Drivers: Most of the features in telematics-based products are indirectly targeted to assist the drivers of the vehicle. Features like navigation, weather data, vehicle health notification, traffic assistance, fuel consumption information and location tracking have been developed to assist the drivers. In each vehicle categorization, the requirements change accordingly.
    3. Fleet management company: The fleet management company, that the vehicle belongs to, is also an actor. Managing thousands of vehicles on the road is a challenging task, and this market potential has driven the creation of a large number of products to satisfy this customer base.

    System Operator – Phase 1

    In the system operator phase shown in Figure 1, each actor was considered as part of the present system, and includes analysis of the elements and functions associated with the vehicles, fleet management company and drivers.

     Figure 1: System Operator Phase One

    This step of the system operator revealed several potential resources available at the super-system that are associated directly or indirectly with the vehicles, drivers and the fleet management company, and the evolution of needs in each user category. Eventually this brought forward features that could be derived for the product.

    System Operator – Phase 2

    Before starting the second phase of the system operator, data collected from the web search about the existing market players, products available and a few of the features offered to the customer were analyzed (narrowed to a search of specific markets and associated technology). Each helped identify the technology being used therein, features that most of the products offer currently. Figure 2 shows the features of the existing solutions in the present system and started looking at the constraints from each actor's (vehicle, driver and fleet management company) viewpoint. Phase two identifies better features than the current marketplace offers.

     Figure 2: System Operator – Phase Two

    From the application of the system operator in each perspective, a bigger knowledge base was created for the products, including the current constraints and unused resources available around the system in telematics and related areas. (See Figure 3.)

     Figure 3: System Operator Mindmap

    Extracting Resources

    Some of the available resources were either not used, or were used ineffectively.

    Constraints

    There are several constraints from the driver's perspective.

    At the end of the system operator exercise, new features were derived by associating the constraints, the sub-system elements, super-system elements (present and future) and the unused resources. The following describes one of the derived features.

    Proximity-based advertisement. A small on-board computer provides the driver information on the road – picture messages on a LCD screen share information on shops 200 meters ahead, the special discounts offered and directions. The existing mobile service provider will transmit the data. Directions/locations are determined through GPS coordinates controlled by the central server.

    Ideal Final Result (IFR)

    According to TRIZ, the ideal system is a system that does not exist yet. However, increasing the degree of ideality of a system is possible. New products, systems and methods being developed for the market clearly show the increasing ideality of functions.

    The IFR was applied by looking at the existing data captured from the web about similar leading telematic based products available in the market. As in a typical S-curve, existing product features can further travel to ideality, achieving more functions without extra cost or harm. In order to get the maximum benefit from applying the IFR, the best approach is to consider each defined actor and create one ideal final feature for all. The following tables describe this approach in detail.

    Table 1: Need – What Is the Final Aim?
    Immediately helping driver/passenger in case of accident
    DriverGet immediate help if accident occurs
    VehicleCollect the data about the accident – who is responsible and damage
    Fleet management companyKnow where the accident occurred, extent of damage and provide fixes

    Table 2: Need – What Is the Ideal Final Result?
    Immediately helping driver/passenger in case of accident
    DriverReal-time information about the accident goes to the people who will provide help
    VehicleSend the collected data of the accident and damage to someone about needed repairs
    Fleet management companyAutomatically inform the parties who will bring help to the passenger(s) and vehicle
    Table 3: Need – What Stops Us From Achieving the IFR?
    Immediately helping driver/passenger in case of accident
    DriverDriver/passenger may be badly hurt and/or unconscious
    VehicleOnly collects the engine health data and fuel-related data, but not when the accident happened; the collected data may not be related to the accident
    Fleet management companyHospitals, mechanics, police, etc. in the area are unknown

    Table 4: Need – How Can We Eliminate the Above Obstacle From the System?
    Immediately helping driver/passenger in case of accident
    Driver"Take out" the responsibility of informing the parties from the driver and have somebody else do that
    VehicleHave "somebody" inform the vehicle about the accident and then the vehicle collects data (such as engine health) itself
    Fleet management companyMaintain a detailed listing of police stations, hospitals, mechanics for all locations that the vehicle may pass through

    Table 5: Need – What Are the Available Resources?
    Immediately helping driver/passenger in case of accident
    DriverThe vehicle itself – the existing communication technology used in the telematics and fleet management products (such as GSM, GPRS, WiFi, CDMA), police station, medical services, ambulance, people, timer, clock
    VehicleThe data of airbag deployment and crash sensor data through OBD
    Fleet management companyGPS data received from the vehicle – to identify the location/contact information for hospitals, police, fire station and service technicians in the area where the accident occurs

    Current products available in the market offer features associated with safety and security for trucks/trailers, rental car customers, theft, loss of valuables, etc. Creating a feature that can further mature the functionality came from looking through the IFR framework and the law of technological system evolution.

    We found the following resources available to implement the safety and security features:

    For the safety and security of the passenger as the requirement while the driver is on road, without third party involvement the product that goes into the vehicle can sense the deployment of airbag or activation of crash sensor, and this data – along with the location data – can be sent to a central server. The data center contains a database with GPS coordination and the nearby police stations/hospitals/fire stations. Once a crash sensor or airbag data is received by this central server, the system identifies the police station/hospital and also the nearest service center from a directory created by the fleet manager/administrator.

    Along with the requirements for asset tracking for trucks and trailers, another feature involving the sensor network was derived. An external sensor network (any type of digital or analogue sensor for temperature, chemical leak detection, glass breaking sensor, proximity sensor, etc.) talks to the product installed on the truck and passes the information to the respective authority in case of a breach.

    Laws of Technological System Evolution

    The following known laws of technological system evolution were also looked at to ensure that the ideal final features correspond to the trends:2

    1. Law of increasing degree of ideality
      1. This primary law of system evolution explains the increasing degree of ideality in a technological system. The degree of ideality is related to the benefit-to-cost ratio.3 Considering the telematics and fleet management system, the law of increasing ideality is clearly visible in the current products available in the market. Many functions like location tracking, communication, data transfer has become less complicated and with multiple technology spectrum has allowed for the creation of new features at low cost. A typical GPS tracking system in a car integrated with digital entertainment and satellite radio is a good example of the increasing degree of ideality in this spectrum. This underlying law of increasing degree of ideality can be applied on each actor's (user's) needs for creating new unique features across the product. The following are some of the thought processes applied to forecast the future:
        • Location tracking may no longer be a "nice to have" system for a vehicle. The emergence of technologies like Wi-Max could bring down the cost of location tracking on a mobile phone.
        • A personal device may replace many of the user actions related to location tracking, personal entertainment, navigation, early warning systems, weather forecast, etc., more convenient and pre-programmed.
        • A vehicle will become a mobile networking node with more computer power integration, dynamically updating the configuration depending on the road condition, terrain and weather – all without bothering the drivers and providing more comfort and security for the driver.
    2. Law of transition to higher-level system
      1. This law explains the evolution of technological systems as the increasing complexity of a product/feature and its multi-functionality. This law was applied at the sub-system level, to identify whether any of the existing hardware and components can traverse further to higher level systems and achieve more functionality. The following sections of a telematics/fleet management product were considered:
        • Processor designed for single function achieves multiple features
        • Using internal bus to transfer data
        • Using the processing power to process data collected on-board, instead of sending to the remote location for processing
    3. Law of increasing the dynamism (flexibility)
      1. Product trends show that the typical process of technology system evolution is based on the dynamization of various components, functionalities, etc. Moving from a rigid mode to a flexible mode, a technology system can perform more functionality and also can adapt to the changing parameters and environment with ease. The following areas were looked at through the law of technology system evolution:
        • External product integration – plug-n-play devices interact with the vehicle to increase the functionalities
        • Vehicle satisfies other needs of driver, passenger – news, forecast, financial market statistics, virtual office
        • Vehicle communicates to the government – updates rules and regulations, report driver violations and security threats
        • Medical devices integrated in the vehicle check driver's and passenger's health – report to the doctor, hospitals

    Contradictions

    Cost Reduction

    The contradiction visible here is – we should implement maximum features derived and the cost of the product should not increase drastically. Incorporating maximum features will increase the need of high speed processing power, battery life, communication bandwidth, data storage capacity and other costs involved in their manufacturing, software development and testing. The result of compromise impacts the market opportunity for the product. The following shows the mapped results of this contradiction:

    What needs to be improved? Implement new features derived.

    Parameter 1: R&D spec/capability/means
    Parameter 6: Production spec/quality/means

    What is getting worse? Costs will increase.

    Parameter 2: R&D cost
    Parameter 7: Production cost

    Table 6: Suggested Principles From TRIZ Business Contradiction Matrix1
    What Needs to be Improved?What Is Getting Worse?Suggested TRIZ Principles
    Parameter 1: R&D spec/capability/meansParameter 2: R&D costTaking out, 2; asymmetry, 4; dynamization,15; enriched atmosphere, 38
    Parameter 1: R&D spec/capability/meansParameter 7: Production costRelative change, 37; parameter change, 35; prior action, 10; local quality, 3; universality, 6
    Parameter 6: Production spec/quality/meansParameter 2: R&D costMerging, 5; taking out, 2; cheap disposable, 27; segmentation, 1
    Parameter 6: Production spec/quality/meansParameter 7: Production costDynamization, 15; self service, 25; local quality, 3; prior action, 10; merging, 5; counter balance, 8

    From the suggested TRIZ principles, the following principles were most relevant:

    The current hardware architecture for implementation was based on two processors – one that takes care of the data processing and communication to the central server, and another that interacts with the vehicle OBD interface. By applying taking out (principle 13), a reduction in cost resulted in removing the processor required for vehicle interface, instead using another system to achieve that function. This approach led to a multi-processor architecture and introduced a low-cost processor that takes care of the vehicle interface functionality. Adding this component saved the BOM fourteen dollars. Prior action (principle 10) provided insight into pre-configured modules at the central server units. The concepts of policy based alarm systems, pre-configured database of location based service center, hospitals, and police stations were derived.

    Reconfigurability and Modularity

    During the process of new feature development, multiple customer segments were associated with a single product. Here, the challenge is not developing multiple versions of the products, but catering to different customer base.2

    What needs to be improved? Adaptability, flexibility, usability and configurability.

    The extent to which a system/object is able to respond to external changes. Also, relates to a system capable of being used in multiple ways or under a variety of circumstances. Flexibility of operation, use and customizability.

    What is getting worse? Ease of manufacturing.

    Issues related to manufacture, fabrication and assembly issues associated with an object or system.

    The technical contradiction matrix suggested segmentation (principle 1), other way around (13) and porous material (31). The following principles are relevant:

    The contradiction was a single product vs. multiple customers segment and different costs. The product should be sold to independent car owners, fleet management companies and rental car companies. In each segment, not all product functionality would be used by the customer. Using segmentation (principle 1), the idea to implement two PCB boards, one circuit board with the main components (processor) and the other for communications, configurable for various market needs, was suggested. This helps not only to meet the market needs, but also to maintain/configure the product with changes in communication technology. This reduces the design time as well as simplifies the upgrading of products in the field. Using the other way round (principle 13) helped configure the product for various user displays. Keeping the existing architecture, it is possible to use different kinds of display from simple LEDs, low-cost alpha-numeric displays to a high-end touch panel.

    Output

    The objective of this project was to create a process that can be reused with TRIZ techniques in product development in the similar scenario. With time and knowledge as significant concerns in the service company, TRIZ techniques like 9 windows and the IFR provide structured thinking and ideation processes. Another important objective was to force the creation of not just new ideas and features, but also how to implement them without increasing the cost and effort. Table 7 lists each technique and their respective uses in this example:

    Table 7: Systematic Innovation Techniques and Their Results
    TechniquesUsageHow it Helped
    System operator (9-windows)
    • Looking at the big picture of market, customers and products.
    • Understanding the consumers and technology trends in the relevant area.
    • Identifying possible resources, directly and indirectly associated with the products and users, inside and outside the product.
    • Identifying the constraints in current product offerings – present and future, at the system and super-system levels.
    • Deriving new features by looking at the resource availability and associating them together.
    • Rid ad-hoc thinking by defining a flexible boundary.
    • Easily identify emerging technology by looking at the future
    • Identified several available resources not being utilized fully in the system to use with super-system elements and developing new features.
    • Forced divergent thinking within the scope of the system.
    Ideal final result (IFR)
    • Deriving common feature(s) for identified user segment(s).
    • Exploiting the existing resource in order to implement the feature(s).
    • Convergent thinking – what is required and how can it be implemented.
    • Easy questionnaire helped engineers not previously exposed to TRIZ to think about "ideality."
    Contradictions
    • Implementation of the new features without increasing costs.
    • Reducing complexity.
    • Increasing modularity and configurability.
    • TRIZ principles forced thinking about hardware design and architecture.
    • Applying the principles at the sub-system, system and super-system levels reduced the costs of hardware, modularity and configuration.
    Laws of technological evolution
    • Effective brainstorming by adding the law of technological evolution to the scope of the project.
    • Forced association of elements (identified from the system operator) validated future trend(s).
    • Ability to dive into the technical domain associated with the product.
    • Out of the box ideas that can be implemented in the future.

    Conclusion

    This case study showcases one of the ways of using systematic innovation tools and techniques to design a technology product from a product development service company perspective. There are many case studies focused on the use of TRIZ techniques in product design, but this case study focuses on the processes (in order) to achieve the ideal outcome with globally dispersed product development strategies.

    This project also revealed the need for techniques in the product development process beyond the system operator. Nine windows can help extract resources and elements associated with the system. However, effective brainstorming was required to create associations among the elements and resources.

    TRIZ, even beyond innovative problem solving, offers techniques in structuring out of the box thinking. Nine windows, the ideal final result and technology evolution are all useful techniques to apply to different contexts of a service problem's domain.

    References

    1. Mann, Darrell. Hands-On Systematic Innovation for Business & Management. IFR Press, 2004.
    2. Mann, Darrell. Hands-On Systematic Innovation – Technical. IFR Press, 2003.
    3. Fey, Victor and Eugene Rivin, Innovation On Demand. Cambridge Press, 2005.
    4. Hipple, Jack. On the Soft Side of TRIZ. Altshuller Institute of TRIZ Studies, 2006.

    Acknowledgments

    Girish Deshpande and Suresh Govindaghatta were involved in this project from start to finish. Others who helped me with valuable feedback and critiques are Dr. Raghunath Govindachari, Darrell Mann, Kalyan Kumar Banerjee, Sathish V.J. and Raj Datta.

    This article was previously published as a part of the Altshuller Institute's TRIZCON2007.

    About the Author:

    Prakasan Kappoth is a systematic innovation facilitator and internal innovation consultant at MindTree Consulting Ltd., Bangalore, India. He teaches TRIZ techniques to engineers and facilitates problem solving exercises. Mr. Kappoth has more than ten years of experience in the software industry. He has worked in a variety of technical domains including network management, industrial automation, image processing, consumer application, and embedded appliance and storage. Contact Prakasan Kappoth at prakasan_k (at) mindtree.com.

    Copyright © 2006-2011 – RealInnovation.com, CTQ Media. All Rights Reserved
    Reproduction Without Permission Is Strictly Prohibited – Request Permission


    Publish an Article: Do you have a innovation tip, learning or case study?
    Share it with the largest community of Innovation professionals, and be recognized by your peers.
    It's a great way to promote your expertise and/or build your resume. Read more about submitting an article.