Qual ferramenta de inovação usar? Um guia por situação
Escolha a ferramenta de inovação certa para onde sua equipe travou: entender, achar a causa, enquadrar, gerar ideias, escolher, testar ou implantar.

Qual ferramenta de inovação usar? Um guia por situação
Escolha a ferramenta pela pergunta em que sua equipe travou, não pela popularidade da ferramenta. Existem só umas sete situações em que uma equipe pode estar, de "não entendemos o problema" a "já decidimos e precisamos entregar", e cada uma tem um pequeno conjunto de ferramentas que se encaixa nela. Dê nome à sua situação primeiro, e a escolha da ferramenta fica curta e óbvia.
A maioria das equipes faz o contrário. Alguém participou de um workshop, gostou de um canvas, e agora todo problema recebe aquele canvas. Um Business Model Canvas é usado para consertar um processo de aprovação emperrado. Convoca-se um brainstorming quando ninguém conversou com um único cliente. A ferramenta é boa; só está respondendo à pergunta errada.
Este guia mapeia o território inteiro. Use-o como consulta: encontre a situação que parece com a sua semana, use uma ou duas das ferramentas listadas e siga os links para os artigos mais aprofundados e os guias de método.
Comece pela pergunta em que vocês realmente travaram
Antes de escolher qualquer coisa, escreva uma frase que termine assim: "Agora, não conseguimos avançar porque não sabemos…". O final dessa frase diz em que situação você está.
| Se a frase termina com… | Você está em | Comece por |
|---|---|---|
| "…o que realmente acontece com as pessoas envolvidas" | 1. Entender | Entrevistas com stakeholders, observação contextual |
| "…por que isso continua dando errado" | 2. Encontrar a causa | Cinco porquês, diagrama de Ishikawa |
| "…qual problema estamos de fato resolvendo" | 3. Enquadrar | Declaração de ponto de vista, perguntas Como poderíamos |
| "…o que poderíamos fazer a respeito" | 4. Gerar ideias | Brainwriting, Crazy 8s |
| "…em qual dessas ideias apostar" | 5. Escolher | Matriz de impacto e esforço, matriz de decisão ponderada |
| "…se isso vai funcionar" | 6. Testar | Mapa de premissas, protótipo em papel |
| "…como tornar isso real sem que desmorone" | 7. Entregar | Blueprint de serviço, matriz RACI, checklist de implantação |
Se a equipe não chega a um acordo sobre como a frase termina, esse desacordo é a sua verdadeira descoberta. Normalmente significa que vocês estão mais no início da sequência do que a pessoa mais sênior da sala acredita.
Há mais uma situação que fica acima das outras sete: "não sabemos para onde deveríamos ir". Isso é estratégia, não resolução de problemas, e tem ferramentas próprias, tratadas no fim da próxima seção.
As sete situações e as ferramentas que se encaixam em cada uma
1. Vocês ainda não entendem o problema
Sinais: a equipe discute com base em opinião, a mesma história se repete e ninguém consegue descrever o dia de um usuário real. A resposta é pesquisa, e a pesquisa mais barata é conversar com as pessoas e observá-las.
- Entrevistas com stakeholders quando você precisa dos motivos por trás do comportamento.
- Observação contextual quando o que as pessoas dizem e o que fazem provavelmente diferem, o que acontece quase sempre.
- Estudo de diário quando a experiência se estende por dias ou semanas, como um onboarding ou uma solicitação demorada.
- Safári de serviço quando a própria equipe nunca usou o serviço que opera.
- Mapa de experiência e um mapa de empatia para dar sentido ao que você ouviu.
A maior parte da pesquisa desperdiçada se perde na própria entrevista. Leia 5 erros de pesquisa que desperdiçam suas entrevistas antes de marcar a primeira e, se pretende mapear a jornada, leia um mapa da jornada que leva à mudança, não a um pôster.
2. Vocês conhecem o sintoma, mas não a causa
Sinais: o problema é mensurável e recorrente (reclamações, atrasos, erros), e toda correção até agora foi temporária. Você precisa de ferramentas de causa raiz, não de ideias.
- Cinco porquês para uma cadeia única e razoavelmente linear de causas. Associado a Taiichi Ohno e ao Sistema Toyota de Produção.
- Diagrama de Ishikawa, atribuído a Kaoru Ishikawa, quando vários tipos de causa (pessoas, processo, sistemas, políticas) estão emaranhados.
- Análise de Pareto quando você tem dados e precisa ver quais poucas causas respondem pela maior parte do problema.
- Árvore de problemas quando também precisa mostrar à liderança os efeitos, não só as causas.
O passo a passo completo está em como encontrar a causa raiz de um problema.
3. Vocês têm a pesquisa, mas não o problema
Sinais: há uma parede de descobertas e cada um enxerga uma manchete diferente nela. É a situação mais subestimada, porque um enquadramento fraco arruína em silêncio cada etapa seguinte.
- Diagrama de afinidade para agrupar as descobertas em temas com que a equipe concorda.
- Declaração de ponto de vista para dizer quem tem o problema, do que precisa e por que isso importa.
- Perguntas Como poderíamos para transformar essa declaração numa pergunta que convida ideias sem impor uma.
Dois textos mais aprofundados: sua declaração do problema é o projeto inteiro e 10 perguntas "como poderíamos": cinco boas, cinco ruins.
4. Vocês precisam de ideias
Sinais: o problema está claro e acordado, e as três primeiras ideias na mesa são as que todos já tinham antes de o projeto começar. Você precisa de variedade antes de precisar de qualidade.
- Brainwriting para que as pessoas mais quietas e as mais juniores contribuam antes que a voz mais alta defina a direção.
- Crazy 8s para variedade rápida e visual em oito minutos.
- Técnica SCAMPER quando você está melhorando algo que já existe.
- Inspiração por analogia quando a equipe está presa aos hábitos do próprio setor.
- Pior ideia possível quando a sala está cautelosa demais para dizer algo fora do comum.
Por que uma sessão aberta de "fala o que vier" rende menos do que essas, e o que fazer no lugar, está em o brainstorming não funciona; veja o que funciona.
5. Vocês têm ideias demais
Sinais: uma parede de post-its, um prazo e um patrocinador perguntando "e aí, qual?". A ferramenta que você escolhe aqui decide se a escolha vai se sustentar depois.
- Matriz de impacto e esforço para um primeiro corte rápido.
- Matriz de decisão ponderada quando a decisão precisa sobreviver ao escrutínio do financeiro ou da liderança.
- Matriz Now, How, Wow quando você quer um mix equilibrado de ganhos rápidos e apostas mais ousadas.
- Votação por pontos só para revelar opiniões, nunca como decisão final.
Compare as opções em como priorizar ideias: cinco formas comparadas e veja por que a última ferramenta da lista engana com tanta frequência em por que a votação por pontos mente para você.
6. Vocês têm uma ideia favorita e não sabem se funciona
Sinais: entusiasmo alto, evidência baixa e alguém querendo começar a construir. É o momento que mais economiza dinheiro.
- Mapa de premissas para encontrar a crença que, se estiver errada, afunda a ideia.
- Protótipo em papel para testar uma interface ou um formulário numa tarde.
- Teste Mágico de Oz quando o usuário deve vivenciar um serviço automatizado que, nos bastidores, é operado à mão.
- Teste concierge quando você entrega o serviço manualmente e às claras para um punhado de pessoas.
- Teste de hipótese para escrever, antes de testar, qual resultado mudaria sua opinião.
Comece por como testar uma ideia antes de construí-la e depois leia o protótipo mais barato que você pode fazer esta semana.
7. Vocês já decidiram e precisam entregar
Sinais: a ideia passou nos testes e agora precisa sobreviver ao contato com operações, TI, compras e as pessoas que vão operá-la num domingo de manhã.
- Blueprint de serviço para mostrar o que acontece na linha de frente, nos bastidores e nos sistemas por baixo.
- Matriz RACI para que cada etapa tenha um único dono.
- Pré-mortem, popularizado pelo psicólogo Gary Klein, para imaginar que o lançamento fracassou e descobrir por quê, enquanto ainda dá para agir.
- Checklist de implantação para os detalhes chatos e decisivos.
Acima das sete: vocês não sabem para onde estão indo
Se a pergunta é sobre direção e não sobre um problema específico, use ferramentas de estratégia: análise SWOT e análise PESTLE para examinar a posição e o ambiente, três horizontes para equilibrar o negócio de hoje com o de amanhã e uma matriz de cenários quando o futuro pode seguir vários caminhos. Elas pertencem ao trabalho de estratégia e rendem mais antes de um projeto de resolução de problemas começar, não no meio dele.
Quando você precisa de um processo inteiro, não de uma ferramenta
Ferramentas isoladas respondem a perguntas isoladas. Quando um projeto precisa ir de "não entendemos" a "está no ar", você precisa de um processo que encadeie as situações em ordem.
- Design thinking percorre entender, enquadrar, gerar ideias e testar. As versões mais conhecidas são os cinco modos da d.school de Stanford e o Double Diamond do Design Council do Reino Unido. Veja design thinking, passo a passo, e onde ele dá errado.
- O design sprint, criado por Jake Knapp no Google e no Google Ventures (GV), comprime enquadramento, ideias, escolha e um teste de protótipo em cinco dias.
- Lean startup foca a situação 6, testando premissas num ciclo construir-medir-aprender.
- Agile cobre a situação 7 e além: entregar partes funcionais em ciclos curtos.
- Stage-Gate, criado por Robert G. Cooper, governa um portfólio de projetos por meio de pontos de decisão.
Como escolher entre os quatro primeiros é o tema de design thinking vs lean vs agile vs design sprint. Se você quer uma lista curta para treinar uma equipe primeiro, veja as 10 ferramentas que toda equipe de inovação deveria conhecer.
Um exemplo prático
Ilustrativo. Uma empresa regional de saneamento numa cidade europeia de porte médio recebe um fluxo constante de reclamações sobre o processo de nova ligação de água para residências. O diretor de operações pede ao líder de inovação que "faça um workshop de design thinking e traga ideias".
O líder de inovação escreve primeiro a frase: "Não conseguimos avançar porque não sabemos… por que as solicitações empacam." Esse final aponta para a situação 2, não para a 4. As reclamações são um sintoma de causa desconhecida.
A equipe levanta seis meses de registros de solicitações e faz uma análise de Pareto. A maioria das solicitações paradas trava numa etapa: a vistoria no local. Uma sessão de diagrama de Ishikawa com vistoriadores, agendadores e a equipe da central de atendimento mostra várias causas emaranhadas, mas uma se destaca: os solicitantes não são avisados de que precisam estar em casa na vistoria, e muitas visitas dão em nada.
Só então a equipe passa para a situação 3, enquadrando o problema como "como poderíamos garantir que os solicitantes estejam prontos no dia da vistoria?". Uma rodada de brainwriting de vinte minutos produz trinta ideias. Uma matriz de impacto e esforço deixa quatro. A equipe testa as duas primeiras com um teste concierge: durante duas semanas, uma coordenadora telefona pessoalmente para os solicitantes dois dias antes de cada vistoria.
O resultado volta ao diretor de operações não como "ideias de um workshop", mas como evidência: o que foi testado, com quantos solicitantes e o que mudou. Em seguida vem o blueprint de serviço da versão definitiva. Foram usadas cinco ferramentas, cada uma para a pergunta que responde, e o workshop que o diretor pediu no início foi uma parte pequena do todo.
O que fazer e o que evitar
Faça
- Dê nome à situação antes de dar nome à ferramenta. Escreva a frase "não sabemos…" e cheguem a um acordo sobre ela.
- Use uma ou duas ferramentas por situação. Profundidade vale mais que um desfile de canvas.
- Volte atrás quando precisar. Se o teste mostrar que vocês entenderam mal o usuário, voltem à pesquisa; é o processo funcionando, não falhando.
- Deixe os resultados de cada ferramenta onde a próxima etapa possa vê-los. Um Ishikawa que vive na foto de um quadro branco se perde até quinta-feira.
- Ajuste a ferramenta ao público. Uma matriz de decisão ponderada convence um comitê financeiro; um storyboard convence uma equipe da linha de frente.
Evite
- Não comece pelas ideias só porque é a parte divertida. Ideação sem enquadramento produz as ideias que todos já tinham.
- Não use a votação por pontos para tomar a decisão final. Ela mede a popularidade na sala, não o mérito.
- Não faça um design sprint completo quando precisa de uma sessão de causa raiz, nem uma única sessão de causa raiz quando o problema exige meses de descoberta.
- Não deixe a ferramenta favorita do facilitador decidir a pauta.
- Não pule o teste porque o patrocinador já gosta da ideia. É exatamente aí que o teste mais importa.
Perguntas frequentes
Quais são as ferramentas de inovação mais comuns? As ferramentas mais usadas pelas equipes são entrevistas, mapas da jornada ou de experiência, perguntas "como poderíamos", brainwriting ou brainstorming, matrizes de impacto e esforço, protótipos e o Business Model Canvas. Mas ser comum não é o mesmo que ser certo para você: use a tabela de situações acima para escolher.
Qual a diferença entre uma ferramenta de inovação e um processo de inovação? Uma ferramenta responde a uma pergunta, como "o que causa isso?" ou "qual ideia primeiro?". Um processo como design thinking, design sprint ou Stage-Gate coloca várias ferramentas numa ordem para que um projeto vá do problema ao lançamento.
Posso usar essas ferramentas sem um facilitador treinado? Sim, a maioria delas. Ferramentas como os cinco porquês, a matriz de impacto e esforço e o protótipo em papel são simples o bastante para qualquer equipe conduzir a partir de um guia. Um facilitador passa a valer a pena quando o grupo é grande, sênior ou dividido, ou quando o que está em jogo na decisão é alto.
Para onde ir agora
Se você está no início de um projeto, comece com entrevistas com stakeholders e perguntas Como poderíamos. Se está se afogando em ideias, vá para a matriz de impacto e esforço. Se está prestes a construir, faça antes o mapa de premissas. Os 75 guias de método estão no índice de guias.