Como o Design descobre novos produtos?

O que você vai ler neste artigo: 

• O que é Design para Descoberta ou product discovery
• Quais as principais etapas desse método
• Os 6 erros mais comuns ao validar uma hipótese de solução
• Como o design para descoberta pode atuar na definição do seu MVP

Como o design para descoberta funciona?

O Design para descoberta é um método aplicado em consonância com princípios do Design Thinking, que tem como base a compreensão de problemas e validação de soluções de forma dinâmica e colaborativa, alinhada com os objetivos do negócio, bem como às necessidades dos seus consumidores.

Composto de quatro grandes etapas, nosso método de product discovery vem sendo aplicado com sucesso em diversos contextos e para diferentes setores da economia nos últimos mais de vinte e cinco anos do CESAR. As etapas são: Imersão, Construção da Visão, Ciclos de Validação e Definição do MVP – mínimo produto viável.

Baixe agora o material completo com todas as fases do método CESAR para Design para Descoberta – ou product discovery.

Imersão

A partir de uma hipótese de solução, inicia-se uma fase de imersão no contexto do problema ou oportunidade apresentada. Nesta fase são realizados estudos e pesquisas primárias e secundárias no âmbito da organização, mercado e consumidores/clientes.

Construção da Visão

De forma colaborativa é realizado nesta etapa um alinhamento de expectativas para definição conjunta de objetivos e riscos e levantamento de hipóteses para o desenvolvimento. Aqui é construída uma visão coletiva com todos os stakeholders envolvidos, sobre como o produto, serviço, processo ou negócio deve ser.

Ciclos de Validação

Nesta fase é criado um plano de validação, com diversos artefatos a serem utilizados para entrevistar usuários reais que enfrentam o problema, e com isso, validar as hipóteses da etapa anterior. Para isto, é necessário realizar mais de um ciclo de validação, pois a essência deste método são as constantes iterações e descobertas.

Definição do MVP

Ao final deste processo serão definidos cenários e requisitos de um mínimo produto viável (MVP), além da construção de um Lean Canvas da solução. A partir desta fase a organização terá uma visão mais clara do que é o produto, a validação se ele será aceito pelo mercado (ou por stakeholders, se for o caso de uma solução interna) e os requisitos essenciais para partir para a fase de desenvolvimento.

Os 6 erros mais comuns ao validar uma hipótese de solução

Ao utilizarmos o método de design para descoberta, a hipótese de solução busca garantir que a solução certa seja desenvolvida para o público ideal. Mas ao conduzir a validação de forma equivocada no início do processo pode não apresentar os benefícios esperados. Sendo assim, elencamos os principais erros cometidos nesta fase.

1. Se apaixonar pela solução, não pelo problema

A solução que está sendo construída só faz sentido se resolver o problema de alguém. Entender o problema e mitigar os riscos das soluções é o grande objetivo de um processo de descoberta. Mesmo que isso signifique jogar sua solução fora e começar de novo.

2. Não ter boa compreensão do problema

Investigações levam a novas dúvidas e uma nova percepção dos riscos. Grandes avanços logo após as primeiras descobertas podem gerar fragilidades na sua solução, levando a decisões equivocadas. Quanto mais complexo um problema, mais será preciso investir recursos no aprofundamento e entendimento desse problema.

3. Não conhecer o público que sua solução atende

Sua solução irá concorrer com várias outras para resolver as dores de um determinado público. É preciso descobrir quais são as motivações, cenários, atividades e desejos deste público para aumentar o aprendizado e refinamento da sua solução.

4. Partir de hipóteses confusas ou frágeis

Hipóteses são pontos de partida para uma solução, mas podem induzir ou estar carregadas de vieses. Elas devem considerar um recorte do passado ou do que está acontecendo, mas nunca do futuro. Devem ser quantificáveis para serem verificadas,  permitindo assim, aprendizados mais rápidos.

5. Não envolver os stakeholders desde o início

Mais que corresponder às expectativas, ter os stakeholders envolvidos cria alinhamento e entendimento conjunto, garantindo que a solução atenderá não somente às necessidades de um determinado público mas também a um objetivo de negócio. Tanto a clareza e o entendimento do objetivo de negócio quanto às decisões que levaram à escolha de determinada hipótese de solução se dão a partir deste envolvimento.

