Produto Mínimo: Escolhendo o seu patinete

Um dos conceitos mais importantes de Lean Startups e Inovação é o do Produto Mínimo Viável (Minimum Viable Product, MVP). Embora tenhamos interpretações diferentes sobre o que é esse Produto Mínimo, o seu objetivo principal é validar algumas das principais Hipóteses de Negócio e colher evidências de que vale a pena construir mesmo esse produto.

Foco no Aprendizado

Nosso foco principal nos primeiros ciclos de prototipação e desenvolvimento deve ser o Aprendizado. Aprendizado sobre nossos clientes, sobre o mercado, sobre características do Produto.

Porém é muito comum vermos empreendedores se apaixonando pelo Produto em vez de buscar mais o Aprendizado. Para não gerar confusão: paixão pelo Produto é sensacional, mas devemos ter em mente que os artefatos construídos nos primeiros ciclos com frequência são descartados ou radicalmente modificados quando temos bons motivos para isso.

Um ótimo motivo: Você saiu do escritório e conheceu melhor sobre seus clientes e viu que suas hipóteses iniciais precisam ser um pouco adequadas para satisfazê-los. Este aprendizado é muito mais valioso do que qualquer artefato de software ou UX que você já tenha construído. Um resumo excelente desta abordagem está no vídeo abaixo.

Construindo o mínimo possível de software

Contrariando o que era senso comum há alguns anos, para avançar mais rápido você precisa começar construindo MENOS software. O MÍNIMO possível. Só o necessário para apoiar o aprendizado.

Isto tem 2 motivos principais:

• Construir software é DEMORADO e CARO, mesmo que o programador seja o seu sobrinho
• Quanto mais software você construir, mais software você terá que MANTER e isto te deixará mais lento para reagir às mudanças.

Pode parecer estranho um profissional de tecnologia te falar para construir menos software, mas esse é o caminho mais efetivo para ter sucesso com seu produto. Alocando capital no momento certo e no local certo.

Escolhendo o seu Produto Mínimo. Ou: Qual é o meu Patinete?

Recentemente a Spotify publicou um vídeo sensacional (embedded no final deste artigo) sobre sua cultura de desenvolvimento de Produtos. Uma metáfora super simples e valiosa deles descreve 2 possibilidades para construirmos o mesmo produto, como abaixo.

Se você está construindo um novo produto que é importante para alguém, a melhor escolha é entregar benefícios tão logo possível, mesmo que seja um produto inicial extremamente simplificado comparando com o que você deseja construir. Se o maior desejo do seu cliente é se deslocar por um trajeto de 5 a 10 km, talvez a melhor experiência seja dar um carro para ele. Mas se antes disso você já entrega um skate ou patinete ele já está tendo benefícios e fica feliz com você.

Esta metáfora é super útil para todos entenderem, mas com relação a um produto de software é muito comum que tenhamos dúvidas sobre ONDE e COMO simplificar e reduzir esforço sem prejudicar a PERCEPÇÃO de Qualidade. Vamos então elaborar 😉

Você está construindo um produto que terá de 5 a 10 mil clientes em algum momento, mas você tem um grupo pequeno de clientes iniciais que está disposto a Co-Criar o produto com você.

• Será que você precisa automatizar o disparo de e-mail Marketing no 1o mês se você não terá mais que 40-50 clientes nesse período?
• Você precisará pagar diversos fornecedores ao longo do tempo, mas será que nos primeiros 2-3 meses você não consegue usar seu Internet Banking pra isso?
• Você precisará segmentar a comunicação e as campanhas para ter um bom atendimento e um bom índice de conversão. Mas será que você precisa integrar um CRM à operação nos primeiros 6 meses? Sério mesmo que o Google Spreadsheets não resolve?
• Você também precisará emitir Notas Fiscais a cada venda, mas quantas vão ser? Se o seu produto tem cobrança mensal recorrente, será que você e alguns amigos não conseguem emitir as NFs manualmente durante quase 1 ano? Ou você aposta que seu produto já vai nascer com 1000 clientes mensais? 😉

Podemos pensar e ilustrar diversos exemplos onde é possível adiar ou eliminar um determinado desenvolvimento usando uma abordagem Concierge, na qual você tem pessoas realizando tarefas que poderiam ser automatizadas, mas não sabemos ainda se vai valer a pena. Boa leitura sobre MVPs Concierge aqui.

Porque queremos adiar esse tipo de esforço? Porque queremos concentrar todo nosso esforço inicial e foco em Ouvir o cliente! Se meus 5 clientes iniciais me deram 30 sugestões e críticas que são importantes para eles, atendê-los é muito mais valioso do que qualquer funcionalidade que os fundadores tenham pensado originalmente.

O desafio nesse contexto é avaliar sempre o que pode e o que não pode ser simplificado com foco na Experiência do Usuário/Cliente e na Percepção de Qualidade que ele terá.

Não vamos entregar um produto feio e com má usabilidade para nosso cliente porque ele não voltará. Mas talvez ele não esteja tão preocupado se a sua Landing Page está com um ícone 1 ou 2 pixels para o lado.

Não vamos fazer otimizações prematuras de engenharia se as páginas carregam rápido para poucos usuários. Vamos procurar entender quais são as páginas mais acessadas e usadas e deixar para otimizá-las quando der tempo.

Entrega o Patinete pro seu cliente o mais rápido que você conseguir e aí se concentre em ouví-lo e atendê-lo. É aí que começa o aprendizado e a chance do seu produto ter sucesso 😉

Spotify Engineering Culture – part 1 from Spotify Training & Development on Vimeo.

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.