Seis Mitos do Desenvolvimento de Produtos

Os gestores de desenvolvimento de produtos estão sempre a lutar para trazer os projectos a tempo e dentro do orçamento. Nunca têm recursos suficientes para realizar o trabalho, e os seus chefes exigem horários e prestações previsíveis. Assim, os gestores pressionam as suas equipas a serem mais parcimoniosos, a escreverem planos mais detalhados, e a minimizarem as variações de horários e desperdícios. Mas esta abordagem, que pode funcionar bem em fábricas de baixo desempenho, pode de facto prejudicar os esforços de desenvolvimento de produtos.

Embora muitas empresas tratem o desenvolvimento de produtos como se fosse semelhante ao fabrico, as duas são profundamente diferentes. No mundo do fabrico de objectos físicos, as tarefas são repetitivas, as actividades são razoavelmente previsíveis, e os artigos que estão a ser criados podem estar num só lugar de cada vez. No desenvolvimento de produtos muitas tarefas são únicas, os requisitos dos projectos mudam constantemente, e os resultados – graças, em parte, à utilização generalizada de desenho e simulação avançados assistidos por computador e à incorporação de software em produtos físicos – é informação, que pode residir em vários locais ao mesmo tempo.

A incapacidade de apreciar essas diferenças críticas deu origem a várias falácias que minam o planeamento, a execução e a avaliação de projectos de desenvolvimento de produtos. Em conjunto, passámos mais de 50 anos a estudar e aconselhar empresas nos esforços de desenvolvimento de produtos, e encontrámos estes conceitos errados – assim como outros que surgem por diferentes razões – numa vasta gama de indústrias, incluindo semicondutores, automóveis, electrónica de consumo, dispositivos médicos, software, e serviços financeiros. Neste artigo vamos expô-los e oferecer formas de ultrapassar os problemas que criam.

Falácia 1: A elevada utilização de recursos melhorará o desempenho.

Tanto na nossa investigação como no nosso trabalho de consultoria, vimos que a grande maioria das empresas se esforçam por empregar plenamente os seus recursos de desenvolvimento de produtos. (Um de nós, Donald, através de inquéritos realizados em cursos executivos no Instituto de Tecnologia da Califórnia, constatou que o gestor médio de desenvolvimento de produtos mantém a utilização da capacidade acima dos 98%). A lógica parece óbvia: os projectos demoram mais tempo quando as pessoas não estão a trabalhar 100% do tempo e, portanto, uma organização de desenvolvimento ocupada será mais rápida e mais eficiente do que uma que não é tão boa a utilizar o seu pessoal.

Mas, na prática, essa lógica não se aguenta. Vimos que a velocidade, eficiência e qualidade de produção dos projectos diminui inevitavelmente quando os gestores enchem completamente as placas dos seus empregados de desenvolvimento de produtos – por mais qualificados que esses gestores possam ser. A elevada utilização tem graves efeitos secundários negativos, que os gestores subestimam por três razões:

Não levam em conta a variabilidade intrínseca do trabalho de desenvolvimento.

Muitos aspectos do desenvolvimento de produtos são imprevisíveis: quando os projectos chegarão, quais as tarefas individuais que irão requerer, e quanto tempo irão demorar os trabalhadores que nunca abordaram tais tarefas antes a realizá-las. As empresas, contudo, estão mais familiarizadas com processos repetitivos como o fabrico e o processamento de transacções, onde o trabalho não muda muito e as surpresas são poucas e distantes. Tais processos comportam-se de uma forma ordenada à medida que a utilização de recursos aumenta. Acrescente 5% mais trabalho, e levará 5% mais tempo a concluir.

Processos com elevada variabilidade comportam-se de forma muito diferente. À medida que a utilização aumenta, os atrasos alongam-se dramaticamente. (Ver a exposição “Atrasos de Alta Utilização”) Acrescentar 5% mais trabalho, e completá-lo poderá demorar 100% mais tempo. Mas poucas pessoas compreendem este efeito. Na nossa experiência com centenas de equipas de desenvolvimento de produtos, descobrimos que a maioria estava significativamente sobrecomprometida. Para concluir todos os projectos a tempo e dentro do orçamento, algumas organizações com quem trabalhámos teriam precisado de pelo menos 50% mais recursos do que tinham.

