O crescimento da indústria ligada ao pensamento, desenho e desenvolvimento de produtos digitais popularizou uma série de conceitos, entre eles e com grande vigor, a ideia de MVP, ou melhor dizendo, de “minimum viable product”. É difícil hoje em dia, participar num projeto sem que surja a discussão do que deve ser incluido no MVP do produto.
Embora seja bastante popular, o MVP está muito longe de ser um conceito fácil ou se quer consensual na interpretação. Não raras vezes, surge também no projeto, uma outra discussão relacionada com o real propósito do próprio MVP. É algo que permitirá testar simplesmente o conceito e depois é deitado fora? É uma primeira versão do produto e que deve marcar o lançamento ao mercado? Muitas são as perguntas, que mesmo com a popularização do termo, subsistem sobre o tópico.
MVP para todos os gostos
Acontece, que se olharmos com alguma atenção, a própria definição do conceito de MVP não é muito linear. A utilização do termo em vários contextos diferentes, enquadrado dentro de diferentes frameworks de trabalho, faz com que a sua definição, deva ser encarada com alguma prudência. A definição de MVP, a sua abrangência e oportunidade, diferente de contexto para contexto.
Seja numa lógica de Lean Startup, Design Thinking, User-centered Design, ou qualquer outra proposta metodológica, a definição do conceito de “minimum viable product”, difere bastantes vezes. Um pouco como em muitas coisas no universo da tecnologia digital, a adaptabilidade de conceitos a determinados contextos, é uma característica intrínseca dos processos de trabalho. Por conseguinte, será sempre muito difícil, no caso do MVP ainda mais, encontrar definições conceptuais que permaneçam imutáveis, independentemente dos projetos, dos contextos ou das equipas.

Pontos comuns
Contudo, apesar da multiplicidade de definições possíveis, relacionadas com o termo, existem algumas premissas, que independentemente da perspectiva, são bastante comuns. Conceitos, que apesar da interpretação e aplicabilidade ampla do termo, são quase sempre referenciados quando falamos de um MVP.
Processo iterativo
Seja em que contexto for, é bastante consensual interpretar o MVP como uma versão do produto em evolução constante. Quer isto dizer, que independentemente daquilo que possa constituir o “minimum viable product”, essa versão do produto terá sempre evoluções a seguir. Seja pelo incremento de novas funcionalidades, alterações as funcionalidades iniciais ou melhorias decorrentes do envolvimento dos utilizadores, quase tudo o que constituiu o MVP inicial será algo que deve ser iterado com o decorrer do projeto.
Poupança de tempo e dinheiro
A gestão eficiente de recursos é sempre um dos grandes desafios em qualquer equipa digital. Quanto mais inteligente for a gestão, mais oportunidades poderá a empresa abraçar no curto, médio e longo prazo. Na perseguição desta premissa, uma ferramenta como o MVP é um valioso instrumento de poupança, seja de orçamento ou de tempo das equipas. A oportunidade de evoluir uma ideia em pequenos passos, representa por norma um investimento ponderado em algo que se está ainda a descobrir qual a melhor solução.
Lançamento rápido
O tempo é em quase tudo no digital um ponto extremamente sensível. Seja o tempo que as equipas de projeto despendem em cada tarefa ou por outro lado, a rapidez com que as novas soluções chegam junto dos seus potenciais utilizadores. No contexto digital é impensável que uma solução demore meses, às vezes anos, até ser testada com utilizadores. Sem falar no risco que é implementar algo que pode não ter a receptividade que esperamos, o MVP permite também, acelerar ao máximo o primeiro contacto com os utilizadores, evitando que a concorrência ocupe primeiro o espaço de mercado em que vai operar o produto em desenvolvimento.
Um pouco de tudo
Um dos conceitos chave quando se fala de MVP é a escolha. É suposto, independentemente do contexto do projeto, que o MVP não seja o produto final, só com a falta de algumas funcionalidades bastante secundárias. Isto não é um MVP é o produto digital em si. Acontece que o processo de escolha daquilo que entra, ou não, no MVP não é uma ciência exacta. Por muito que gostássemos de ter uma fórmula mágica que calculasse o que em cada caso, deve ou não entrar no MVP, este processo de escolha é tudo menos fácil.
Acontece, que este processo, independentemente da forma que seja feita, deve ter em conta que um produto é o somatório de muitas premissas diferentes. Se queremos que o MVP seja realmente relevante, mesmo sendo uma versão embrionária do produto, este deve integrar um pouco de todas as componentes que lhe vão dar corpo no curto, médio e longo prazo. Imagine que teria de escolher o que incluir ou não no MVP. Imagine que essa escolha, fosse como uma fatia de pizza. Ia querer ficar só com um dos ingredientes ou gostava de provar um pouco de tudo? Afinal de contas, quem é que gosta de comer só o pão da pizza?

