Como construir um produto mínimo viável de sucesso

Passei minha carreira no Vale do Silício, profundamente imerso em sua vibrante cultura empreendedora. Toda startup está em uma jornada emocionante e muitas vezes perigosa em território desconhecido, e eu embarquei nessa jornada várias vezes – como engenheiro de software, gerente de engenharia, CTO, fundador e desenvolvedor freelance. Muitos dos produtos que construí alcançaram um público de milhares de pessoas – e alguns, milhões.

Na minha experiência, uma das ferramentas mais potentes do kit de ferramentas do Vale do Silício é a capacidade de equilibrar velocidade e profundidade ao lançar novos produtos. O best-seller de Eric Ries, The Lean Startup, codifica essa filosofia dentro do conceito do produto mínimo viável (MVP).

Por que os MVPs são mais úteis do que nunca

Uma das principais razões pelas quais a noção de MVP tem proliferado nos últimos anos é a velocidade e a escala sem precedentes com que agora podemos obter e agir de acordo com o feedback dos clientes. Em 2009, meu jogo para iPhone Slingshot Cowboy foi baixado por milhões de pessoas em uma semana de seu lançamento e rapidamente chegou ao topo das paradas (alcançou a posição # 1 de jogo grátis várias vezes ao longo de sua vida) . Uma grande parte desse sucesso pode ter sido sorte, mas se eu não coletasse feedback rápido e aplicasse os princípios básicos do MVP desde o início, não teria sido capaz de sustentar esse impulso por muito tempo.

Os princípios Lean resumem-se a ser capaz de iterar rapidamente, ser inteligente em gastar sua energia e recursos e ser ágil, focado e de mente aberta. Mas acreditamos que a aplicabilidade dessa metodologia não se limita a startups – equipes de grandes empresas podem maximizar seu ritmo de inovação criando MVPs de sucesso.

Alcançar o equilíbrio entre velocidade e qualidade é um dos mais importantes impulsionadores da inovação para organizações de qualquer tamanho. À medida que você lidera o desenvolvimento de seu próprio produto mínimo viável, aqui estão nossas estratégias para ajudar a manter esses dois ingredientes essenciais em equilíbrio.

Certificando-se de que seu MVP é 'V'

Se o seu produto não for viável, os esforços de desenvolvimento de sua equipe serão em vão. Para a criação bem-sucedida de um produto mínimo viável, você precisa de feedback interno inicial para defini-lo amplamente, feedback contínuo para moldá-lo adequadamente e ferramentas como testes A/B para mantê-lo prosperando.

Obtenha opiniões antecipadas das pessoas certas

Obter feedback negativo do usuário sobre seu MVP pode ser tão desanimador que você se sente compelido a descartar o projeto. Os inovadores podem evitar esse golpe devastador solicitando opiniões antecipadas das partes interessadas com uma compreensão profunda do espaço, bem antes de contemplar um MVP. É ainda melhor se você tiver consultores experientes que possam ajudar a definir seu MVP no estágio de conceito.

Quando uma equipe de inovação tem uma ideia promissora, pode ficar tentada a ocultar a criação do MVP: “Estamos em modo furtivo, ainda não posso falar muito sobre isso”. Isso pode valer a pena em alguns casos, mas, em geral, obter feedback é mais importante. Se você acha que seu produto representa uma invenção verdadeiramente original, você sempre pode registrar uma patente provisória.

Colete feedback definitivo do usuário

Mesmo que você se considere um visionário em sua indústria ou setor, seus juízes finais são seus usuários, e eles podem provar que você está errado em muitas coisas. Coletar feedback da experiência do usuário e rastrear o comportamento do usuário estão entre os objetivos mais importantes do MVP.

Insira a análise. A coleta de dados abrangentes é a chave para alcançar um dos principais objetivos do seu MVP – “aprendizagem validada”, um processo no qual se aprende experimentando uma ideia inicial e medindo-a para validar (ou invalidar) o efeito. Isso não significa que você deseja acompanhar tudo sobre o UX que puder – em vez de ficar sobrecarregado com volumes de dados brutos, identifique as métricas mais importantes.

Use testes A/B para iterar rapidamente

O teste A/B tornou-se um elemento básico da empresa quando se trata de refinamento de produtos. Sempre que você precisar escolher entre comportamentos alternativos de produtos, o teste A/B é uma maneira de fazer isso em tempo real sem precisar lançar uma nova versão.

Por exemplo, se o seu produto for um jogo, você pode tentar diferentes configurações de jogo e examinar suas análises para deduzir qual combinação afeta positivamente suas principais métricas: jogo mais longo, melhor aderência etc. Foi exatamente isso que fiz para a maioria dos meus jogos: todos os aspectos da jogabilidade eram controlados por uma configuração que eu podia ajustar em tempo real. Essa forma de aprendizado validado me ajudou a determinar a combinação ideal de configurações para meu mercado-alvo.

Para leitura adicional, Steven Dow, de Stanford, explora variações desse conceito em How Prototyping Practices Affect Design Results.

Observe o espaço do seu produto

Não importa quão original sua ideia pareça, tenha certeza de que alguém já pensou nela. Se o seu produto mínimo viável atende a uma necessidade oportuna e urgente do cliente, é provável que, quando você terminar, seu concorrente também esteja ganhando força. A estabilidade é importante—como a próxima seção enfatiza—mas não há problema em ajustar seu MVP de tempos em tempos, inspirando-se nos concorrentes e mudando o foco para enfatizar os recursos que são sua vantagem competitiva.

Encontrar o equilíbrio entre “mínimo” e “viável” é uma habilidade intuitiva e que você precisará exercitar repetidamente, especialmente se o mercado mudar antes de enviar seu MVP.

Encontrando o 'M'

Depois de determinar um produto viável que atenda a uma necessidade clara de seu mercado-alvo, é essencial restringir o foco de sua equipe.

Defina seu produto

Um MVP é como uma boneca matryoshka: sempre há um MVP menor dentro. A definição do produto consiste em encontrar o mínimo mais prático, dependendo de seus objetivos.

Se o seu produto for voltado para o usuário, comece com wireframes – este é o seu primeiro MVP mais interno. A próxima “boneca” pode ser um “click dummy”, uma demonstração interativa que não faz nada de verdade, mas permite que você a veja na plataforma de destino e tenha sua primeira experiência com o fluxo do usuário.

Quando estiver satisfeito com esse protótipo, comece a criar a boneca maior, a camada que começa a fornecer valor real aos usuários. Nesta fase, você pode optar por começar a detalhar os recursos principais. Conclusão: defina claramente os mini-marcos, não vá em frente e certifique-se de que atendeu aos seus próprios critérios antes de avançar.

Isso é verdade para o MVP que sua empresa traz inicialmente ao mercado, mas a mentalidade mínima viável também deve continuar ao longo de todo o ciclo de vida do seu produto. Pense em cada nova versão como um MVP maior – quando você adiciona uma nova camada de novos recursos, certifique-se de que ela se encaixe perfeitamente na anterior, fazendo o mínimo de alterações necessárias para obter uma nova versão viável.

Encontrar o equilíbrio entre “mínimo” e “viável” é uma habilidade intuitiva e que você precisará exercitar repetidamente.

Gerencie com disciplina

Independentemente de seus stakeholders mais expressivos estarem dentro de sua empresa ou clientes externos, eles fariam bem em serem informados sobre os perigos da fluência de recursos e suprimir seus impulsos de adicionar novos “obrigatórios” no último momento.

Se não for controlada, a tendência a desviar-se do mínimo definido drenará o moral. O momento de orgulho em que os desenvolvedores terminam de conectar todos os componentes se torna um anticlímax. Objetivos em constante movimento alimentam a instabilidade do produto.

Especialmente na empresa, o processo de construção de MVPs bem-sucedidos se beneficiará de patrocinadores executivos lembrando seus colegas e outras partes interessadas – sempre que necessário – que “Precisamos parar agora e lançar esse recurso. Pode não parecer bom o suficiente para você, mas será muito pior se estiver quebrado.” Como executivo, é seu trabalho proteger os desenvolvedores de influências externas, dando o exemplo dentro de sua cultura de trabalho de manter as prioridades.

Engenheiro com disciplina

Por outro lado, os desenvolvedores de software e seus gerentes devem apreciar os prazos e manter suas aspirações perfeccionistas sob controle. Aqui está um cenário comum: “Este pedaço de código parece feio, aquele é realmente ineficiente; temos que limpar e refatorar.”

Os desenvolvedores podem estar certos em dizer isso, mas seus gerentes ainda devem reagir. Como gerente técnico, você pode estar feliz com a atenção deles aos detalhes e querer agir de acordo com isso. Mas é uma questão de tempo – lembre-se da importante consideração de enviar e obter feedback e, em vez disso, anote os problemas não críticos para a missão, limpando-os na próxima iteração.

Princípios Lean em ação

O sucesso do seu produto depende totalmente da dinâmica do mercado que você está prestes a entrar. Mas onde quer que você trace a linha de definição do produto para o seu MVP, oferecemos duas táticas práticas adicionais que as empresas de sucesso usam para enviar seus MVPs.

Faça uso de componentes de terceiros

Na medida do possível, as equipes de inovação não devem reinventar a roda ao criar MVPs. Você sempre pode substituir componentes de terceiros posteriormente por algo desenvolvido internamente, quando for a hora certa. A vergonha da falta de originalidade já se foi: é uma prática comum agora, e muitos dos blocos de construção são de código aberto e personalizáveis.

Por exemplo, se o seu produto inclui comunicação em tempo real, existem excelentes soluções de terceiros que são fáceis de integrar e incluem recursos importantes como interfaces de usuário personalizáveis, infraestrutura de comunicação e criptografia. Da mesma forma, se você estiver criando um aplicativo, obter uma aparência profissional com animações e transições rápidas pode não exigir um designer interno – seus desenvolvedores podem economizar tempo com componentes de terceiros.

É verdade que poucas soluções de terceiros se encaixam perfeitamente em seus casos de uso. Mas eles não precisam – ainda. Contanto que eles permitam que você envie um produto que possa validar investimentos futuros em soluções personalizadas, você ainda estará à frente.

Reduza o tempo de desenvolvimento, mas não sacrifique uma base sólida para o futuro

Seu primeiro desenvolvedor tem que ser de alto nível. Não comece com estagiários: invista no talento desde o início. Isso pode soar como uma contradição da premissa central da metodologia “enxuta”, mas “barato” não é necessariamente “enxuto”. Embora até os orçamentos corporativos possam ser apertados, a taxa horária de um desenvolvedor é apenas um componente do custo – o tempo de desenvolvimento cresce em proporção inversa à taxa horária. Multiplique os dois juntos e sua vantagem de custo já se foi.

Adicione o tempo que você gasta orientando e perseguindo bugs que não deveriam estar lá em primeiro lugar. Considere as despesas gerais de cada dia perdido: espaço do escritório, salários de outros funcionários, taxas de servidor, etc. Leve em consideração intangíveis como o custo de oportunidade se você chegar muito tarde ao mercado.

Fazendo as contas, você percebe que será muito melhor contratar um desenvolvedor “caro” e experiente para produzir um MVP do que um monte de juniores. Desenvolvedores juniores podem vir mais tarde, assim que a base do seu produto estiver construída e você começar a pensar em otimizar o custo de longo prazo.

Aqui está um exemplo da vida real. Um amigo meu empresário queria adicionar alguns recursos aparentemente triviais ao seu MVP. Ele tinha um desenvolvedor muito experiente na equipe que vinha produzindo ótimos resultados a US$ 120/hora. Pensando que os próximos recursos poderiam ser mais baratos, meu amigo contratou um estagiário por US$ 30/hora.

O estagiário terminou quatro dias depois. Em um exame superficial, os recursos pareciam estar funcionando, e meu amigo passou para o próximo estágio. O desenvolvedor experiente se envolveu novamente e percebeu que não apenas o código estava falhando em alguns casos de canto, como era insustentável daqui para frente. Então ele passou um dia inteiro reescrevendo.

Quatro dias de trabalho de um estagiário ($ 960) mais um dia de reescrita ($ 960) = $ 1.920. Se o desenvolvedor experiente tivesse trabalhado no recurso em primeiro lugar, teria sido feito em um quinto do tempo e custaria menos da metade do dinheiro, mesmo sem outros custos incluídos.

A perfeição ainda não é o objetivo, mas existe o risco de corrigir demais a qualidade – você pode desacreditar completamente seu produto lançando algo que está falhando a torto e a direito, não polido, desajeitado e simplesmente inutilizável. Como resultado, você pode não ter uma segunda chance.

Aguce seus instintos e aproveite a aventura

Nós apenas tocamos em alguns aspectos do desenvolvimento do MVP aqui. Mas mesmo com um guia exaustivo, sempre haverá mais no processo do que você acreditou, mais trabalho do que você previu e mais desafios do que você previu.

Em algum momento você tem que traçar a linha e levar seu produto para o mundo. Este é o momento mais arrepiante e emocionante, e não há ciência exata para isso. Você precisa confiar em sua intuição, mas seguir os princípios lean no processo o ajudará a aprimorar seus instintos e facilitar essa decisão crucial. E uma vez que você alcance esse primeiro marco de feedback positivo e tenha confiança em sua visão, você pode começar a avançar cada vez mais longe, nas profundezas, em direção ao produto dos seus sonhos.