Eu abandonei o MVP

Rich Mironov - 22/09/2020 Traduzido por: Marcelo Knakiewicz

Depois de anos lutando, decidi aconselhando todos os meus clientes e os coaches de líderes de produto para pararem de user o termo "MVP". Não para parar de fazer validação, discovery, prototipagem ou experimentos, mas para remover o rótulo MVP de todos seus documentos, apresentações e conversas. Para apagar as letras MVP de todos os roadmaps e mapa de produto. Banir do vocabulário, não deixar ser dito. Explico porque...

Na maioria das vezes, vejo no lado "Criador" de empresas de softwares (Desenvolvedor, designer, pessoas de produto, DevOps, Tech Writers...) e no lado "go-to-market" (Vendas, Marketing, Support, Customer Success...) definições incompatíveis para o termo MVP.

Os "Criadores" referem-se a Eric Ries (e muito antes) para definir MVP, como "qualquer oferta ou capacidade que requer o mínimo de esforço para construir enquanto concede a empresa a maior habilidade de aprender com o usuário". Criticamente, isso pode ser uma descrição de text ou esboço Balsamiq ou protótipo web ou flipbook que nos dá a chance de mostrar a um estranho o que queremos dizer. Não se destina à venda ou receita, mas para aprendizado rápido. O "P" nominalmente significa "Produto", mas quase sempre não é um produto.

Já o lado "Go-to-Market" querem algo para vender ao mercado. Portanto, apesar de nossos longos argumentos acadêmicos, eles se concentram na palavra "Produto". Na verdade, a definição mais frequente que recebo dos executivos da GTM é "Algo que posso vender agora mesmo para clientes selecionados pela atual receita, em vez de esperar mais alguns trimestres para o produto perfeito". Em questão de minutos, essa frase é reduzida para "Algo que posso vender agora". Todo mundo fica empolgado com apresentações ao vivo para clientes (E até fechando venda), mesmo que até agora sejam apenas slides simulados.

Distinções sutis são perdidas. Nós, "Criadores", mesmo sendo os reais qualificadores, mesmo advertindo, avisando, somos esquecidos. Arquivado como "Desculpas lamentáveis da gestão de produtos por falta de datas de entrega". Então, na minha humilde opinião, chamar algo de MVP é um convite para o caos.


Sintomas


Alguns resultados ruins dessa confusão:

  • Nós nunca terminamos nosso MVP. Stakeholders constantemente expandem a definição de "Pronto", já que não conseguimos entregar um produto com receita real sem as funcionalidades A, B, C, X, Y e Z. Isto causa uma pane no processo de aprendizado e retarda a entrega. Engenharia e Produto são descartados como desperdiçadores de tempo intelectual.

  • Nós iniciamos os esforços de marketing/suporte muito cedo. Marketing precisa de informações relacionadas a estágios avançados de um produto: telas, segmentação nítida, declarações de benéfico validadas, cálculos de ROI, clientes referencia. Suporte precisa de guias de instalação, treinamento, FAQs, categorias para segmentar BUGs. Isto tudo (Claramente) não existe ainda, uma vez que nós ainda estamos testados/conceituando os problemas e recursos. A maior parte de tudo isso mudará criando retrabalho várias vezes, já que nós adicionamos/repensamos/atualizamos as funcionalidades, substituindo os mocks pelos visuais finais, revisando preço e embalagem. Muita frustração e perda de tempo. Mas a pressão por ativos muito cedo é irresistível.

  • Nós apressamos nosso "Aprendizado" com o MVP para clientes pagantes ou potenciais. O pessoal de vendas acredita que isto é real, e engaja muito cedo. Já que existe apenas algumas funcionalidades parciais funcionando (ou nenhum), todo mundo fica envergonhado. Times prometem nunca vender a versão final, independente de quando ela for lançada, e conclui que o time que cria é incompetente. O produto completo está morto antes mesmo de nascer, já sendo taxado como um fracasso.

  • Produto e Design/UX são barrados de mostrar mais protótipos para clientes pagantes. A definição clara entre validação e venda está perdida, com times de vendas protegendo clientes específicos (e nossa reputação) a todo custo. Os fabricantes se contentam em interrogar nossos próprios funcionários sobre as prováveis reações dos usuários. Isso enfraquece o motivo pelo qual Designers e Gerentes de Produtos precisam de feedback direto e reações de usuários ativos no início do ciclo do produto: para equilibrar miopia interna, viés diversos, falta de contexto técnico e nossas muitas suposições erradas. Prefiro que aprendamos nossas duras lições muitos meses antes do envio, com baixo custo, em vez de nos desculpar pela v1.0