É verdade que alguma variabilidade é o resultado de uma falta de disciplina, e que algumas tarefas de desenvolvimento de produtos (como conceber componentes para um protótipo de avião ou realizar ensaios clínicos) incluem trabalho mais repetitivo. Mas mesmo que algum do trabalho seja previsível, quando é combinado com outro trabalho imprevisível, ver-se-ão problemas de fila de espera.

Não compreendem como as filas de espera afectam o desempenho económico.

Uma elevada utilização dos recursos cria inevitavelmente filas de espera de projectos. Quando o trabalho parcialmente concluído fica parado, à espera de capacidade para se tornar disponível, a duração do projecto global irá aumentar. As filas também atrasam o feedback, fazendo com que os promotores sigam caminhos improdutivos durante mais tempo. Tornam difícil para as empresas ajustarem-se à evolução das necessidades do mercado e detectarem fraquezas no seu produto antes que seja demasiado tarde. Ironicamente, estes problemas são precisamente os que os gestores pensam que uma utilização elevada permitirá às suas equipas evitar.

p>Even quando os gestores sabem que estão a criar filas, raramente se apercebem do custo económico. Embora esse custo possa ser quantificado, descobrimos que a grande maioria das empresas não o calcula. Os gestores precisam de pesar os custos das filas contra os custos da capacidade subutilizada, de modo a atingir o equilíbrio certo.

No desenvolvimento de produtos, o inventário do trabalho em processo é predominantemente invisível.

As filas de fabrico consistem em coisas físicas, e quando o inventário numa fábrica duplica, é óbvio. Este não é o caso no desenvolvimento de produtos, onde o inventário consiste em grande parte de informação, como documentação de concepção, procedimentos e resultados de testes, e instruções para a construção de protótipos. Quando o inventário duplica num processo de engenharia, não há sinais físicos. Além disso, porque as normas contabilísticas exigem que a maioria dos R&D inventário seja realizado a valor zero, as demonstrações financeiras não dão qualquer indicação de excessos graves de inventário no desenvolvimento de produtos.

É muito difícil combater um problema que não se consegue ver ou medir. Considere a situação de uma grande empresa farmacêutica. Há vários anos, o seu recém-nomeado chefe da descoberta de medicamentos enfrentou um dilema de gestão. Tal como outros executivos seniores que dirigem grandes organizações R&D, ele estava a tentar encontrar formas de tornar os seus cientistas mais inovadores. Ele queria que eles experimentassem mais com novos compostos químicos que pudessem gerar novas drogas promissoras e, ao mesmo tempo, eliminar candidatos pouco promissores o mais cedo possível. As experiências com organismos vivos, contudo, eram da responsabilidade de testes em animais, um departamento que não estava sob o seu controlo e que era gerido como um centro de custos. Foi avaliado pela eficiência com que utilizava os recursos de testes, o que naturalmente levou a uma elevada utilização. Consequentemente, os cientistas na descoberta de drogas tiveram de esperar três a quatro meses pelos resultados de testes que demoraram pouco mais de uma semana a realizar. A organização de testes “bem gerida” impediu o progresso da unidade de descoberta.

A solução óbvia para tais problemas é fornecer um tampão de capacidade em processos que são altamente variáveis. Algumas empresas há muito que compreenderam isto. Durante décadas, a 3M tem programado os criadores de produtos em 85% da sua capacidade. E a Google é famosa pelo seu “20% de tempo” (permitindo aos engenheiros trabalhar um dia por semana em qualquer coisa que queiram – uma prática que significa que há capacidade extra disponível se um projecto ficar atrasado). No entanto, na nossa experiência, este tipo de solução é bastante difícil de implementar. Como discutiremos, poucas organizações conseguem resistir à tentação de utilizar até à última parte da capacidade disponível. Os gestores começam reflexivamente mais trabalho sempre que vêem o tempo ocioso.

Mas existem outras soluções viáveis:

Alterar os sistemas de controlo de gestão.

Para a empresa farmacêutica, isto pode envolver tomar medidas para alinhar os objectivos da unidade de testes com os da unidade de descoberta. A empresa poderia, por exemplo, recompensar os testes em animais por respostas rápidas (medição do tempo desde o pedido até à conclusão do teste) em vez de utilizar os recursos.

Aumentar selectivamente a capacidade.

Adicionar recursos extra às áreas onde as taxas de utilização são 70% ou superiores pode reduzir significativamente o tempo de espera. Se a empresa farmacêutica o fizesse em testes com animais, obteria feedback sobre novos compostos químicos muito mais rapidamente. Em ambientes onde os testes são realizados com modelagem e simulação por computador, o aumento da capacidade é muitas vezes relativamente barato, uma vez que envolve apenas a compra de equipamento informático adicional e licenças de software.