6. Realizar ciclos de validação insuficientes

Validações são aprendizados valiosos com o intuito de reduzir o risco da solução. Juntar esforços para tentar cobrir todas as questões em apenas um ciclo pode desfocar dos aprendizados do processo, tornando-o improdutivo. Pequenos ciclos de validação focados em responder pequenas questões levam a menos esforço e mais resultados.

Baixe aqui o conteúdo completo dos  6 erros mais comuns ao validar uma hipótese e tenha sempre com você!

Como o design de descoberta pode atuar na definição do seu MVP

Em um artigo escrito pela nossa colaboradora e especialista de em Design da Experiência do Usuário, Priscila Alcântara e divulgado originalmente no UX Collective e em seguida detalhado neste case do CESAR, apresentamos como o Design para descoberta pode ajudar você na construção do seu mínimo produto viável, o MVP.

Após checar que não está cometendo nenhum dos erros mais comuns e realizar alguns ciclos de validação, você sai do processo de Design para Descoberta com uma hipótese de solução validada. Porém, seguir para a definição de um produto mínimo viável (MVP) a partir daí pode ser um grande desafio para quem está começando.

O fato é que às vezes a nossa ideia completa, do jeito que nós pensamos, pode levar muito tempo para ser desenvolvida. Isso pode gerar vários tipos de problemas e um desses, por exemplo, é perder o timing de lançar algo de valor no mercado. Por isso é importante ter um MVP. Ele ajuda a colocar sua ideia em um ambiente real e já começar a produzir resultados enquanto você ganha respiro para continuar aprimorando o que está sendo entregue.

Porém, muitos donos de produto (product owners) acabam tendo dificuldade em escolher quais são as funcionalidades que vão entrar no seu MVP. E métodos ágeis e co-criativos podem ajudar a tomar essa decisão de forma consciente, considerando o tamanho e a velocidade do seu time de desenvolvimento.

Para exemplificar esse processo, trazemos um caso real de como um dos nossos clientes conseguiu se beneficiar da abordagem de design para descoberta no processo de decisão do que seria implementado no seu primeiro MVP.

E mais, como esse processo de design de descoberta foi aplicado em tempos de pandemia, e o uso de tecnologia foi de grande ajuda, já que esta foi uma etapa 100% remota. Todo mundo trabalhou junto para planejar a entrega de um produto digital que vai funcionar em todo Brasil, com perspectiva de se estender para toda a operação desse cliente na América Latina.

Um pouco de contexto de um backlog enorme

O time de desenvolvimento deste produto é composto de 26 pessoas (entre gerente de projeto, designers, desenvolvedores e testers), trabalhando de forma remota.

Nesse produto (que ainda está em desenvolvimento) temos uma aplicação com uma frente mobile e outra web que fazem parte de uma “família”, ou seja: têm dependências e integrações que um outro produto sozinho não tem.

Para ficar mais claro porque era necessário priorizar as funcionalidades essenciais: é um produto tão gigante que o time estava entregando uma estória de usuário por sprint utilizando um scrum adaptado às necessidades e processos do cliente! Ou seja: a menos que o produto inteiro tivesse 5 estórias, seria impossível.

Como o Design poderia ajudar na priorização das estórias para um MVP?

O time do CESAR propôs um workshop cujo objetivo era abrir os olhos dos gestores de produto para o tamanho do que era esperado e, assim, fosse mais simples enxergar que as expectativas para uma primeira versão do sistema estavam muito altas. Precisavamos considerar a capacidade de entrega do time de desenvolvimento considerando o tempo esperado de entrega e as funcionalidades desejadas inicialmente

Levamos a proposta da colaborativa em  uma apresentação explicando cada uma das 3 técnicas que iríamos usar em alto nível e botamos a mão na massa para preparar tudo.

O tempo total de execução foi de 8 horas — tivemos um intervalo de pouco mais de uma semana antes da conclusão e escolhemos o Miro como a ferramenta base que nos daria suporte nesse workshop e montamos o nosso board.

Definindo e alinhando o objetivo do produto

Na primeira etapa do workshop queríamos que todo mundo entendesse bem quais eram os objetivos de curto, médio e longo prazos para aquilo que estávamos construindo.Isso iria nortear o que precisava vir mais cedo numa entrega e o que poderia ficar para depois.