Definir um MVP
Para lá definição do conceito de MVP, que já percebemos que pode variar dependente dos contextos metodológicos, mas onde existem algumas premissas transversais, “minimum viable product” é sempre sinónimo de pizza, quer dizer, de escolha.
Mas, um dos maiores desafios, é tentar perceber como fazer esta escolha do que incluir, ou não, no produto digital de forma sustentada. Ninguém tem uma bola de cristal e por conseguinte, dificilmente alguém terá a solução ideal, mas ainda assim, é bom que o processo de escolha de tudo aquilo que deve dar corpo à primeira versão do MVP, seja feita de forma consciente. Para tal, existem alguns conceitos e instrumentos, que podem ser muito úteis na “difícil” hora de decidir o que incluir, ou não.
Escolher no momento certo
É impossível definir de forma estruturada um MVP, numa reunião de Conselho de Administração, ou por outras palavras, em qualquer outro momento de trabalho, sem que exista a informação certa a suportar essa decisão. A decisão daquilo que deve ou não constar numa primeira versão de qualquer produto digital, não pode ser levado de forma leviana. Esse é o primeiro passo para que nada corra bem. Na mesma linha de pensamento, é igualmente perigoso, tentar definir o MVP no início do projeto, antes mesmo de qualquer trabalho de research.
Não se pode definir o “minimum viable product” de algo que não se sabe o que é ou para que utilizadores será mais indicado. Embora esta indecisão, seja muito complicada de gerir, porque na prática faz com que se arranque um projeto sem que se conheça um planeamento completo, definir só o MVP, no momento em que a equipa tenha a informação certa para suportar essa decisão, é quase sempre uma das opções mais sensatas.
Pesquisar, pesquisar e pesquisar
Se é fundamental, escolher no momento certo, nada disso vai acontecer por artes mágicas. A única ferramenta que existe à disposição das equipas, para terem a informação certa que lhes permita escolher bem o que iterar no MVP é o research. Só com uma pesquisa séria, seja do mercado, do contexto, do problema, dos utilizadores, das necessidades e das oportunidades, será possível mais tarde decidir de forma estruturada o que deve estar ou não no MVP.
Em momentos críticos de definição do MVP, pode ser útil dividir a pesquisa em dois momentos, uma pesquisa inicial e outra mais profunda. Com um ciclo de pesquisa inicial mais curto, é possível reunir e sistematizar imensa informação, que pode ser muito útil na definição urgente do MVP. Embora possa não ser a abordagem ideal, em alguns casos (muito específicos) pode ser uma solução de compromisso. Afinal de contas, mais pesquisa é melhor que pesquisa nenhuma.
Resolver um problema de cada vez
Muitas vezes, a tentação é fazer com que o MVP possa resolver todos os problemas de uma só vez. Se deixarmos que esta linha de pensamento ganhe força no projeto, quando menos nos dermos conta, ao invés de estarmos a falar de um “minimum viable product” estamos já sim a construir um “maximum viable product”. O que era suposto ser rápido para experimentar soluções, torna-se moroso e com um grau de compromisso bem maior.
Optar por resolver um problema de cada vez, com cada MVP, pode ser uma chamada de atenção importante. Claro que esta abordagem inclui, definir bem cada problema. Mas perceber bem a necessidade essencial que queremos resolver e construir o MVP em torno da resolução desse problema, pode ser uma estratégia muito inteligente. Naturalmente, que se o problema for “resolver todos os problemas do mundo”, será impossível pensar um MVP para este desafio. É fundamental que o problema seja relativamente circunscrito, para que seja possível testar soluções através de um, ou vários, MVP.
Diferenciar necessidades e vontades
O critério de escolha das funcionalidades a incluir no MVP, como tem ficado bastante evidente, é da maior importância. De alguma forma racional, será necessário na definição do MVP, deixar funcionalidades de fora desta primeira versão do produto. Para que isto aconteça de forma mais ou menos estruturada, é preponderante encontrar critérios que ajudem no processo de escolha. Um dos critérios, mais úteis será conseguir diferenciar aquilo que são as necessidades dos utilizadores e aquilo que são as suas (ou as nossas) vontades.
Resolver uma necessidade real, tem um impacto positivo nos utilizadores, infinitamente maior, do que corresponder simplesmente a uma das suas vontades. Por outras palavras, se com o MVP conseguir testar soluções para necessidades específicas dos utilizadores, estamos acrescentar bastante valor e com isso mais perto de encontrar soluções que gerem negócio. Por outro lado, ir ao encontro de vontades, mais secundárias do que necessidades, corremos o risco de tornar a ponderação entre custo/benefício dessas ações ser bastante baixo e por conseguinte, tornar complexo sem nenhum ganho adicional, o nosso próprio produto mínimo possível.
Fotografia © Alessandra Caretto (Unsplash)