Limitar o número de projectos activos.

Se a empresa farmacêutica não conseguisse aumentar a capacidade dos ensaios em animais, poderia ainda assim baixar a taxa de utilização reduzindo o número de projectos activos que exploram novos compostos químicos. A disciplina de colocar um limite duro no que vai para um pipeline de desenvolvimento de produtos resulta frequentemente num foco mais acentuado e prioridades mais claras.

Fazer o inventário de trabalho em processo mais fácil de ver.

Um método é utilizar placas de controlo visual. Estes podem assumir várias formas, mas a chave é ter algum tipo de ficha física, tal como uma nota Post-it, representando o trabalho de desenvolvimento (ver a exposição “Typical Work-in-Process Control Board”). Um painel de controlo deve exibir todo o trabalho activo e mostrar em que estado se encontra cada parte do projecto. Deve estar no centro do processo de gestão da equipa. As equipas podem realizar reuniões de stand-up diárias de 15 minutos em torno desses quadros para coordenar esforços e manter o trabalho em movimento.

Falácia 2: O trabalho de processamento em grandes lotes melhora a economia do processo de desenvolvimento.

Uma segunda causa de filas de espera no desenvolvimento de produtos é o tamanho do lote. Digamos que um novo produto é composto por 200 componentes. Poderia optar por conceber e construir todas as 200 peças antes de testar qualquer uma delas. Se, em vez disso, concebesse e construísse apenas 20 componentes antes de começar a testar, o tamanho do lote seria 90% menor. Isso teria um efeito profundo no tempo de fila, porque a fila média num processo é directamente proporcional ao tamanho do lote.

A redução do tamanho do lote é um princípio crítico de fabrico enxuto. Os lotes pequenos permitem aos fabricantes cortar o trabalho em processo e acelerar o feedback, o que, por sua vez, melhora os tempos de ciclo, a qualidade e a eficiência. Os pequenos lotes têm ainda maior utilidade no desenvolvimento de produtos, mas poucos programadores se apercebem do poder deste método.

Uma razão é a natureza do seu fluxo de trabalho. Uma vez mais, porque a informação que produzem é na sua maioria invisível para eles, os tamanhos dos lotes também o são. Em segundo lugar, os programadores parecem ter uma tendência inerente para utilizar grandes lotes – possivelmente porque acreditam incorrectamente que os grandes lotes produzem economias de escala.

Num processo bem gerido, o tamanho do lote equilibrará os custos de transacção e de manutenção (ver a exposição “Como determinar o tamanho óptimo do lote”). É semelhante à compra de ovos na mercearia. Se comprar um fornecimento de 12 meses numa única viagem, o seu custo de transacção é baixo, mas a maioria dos ovos vai estragar-se, aumentando o custo da sua exploração. Se comprar um fornecimento de um dia de cada vez, a sua deterioração será baixa, mas os seus custos de transacção serão elevados. Intuitivamente, tenta encontrar um equilíbrio entre os dois.

As empresas que compreendem como isto funciona exploraram os avanços informáticos para reduzir o tamanho dos lotes, muitas vezes com resultados surpreendentes. Algumas empresas de software que costumavam testar grandes lotes de código a cada 90 dias estão agora a testar lotes muito mais pequenos várias vezes por dia. Um fabricante de periféricos de computador que utilizava uma abordagem semelhante com o seu grupo de software reduziu o tempo de ciclo nos testes de software em 95% (de 48 meses para 2,5 meses), melhorou a eficiência em 220%, e diminuiu os defeitos em 33%. A poupança de custos foi duas vezes maior do que a empresa tinha esperado. Embora esses resultados fossem excepcionais, descobrimos que a redução do tamanho do lote melhora significativamente a maioria dos projectos de desenvolvimento. Da mesma forma, as ferramentas de modelagem e simulação computadorizadas reduziram drasticamente o tamanho óptimo dos lotes de experimentação e testes em empresas que desenvolvem produtos físicos.

Falácia 3: O nosso plano de desenvolvimento é óptimo; só precisamos de nos cingir a ele.