O objetivo de curto prazo foi nomeado como “Ajudar a fazer o trabalho com o que já existe hoje”.

Para um objetivo mais adiante, nós demos o nome de “Fazer o trabalho que faz hoje de forma melhor”.

Assim, saberíamos quais as funcionalidades precisam estar prontas para que o processo atual das pessoas que executam o trabalho que faz parte do fluxo da aplicação que está sendo desenvolvida, fosse aprimorada. Isso nos daria uma visão de próximos passos depois de uma primeira versão entregue.

Por fim, para superar as expectativas, trouxemos a pergunta “Como nós [os product owners] enxergamos que seria a última versão deste produto?”. Com isso, teríamos uma visão de longo prazo e todo mundo que participa do desenvolvimento do produto teria ciência de onde queríamos chegar.

Com os objetivos em mente, era hora de refletir isso no que tínhamos no backlog

Agora precisávamos pegar todas as estórias e priorizá-las do ponto de vista do negócio e mostrar, do ponto de vista de desenvolvimento o quanto aquilo ia custar para ficar pronto.

Os product owners do projeto escolhiam o que era mais prioritário, posicionando cada um dos cartões com as estórias no Miro. E o time de desenvolvimento é quem decidia o quão rápido essa estória podia ser implementada.

Havia uma maior complexidade de desenvolvimento para negócios. Isso estava tornando o lançamento do produto distante e complicado. Por isso, precisávamos de uma nova etapa de priorização, e ela precisaria levar em conta o tempo disponível para desenvolver e o time que nós tínhamos.

Usamos uma adaptação da técnica de Sequenciador que chamamos de planejamento em ondas, levando em conta a velocidade de estórias que vínhamos cobrindo por sprint, com os cards para cada uma das ondas.

Estava tudo indo bem e exatamente como planejado — foi aqui que o processo deu um crash. Deu um crash, mas não deu errado. Na verdade, esse impasse já era esperado.

Chegou a hora de refletir

Os gestores de produto perceberam que não iam conseguir trazer tudo o que era prioridade de uma vez. Nessa hora, o grupo entendeu que era necessário quebrar as atividades grandes em menores.

Além disso, era preciso rever as expectativas e entender que podíamos fazer uma entrega menor que trouxesse valor, ainda que não fosse a entrega completa que queríamos.

Quando nos reunimos de novo, revisamos os objetivos e transformamos o objetivo de ajudar a fazer o trabalho com o que já existe hoje mais simples. Agora ele era uma visão de que a primeira poderia ser lançada e poderiam existir entregas intermediárias entre esta e a próxima grande entrega, que seria o Fazer o trabalho que faz hoje de forma melhor.

Com isso, quebramos as estórias e olhamos somente para essa primeira grande entrega, trazendo só ela para as ondas. Foram 10 estórias priorizadas sem precisar burlar as regras.

Para além do workshop

Depois do processo, saímos com uma visão clara e alinhada do que seria entregue e uma estimativa de prazo em alto nível. Mais do que isso, o nosso cliente sugeriu que nos reuníssemos com mais frequência para revisar o backlog e verificar quais são as prioridades de forma mais constante e incremental.

O ganho foi enorme do ponto de vista de entender melhor a velocidade do time. Mais do que isso, o time de desenvolvimento pôde entender melhor a necessidade das entregas e ter a visão de futuro da solução proposta. Isso foi parte do processo que trouxe o time para olhar para os diversos stakeholders envolvidos na construção de um produto.

Como esse caso pode ajudar você

A construção de um produto não é uma jornada linear. O mindset experimental deve ser constante, desde a concepção da ideia, passando pela validação da hipótese de solução,  até o processo de desenvolvimento. O caráter iterativo das fases anteriores do processo de Design para Descoberta precisa ser mantido também na fase de criação do MVP e experimentação e incremento dele. E para o isso, o Design traz muitas técnicas ágeis para garantir esse compasso.

Este caso mostra como essa jornada pode apresentar desafios, e sua organização precisa ser ágil e estar atenta para tornar o processo de design de descoberta para o desenvolvimento de um produto o mais dinâmico possível.

Precisa de ajuda para implementar o design de descoberta na sua empresa? Descubra como nós auxiliamos a Neoenergia através do design e inovação para melhoria operacional e da experiência do colaborador.