Design Thinking e Etnografia são Modas?
Technology First, Needs Last
"Necessity is often not the mother of invention. In many cases, it surely has been just the opposite. When humans possess a tool, they excel at finding new uses for it. The tool often exists before the problem to be solved." Nye, D. E. (2006).
Don Norman, PhD. Northwest University.
I've come to a disconcerting conclusion: design research is great when it comes to improving existing product categories but essentially useless when it comes to new, innovative breakthroughs. I reached this conclusion through examination of a range of product innovations, most especially looking at those major conceptual breakthroughs that have had huge impact upon society as well as the more common, mundane small, continual improvements. Call one conceptual breakthrough, the other incremental. Although we would prefer to believe that conceptual breakthroughs occur because of a detailed consideration of human needs, especially fundamental but unspoken hidden needs so beloved by the design research community, the fact is that it simply doesn't happen.
New conceptual breakthroughs are invariably driven by the development of new technologies The new technologies, in turn, inspire technologists to invent things, not sometimes because they themselves dream of having their capabilities, but many times simply because they can build them. In other words, grand conceptual inventions happen because technology has finally made them possible. Do people need them? That question is answered over the next several decades as the technology moves from technical demonstration, to product, to failure, or perhaps to slow acceptance in the commercial world where slowly, after considerable time, the products and applications are jointly evolve, and slowly the need develops.
Are flush toilets, indoor plumbing, electric lighting, automobiles, airplanes, or modern telecommunication essential needs? Civilization got along quite well without them for thousands of years. Today, many consider them not just needs but essentials. And every one of these was driven by technology.
Revolutionary innovation is what design companies prefer, what design contests reinforce, and what most consultants love to preach. But if you examine the business impact of innovation, you will soon discover that the most frequent gains come from the small, incremental innovations, changes that lower costs, add some simple features, and smooth out the rough edges of a product. Most innovations are small, relatively simple, and fit comfortably into the established rhythm and competencies of the existing product delivery cycle.
Successful revolutionary innovation is rare. In any given arena, it happens only a few times per decade. Why? In part because it is difficult to invent a new concept that truly fits people's lives and needs. In part, it is because existing products already satisfy most people and when the new concepts appear, the older, existing technologies have a remarkable way of rising to the challenge and sustaining themselves for years - decades even - long after people thought they would disappear. How long did it take the train to overtake the canal as a means of shipping goods? How long did it take the automobile to overtake the horse and carriage as a means of transportation? Think decades. Even simple innovations take decades to gain market acceptance. The path of diffusion of innovation has been well studied, well documented. Most radical innovations fail. Those that succeed can take decades before they are successful.
The grand, breakthrough innovation is what professors love to teach their students, love to write about, and to discuss. But not only is it rare, even the occasional brilliant concepts are difficult to pull off. Yes, it is exciting to contemplate some brand new concept that will change people's lives, but the truth is that most fail. The failure rate has been estimated to be between 90 and 95%, and I have heard credible, data-based estimates as high as a 97% failure rate.
In reality, innovation comes in many shapes and forms. Most new product development is innovative, but at a very tiny, incremental level. Costs are trimmed. Manufacturing and distribution efficiencies are introduced. Costly features of little use are removed, new features thought to enhance competitive value are introduced. Simple, small, yet very important in the life cycle of a product.
Myth: Use ethnographic observational studies to discover hidden, unmet needs
To achieve major conceptual breakthroughs, we should do ethnographic field study to understand the hidden unmet needs of our potential customers. Right or wrong?
It all sounds logical: study people. Discover hidden, unmet needs. Fulfill those needs, and leap ahead of the competition, producing yet another wondrous advance. This is the mantra of the design research community. The research community does a wonderful service. It investigates the way people live. It makes voyeurs of all of us, and the results of their studies provide important titillations to our understanding of human behavior. And it's fun to do: you get to go to exotic locations, to watch people do intimate acts, and then to come back and tell the world what you have seen, carefully disguising the identity of the "informants." Oh yes, I know it can also be dull and dreary, exhausting and depressing, and sometimes even dangerous: but even these aspects can serve to embellish the final story.
But the real question is how much all this helps products? Very little. In fact, let me try to be even more provocative: although the deep and rich study of people's lives is useful for incremental innovation, history shows that this is not how the brilliant, earth-shattering, revolutionary innovations come about.
Major innovation comes from technologists who have little understanding of all this research stuff: they invent because they are inventors. They create for the same reason that people climb mountains: to demonstrate that they can do so. Most of these inventions fail, but the ones that succeed change our lives.
Take a look at the powerful inventions that have changed society and ask what role design research played:
- The Airplane
- The Automobile
- The Telephone
- The Radio
- The Television
- The Computer
- The Personal Computer
- The Internet
- SMS Text Messaging
- The Cellphone
What role did design research play? What role did marketing research play? No role. All were driven by technology. In his recent study of technology, the economist Brian Arthur reached a very similar conclusion: technologies evolve from earlier technologies, driven by science, driven by engineering, driven by tinkerers of all sorts. Needs follow so slowly, that Arthur does not even cover them.
Consider the cycle. First comes a new technology. Perhaps it is a new idea or perhaps an old idea that has finally reached a commercially viable state where inventors can consider it. Note that the time here varies. Edison launched his first phonograph company within months of his invention: he never questioned the need. He had invented the paperless office, he announced, and launched his product. The notion that the phonograph was better suited for playing back pre-recorded music came much later, and from Emile Berliner, a competitor (whose company morphed into RCA Victor and succeeded whereas Edison's several attempts all failed). Technology first: needs last. Multiple-touch interaction with displays took roughly two decades to move from the research laboratory to its appearance in everyday products, and even so, it is not yet common outside of a few limited product categories.
New ideas face two different kinds of hurdles. The first is in the company. Brand new ideas are strange and foreign. If developed within a company, they often do not fit. They compete for scarce resources with other, proven products. New ideas have to fit into the competencies of a company, they have to fit the product schedule, the manufacturing, marketing, and distribution chains. Any new idea that goes outside of the norm has introduced more barriers to success: the innovator's job is not over until all these other barriers have been taken account of, so that the entire system will work smoothly. Innovation is a systems issue; it is not about product or process: it is about the entire system.
The second hurdle is outside the company. If the idea is done outside of a company, then the same hurdles exist in trying to convince people to fund the development. It is risky, unknown, untested. Why should anyone invest? Especially when the data show that most such investments fail. The history of innovation is filled with the stories of those grand inventors who persisted in the face of severe doubt and near financial ruin before they finally succeeded: The xerographic copier, early automobile companies, the development of television, and then color television. The videophone. For that matter, history would be filled with the even greater story of all those who followed similar paths but had to give up for lack of finances: they didn't make it to the history books.
A revolutionary product is fraught with peril: it may not fit people's life or work styles. It probably is too expensive, too limited in power, at least in its initial instantiation. Within an established company, it probably is disruptive of the orderly method of product development, manufacture, and development. It causes strains within the organization.
When I was at Apple, I watched many innovative products fail. Badly done? No, simply ahead of their time. For example, from 1992 to 1994 Apple developed one of the first commercial digital cameras, the Apple QuickTake 100, one of the very first smart pen-based computers (the Newton), and innovative software applications (e.g., CyberDog, Activity Based Computing, OpenDoc). In my consulting practice I helped develop the first digital picture frame and an extremely high quality distance education system for MBA courses. All failed. Were they bad ideas? No. Were they badly implemented? No. All were excellent concepts: they were ahead of their time. The first company to make automobiles in the United States failed. The first commercially sold computer that used a graphical user interface and that helped develop many of the ideas now central to today's world of computing, the Xerox Star, failed. The second commercial attempt to use a similar philosophy, the Apple Lisa, failed. The third attempt, the Apple Macintosh, almost failed, saved only by the fortuitous arrival of Adobe's development of Postscript and Canon's introduction of low-cost laser printing.
Why did the Macintosh almost fail? Was the world ready for the concept? Not really. Apple didn't help with its advertising campaign that snubbed business as dull, dreary, and not worthy of a Macintosh, yet business should not only have been Apple's biggest customer base, but families wanted to buy their children the same computer they would be using in business. As a result, a far inferior computer, the IBM PC, running a command-line, baroque operating system (MS-DOS), swept the market. Within Apple itself, the Macintosh caused huge internal disruption between the Lisa, Macintosh, and the Apple II groups. The Apple II was where Apple was making its money: the other groups were losing money. Internal politics? Massive. Interdivisional rivalry? Yup.
New technological advances inspire inventors to dream of applications, from the silly to the reasonable: examine patent applications over the last century and most are mundane, many are silly, and some hint at broad breakthroughs. New products arose through the tinkering and experimenting of inventors. Most fail. But some were accepted as people discovered their value. Often they had to be nurtured, tamed, modified, but over time, a small number found their niche: the technology launched the products. The products discovered needs. People slowly adopted them, leading to more changes in the products.
Technology first, invention second, needs last.
Where does design research fit into this cycle? Design research has many definitions, but within the product cycle, it consists of studies aiming to understand the activities, desires, and needs of the people for whom a product or service is desired. Design researchers use a wide variety of methods, but all of them, whether it be ethnographic observations, systematic probes, or even surveys, questionnaires, and focus groups aim at one thing: to determine those hidden, unspoken needs that will lead to a novel innovation and then to great success in the marketplace.
In the product world, innovation comes in many forms. The least interesting innovations to the university and company research community are the small, slow enhancements that gradually lower costs while improving performance. But in fact, not only is this where most product enhancement takes place, it is also where the research community can add the most value. This is where ethnographic observation can be powerful, discovering the difficulties people have in everyday use, the workarounds and hacks they invent that suggest product modifications. This allows existing products to be modified at low cost, low risk, yet making them ever more attractive, ever more valuable to the customer base.
But even though incremental improvement is the most powerful and important mechanism for a company, all the excitement revolves around the dramatic breakthrough. And yes, the payoffs from these inventions are so large that their success cam compensate for the risk. But the initial products are almost likely to fail, so it takes a company with money and patience to succeed in these markets. And in these domains, although creativity and imagination are essential, design research, market research, and our beloved careful assessment of people's needs, whether visible or hidden, are largely irrelevant. The inventors will invent, for that is what inventors do. The technology will come first, the products second, and then the needs will slowly appear, as new applications become luxuries, then "needs," and finally, essential.
Once a product direction has been established, research with customers can enhance and improve it. Beforehand? Leave it to the technologists. They will get the grand ideas running, but their implications are apt to be complex, overwhelming, and just plain horrid. Horrid applications? Yes, but that's good news: we will forever be indispensible.
Don Norman wears many hats, including co-founder of the Nielsen Norman group, Professor at Northwestern University, Visiting Professor at KAIST (South Korea), and author: his latest book, Sociable Design: Why Complexity Is Better Than Simplicity is scheduled for publication in Fall 2010. He lives at jnd.org.
READINGS
Arthur, W. B. (2009). The nature of technology: what it is and how it evolves. New York: Free Press.
Kaplan, J. A., & Segan, S. (2008, July 18). 21 Great Technologies That Failed: The most innovative tech doesn't always succeed. Here we present 21 great technologies from both Apple and Microsoft that were simply too far ahead of their time. PCmag.com.
http://www.pcmag.com/article2/0,2817,2325931,00.asp
Nye, D. E. (2006). Technology matters: questions to live with. Cambridge, MA: MIT Press.
Column written for Interactions. © CACM. This is the author's version of the work. It is posted here by permission of ACM for your personal use. It may be redistributed for non-commercial use only, provided this paragraph is included. The definitive version will be published in Interactions.
Link para o Primeiro Capítulo do Livro >>
Extraído de: http://www.jnd.org/dn.mss/technology_first_needs_last.html
As perguntas mais esperadas do iPAD de Mossberg do Wall Street Journal
WSJ's Personal Technology columnist Walt Mossberg joins the Digits Live Show to discuss the most-wanted questions about the soon-to-be-released Apple iPad. Plus, can Tivo stay competitive. And, how algae or beets may one day fuel your car.
Fonte: Wall Street Journal
PALESTRA: Metodologia de Projeto Transformada em Negócio
O MUNDO EM FOCO
Alvin Toffler:
A visão de Alvin Toffler à respeito do mundo. Escrito na década de 80, apontava como a civilização iria evoluir para uma cultura OnLine, digital, e os impactos na sociedade de massa.
Link para o Livro no Submarino >>
Biografia Wikipedia de Alvin Toffler >>
COP 15:
A fracassada conferência do clima, onde os estados não avançaram nas políticas de combate ao Global Warming. Cabe à sociedade agora resolver os problemas apontados. De que lado você está? Do discurso ou da Ação?
Link para o COP15 >>
Vídeo no YouTube, Ação! >>
IBM:
Nesta década alcançamos o ponto em que a tecnologia humana permite corrigir os erros do passado; ambientais, trabalhistas, sociais e humanos. Este vídeo apresenta a ponta do iceberg, vale conferir.
Link: http://asmarterplanet.com/blog/2010/03/the-internet-of-things.html
CNI
O que a Confederação Nacional da Indústria apresenta como Agenda para a indústria brasileira? O que fizemos, quais os desafios, quais as metas do futuro brasileiro?
BRICS
S&P 500 >>
S&P Indices /Quantitative Analyses >>
TipoD:
A FILOSOFIA DA TIPOD
Um bom exemplo de algo que não pode dar errado, um lançamento espacial. Tudo deve ser planejado, dos projetos dos diversos equipamentos e sistemas até o conhecimento adquirido. Se um lançamento de satélite falha, o empreendimento perde dinheiro e afeta a população e instituições que iriam se beneficiar do tal satélite. E quando uma nave falha? Vidas estão em jogo, ponto final.
De onde buscar maior inspiração para as ações do cotidiano em uma empresa de projeto? De onde buscar maior fonte de conhecimento? De onde buscar melhores práticas de organização, de métodos? É fato que "rocket science" para o design e engenharia de produto pode ser demais, porém a postura de inovação diante de desafios destes projetistas e cientistas é um fato. Vide o que a humanidade conseguiu com esta postura:
Voyager - Fevereiro, 21 de 2010. A Nasa celebra 20 anos de operação da sonda Voyager. Saiba Mais >>
Projeto Mercury - Iniciado em 1958 lançou um astronauta americano em 1961, saiba mais >>
Programa Apollo, Projeto Apollo - colocou o homem na Lua em 1967, saiba mais >>
Isto sem citar outros tantos feitos de diversos outros países. Portanto estudar os projetos, as missões, programas sempre nos inspirou profundamente.
Diante do conhecimento de gigantes, desenvolvemos uma onde devemos com todos os esforços cumprir as metas estipuladas. Nada menos que isso seria aceitável. De modo a atender esta premissa, necessitamos de uma base comum para colaboradores e sócios, para tal desenvolvemos os 3As que são a filosofia comum para a conduta na empresa:
1 - ANTECIPAR
2 - ANALISAR
3 - AGIR
Esta filosofia, dos 3As trabalha, para nos, em harmonia com os ciclos PDCA (plan, do, check and action) e o Iniciar, Planejar, Executar, Controlar e Encerrar do PMBOK. Ou seja, a simplicidade que cataliza todas as operações cotidianas: tarefas, estudos, planejamento, execuções, contratações, análises...
A METODOLOGIA DE PROJETO INTEGRADO DE PRODUTOS DA EMPRESA
1 - Gerenciamento de Projeto, baseado no PMI, link >>
2 - Organização do Projeto, ROZENFED & FORCELLINI, link >>
3 - Referência de metodologia /ferramentas, Baxter >>
4 - Metodologia de projeto de engenharia, escola semântica de Pahl e Beitz, link >>
Bem, os demais livros podem ser vistos nas fotos da "estante" apresentada na palestra... Qualquer coisa só perguntar que enviamos a bibliografia, negócios, projeto, referência...
Abordando a complexidade de TI no design de produto
Tackling IT complexity in product design
As more products are loaded with technology, tangled IT designs can undermine product strategies. Product managers and technical specialists need a better game plan.
MARCH 2010 • Marcus Schaper
Source: Business Technology Office
Today, it seems that just about every product contains some sort of embedded computing technology. Cars, phones, even washing machines boast interactive features that would not have been imaginable, much less affordable, a decade ago.
That such products have entered the mainstream is easy to understand (Exhibit 1). Smart phones, electronic navigational equipment, and Wi-Fi-enabled TVs offer convenience, portability, and personalization at reasonable prices. But the price of such progress is growing IT architecture1 and design complexity.
Consider the fact that in the past five years, the average number of tech-enabled engine control units in each new vehicle produced by the automotive industry has risen to 80, from 20. In the mobile-phone sector, the number of IT-based updates per year is about 40, more than twice the level back in 2000. And despite challenging economic times, the number of avionics features—from cockpit VoIP and wind sensors to the electronic flight manuals introduced in newer aircraft—has doubled in recent years. The growing demand for electronics-based product enhancements finds companies across industries struggling to keep costs in line amid fast-changing technologies and the constant pressure for product upgrades.
The problem of technical complexity
The pace of product development is creating enormous engineering and technical-development challenges. Traditional product development was driven largely by hardware considerations. When you pressed a button on an analog telephone, the button dialed one number, and that was the limit of its functionality. Today’s tech-enabled products depend on the successful integration of multiple hardware and software components—a multidimensional process. Now, a single button on a new smartphone may connect, in different ways, to a dozen distinct applications.
Software is by nature more abstract—strings of program code are pieced together in interconnected layers. The IT architecture underlying new product designs is thus far more intricate than the specifications of traditional products. In the predigital world, for instance, one vacuum cleaner operated more or less like any other. But throw in a silicon chip, and today you might have a Roomba: an intelligent robot vacuum cleaner guided by sensors and processors.
Poor product architecture
Development teams, beset by demands for customized features, may fail to realize that poor product architecture decisions upfront can have costly downstream consequences. Those teams, often led by electrical engineers, sometimes lack the specialized software-engineering skills needed to anticipate potential programming, upgrade, or reuse issues. This problem can create a vicious cycle, where poor design decisions and architecture lead to unmanageable code and greater complexity. In the auto industry, for example, a recall resulting from electronics issues cost a manufacturer close to €300 million. These design mistakes can tarnish a company’s reputation—as a high-end automaker learned after introducing new user interfaces that proved overly challenging to operate and broke down as a result of software problems.
Juggling a range of technical requirements for any single product can hinder a company’s ability to think more broadly about how certain features and functions might be leveraged across its product portfolio. This failing can force companies into a series of “one-off” applications. The Apple engineers who designed the iPod touch successfully combined new hardware (a touch screen) with better software logic (an intuitive, user-friendly interface), but others struggle to create flexible, integrated architectures. A home-electronics supplier, for instance, had to design a new user interface each time it upgraded a product—which put it at a disadvantage to competitors that took a more modular (or plug-and-play) approach to product development.
Weak linkage with business priorities
For some organizations, the bigger issue is that the technical challenges of tech-enabled products often conflict with business strategy.
Many companies have decades of experience developing mass-produced hardware-oriented products, such as televisions, radios, and home appliances, with relatively long shelf lives. Design and R&D processes have therefore been optimized around volumes and efficiency. The new era of tech-enabled products, with their niche features and faster pace of product change, requires a different set of processes and skill sets, as well as a longer learning period while organizations reshape traditional ways of doing business. The result is a significant risk of escalating costs, cycle times, and mission creep. Product managers seeking to eclipse the competition may push for next-generation design changes that stretch the limits of current technology. IT developers keen to leverage an application’s reach may overengineer a group of features.
For product strategies to be successful and sustainable, business considerations must drive technical ones. In an effort to deliver a consistently high-quality gaming experience, for instance, Nintendo deliberately kept the architecture underlying its Wii system simple, limiting the feature set in favor of rigid quality and control standards. Those traits delighted consumers and made the platform a best seller. Other companies may overlook the importance of ensuring that business audiences understand the far-from-intuitive choices that go into a product’s underlying architecture.
The abstract nature of many embedded IT systems makes functionality hard to describe. Nontechnical managers in the business units can struggle to determine which set of features and options is suitable from the standpoint of cost, ease of use, and process time. A mobile-phone company, for example, learned this lesson when unclear lines of authority led its product-development and engineering teams to argue over which of them was responsible for the features, costs, and timetables of a certain product. The confusion resulted in long lead times in completing it and a failure to offer technology matching that of the company’s rivals.
Cost management is also far more complex in the tech-enabled-product environment, where life cycles for software and hardware components often don’t align, making architectural integration difficult. The present tough economic environment exacerbates this problem. Managers are under intense pressure to bring new products to market quickly while also saving costs. In the absence of a clear development framework that brings both technological and business considerations to bear, development teams too often resort to quick fixes or “strokes of genius” rather than more sustainable solutions. To meet a launch date, for example, engineers at one company built a device with readily available, function-rich, but expensive third-party software. That helped the company meet its release target but exposed it to higher-than-expected costs.
Capturing greater value
With consumer demand for tech-enabled products continuing to grow across industries, some manufacturers are addressing these issues and optimizing electronics architectures.
Align business and engineering goals
Underlying the success of some companies in industries such as automotive and high tech is an integrated approach to designing the architectures of electronics products. In practice, that means aligning the product vision with design, the road maps of individual products with the broader electronics platform strategy, and, ultimately, the business side of product management with the engineering side. Only when companies set clear goals that demand such an alignment will customer and commercial considerations remain squarely in the center, grounding the development process and minimizing unnecessary complexity. The difference between a well-run and a poorly run development unit can vary overall productivity by a factor of ten.
A good architecture has a number of important characteristics. It is modular, allowing sections to be tagged, stored, and applied in different products. It is built on standards, providing for easier integration. It is configurable, letting one system serve many customer requirements. And it is updatable, allowing new features to be implemented without any need to discard large parts of older releases.
This list may seem straightforward. But it’s one thing to recognize a good architecture, another to build one and keep it in good shape. Setting the right goals also requires clarity about the dimensions of the task. Consider what goes into the body of a typical tech-enabled product. Hardware, plastics, resins, nuts, and bolts make up the skeletal frame. Transistors, microcircuitry, and other kinds of electronics manage the flow of information, much as tissues and veins do in living things, and software provides the neurological connections that direct and control operations. The layered architecture defines that anatomy, specifying everything from the user interface to the way the product functions to its interactions with other systems and components.
Adopt a transparent process
Companies must adopt a management process that optimizes the way these layers work together. The process involves a new form of collaboration among engineering, marketing, product design, and other product functions. Interaction helps IT- and engineering-development teams balance what the market demands in a feature set against what the business requires in costs and cycle times—all, of course, within the realm of what is possible technically. As Exhibit 2 illustrates, the best solution usually involves balancing multiple trade-offs.
Along the lines of this framework, teams from both business and IT begin by mapping their product requirements and addressing such questions as, “Who is the buying audience?” “Where is the greatest opportunity?” and “What are the right features?” Factoring in cost, budget, and other constraints, teams emphasize features likely to have the greatest impact on customer satisfaction. Those features are translated into a range of architectural components, each with its own strengths and weaknesses from a cost and performance perspective. As teams toggle through which component options make the most business and technical sense, the answers define the underlying product architecture.
With the business requirements sorted out, the teams examine their architectural design options. They may find that what they need is not yet commercially viable or that it requires too much customization for mass production. Such constraints oblige the teams to toggle between what they want and the real-world options in order to find the most suitable architecture. This iterative process forces business and IT perspectives to fuse, creating an alignment between the product’s overall strategic objective and the appropriate tech-enabled architecture.
Focus on a subset of possible architectures
One mobile-phone maker needed to create a low-cost handset for sale in emerging markets. Business requirements dictated a rugged design and a limited feature set. After a series of iterations, the engineering team presented a number of design options that emphasized electronic and mechanical components that could withstand harsh physical conditions, coupled with a small and relatively inexpensive processor. Another mobile-phone maker, with plans to compete for the iPhone demographic, had a different set of business requirements, which favored a more complex, memory-intensive architecture supporting a variety of features, despite the higher costs.
The ability to balance different design options in accordance with business strategies is the basis of an optimized tech-enabled architecture. Yet different facets of an architectural framework support different aspects of product performance—for example, those that govern customer-facing processes, define how software and hardware relate, or guide the interplay among applications (Exhibit 3). We have found that teams can simplify the process by focusing on a few specific architectural facets, weighing their relative importance to the overall set of business objectives and product capabilities.
Consider what happened at an automotive supplier struggling to improve its fuel injection system. In the company’s original siloed world, engineers built custom IT components from scratch for each product upgrade. This approach bogged down the production timetable and prevented the company from keeping pace with other market leaders.
With improvements in time to market as the main business goal, the company established a cross-functional product team that sat down to work through the iterative process described here. To stop building everything from scratch, the team agreed to create an internal library of resources to make better use of existing technologies. These embedded software systems and widely used electronic components were governed by the architecture’s capabilities (domain) layer. To streamline development and reduce component costs, the team sifted through the list of required fuel injection hardware and identified basic components that could be standardized across multiple engines. To speed up development time, engineers and product managers decided to take advantage of modular software and electronics elements. These could be plugged into a variety of different applications that made the fuel injection system work.
The resulting electronics architecture brought products to market twice as quickly as the older, more labored one. By optimizing the interior electronics, thus replacing a complex architecture with a simplified one, the company saved a few euros for every car it built. This savings added up to more than €10 million over the entire series. In addition, the platform, initially designed for four-cylinder engines, can now be used in eight-cylinder engines as well, saving the company additional costs and development time.
In another example, a power-equipment supplier was eager to get its new windmill product line up and running. But the advanced control facility for these windmills faced a sizable hurdle. The company needed to find a cost-effective way to monitor how much power the windmills were supplying to the grid. The business requirements for this feature made it clear that the best solution would be a cheap control device with an architecture that allowed it to be scaled up easily across a network of windmills.
The technical team decided that the domain-based architecture layer was the place to concentrate efforts to meet the product requirements. It met with the team from the business unit and presented three options for managing the system’s processes: a general-purpose processor, a microcontroller, and a digital signal processor. All three would measure power output, but each solution had its own costs and benefits. The technical team needed to make sure that the product managers understood the various trade-offs so that together the technical and business sides could make the optimal choice for the new tech-enabled architecture.
Weighing the three alternatives, the team found that the general-purpose processor had the advantage of being easy to install and upgrade, but the hardware supporting the processor had to be purchased separately, making it too costly. The digital signal processor offered a stripped-down operating-system architecture that was cheap to develop and could monitor basic power use, but it could not provide needed billing and reporting features. This left the microcontroller as the best option. It cost more but gave the product team the flexibility of a complete off-the-shelf solution, since all the needed hardware and software was built right in.
Building a better product-development organization
Integrated development of tech-enabled products requires an equally integrated management approach. One successful company began by creating a project steering group led by the overall product group manager and the chief technology officer, who together outlined the product platform strategy and directives. Working below this leadership level, business and engineering teams mapped out the consumer and technical requirements and then came together to discuss and prioritize the elements of the final approach. The teams shared the resulting architecture with the product group manager and the CTO to confirm that the solution would meet the company’s consumer, cost, and market delivery objectives. They also established a series of performance metrics to quantify cost and productivity gains and to further refine their ideas about where improvements could be made. This holistic procedure helped ensure that both the business and the technical team focused on the features that mattered most—those tied to the product’s overall strategic objective.
Establishing the right architecture for tech-enabled products is not a one-time effort. It’s an ongoing process that is especially important to support the product life cycle. When the search for the right architecture is elevated to a discipline followed by both engineers and the business side, companies with tech-enabled products can experience gains in productivity, quality, and costs.
About the Author
Marcus Schaper is a principal in McKinsey’s Frankfurt office.
Notes
1 Architecture refers to the technical and business model used to plan and govern the design, functionality, and integration of software, hardware, and IT.
PARKS RECEBE PRÊMIO DESTAQUE ANUÁRIO INFORMÁTICA HOJE 2009
O Anuário Informática Hoje 2009, editado pela Plano Editorial, premiou a Parks como destaque do ano na Categoria Fabricantes de Hardware. A premiação que ocorreu no dia 31 de agosto, em São Paulo, foi entregue para o presidente da Parks, Edgar Bortolini.
O Anuário Informática Hoje faz, há 23 anos ininterruptos, a análise do desempenho econômico-financeiro das empresas que atuam no mercado brasileiro de tecnologia da informação. O Anuário publica o ranking das 200 maiores empresas de TI do país, de acordo com sua receita líquida, escolhe as empresas Destaque do Ano em cada um dos segmentos que compõem o mercado brasileiro de TI e elege a Empresa do Ano.
Todos os dados são analisados pela equipe que produz o Informática Hoje, sob a supervisão de professores da Fundação Getúlio Vargas de São Paulo. O Anuário atribui ainda o Prêmio Excelência em P&D aos melhores projetos de pesquisa e desenvolvimento incentivados pela Lei de Informática. São avaliadas empresas fabricantes de hardware, desenvolvedores de software, integradores, prestadores de serviços e canais de venda, todos divididos por segmento, porte e faturamento.