Em todo o nosso trabalho de consultoria e investigação, nunca nos deparámos com um único projecto de desenvolvimento de produto cujos requisitos se mantiveram estáveis ao longo de todo o processo de concepção. No entanto, muitas organizações depositam uma fé desmesurada nos seus planos. Atribuem quaisquer desvios à má gestão e execução e, para os minimizar, rastreiam cuidadosamente cada passo em relação a objectivos e marcos intermédios. Tal raciocínio é bom para actividades altamente repetitivas em processos de fabrico estabelecidos. Mas pode levar a maus resultados na inovação de produtos, onde novos conhecimentos são gerados diariamente e as condições estão em constante mudança.

Um estudo clássico de resolução de problemas técnicos realizado por Thomas Allen do MIT realça a natureza fluida do trabalho de desenvolvimento. Ele descobriu que os engenheiros que estavam a desenvolver um subsistema aeroespacial conceberam e avaliaram uma série de alternativas de concepção antes de seleccionarem uma que consideraram ser a melhor. Ao longo do caminho, as suas preferências mudaram frequentemente, à medida que testaram e aperfeiçoaram soluções técnicas concorrentes. Isto é típico em projectos de inovação: Testes e experimentação revelam o que funciona ou não, e os pressupostos iniciais sobre custos e valor podem ser desmentidos.

Definir as necessidades dos clientes também pode ser difícil de fazer no início de um projecto de desenvolvimento de produto. Quando se pensa no assunto, isso não é surpreendente: Não é fácil para os clientes especificar com precisão as suas necessidades de soluções que ainda não existem. De facto, a familiaridade com os atributos do produto existente pode interferir com a capacidade de um indivíduo de expressar a sua necessidade de um produto novo. As preferências dos clientes podem também mudar abruptamente no decurso de um projecto de desenvolvimento, à medida que os concorrentes introduzem novas ofertas e surgem novas tendências.

Por todas estas razões, manter-se fiel ao plano original – por mais excelente que seja a sua concepção e por mais hábil que seja a sua execução – pode ser uma receita para o desastre. Isto não é para sugerir que não acreditamos no planeamento. O desenvolvimento de produtos é um conjunto de actividades complexas que requerem uma cuidadosa coordenação e atenção aos mais pequenos pormenores. Contudo, o plano deve ser tratado como uma hipótese inicial que é constantemente revista à medida que as provas se desdobram, os pressupostos económicos mudam, e a oportunidade é reavaliada. (Ver “The Value Captor’s Process”, de Rita Gunther McGrath e Thomas Keil, HBR Maio de 2007.)

Fallacy 4: Quanto mais cedo o projecto for iniciado, mais cedo estará terminado.

Como discutimos anteriormente, o tempo ocioso é um anátema para os gestores. Eles tendem a explorar qualquer tempo de inactividade iniciando um novo projecto. Mesmo que a tarefa não possa ser concluída porque as pessoas têm de regressar a outro projecto, os gestores argumentam que qualquer coisa realizada no novo projecto é trabalho que não terá de ser feito mais tarde. Tal pensamento leva as empresas a iniciar mais projectos do que aqueles que podem prosseguir vigorosamente, diluindo os recursos.

Esta diluição é perigosa. Se uma empresa embarca num projecto antes de ter os recursos para avançar, tropeçará lentamente através do processo de desenvolvimento. Isto é problemático porque o trabalho de desenvolvimento do produto é altamente perecível: As suposições sobre tecnologias e o mercado podem tornar-se rapidamente obsoletas. Quanto mais lento for o progresso de um projecto, maior será a probabilidade de este ter de ser reorientado. De facto, um ramo das forças armadas descobriu que os seus custos e prazos de execução eram exponencialmente proporcionais (à quarta potência) à duração de um projecto. Por outras palavras, quando o cronograma original de um projecto duplicou, o custo e o calendário de ultrapassagens aumentaram num factor de 16,

A importância de reduzir a quantidade de trabalho em processo é evidente quando olhamos para uma das fórmulas clássicas da teoria das filas de espera: Lei de Little’s. Afirma simplesmente que, em média, o tempo de ciclo é proporcional ao tamanho da fila dividida pela taxa de processamento. Assim, se 20 pessoas estiverem à sua frente na fila do Starbucks e o barista servir cinco pessoas por minuto, será servido em quatro minutos. Pode encurtar o tempo de ciclo aumentando a taxa de processamento ou reduzindo o número de postos de trabalho em curso. Na maioria dos ambientes, esta última é a única escolha prática.

