Lean Startup em Corporação, 10 maiores aprendizados até o momento

Introdução e ambiente de negócios: Concrete Solutions aplicando Lean Innovation 

Sobre generalização prematura e necessidade de empirismo

caution

Alguns conceitos e ferramentas têm uma combinação perigosa de abrangência, poder e simplicidade conceitual que levam a uma reflexão imediata de praticantes das mais variadas áreas assim que os aprendem: “Isso também pode ser aplicado em XXXXX”, onde XXXX é o domínio conceitual em que eles estão mais confortáveis. Esta reflexão acontece antes que o conceito tenha sido corretamente entendido e eventualmente fora das condições de contorno onde o modelo foi criado.

Isto aconteceu na minha experiência com coisas bem variadas como  Mapa de Forças de PorterMatriz BCG, SCRUM, Opções Reais e, recentemente, Customer Development & Lean Startup.

O problema dessa abordagem não é obvio, mas é muito sério. Antes de você generalizar um modelo, é necessário um conhecimento profundo dele. Na minha experiência, esse conhecimento não vem de uma reflexão isolada sobre o tema, mas da aplicação repetitiva em um ciclo de aprendizado que alimente um mesmo grupo de praticantes. Esse grupo acumula a experiência e reflexões passadas iterativamente até que se crie músculo intelectual (reflexões validadas e ortogonais) e não gordura (“entendi a superfície”).

Trajetória

No contexto deste artigo, é importante entender as particularidades da nossa trajetória: passamos por Waterfall em 2000, RUP em 2003, SCRUM em 2007 (depois Kanban), Customer Development e BMG no final de 2010, Lean Startup, Lean Analytics e AARRR + Inbound Marketing (Web) 2011, Marketing Digital Mobile &   Lean Innovation (L.S. em corporação) em 2012.

Abordagem, olhando para trás

Quando começamos a generalizar o modelo de Lean Startup em 2012, tínhamos a nosso favor um grupo que fazia SW junto, como empresa, há 14 anos e um “site SCRUM” com cinco anos de maturidade. O resto era muito recente para nós e para o mercado, então, a trajetória de aprendizado foi extremamente empírica.

040-empiricism-and-reason

Aprendizado

Depois desse grande aviso de cuidado, lá vão as 10 maiores reflexões que fizemos neste período.
Obs: quando o “conhecimento validado” tiver caráter de antipattern, a ideia é conduzir um diálogo e propor uma hipótese de solução.

1) O inimigo é sempre interno.

enemy-within
Os motivos de falha dos produtos digitais nunca são externos. A competição é irrelevante. Utilizando a metáfora da “Idea Maze” do @cdixon, a busca da validação do modelo de negócio de sucesso é como achar a saída de um labirinto, o bom fundador é aquele que consegue apesar da desorientação natural, tomar boas decisões de caminho baseadas em cada caminhada anterior. Competição é só sinal de que tem mais gente no labirinto e que você deve estar próximo de alguma coisa. Estendendo a metáfora, o minotauro é o burn rate, que pode te pegar antes de você encontrar a saída.

Workaround: Existe uma enorme necessidade de facilitação interna com as áreas que eventualmente poderão receber o modelo de negócio validado e as áreas com poder de veto. O foco tem que sair de funcionalidades e ir para resultados de negócio, que devem ser comunicados à exaustão, naturalmente gerando um empuxo até os tomadores de decisão.
No livro Lean UX, Jeff Gothelf fala “shift the conversation of the leadership from features, to outcomes. Product managers and product owners must determine which business metrics require their attention. In turn, have conversation around outcomes with managers, this way the shift will inevitably go to the highest levels of the organization”.

2) A principal causa de insucesso e mortandade de iniciativas é a penalização do erro.

XERXES-300_510x383
Se não houver uma mudança cultural drástica na área de produtos/inovação e os PO/fundadores ou intraempreendedores forem encorajados a tomar risco, o anti-pattern da Profecia do Fracasso Autorealizável toma forma.

Workaround: Temos que realmente implementar uma nova visão do que é geração de valor e entender conceitos de contabilidade de inovação e “o que aprendemos até agora”, onde gerar novos intraempreendedores é tão importante quando o produto em si. Uma maneira de precificar isto é procurar casos de fusão e aquisição, e precificar esse processo de inovação como uma alternativa a esses investimentos. 

3) O fracasso é uma profecia auto-realizável.

Agile-Waterfall-Success-Failure-Rates
Os times de TI criados num ambiente Waterfall foram selecionados darwinianamente pela sua capacidade de sobreviver a desastres. Com um método de desenvolvimento de produto/SW que tem 14% de chance de sucesso  é difícil não entender a posição deles.

Quando o projeto começa a se materializar, o antipattern que pode ser modelado como o dilema do prisioneiro, o pior resultado vai acontecer.
Se o time de negócios (business owners ou analistas) se colocar como cliente do fracasso de terceiros, viverá para fracassar uma nova vez (“live to fail another day”). Se o time de negócios e dono da visão se comportar dessa forma, o fracasso é uma profecia auto-realizável.

