Tiremesù
PT
Ecossistema e inovação abertaGuia prático9 min de leitura

Como trabalhar com startups sem desperdiçar o tempo delas nem o seu

Como grandes empresas podem trabalhar com startups: parta de um problema real, decida rápido e faça um piloto pago com critérios claros e contrato à vista.

Editores da Tiremesù

Como trabalhar com startups sem desperdiçar o tempo delas nem o seu

Para trabalhar bem com startups, parta de um problema que vocês já decidiram resolver, dê a uma pessoa autoridade para decidir rápido e faça um piloto curto e pago, com critérios de sucesso escritos antes do início e um contrato esperando caso dê certo. A maioria das colaborações entre grandes empresas e startups fracassa não porque a tecnologia esteja errada, mas porque a organização grande anda no seu próprio ritmo, muda de ideia e trata o piloto como um experimento sem consequência. Para uma startup, uma "prova de conceito" de seis meses, sem pagamento e que não leva a lugar nenhum, pode ser a diferença entre sobreviver ou não.

Este texto trata da mecânica prática. Para o quadro mais amplo de organizações resolvendo problemas juntas, veja Inovação em ecossistema.

Por que essas parcerias dão errado

Os dois lados funcionam em relógios diferentes. Uma startup mede o fôlego de caixa em meses; uma organização grande aprova orçamentos uma vez por ano. Os fundadores de uma startup decidem num dia; uma decisão corporativa pode exigir quatro assinaturas e uma análise de compras. Nenhum dos dois está errado, mas a distância produz as mesmas falhas o tempo todo:

  • A armadilha do scouting. A equipe de inovação conhece cinquenta startups, faz um demo day e não tem nenhuma unidade de negócio pronta para usar qualquer uma delas.
  • O piloto sem fim. O teste se arrasta porque ninguém combinou o que significava "sucesso", então ninguém consegue declará-lo.
  • A consultoria de graça. A startup passa semanas adaptando o produto aos seus requisitos, sem receber nada, e depois não tem mais notícia.
  • O muro de compras. O piloto funciona, a unidade de negócio quer a solução, e aí o cadastro de fornecedor, a análise de segurança e a licitação levam um ano.

A solução não é entusiasmo. É estrutura do seu lado.

Como fazer, passo a passo

  1. Parta de um problema que uma unidade de negócio assume. Não "queremos explorar IA", e sim um problema nomeado, com um dono nomeado que tenha orçamento e que vá mudar o jeito de trabalhar se uma solução servir. Escreva-o como uma pergunta Como poderíamos: "Como poderíamos reduzir o tempo que a nossa equipe de sinistros gasta lendo formulários escritos à mão?" Se nenhuma unidade de negócio aceitar ser dona, ainda não procure startups.
O canvas das perguntas Como poderíamos
O canvas das perguntas Como poderíamos
  1. Decida que tipo de relação você quer. De modo geral são quatro, e confundi-las desperdiça tempo:

    • Comprar: você vira cliente de um produto que já funciona. O caminho mais rápido e mais comum.
    • Pilotar: você testa um produto que funciona no seu contexto antes de comprar.
    • Codesenvolver: vocês constroem algo novo juntos, geralmente com questões de propriedade intelectual compartilhada.
    • Investir: você entra no capital. Outra equipe, outras condições, outro horizonte de tempo. A abordagem de "venture client", popularizada pela BMW Startup Garage a partir de 2015, defende que a maioria das organizações deve começar comprando e pilotando, e não investindo, porque ser cliente de uma startup cria valor para os dois lados mais rápido.
  2. Acerte o seu caminho interno antes de procurar. Antes de contatar qualquer pessoa, descubra o que a sua organização precisa para pagar um fornecedor pequeno: cadastro, análise de segurança e de dados, modelo de contrato, prazos de pagamento. Combine um caminho rápido para pilotos abaixo de um valor definido. Se você não consegue pagar uma startup em poucas semanas depois de um piloto bem-sucedido, resolva isso primeiro.

  3. Busque com o problema, não com uma chamada por "inovação". Descreva o problema, os dados e o ambiente disponíveis e como é um resultado bem-sucedido. As startups que não conseguem resolvê-lo vão se excluir sozinhas. Faça a pré-seleção com uma matriz de decisão ponderada curta: aderência ao problema, maturidade do produto, capacidade de entregar no seu ambiente, equipe.

