Como definir um escopo de MVP em 3 horas

Quando fui contratado como gerente de produto por uma empresa de processamento de pagamentos em estágio inicial, a empresa estava lutando para criar e entregar um sistema de gerenciamento de estoque em tempo hábil. A solução em vigor era um aplicativo de teclado simples que não era fácil de usar e, como resultado, estava causando uma rotatividade significativa de clientes. Meu trabalho era liderar uma equipe encarregada de construir o sistema de inventário que expandiria os recursos do aplicativo além da funcionalidade do teclado.

Como tínhamos que operar em uma linha do tempo truncada, criei uma abordagem simples, mas radicalmente eficiente, para conceber, projetar e construir um produto mínimo viável (MVP) com recursos essenciais que correspondiam ao que nossos usuários procuravam. O processo condensou o escopo de um MVP em uma sessão intensiva de três horas – em vez de dias ou semanas – e economizou meses de desenvolvimento para nossa equipe.

Esse processo acelerado de definição de escopo do MVP pode ser usado para orientar qualquer equipe de produto e pode ser aplicado à criação de qualquer produto zero a um.

Visão geral do caso de uso

Problema: a funcionalidade simples do teclado do aplicativo não fornecia aos usuários, que eram fornecedores, a capacidade de gerenciar estoque ou selecionar itens para adicionar ao pedido de um cliente.

Restrições: A liderança da empresa queria uma solução entregue em oito semanas; uma potencial rodada de captação de recursos dependia, em parte, do sucesso de uma versão melhorada do produto.

Contexto: A partir de uma análise do mercado e depois de passar um tempo com muitos de nossos usuários, determinei que esses fornecedores precisavam de um sistema de gerenciamento de estoque para otimizar seu fluxo de vendas. Observei-os processar os pedidos dos clientes: primeiro, eles escreviam os itens solicitados em pedaços de papel, usavam calculadoras para contabilizar os itens e, em seguida, inseriam os pedidos no aplicativo. Eles estavam usando três ferramentas quando deveriam precisar apenas de uma.

Solução: Precisávamos desenvolver uma solução que permitisse aos usuários carregar seus estoques em um catálogo digital, gerenciar esses estoques e tocar em itens selecionados para adicioná-los ao carrinho de compras de um cliente, tudo dentro do aplicativo.

A Decisão do Design Sprint

Como já sabíamos qual produto precisávamos desenvolver, optei por abrir mão de um sprint de design típico – um workshop de quatro a cinco dias no qual as equipes colaboram para identificar um grande desafio de negócios, coletar ideias de clientes sobre como resolver o problema, desenvolver um conceito para um produto, projetar um protótipo e começar a testá-lo.

Os sprints de design são um método eficaz para construir MVPs – para aqueles que precisam identificar problemas centrais e que têm um tempo considerável disponível para desenvolver soluções. Em empresas em estágio inicial ou novas unidades de negócios em organizações existentes, no entanto, as questões centrais são normalmente evidentes: os conceitos foram desenvolvidos e o ajuste do produto/mercado geralmente foi determinado antes que os gerentes de produto, engenheiros e designers sejam contratados.

O fluxograma a seguir detalha as etapas que dei ao decidir que a melhor maneira de prosseguir com este projeto era pular o sprint de design e começar com a sessão de três horas, também conhecida como pontapé inicial da equipe. Nessa reunião, os participantes fariam um brainstorming e gerariam dezenas de ideias para recursos e, em seguida, reduziriam a lista apenas ao que era necessário para o MVP.

O processo de desenvolvimento MVP

Preparação

Antes da sessão de três horas, você deve coletar informações sobre suas personas de usuário conversando e observando clientes atuais ou potenciais e realizando pesquisas de mercado.

Em seguida, crie uma apresentação para os designers e engenheiros. Deve explicar:

• O problema que você está tentando resolver.
• O produto que você está construindo.
• Como o produto resolverá esse problema em termos de métricas e UX.
• O impacto previsto do produto em seus negócios e nos negócios de seu cliente.
• As missões e objetivos e os principais resultados (OKRs) no nível da empresa e da equipe, bem como como o produto ajuda a cumprir essas missões e alcançar esses OKRs.

A apresentação deve dar aos designers e engenheiros uma compreensão sólida do produto para prosseguir com o escopo do MVP.

A reunião inicial de três horas

O kickoff deve envolver toda a equipe de desenvolvimento, permitindo que ela participe de todas as etapas do processo, desde a idealização e criação da história até o desenvolvimento do conceito do MVP. Isso inclui gerentes de produto sênior, júnior e associados; proprietários de produtos; leads de produtos (se aplicável); Designers de UX; engenheiros de software; e engenheiros de controle de qualidade.

