Hackathon, design jam ou desafio de inovação: qual se encaixa no seu objetivo

Escolha um hackathon quando o problema está claro e você precisa de um protótipo funcionando, construído por pessoas que sabem programar ou fabricar. Escolha um design jam quando ainda não tem certeza de qual é o serviço ou a experiência certa e precisa descobrir isso com usuários reais, rápido. Escolha um desafio de inovação quando a solução provavelmente já existe em algum lugar, numa startup, num laboratório ou num fornecedor, e você precisa encontrá-la, testá-la e contratá-la.

Dito de outro modo: o hackathon responde "conseguimos construir?", o design jam responde "o que devemos construir?" e o desafio responde "quem já tem isso?". O restante deste artigo mostra como saber qual pergunta você está realmente fazendo. Para toda a família de formatos, veja todos os tipos de hackathon e jam explicados.

A comparação num relance

Quando o hackathon se encaixa

O hackathon se encaixa quando três coisas são verdadeiras. O problema é específico o bastante para ser dito numa frase. Os sistemas, dados ou materiais estão disponíveis e liberados. E existe alguém que vai pegar o resultado e financiar a próxima etapa.

Bons usos típicos: automatizar uma etapa manual que todos concordam ser penosa, construir uma ferramenta interna sobre uma base de dados existente, conectar dois sistemas que deveriam conversar entre si ou testar se uma tecnologia nova aguenta uma carga de trabalho real. Em todos esses casos, a incerteza é técnica, não humana.

O hackathon se encaixa mal quando ninguém verificou se os usuários querem aquilo. As equipes vão construir respostas impressionantes para a pergunta errada, e os jurados vão premiar a mais impressionante. Se escolher esse caminho, siga como organizar um hackathon que produz algo real.

Quando o design jam se encaixa

O design jam se encaixa quando o problema está em como as pessoas vivem um serviço e você não sabe onde ele quebra. Sua força está em as equipes saírem da sala. Elas fazem Observação contextual, conversam com as pessoas, encenam o serviço com Dramatização (role play de serviço) e testam protótipos em papel na mesma tarde.

O modelo mais conhecido é o Global Service Jam, criado em 2011 por Adam Lawrence e Markus Hormess, e seu irmão do setor público, o GovJam: 48 horas, um tema revelado no início, protótipos compartilhados abertamente no final. Num design jam interno, em geral se deixa de lado o tema secreto e se coloca no lugar um problema de serviço real.

Bons usos típicos: redesenhar uma jornada de onboarding, reduzir visitas ou ligações repetidas, repensar um serviço para um grupo que ele hoje não atende bem ou ensinar uma equipe como o service design funciona, fazendo. Um jam também é barato de organizar, porque ninguém precisa de ambiente de desenvolvimento.

O design jam se encaixa mal quando a organização espera software no final. Garanta que o patrocinador saiba que a entrega é um conceito testado, muitas vezes registrado num Blueprint de serviço (service blueprint) ainda tosco, e que construí-lo é uma etapa separada. Como organizar um jam trata do formato em detalhe.

Quando o desafio de inovação se encaixa

O desafio de inovação se encaixa quando você suspeita que a capacidade existe fora da organização e que construí-la internamente seria mais lento ou mais arriscado. Você publica um desafio, recebe candidaturas, faz uma pré-seleção, apoia os finalistas a adaptar sua solução ao seu contexto e faz o piloto de uma ou mais delas.

Bons usos típicos: encontrar um parceiro de tecnologia para um problema comum ao seu setor, buscar startups para um programa de pilotos ou convidar universidades a aplicar pesquisas existentes a um problema operacional. É o formato certo quando você precisa de solucionadores que passaram anos no problema, não um fim de semana.

Ele se encaixa mal quando os processos de compras, jurídico ou segurança da informação não conseguem lidar com um piloto com uma empresa pequena. O desafio vai atrair bons candidatos e depois perdê-los no processo de contratação. Resolva os termos do piloto, o acesso a dados e a propriedade intelectual antes do lançamento. Como escrever um enunciado de desafio que as pessoas queiram resolver trata do briefing; como trabalhar com startups trata da relação.

Combinando os três: a sequência que funciona

