O que é Lean Startup e como aplicar fora de uma startup

Lean Startup é um método para descobrir se vale construir algo antes de construir tudo. Você entrega a versão mais simples que já é utilizável, mede o que acontece no uso real e decide com base nisso se muda de direção ou continua. A ideia central não é construir rápido, é errar cedo, quando o erro ainda é barato.

O nome vem de startup, mas o problema que ele resolve não é exclusivo de startup. É de qualquer organização que aprova orçamento para um produto antes de saber se alguém quer aquele produto.

O cenário é conhecido: um ano de projeto, orçamento aprovado, plano de negócios bem feito, produto pronto. Três meses de divulgação e a venda não acontece. Ninguém errou a execução. Erraram a premissa, e descobriram no fim.

De onde o método veio

Eric Ries é empreendedor do Vale do Silício e desenvolveu o Lean Startup a partir dos próprios fracassos, observando startups que morriam em um ano com a equipe convencida de que estava fazendo tudo certo. Publicou o livro The Lean Startup em 2011, e desde então o método passou a ser aplicado também em corporação grande lançando produto novo.

A base é o pensamento Lean da Toyota, formulado por Taiichi Ohno nos anos 50 e 60: eliminar desperdício e valorizar quem faz o trabalho. A tradução do Lean para produto digital é direta, e desconfortável. O maior desperdício não é código malfeito. É código bem feito que ninguém usa.

O que substitui o plano de negócios

Ries propõe trocar o plano de negócios extenso por um instrumento mais honesto sobre o próprio grau de certeza. O Canvas é o mais usado: um diagrama de uma página que explicita como o negócio pretende criar valor, para quem e a que custo.

A diferença não é o formato. É o que você faz com o documento.

Um plano de negócios é um compromisso. Um Canvas é uma lista de hipóteses, e hipótese existe para ser testada.

O MVP não é uma versão pior do produto

Essa é a parte mais mal entendida do método, e a que mais gera projeto ruim quando se entende errado.

MVP não é protótipo cheio de bug, que só ensina que o produto está quebrado. E também não é o produto completo com tudo pela metade. É a versão mais simples que já resolve o problema de alguém de verdade, porque só assim o comportamento de quem usa vira informação.

O exemplo do carro ajuda. No modelo tradicional você monta rodas, chassi, motor, e só na última etapa existe algo que anda. No modelo incremental, cada etapa entrega algo que já leva a pessoa de um lugar a outro: skate, patinete, bicicleta, carro. O destino é o mesmo nos dois. Muda o momento em que você descobre que o destino está errado.

E aqui está a razão prática de fazer assim: quando a validação acontece só no fim, quem conhece o assunto sabe o que vem. O cliente quer mudar o escopo, ou diz que o produto não atende. Não porque agiu de má fé, mas porque aquela foi a primeira vez que ele viu o produto funcionando.

As ferramentas que sustentam o método

Entrega contínua. Se o produto muda a cada rodada de feedback, a organização precisa conseguir publicar mudança com frequência e sem drama. Sem isso, o ciclo trava na engenharia e o método vira teoria. Não é detalhe técnico, é pré-requisito.

Teste A/B. Duas versões no ar ao mesmo tempo, para decidir por comportamento em vez de por reunião. Serve quando existem dois caminhos plausíveis e nenhum argumento decide.

Métrica acionável. É a métrica que aponta uma ação. Número de download por plataforma diz se investir em web ou mobile. Total de visita acumulada não diz nada, só faz o gráfico subir. Ries chama essa segunda categoria de métrica de vaidade, e ela é confortável justamente por não cobrar decisão.

Pivotar é mudar a hipótese, não desistir

Pivotar é corrigir a direção para testar uma hipótese diferente sobre o produto, o mercado ou o crescimento, mantendo o que já se aprendeu.

Na prática é a decisão mais difícil do método, e não por razão técnica. O MVP nasceu de uma hipótese que alguém defendeu internamente. Quando o dado contraria a hipótese, existe trabalho investido, expectativa criada e alguém que apostou publicamente naquilo.

É aí que o método cobra maturidade organizacional, não disciplina de processo.

Na minha visão, o que trava o pivô em empresa grande raramente é falta de dado. É que interromper um investimento aprovado exige uma governança que aceite isso como resultado legítimo, e não como fracasso de quem propôs.

O ciclo construir, medir, aprender

O ciclo tem três etapas e uma direção.

Construir um MVP a partir da hipótese. Medir o que acontece quando ele é usado, com métrica que aponte ação. Aprender, o que significa terminar com uma decisão: pivotar ou seguir.

Repare que o ciclo não termina em entrega. Termina em decisão. Um ciclo que produz incremento e nenhuma decisão não é Lean Startup, é desenvolvimento incremental com nome bonito.

O WhatsApp é um caso conhecido, e vale contar certo porque a versão errada circula muito. O aplicativo lançado em 2009 não era de mensagem. Era um app de status: você atualizava o seu para os contatos saberem o que estava fazendo. Quando a Apple liberou o push notification, as pessoas começaram a receber aviso da mudança de status dos amigos e passaram a responder umas às outras ali. Jan Koum percebeu o comportamento e pivotou o produto para mensagem.

Ou seja, o caso não é sobre alguém ter acertado a ideia no começo. É sobre alguém ter medido o uso real e mudado de direção por causa dele. É exatamente o ciclo, e o pivô é a parte que importa.

Feedback que serve e feedback que engana

Ries separa feedback qualitativo de quantitativo, e os dois têm armadilha.

O qualitativo é o que a pessoa diz. É fácil de obter e fácil de contaminar, porque a forma da pergunta induz a resposta. Perguntar "você usaria isso?" quase sempre produz sim, e sim não é uso.

O quantitativo é quanta gente realmente usou, com que frequência e até onde foi. É mais trabalhoso e menos gentil, e é o que responde se o produto tem valor.

Prefira pergunta aberta a pergunta de sim ou não. E prefira observar comportamento a coletar opinião.

Onde isso encosta na governança

Lean Startup não é sobre lançar produto pequeno. É sobre reduzir o intervalo entre decidir e descobrir.

Em uma startup isso é sobrevivência. Em uma empresa estabelecida é mais difícil, porque o ciclo de orçamento, a aprovação de investimento e a avaliação de quem propôs o projeto costumam ser anuais, enquanto o aprendizado é semanal.

Na sua organização, a decisão de continuar um produto é revisitada com que frequência? Ou ela é tomada uma vez, no começo, quando ninguém ainda tinha dado nenhum?