O canvas da matriz de decisão ponderada
O canvas da matriz de decisão ponderada
  1. Dê uma resposta em dias, não em meses. Converse com as startups pré-selecionadas e decida. Avise as que você recusou que foram recusadas, e por quê. O silêncio custa mais a uma startup do que um não.

  2. Escrevam juntos o plano do piloto, numa página. Indique a hipótese, o que será medido, o limite para o sucesso, a duração, quem do seu lado dá suporte e o que acontece se passar. O formato de teste de hipótese funciona bem. Use o mapa de premissas para encontrar a premissa mais arriscada e teste essa primeiro.

  3. Pague pelo piloto. Mesmo um valor modesto muda a relação: os dois lados levam a sério, a startup consegue alocar gente e a sua organização já passa pelas etapas de compras de que vai precisar depois.

  4. Monte a equipe do seu lado. Um piloto precisa de um dono do negócio que vai usá-lo, de um contato técnico que libere acessos e de alguém que remova bloqueios. Uma matriz RACI para o piloto leva dez minutos e poupa semanas.

  5. Decida na data marcada. No fim, compare os resultados com o limite combinado. Passou: avance para um contrato em condições definidas de antemão. Não passou: pare e diga isso. "Vamos estender um pouco" é a resposta que faz todo mundo perder tempo; se for estender, estenda uma vez, por um motivo, com nova data.

  6. Planeje a implantação antes de o piloto terminar. Quem vai operar, com quais sistemas se conecta, quem treina os usuários. Um checklist de implantação evita que a passagem de bastão trave.

O que fazer e o que evitar

Faça

  • Nomeie um dono do negócio antes de contatar uma única startup.
  • Diga cedo às startups quanto você pode pagar, em que prazo e por qual processo.
  • Combine os critérios de sucesso antes de o piloto começar.
  • Pague pelos pilotos, mesmo que pouco.
  • Proteja a propriedade intelectual da startup. Seja claro sobre os direitos de que precisa e não peça mais do que isso.
  • Se der certo, apresente a startup a outras unidades. Uma referência sua pode valer mais do que o contrato.

Evite

  • Não faça demo days sem donos na plateia que possam comprar.
  • Não peça desenvolvimento sob medida durante um piloto. Teste o que já existe.
  • Não troque o responsável no meio do piloto sem uma passagem de bastão adequada.
  • Não deixe a análise jurídica começar só depois de o piloto dar certo. Comece em paralelo.
  • Não use pilotos para colher ideias de graça para um desenvolvimento interno. Startups conversam entre si, e a sua reputação se espalha.
  • Não meça o seu programa pelo número de startups que você conheceu. Meça quantos pilotos viraram contratos.

Exemplo ilustrativo

Ilustrativo. Uma seguradora de porte médio na Holanda queria reduzir o tempo que sua equipe de sinistros gastava com sinistros residenciais por danos causados por água. O diretor de sinistros aceitou ser dono do problema e separou um pequeno orçamento para o piloto.

Antes de buscar, o líder de inovação passou três semanas com a área de compras combinando um caminho rápido: pilotos abaixo de um valor definido poderiam usar um modelo de contrato curto e passar por uma análise de segurança mais leve, desde que nenhum dado de cliente saísse dos sistemas da seguradora. A chamada descrevia o problema, os dados anonimizados de sinistros disponíveis e a meta: reduzir com margem clara o tempo de tratamento dos sinistros simples, mantendo a precisão pelo menos no nível atual.

Doze startups responderam. Quatro foram pré-selecionadas com uma matriz ponderada; duas foram entrevistadas; uma foi escolhida em dez dias, e as outras três foram informadas de por que não tinham sido selecionadas. O plano do piloto coube numa página: oito semanas, três analistas de sinistros, um conjunto definido de tipos de sinistro, um limite para o sucesso e um preço de licença combinado de antemão caso passasse.

O piloto atingiu o limite na maioria dos tipos de sinistro e ficou abaixo em um. O diretor de sinistros assinou o contrato para os tipos que passaram, e o tipo restante foi para um segundo teste, mais curto.

Perguntas frequentes

Devemos pagar startups por uma prova de conceito? Sim, na maioria dos casos. Um piloto pago é levado a sério pelos dois lados, permite que a startup aloque pessoas e obriga a sua organização a passar pelas etapas de compras de que vai precisar de qualquer forma. Provas de conceito não pagas tendem a se arrastar e favorecem as startups que podem se dar ao luxo de trabalhar de graça, não as que têm o melhor produto.

Quanto tempo deve durar um piloto com startup? O suficiente para medir o resultado combinado, e não mais. Para um produto que funciona num processo definido, de seis a doze semanas é comum. Se o piloto precisa de seis meses, vocês provavelmente estão codesenvolvendo, o que exige outras condições.

De quem é a propriedade intelectual num piloto entre empresa e startup? Normalmente a startup mantém a propriedade do seu produto e de tudo o que traz, e você fica com os seus dados e com o que a sua equipe criar. Combinem por escrito os direitos de que você precisa para usar os resultados. A equipe jurídica decide os detalhes; o princípio é pedir só o que realmente for necessário.

Para onde ir agora

Use as perguntas Como poderíamos para enquadrar o problema antes de buscar, uma matriz de decisão ponderada para a pré-seleção e um teste de hipótese para escrever o plano do piloto. Para o quadro mais amplo, leia Inovação em ecossistema; para uma chamada pública a muitas startups de uma vez, veja Inovação aberta, cocriação ou crowdsourcing; e, para parceiros de pesquisa, Parcerias com universidades em inovação.