Abandonar os seus preconceitos e aprender porque é que empresas de sucesso abraçam o MVP como chave para fazer os seus clientes felizes.
Por Arbi Vartan e Jeff Brinkerhoff
Slalom ama Agile. Estamos entusiasmados com os benefícios reais e mensuráveis que vimos as empresas ganharem com isso, e estamos falando de algumas de suas maiores vantagens em uma série de posts de blogs e um webinar-watch Agile gratuito on-demand.
O MVP, ou Produto Mínimo Viáveis, é básico para a prática do Agile. E também é algo que gera resistência. Já ouvimos nossos clientes dizerem coisas como: “Nossos executivos não querem o mínimo – eles querem a melhor qualidade possível”. De facto, porque não querem fazer o seu melhor? É uma grande pergunta, mas baseada num mal-entendido do MVP.
Coined by Frank Robinson in 2001, e popularizado por Eric Ries através do seu livro Lean Startup, o MVP tornou-se um pilar de equipas de produtos de alto desempenho em todo o mundo. Por que o Google tem sido tão dominante por tanto tempo? Porque é que a Apple faz alguns dos produtos mais populares do mundo? Porque é que a Netflix não só sobreviveu, como também prosperou para além do seu modelo de negócio original? Muitos fatores contribuíram, mas um tópico comum é que todos eles usam o MVP.
Então o que é o MVP? Aqui está a definição de Eric Ries: Aquela versão de um novo produto que permite a uma equipa recolher o máximo de aprendizagem validada sobre clientes com o menor esforço.
Como esta definição deixa claro, o MVP não é um produto com a menor funcionalidade possível necessária para um lançamento público. Não tem nada a ver com o lançamento público de um produto. Ao contrário, o MVP é a chave para usar o método científico para construir produtos. É puramente um mecanismo de aprendizagem validado, usado para testar hipóteses e descobrir o que vai atender as necessidades dos clientes.
Deixar o termo se você deve – mas manter o conceito
Na Slalom, integramos o conceito do MVP tanto na forma como construímos produtos para empresas como na forma como fazemos parcerias com elas para colher os benefícios da incorporação de princípios e práticas Ágeis em seu modelo de negócio. No entanto – após mais de vinte transformações empresariais Agile e centenas de parcerias entre indústrias – descobrimos que às vezes é mais simples não forçar o uso de termos como o MVP. Alguns mudaram para o termo “Produto Mínimo Amável”, e Henrik Kniberg (mais conhecido por seu trabalho com a cultura de engenharia Spotify) propõe o uso dos termos “O mais antigo possível”, “O mais antigo possível” e “O mais antigo possível”.
Any destes termos está bem. Agile é sobre equipes mais felizes, mais produtivas – não terminologia. Nossa abordagem a este ou qualquer outro conceito Ágil mal interpretado e pouco claro é saltar a palavra e fazer as três perguntas seguintes:
- Por que fazer? No caso do MVP, trata-se de aprender rápido, assim como os princípios subjacentes: satisfação do cliente, melhoria contínua e simplicidade.
- O que seria necessário para fazer isso na minha empresa? Oh, o poder de enquadrar! Em vez de perguntar se você pode fazer isso, nós nos afiamos nos bloqueadores-organizacionais ou não. A resposta a esta pergunta muitas vezes toma a forma de uma compra por indivíduos que se pensava serem inamovíveis.
- E se não o fizéssemos? Outra estratégia de enquadramento: focar nos custos do “slogging” juntamente com o status quo. Isto pode construir um senso de urgência e estabelecer alinhamento em torno de uma nova maneira de trabalhar.
Aqui está uma história sobre os perigos do status quo: Um projeto para uma empresa com a qual trabalhamos recentemente envolveu passar seis meses em um grande lançamento de software impactando mais de 200 usuários internos. Eles se trancaram em uma sala e completaram a construção e todos os testes. E foi apenas neste ponto que solicitaram o feedback de um punhado de analistas de negócios – não de usuários reais. Este tipo de actividade de caixa de verificação, demasiado tarde para causar qualquer impacto real, e sem um verdadeiro foco na aprendizagem validada, dificilmente se qualifica sequer como solicitação de feedback. É realmente uma tentativa de validar o inevitável.
O resultado foi previsível. Como tanto tempo e dinheiro já haviam sido gastos, eles se sentiram compelidos a avançar, e todos os 200 usuários rejeitaram o novo software devido ao seu lento desempenho e falta de usabilidade. Seis meses e mais de $12 milhões gastos, com apenas um dedo apontado entre as equipes de negócios e tecnologia para mostrar para ele.
Agora imagine este mesmo cenário com um MVP implantado para um grupo de usuários finais no início do projeto. Os desenvolvedores poderiam aprender imediatamente o que estavam errando, depois implantar mais MVPs melhorando iterativamente com cada um deles até a implantação de um produto final – desenvolvido com e aprovado por usuários reais. Um benefício adicional: Os usuários no grupo de teste seriam completamente investidos no projeto e o evangelizariam entre seus pares.
Vimos exatamente esse cenário se desenrolar, e é por isso que somos tão crentes no MVP – o que quer que você escolha chamá-lo.