Geralmente, isso é mais do que apenas um problema de vocabulário. Mas podemos reduzir a confusão / frustração escolhendo palavras inequívocas com significados claros. Aqui está um conjunto de palavras para utilizar no lugar de MVP:


"Validação de Problema" ou "Teste de Conceito" (NENHUMA RECEITA)

  • Algumas ferramentas para auxílio, Jobs To Be Done, Canvas, Mapas de Jornada, Protótipos de Papel, Histórias de Heróis, Entrevistas do gênero "O que você compraria no lugar?"

  • Objetivo: Entender se identificamos a causa raiz do problema. Podemos aprender o que realmente está quebrado e testar algumas soluções? Quão entusiasmados estão os clientes em potencial?

"Workflow conceitual" ou "Testes de UX" (NENHUMA RECEITA)

  • Inclui simulações ou flipbooks ou interfaces web clicáveis sem lógica interna

  • Objetivo: Verificar se os usuários concluem uma tarefa. Quais inputs estamos perdendo? Nomeamos as coisas corretamente? O Fluxo de trabalho A ou o Layout B tem melhor resultado?

“Validação de conceito da engenharia” (NENHUMA RECEITA)

  • Pode incluir dados de amostra executados por meio de algoritmos parciais ou testes de escalabilidade, ou código "Hello world" para integração de API

  • Objetivo / Perguntas: a funcionalidade X funcionará? Estoura nossos servidores em nuvem? Encontramos algum sinal acionável nos dados? Nossa arquitetura faz sentido? Os primeiros testes técnicos mudam nosso escopo ou identificam recursos ausente?

"Beta teste técnico” (NENHUMA RECEITA)

  • Pode incluir um desenvolvimento primário, com funcionalidades principais mas limitação em segurança, verificação de erros, fluxos paralelos de uso e documentação. Nós provavelmente instalamos/configuramos em um usuário de teste.

  • Objetivo: verificar se um ou dois clientes mais interessados aceitam obter um produto versão inicial para testar. O que podemos aprender sobre seu ambiente de uso? Onde eles ficam presos utilizando? O que mais precisamos implementar para ter um volume de usuários de sucesso?

“Programa Early Adopter” (COM RECEITA)

  • Precisaremos de um produto funcional bastante completo para um conjunto restrito de clientes reais, complementado por muita paciência e ajuda prática. O gerente de produto deve ter um checklist qualitativo detalhado para garantir que estes são usuários "amigáveis" que atendem todos os requisitos técnicos. Idealmente, nenhum deles está atualmente negociando grandes acordos de licenciamento conosco.

  • Objetivo: Após a conclusão, queremos que eles nos paguem algo e sejam uma referência de vendas.

“Disponibilidade total de Mercado” (COM RECEITA)

  • Temos tudo o que precisamos para fechar um conjunto amplo de clientes pagantes. Isto inclui software totalmente testado, documentação, preço/embalagem, número de peças, ativos de marketing, geração de leads direcionados, inteligência competitiva, time de suporte treinado, problemas escalonados, materiais de parceiros / canal, etc.

  • Objetivo: Lançar um produto vencedor com receita notável, aclamação do mercado, clientes entusiasmados e glória refletida para a equipe que fabricou o produto.

Sound Byte


Você pode escolher quaisquer estágios e artefatos adequados à sua situação. Mas é crítico dar a esses estágios nomes simples e difíceis de interpretar erroneamente, que sinalizem claramente se haverá receita envolvida na etapa. Sem encheção de linguiça, sem posicionamento, sem ofuscação. Nossas equipes que produzem o produto e grupos de entrada no mercado trabalham muito para que possamos confundir uns aos outros. Assim fugimos da cilada de discutir durante mil horas se algo é mínimo, viável ou um produto.

Artigo original: https://bit.ly/3mygezc