Workaround:


images

Peça desculpas, não peça permissão, coloque em produção, gere conhecimento validado e divida isso com o time. Treine, não espere que o time do cliente se comporte como POs maduros se eles não viveram isso antes e nem foram treinado formalmente como tais.

4) Os Produtos Mínimos Viáveis nunca são Mínimos.

ironman_mvp
O custo político de fazer a coisa realmente iterativa e empírica no desenvolvimento de produto é percebido como alto demais. O que acontece, na maioria das vezes, é um desenvolvimento ágil sem Customer Development (validação de problema/solução) no início que deve gerar no time uma busca paranoica de ir para produção o mais rápido possível. Vale a máxima “o projeto começa quando os stakeholders acham que ele terminou” (primeiros releases em produção). A partir da primeira versão em produção o PO/fundador precisa chavear mentalmente para CustDev e o time trabalhar com sprints de uma semana ou Kanban.

Workaround: Faça o projeto numa “empresa de propósito específico”, diminua o risco de marca. Consiga o mandato para implementar um MVP menor e validar proposições centrais no longo prazo. Crie o ambiente para que o cliente entenda as bases dos processos lean e BMG de validação de problema para que as visões a virarem MVP venham com níveis melhores de validação de problema.

5) Continua sendo um mundo de orçamento, porém eles são diferentes.

burn-rate
Faça orçamento levando em conta o MVP político (gordo) que dificilmente levará menos do que 3 ou 4 meses. Depois disso podemos usar métricas de validação de modelo de negócio de startup como base para o orçamento. Por outro lado o orçamento via burn rate com três linhas, time, cloud e marketing, funciona bem. Adicionalmente, acredito que o prazo mínimo de burn rate deve ser 12 meses e potencialmente 18, se nesse cenário.

Workaround: Para ciclos de validação mais curtos, é necessário um mandato para o time de sair do escritório no dia zero, implementar MVPs realmente pequenos e eventualmente decidir sobre pivot,persevere or close. Neste caso (close) esse time e recursos dessa iniciativa são realimentados no portfólio.

6) Estruture o time para lidar com a estrutura de governança.
Emergiu a necessidade de uma mentoria adicional ao SM (Scrum Master) e PO(s) para lidar com os níveis hierárquicos mais altos que estão longe da ação. O time é um eletroímã de mísseis políticos, porque está naturalmente exposto a risco, e essa mentoria precisa blindar esse risco.

7) Os objetivos são duplos, fazer o produto e desenvolver times e esquadrões.

seal-team-6
Se o PO/fundador for externo, a corporação vai detectar um DNA de fora e rejeitar o produto quando ele tiver que ser reinserido no ambiente corporativo para seus novos “pais”. Tão importante quanto validar o modelo de negócios é formar POs/fundadores e esse processo de aprendizado é contínuo.

8) Você só deve inserir de volta na corporação produtos com modelos de negócio validados.

BM-Validation
A idéia é envolver os possíveis “donos” e “blockers”, mas conseguir os “waivers” dos seus “sponsors” principais para usar plataformas, método, alocação de despesas, contratação de terceiros adequada para inovação, o que significa provavelmente nada do que é usado atualmente pela corporação. Essas ferramentas são adequadas para execução eficiente de um modelo de negócios validado e não para a busca de validar um novo modelo. Por sinal, sem open source e cloud, a chance de sucesso é mínima (condições necessárias e obviamente não suficientes).

9) Valuation para ativos digitais não é uma ciência óbvia.
A ferramenta habitualmente utilizada para justificar investimento em corporações é o Fluxo de Caixa Descontado, buscando taxas de retorno maiores que o WACC (custo de capital médio ponderado) da empresa. Nesse contexto, avaliações por paralelo, uso de séries históricas de classes de ativo semelhantes, e, talvez, opções reais são mais indicadas. Tratar o processo de tomada de risco como se a classe de ativo fosse um negócio sem incerteza irá levar a uma alocação errada de recursos. Se por outro lado a estratégia de investimento  “Spray & Pray” de Venture Capital americano não é aplicável, existe, em minha opinião, a necessidade de espalhar risco num portfólio de inovação.

10) O jogo é de estrutura e cultura.
Deve existir uma estrutura fatorada com representantes das áreas de negócio (futuras receptoras) em comitês. Continuo advogando o conceito de aceleradora corporativa (semelhante a estrutura de ágil em larga escala explicada pelo pessoal do Spotify) com esquadrões se comportando como startups e POs como fundadores.
Tem que haver condições para aparecimento de uma cultura de tomada de risco e de “ownership”, onde curto e longo prazo possam conflitar, mas que a busca de conceitos necessários como “tração” e “validação” de modelo/aprendizado não sejam mortos numa busca prematura de monetização ou materialização de um produto.

  • Barizon

    Perfeito, Fernando! Experiência valiosa. Parabéns!