Dica rápida: Embora seja pouco ortodoxo, recomendo incluir engenheiros antes da fase de construção. Eles normalmente fornecem ótimas ideias e têm paixão pelo produto que estão tentando melhorar. A maioria deles gosta de estar envolvida no escopo do MVP; isso os ajuda a se tornarem mais envolvidos no projeto e valorizados pelas outras equipes.

Reúna todos em uma sala de conferência ou espaço de trabalho virtual. No nosso caso, tínhamos 10 pessoas. Bloqueie três horas.

O produto e as jornadas do usuário (60 minutos)

1. Entregue a apresentação. (15 minutos)

2. Comece a identificar todas as personas de usuário do seu produto. Mesmo que você ainda não tenha identificado nenhum fluxo ou trabalho de recurso, você pode definir o número de fluxos que precisam ser criados. (10 minutos)

   Dica rápida: não exagere adicionando mais personas do que o necessário. Após o lançamento do MVP, o feedback do cliente revelará se você precisa de funções adicionais.

   Exemplo de caso de uso: Tínhamos três personas: o gerente da loja (ou administrador), o caixa e o cliente final. Havia outras personalidades de nível sênior em potencial, como o dono da loja, mas para fins de um MVP, elas poderiam ser cobertas pelo administrador.

3. Mapeie a jornada do usuário do início ao fim. Atribua uma cor a cada persona para ajudar a identificar cada etapa do fluxo que um usuário encontrará. Para reuniões presenciais, poste notas adesivas na parede ou use um quadro branco. Para reuniões virtuais, use uma placa FigJam ou algo semelhante. (35 minutos)

   Dica rápida: faça com que a equipe compartilhe todas as suas ideias e seja granular. Cada etapa do fluxo se tornará um recurso a ser construído - e cada usuário terá um fluxo separado - mas o processo de delinear as etapas será o mesmo.

   Exemplo de caso de uso: aqui está a lista de recursos para nossa persona de caixa:

   • Abra o aplicativo de ponto de venda.
   • Faça login usando um PIN.
   • Identifique o primeiro item para compra do cliente.
   • Identifique a quantidade do item.
   • Identifique quaisquer itens adicionais para compra do cliente.
   • Adicione um desconto em um item (se aplicável).
   • Total do custo de todos os itens no carrinho de compras (neste ponto, o preço total da compra, incluindo o imposto sobre vendas, é exibido).
   • Finalize o checkout e o processamento do pagamento.
   • Confirme a compra.
   • Permita que o cliente adicione uma gorjeta.
   • Feche a venda.
   • Mostrar o total de todas as vendas diárias.
   • Acabe com o tempo limite após um período predeterminado de inatividade (por exemplo, cinco minutos).

   Nota: Esta lista detalha a maioria dos recursos que pensamos para esta persona. Criamos cerca de 60 recursos no total em todas as personas, com sobreposição mínima, pois o caixa, o gerente da loja e o cliente final se envolvem com o aplicativo de maneiras diferentes. Dependendo do tipo de produto que você está desenvolvendo, pode haver uma sobreposição de recursos significativamente maior entre os tipos de usuário.

   

Recursos essenciais das jornadas do usuário (45 minutos)

1. Agrupe recursos para cada tipo de usuário nas partes discretas de cada jornada do usuário em um quadro branco real ou virtual. Em seguida, desenhe uma linha horizontal no quadro. Acima da linha, identifique os conjuntos necessários para que o produto funcione. Abaixo da linha, coloque recursos que são bons de se ter, mas podem esperar até lançamentos posteriores. (30 minutos)

   Dica rápida: divida os designers e engenheiros em grupos para concluir esta etapa e, em seguida, reúna-se para comparar as notas. Isso é especialmente útil em reuniões de 10 pessoas ou mais.

   Exemplo de caso de uso: para nosso aplicativo, tínhamos 12 conjuntos de recursos neste momento, que incluíam carregar itens no catálogo de estoque, precificá-los, selecionar itens para adicionar ao carrinho de um cliente, fazer check-out e fechar a venda, reordenar estoque baixo, e mais. Eventualmente, reduzimos o número de conjuntos de recursos para quatro.

   Esse processo de eliminação nos ajudou a determinar que a entrada de segurança de um usuário não era necessária na primeira iteração do aplicativo. Nem estava adicionando um desconto ou uma gorjeta. Também decidimos que o caixa não precisava mostrar o total de todas as vendas diárias como parte de um MVP, embora o gerente ou proprietário da loja pudesse.