â© Para alguns criadores de produtos a solução tem sido controlar rigorosamente a taxa a que eles começam a trabalhar. Fazem-no corresponder ao ritmo a que o trabalho é realmente concluído; gerem cuidadosamente o número de projectos em curso; certificam-se de que, uma vez lançado um projecto, este é dotado de pessoal adequado até estar concluído; e resistem à tentação de roubar recursos de um projecto em curso para os comprimir em novos.

Falácia 5: Quanto mais características colocarmos num produto, mais clientes gostarão dele.

Equipas de desenvolvimento de produtos parecem acreditar que acrescentar características cria valor para os clientes e subtraí-las destrói valor. Esta atitude explica porque é que os produtos são tão complicados: Os comandos remotos parecem impossíveis de utilizar, os computadores levam horas a configurar, os carros têm tantos interruptores e botões que se assemelham a cabinas de pilotagem de aviões, e até a humilde torradeira vem agora com um manual e ecrãs LCD.

Empresas que desafiam a crença de que mais é melhor criar produtos que sejam elegantes na sua simplicidade. Bang & Olufsen, o fabricante dinamarquês de produtos áudio, televisores e telefones, compreende que os clientes não querem necessariamente brincar com o equalizador, equilíbrio, e outros controlos para encontrar a combinação óptima de definições para ouvir música. Os seus altifalantes de topo de gama fazem automaticamente os ajustes necessários para reproduzir uma canção com a maior fidelidade possível ao original. Tudo o que resta aos utilizadores para seleccionar é o volume.

Conseguir que as empresas comprem e implementem o princípio de que menos pode ser mais é difícil porque requer um esforço extra em duas áreas de desenvolvimento de produto:

Definir o problema.

Articular o problema que os criadores tentarão resolver é a parte mais subestimada do processo de inovação. Demasiadas empresas dedicam muito pouco tempo a ele. Mas esta fase é importante porque é onde as equipas desenvolvem uma compreensão clara de quais são os seus objectivos e geram hipóteses que podem ser testadas e refinadas através de experiências. A qualidade de uma declaração de problemas faz toda a diferença na capacidade de uma equipa se concentrar nas poucas características que realmente importam.

Quando Walt Disney planeava a Disneylândia, não se apressou a acrescentar mais características (passeios, tipos de comida, quantidade de estacionamento) do que outros parques de diversões tinham. Pelo contrário, começou por fazer uma pergunta muito maior: Como poderia a Disneyland proporcionar aos visitantes uma experiência mágica ao cliente? Certamente, a resposta não veio da noite para o dia; exigiu uma pesquisa minuciosamente detalhada, experimentação constante, e conhecimentos profundos sobre o que “mágico” significava para a Disney e os seus clientes. IDEO e outras empresas têm fases dedicadas nas quais mergulham completamente no contexto em que o produto ou serviço previsto será utilizado. Os seus criadores lêem tudo o que é de interesse sobre os mercados, observam e entrevistam futuros utilizadores, ofertas de pesquisa que irão competir com o novo produto, e sintetizam tudo o que aprenderam em imagens, modelos, e diagramas. O resultado é uma profunda percepção dos clientes que são testados, melhorados, ou abandonados ao longo do processo de desenvolvimento iterativo.

Determinar o que esconder ou omitir.

As equipas são frequentemente tentadas a exibir-se, produzindo soluções técnicas brilhantes que surpreendem os seus pares e a sua gestão. Mas muitas vezes os clientes preferem um produto que simplesmente funcione sem esforço. Do ponto de vista de um cliente, as melhores soluções resolvem um problema da forma mais simples e escondem o trabalho de que os criadores tanto se orgulham.

Uma empresa que compreendeu isto é a Apple. É conhecida por muitas coisas – produtos inovadores, designs elegantes e marketing inteligente – mas talvez a sua maior força seja a sua capacidade de chegar ao âmago de um problema. (Ver “The Real Leadership Lessons of Steve Jobs”, de Walter Isaacson, na nossa edição de Abril). Como o falecido Steve Jobs explicou uma vez, “Quando se começa a olhar para um problema e parece realmente simples, não se compreende realmente a complexidade do problema. E as suas soluções são demasiado simplificadas. Depois entramos no problema, e vemos que é realmente complicado. E surgem todas estas soluções convolutas….É aí que a maioria das pessoas pára”. Não é a Apple. Continua-se a ligar. “A pessoa realmente grande vai continuar”, disse Jobs, “e encontrar…o princípio fundamental subjacente ao problema e encontrar uma solução bela e elegante que funcione””