Os três formatos são mais fortes em sequência, porque cada um produz um tipo diferente de evidência.

1. Jam para encontrar o problema. Um design jam de um ou dois dias com usuários identifica onde o serviço realmente falha e a qual conceito os usuários respondem.
2. Hackathon para provar que dá para construir. Um hackathon focado, com um briefing estreito tirado do melhor conceito do jam, testa a viabilidade técnica nos seus próprios sistemas.
3. Desafio para escalar com ajuda de fora. Se construir internamente não for o caminho certo, um desafio busca parceiros capazes de entregar em escala, com a evidência do jam no enunciado do desafio.

Nem sempre você vai precisar dos três. Mas fazê-los na ordem errada, um hackathon antes de alguém ter conversado com um usuário ou um desafio antes de você conhecer o problema, é o motivo mais comum para esses eventos decepcionarem.

Exemplo ilustrativo

Ilustrativo. Um serviço nacional de bibliotecas no Canadá queria que mais jovens adultos usassem suas unidades. Um membro do conselho propôs um desafio de inovação aberta para "a biblioteca do futuro". A equipe de inovação discordou: ainda não sabia por que os jovens adultos se mantinham afastados.

Ela fez primeiro um design jam de dois dias. As equipes passaram a primeira manhã em três unidades e em dois cafés próximos, observando e conversando com estudantes. A descoberta não tinha a ver com livros nem com tecnologia: os jovens adultos queriam um lugar para estudar até tarde, e as unidades fechavam às 18h. As equipes prototiparam uma noite de estudo com funcionários presentes e a testaram com um Teste concierge (MVP concierge) em uma unidade na semana seguinte.

As noites funcionaram, mas mantê-las com funcionários custava caro demais. Então a equipe fez um hackathon interno curto sobre uma única pergunta: a entrada e a reserva em autoatendimento poderiam rodar no sistema de cadastro existente? Podiam, com limites. Só então o serviço lançou um desafio, em busca de um fornecedor capaz de oferecer acesso seguro em autoatendimento em muitas unidades. Cada formato respondeu a uma pergunta que o anterior tinha levantado.

O que fazer e o que evitar

Faça

• Nomeie a pergunta primeiro: conseguimos construir, o que devemos construir ou quem já tem isso.
• Enquadre o problema com uma Árvore de problemas e com Perguntas Como poderíamos (How might we), seja qual for o formato escolhido.
• Combine o dono com o formato: um líder de produto para o hackathon, um líder de serviço para o jam, um dono do negócio com a área de compras para o desafio.
• Use a mesma lógica da Matriz de decisão ponderada (matriz de priorização) nos três, com critérios ponderados pela evidência que cada formato produz.

Evite

• Fazer um hackathon para responder a uma pergunta sobre o que os usuários precisam.
• Fazer um design jam e prometer software funcionando.
• Lançar um desafio antes de a sua organização conseguir de fato contratar o vencedor e fazer o piloto com ele.
• Escolher o formato pela foto. O hackathon aberto com um prêmio grande é o mais visível e, para muitos problemas, o menos útil.

Perguntas frequentes

Um design jam é a mesma coisa que um hackathon? Não. Eles compartilham o formato curto e intenso, mas o hackathon é avaliado pelo que funciona tecnicamente e o design jam por um conceito de serviço se sustentar com usuários reais. Jams não exigem programação e passam muito mais tempo fora da sala.

Um desafio de inovação é melhor do que um hackathon para startups? Normalmente, sim. Startups estabelecidas raramente abrem mão de um fim de semana para construir do zero, mas se candidatam a um desafio que oferece um piloto real. Hackathons servem a quem está construindo algo novo; desafios servem a quem já tem algo.

Podemos fazer um hackathon e um desafio ao mesmo tempo? Pode, mas mantenha-os separados. Misturar funcionários construindo do zero com startups que já têm um produto cria uma disputa injusta e confunde a avaliação. Faça-os como duas trilhas com critérios diferentes, ou em sequência.

Para onde ir agora

Para o caminho do jam, comece pela Observação contextual e pelo Blueprint de serviço (service blueprint). Para testar o que qualquer formato produz, use o Protótipo em papel e o Teste concierge (MVP concierge). Todos os guias estão no índice de guias.