2. Refine a lista de recursos. Pergunte “Se isso fosse omitido, o produto ainda funcionaria?” Se a resposta for sim, deixe esse recurso fora do MVP – salve-o para uma iteração posterior do produto. Se a resposta for não, você deve incluir esse recurso no MVP. Ao final desse processo, você saberá o que é realmente necessário para tornar seu produto funcional. Muitas vezes, isso consistirá em apenas três ou quatro recursos para cada conjunto. (15 minutos)

   Nota: Evite construir muitos conjuntos de recursos no MVP. Embora você deva antecipar opiniões divergentes sobre o que é mais importante incluir, é seu trabalho como gerente de produto fazer a ligação. Você fez sua pesquisa e tem dados para respaldar suas decisões. Na minha experiência, muitos produtos são inicialmente construídos com mais robustez do que precisam, e a maioria das empresas prefere colocar algo nas mãos dos usuários para teste e feedback o mais rápido possível.

Projeto, teste e engenharia do produto (75 minutos)

1. Faça com que os designers integrem os recursos principais em um design de estrutura de arame do MVP, que os engenheiros usarão para construir a arquitetura do produto. (45 minutos)

2. Permita que os especialistas e designers de produtos trabalhem juntos em alguns testes leves de UX do design do wireframe. (15 minutos)

   Nota: Existem muito poucos cenários de gerenciamento de produtos nos quais você deve construir sem envolver o cliente final, mas no caso de testes e desenvolvimento rápidos, você pode testar um protótipo de design internamente ou com amigos e familiares que não conhecem seu produto. Se eles estiverem confusos, alguns de seus usuários também ficarão.

3. Dê os wireframes projetados aos engenheiros para que eles comecem a construir a arquitetura do MVP. Eles não terão tudo o que precisam – ou tempo – para construir uma solução completa, mas podem começar, e a arquitetura que construirem será usada ao concluir o MVP. Enquanto isso, as equipes de produto e design podem continuar testando em seus wireframes com membros internos da equipe ou amigos e familiares atuando como usuários. Ter equipes trabalhando simultaneamente nesta etapa economiza tempo. (15 minutos)

À medida que você se torna mais apto a usar esse processo, ficará mais fácil identificar quais recursos são componentes principais de um MVP e quais podem ser criados posteriormente. A prática também evitará que você construa as coisas erradas: você pode ter algo em mente para a lista “depois”, apenas para descobrir posteriormente que nenhum cliente quer isso.

Resultados e principais conclusões

Antes de nossos esforços, nosso aplicativo era um teclado com os números de 0 a 9, um ponto decimal e um botão de carregamento. Devido a essa limitação e ao fluxo de trabalho ineficiente que ela criou, ao longo de um ano, nossa retenção foi baixa – cerca de 20%. Embora tivéssemos adquirido novos usuários mais rapidamente do que nossos concorrentes, estávamos perdendo-os quase com a mesma rapidez.

Ao longo do processo de criação do MVP, construímos quatro conjuntos de recursos principais, todos com escopo mínimo, mas de alta qualidade. Um usuário pode agora:

1. Carregue itens no inventário diretamente de um dispositivo móvel simplesmente usando uma câmera, inserindo um nome e um preço.
2. Selecione esses itens e adicione-os ao carrinho de compras de um cliente.
3. Feche a venda enquanto visualiza os itens que estão sendo vendidos.
4. Veja o número de itens vendidos em um determinado período de tempo.

Os clientes adoraram o produto melhorado. A taxa de retenção foi de 45% entre os novos usuários que aproveitaram a funcionalidade do catálogo para fazer o checkout pelo menos cinco vezes na primeira semana de carregamento dos itens.

Graças à eficiência do nosso processo de definição de escopo do MVP, construímos e entregamos nosso aplicativo totalmente finalizado em cerca de dois meses. Esse processo provavelmente levaria quatro meses ou mais com uma abordagem de desenvolvimento tradicional - se o produto fosse construído.

Este processo acelerado economiza tempo e dinheiro. Um sprint de design completo pode ser caro. Começar com a reunião inicial torna meu processo mais econômico desde o início, e essas economias são amplificadas pelo cronograma geral de desenvolvimento muito mais curto.

No entanto, os dois processos também podem funcionar em conjunto: se sua equipe concluiu um sprint de design para definir um problema central de negócios e a solução que você precisa criar, você pode usar meu processo para definir seu escopo de MVP com mais eficiência.

Lembre-se de que esse processo é apenas o começo: um MVP é um trabalho em andamento que será aprimorado em versões posteriores. Assim que estiver totalmente construído e pronto para ser entregue, recomendo adicionar uma chave beta que os usuários podem desativar para retornar à experiência do aplicativo antigo. Aproveitar o software de comportamento, como o Heap, para rastrear quantos usuários exercem essa opção lhe dará uma boa ideia do que precisa ser adicionado ou alterado para aprimorar seu produto na próxima iteração.