Determinar quais as características a omitir é tão importante como – e talvez mais importante do que – determinar quais as que devem ser incluídas. Infelizmente, muitas empresas, num esforço para serem inovadoras, lançam todos os sinos e apitos possíveis sem considerar completamente factores importantes como o valor para os clientes e a facilidade de utilização. Quando tais empresas omitem alguma funcionalidade planeada, é tipicamente porque precisam de cortar custos ou porque sofreram atrasos ou porque a equipa falhou de alguma outra forma.

Em vez disso, os gestores devem concentrar-se em descobrir se a eliminação de qualquer característica proposta pode melhorar um determinado produto e permitir que a equipa se concentre em coisas que aumentem verdadeiramente a experiência global do cliente. Isto pode ser determinado tratando cada alegada exigência como uma hipótese e testando-a em pequenas e rápidas experiências com potenciais clientes.

As equipas de desenvolvimento assumem frequentemente que os seus produtos são feitos quando não é possível adicionar mais características. Talvez a sua lógica deva ser a inversa: Os produtos aproximam-se da perfeição quando não podem ser eliminadas mais características. Como Leonardo da Vinci disse uma vez, “A simplicidade é a derradeira sofisticação”

Falácia 6: Seremos mais bem sucedidos se acertarmos na primeira vez.

Muitos projectos de desenvolvimento de produtos não cumprem os seus objectivos em termos de orçamentos, cronogramas, e desempenho técnico. Sem dúvida, um planeamento deficiente, processos rígidos e uma liderança fraca desempenham todos um papel. Mas outra causa que é frequentemente ignorada é a exigência dos gestores de que as suas equipas “façam as coisas bem à primeira”. Exigir sucesso nas equipas de primeiro passe enviesado para as soluções menos arriscadas, mesmo que os clientes não as considerem uma grande melhoria em relação ao que já está disponível. Pior ainda, as equipas têm pouco incentivo para procurar soluções inovadoras para os problemas dos clientes.

Para evitar cometer erros, as equipas seguem um processo linear no qual cada etapa (especificar, conceber, construir, testar, escalar, lançar) é cuidadosamente monitorizada nos “portões” de revisão. Os trabalhos na fase seguinte não podem começar até que o projecto passe pelo portão. À medida que o projecto avança na linha, são assumidos compromissos significativos e o custo de responder a novos conhecimentos aumenta por ordens de magnitude. Os testes bem sucedidos em fases tardias são celebrados, e as surpresas, por mais valiosas que sejam, são consideradas retrocessos. Infelizmente, um tal fluxo de processo linear pode causar a ultrapassagem do projecto porque o feedback dos testes é atrasado, as equipas agarram-se a más ideias mais tempo do que deveriam, e os problemas não são desenterrados até que seja dispendioso resolvê-los.

Uma tolerância para “errar na primeira vez” pode ser a melhor estratégia desde que as pessoas iterem rápida e frequentemente e aprendam rapidamente com os seus fracassos. Os avanços nas tecnologias de simulação e de prototipagem rápida tornaram o funcionamento desta forma muito mais fácil e menos dispendioso.

Consideramos o que encontramos num estudo de 391 equipas que conceberam circuitos integrados personalizados. Equipas que seguiram uma abordagem iterativa e realizaram testes precoces e frequentes cometeram mais erros ao longo do caminho. Mas como utilizaram tecnologias de protótipos de baixo custo, superaram (em termos de tempo e esforço necessário) as equipas que tentaram acertar a sua concepção da primeira vez. As equipas que enfrentaram elevados custos de prototipagem investiram mais esforço na especificação, desenvolvimento e verificação. E porque fizeram as suas iterações mais tarde no processo – e fizeram muito menos – atrasaram a descoberta de problemas críticos.

Experimentar com muitas ideias diversas é crucial para os projectos de inovação. Quando as pessoas experimentam rápida e frequentemente, muitos conceitos inovadores falharão, é claro. Mas tais fracassos iniciais podem ser desejáveis porque permitem às equipas eliminar rapidamente as más opções e concentrarem-se em alternativas mais promissoras. Um teste de colisão que mostra que o desenho de um carro não é seguro, um candidato a drogas que se revele tóxico, ou uma interface de utilizador de software que confunda os clientes, podem ser resultados desejáveis – desde que ocorram cedo num processo, quando poucos recursos foram afectados, os desenhos são ainda muito flexíveis, e outras soluções podem ser experimentadas.