Nesse texto vamos ao resumo em Português da parte 4.2 do livro Inspired do Marty Cagan, um dos livros de Produto mais indicados no mercado e que atualmente não tem uma versão traduzida para o Português.
Não está entendendo o que é a Parte 4.2? Então provavelmente você não leu a Parte 1, a Parte 2, a Parte 3 ou a Parte 4.1.
______________________________________
Parte 4.2 – O Processo Certo
Técnicas de Prototipação
Existem diferentes formas de prototipação, cada uma com características diferentes e utilizadas para testar diferentes coisas. A escolha de qual usar depende do tipo de produto e de qual risco você está abordando, mas existem princípios chaves no uso de todos eles, que são:
- O objetivo de todo protótipo é aprender algo com um custo substancialmente menor em termos de esforço e tempo, do que construindo o produto em si.
- Um dos maiores benefícios de prototipar é forçar você a pensar sobre o problema em um nível mais profundo. O próprio ato de criar um protótipo já evidencia problemas.
- Essa é uma técnica poderosa para promover a colaboração entre o time, garantindo também que todos estão na mesma página.
- Existem vários níveis possíveis de fidelidade de protótipo, que são determinados pelo quão realista o protótipo é.
Protótipo de viabilidade/ Prova de Conceito (POC)
Em algumas situações o time de engenharia pode encontrar riscos de viabilidade envolvendo uma solução, e essas preocupações podem envolver tópicos como performance, escalabilidade, erros, uma tecnologia que o time não tem experiência, um componente ou serviço de terceiros que o time nunca usou, um sistema legado ou dependência de outros times.
Nesses casos, uma forma de mitigar esse tipo de risco é trabalhar em uma prova de conceito (conhecida como POC), na qual o time de engenharia irá trabalhar em criar o mínimo de código possível para demonstrar que a solução proposta é viável.
Boa parte das vezes esse código não terá a qualidade certa e provavelmente será descartado após o teste, mas tudo bem, afinal o objetivo aqui é validar ou invalidar a proposta. Lembre-se esse é um trabalho de discovery e não de delivery.
Essas POC’s geralmente levam de 1 a dois dias para serem criadas, mas se você está trabalhando em uma nova tecnologia, pode ser que seja bem mais, tudo depende do time de engenharia.
Protótipo de Experiência do Usuário
Existem diversas ramificações desse tipo de protótipo variando em tipos de fidelidade, começando pelos de baixa fidelidade que não parece real e é essencialmente um wireframe interativo. Do outro lado temos protótipos de alta fidelidade que parecem extremamente reais.
Protótipo de Dados
Em algumas situações precisamos levantar dados de uso reais e é ai que entram os protótipos de dados. Nesse caso trabalhamos em criar e disponibilizar uma parte do produto para usuários reais, mas não nos preocupamos com qualidade ou com aspectos como SEO, performance, escalabilidade, dentro outros, afinal o objetivo é liberar algo rápido para coletar dados significativos e tomar decisões.
Que fique claro, não estamos criando um produto comercializável e que você consegue sustentar um negócio, então se os testes se provarem bem sucedidos você precisará trabalhar no delivery.
Protótipos Híbridos
Existem protótipos que combinam diferentes aspectos dos tipos falados anteriormente. Um ótimo exemplo é o protótipo conhecido como Mágico de OZ que combina um protótipo de experiência do usuário de alta fidelidade com alguém manualmente trabalhando por trás para desempenhar as ações. Com esse protótipo você descobrirá várias demandas e entenderá a fundo o que precisa acontecer para que o problema do seu cliente seja solucionado.
Técnicas para teste
Teste de Usabilidade
Testes de usabilidade é a técnica mais madura e direta de discovery. Se sua empresa tem um time de pesquisa (ux researchers), aproveite o máximo de tempo que conseguir deles, serão excelentes recursos. Caso esse time não exista, você terá que pagar uma empresa especializada ou fazer você mesmo. Neste último caso, aqui estão algumas dicas.
Começando por recrutar usuários para os testes. Você pode utilizar os canais que já possui de contato com o usuário, como, por exemplo, seu site, ou uma lista de e-mail de usuários do seu produto (se o teste tiver esse público como foco), mas você também pode usar plataformas de anúncio ou ir até um local como shoppings, convenções, cafeterias.
Normalmente os testes de usabilidade são feitos com protótipos de alta fidelidade e devem estar presente a Product Manager, a Product Designer e, se possível, alguém do time de engenharia. Você deve ter pensado com antecedência quais as ações você quer testar e é importante que durante o teste você tenha outra pessoa anotando os insights para que após o teste vocês consigam repassar os maiores achados e chegar a conclusões.
O local do teste vai variar conforme os recursos que você tem, mas se você conseguir fazer o teste no ambiente do usuário verá que terá grandes insights além da entrevista. Senão, uma mesa de starbucks ou uma sala no seu escritório funcionarão muito bem.
No começo do teste diga ao usuário que o que ele verá é um protótipo e que não é real. Explique que a pessoa não estará ferindo seus sentimentos ao dar um feedback sincero, também diga a ela que você está testando uma ideia e não a pessoa, sendo assim não existe resposta certa ou errada.
Seguindo para o teste, você quer manter os usuários no modo teste e não no modo crítica, realmente não importa se eles acham a página feia, por exemplo, a não ser que eles sejam designers. O mais importante aqui é observar o que eles fazem, muito mais do que o que eles dizem.
Você quer evitar interferir no teste, ajudando ou orientando o usuário, portanto acostume-se com o silêncio. Entretanto, se ver que o usuário está fazendo algo que você gostaria de saber o porquê, está tudo bem pedir para que a pessoa explique o que está fazendo.
Se os usuários te perguntarem algo, aja como um papagaio e repita a pergunta, por exemplo, se ele perguntar, ‘Se eu clicar aqui, entrarei novamente?’, você pode dizer, ‘Você acredita que se clicar ali entrará novamente?’, assim você instiga o usuário a tentar responder sua própria pergunta.
Todo o objetivo aqui é entender quais hipóteses estão erradas em relação ao seu protótipo e, acredite, nos testes você descobrirá muitas coisas, tanto pelas ações dos usuários, quanto pela sua linguagem corporal e atitude após o teste. Identificando os problemas, os arrume imediatamente, não é necessário que você espere o final da rodada de testes para modificar, afinal você está tentando aprender e não provar algo quantitativamente.
Testando Valor
Entenda que ninguém é obrigado a comprar seus produtos e usuários não têm o dever de usar uma feature, portanto, para que isso aconteça é preciso que você entregue valor real. Para tal, existem algumas técnicas que nos ajudam a identificar se esse valor está sendo percebido.
Testando Demanda
Um dos maiores desperdícios é quando o time gasta tempo, esforço e dinheiro criando e construindo um produto e quando ele é lançado ninguém o compra ou usa.
Uma das técnicas para testar demanda é criar uma fake door no produto, na qual você coloca um botão que direcionaria para tal funcionalidade, mas quando o usuário clica ele é direcionado para uma página explicando que você está estudando criá-la e está procurando usuários para falar sobre isso. Os usuários não devem ter nenhuma indicação de que é um teste antes de clicar no botão.
Outra forma de testar demanda é criando uma landing page, nela nós descrevemos exatamente o que gostaríamos de lançar, mas quando os usuários clicam no call to action eles veem uma página explicando que você você está estudando a possibilidade de criar o produto e que está levantando pessoas para conversar sobre.
Tratando-se de empresas grandes e consolidadas pode ser que exista um receio de que testes como esses sejam prejudiciais à marca e aos lucros da empresa, por interferir no relacionamento com o consumidor. Existem algumas orientações para que os testes sejam feitos de maneira responsável, por exemplo, quando for testar, teste com 1% ou menos da base de usuários, ou, quando fizer testes de protótipo pessoalmente, peça que os usuários assinem um NDA.
Testes qualitativos de valor
Testes qualitativos não são sobre provar algo e sim sobre aprender o mais rápido possível. Marty diz que os testes qualitativos de valor são as atividades de discovery mais importantes, devendo ser feitos pelo menos dois ou três por semana, todas as semanas.
Geralmente começamos com uma pequena entrevista na qual garantimos que o usuário possui os problemas que achamos que ele tem, como eles resolvem esse problema hoje e o que seria necessário para que eles migrassem de solução.
Seguindo, fazemos um teste de usabilidade para entender se o usuário consegue entender sozinho como usar o produto. É importante seguir essa ordem para que quando falarmos de valor o usuário saiba exatamente qual a solução que estamos discutindo.
As pessoas tendem a tentar ser legais com você e os testes de valor, que vem a seguir, são uma forma de tentar contornar isso. Vejamos:
- Dinheiro – uma técnica para validar valor é entender se usuário está disposto a pagar pela solução, mesmo que não tenhamos a intenção de cobrar por ela. Esperamos que ela esteja disposta a passar seu cartão naquele momento, ou, no caso de uma solução cara para negócios, queremos que ela assine um carta de intenção de compra.
- Reputação – Existem outras formas de pagar que não são com dinheiro. Você pode pedir para que eles paguem com sua reputação ao recomendar o produto para seus amigos, colegas ou chefe, divulguem nas redes sociais, ou mesmo passem o e-mail de seus colegas.
- Tempo – Especialmente quando falamos de empresas, você pode pedir para marcar um tempo significativo com ele para que vocês trabalhem juntos na solução (mesmo que você não precise). Essa é outra forma de pagar pelo valor.
- Acesso – Você também pode pedir para que as pessoas te passem o acesso da solução que eles usam agora. De novo, você não quer realmente seu login e senha, mas você quer identificar se eles realmente estão dispostos a migrar.
De novo, o objetivo aqui é aprender. Se você receber respostas totalmente diferentes de dois usuários, seu trabalho é entender qual a razão disso.
Testes quantitativos de valor
Técnicas quantitativas, diferente das qualitativas, são sobre coletar evidências. Às vezes conseguimos coletar dados suficientes para configurar uma amostra estatisticamente relevante, em outros casos isso não é possível, mas coletamos evidências significantes que nos ajudem a tomar melhores decisões.
Uma forma de coletar evidências é através de testes A/B. Nesse tipo de teste o usuário não sabe que está participando, o que gera dados realistas. Testes A/B de otimização e testes A/B de discovery são diferentes, os de otimização não envolvem riscos altos e trabalham com mudanças pequenas como cores e calls to action, trabalhando com amostras de 50/50. Por sua vez, os de discovery envolvem amostras de teste pequenas, considerando uma proporção de mais ou menos 99/1.
Outra técnica é a de testes somente para convidados. Nessa prática, usadas por empresas mais avessas a riscos, você seleciona cuidadosamente os usuários para o teste e os convida para usar uma nova versão, informando que se trata de um teste, então eles escolhem se participam ou não.
O papel da análise dados se tornou extremamente significativo para empresas de produto, sendo uma ótima tática para entender melhor o perfil dos usuários e seu comportamento ao usar o produto, mas também para estabelecer metas de negócio e medir seu progresso.
Além disso, dados e métricas são formas práticas de provar se determinada ideia funciona ou não, também são catalisadores de melhores decisões de produto. Acima de tudo, dados são ótimas fontes de ideias e oportunidades.
Testando viabilidade técnica
Em termos de viabilidade técnica o time de engenharia deve estar acompanhando o processo de discovery com os usuários constantemente, e, nesse processo, tentando responder perguntas de viabilidade técnica. Às vezes será preciso trabalhar em protótipos de viabilidade para determinar se é possível construir determinada solução, em outras o time já sabe a resposta. Mas é importante entender que em vários momentos o time de engenharia vai precisar de tempo para determinar a viabilidade técnica.
Testando viabilidade de negócio
Ademais, o produto precisa ser viável para o negócio e suas áreas acessórias. Por exemplo, o time de Marketing se importa com possibilitar vendas, com a marca e a reputação da empresa, e também com diferencial competitivo. O time de Marketing também se importa com os canais de marketing, então se o que você está propondo impacta qualquer uma dessas coisas, é preciso mostrar a eles seus protótipos antes de construir qualquer coisa.
Bons produtos são criados em torno de canais de venda, considerando suas forças e limitações, mas se o que você está propondo modifica um canal já existente ou necessita de um novo canal, é preciso que o time de vendas esteja a par antes de qualquer coisa.
A parte financeira apresenta várias limitações para o produto, visto que temos que entender se conseguimos pagar pelo desenvolvimento, venda e operação do produto. Por sua vez, o Jurídico pode apresentar considerações como preocupações de compliance, propriedade intelectual e privacidade.
O time de segurança também pode ser extremamente importante, visto que se você está propondo algo que possa interferir nisso você precisará sentar com esse time previamente e debater suas preocupações. Também é preciso considerar se existe algum impacto nas áreas de relacionamento com consumidores ou fornecedores.
Teste de usuário, Demo do produto e Passo a passo
Existem três diferentes técnicas para mostrar o protótotipo e cada uma delas será útil para um determinado momento.
Teste de usuário servem para testarmos ideias de produto com usuários reais e clientes, validando ou invalidando sua usabilidade e valor. Por sua vez, a demo é para que você venda seu produto a usuários e clientes ou evangelize sobre a solução na empresa. Essa é uma ferramenta de vendas e persuasão.
Em contrapartida, o passo a passo é quando você mostra seu protótipo para stakeholders e quer garantir que eles estejam cientes de todos os aspectos que podem gerar alguma preocupação para eles. O objetivo aqui é dar uma oportunidade para que eles levantem problemas.
Técnicas de Transformação
Vimos várias técnicas importantes de discovery, mas sabemos que fazer com que times e empresas adotem novas práticas é difícil. Felizmente existem algumas técnicas que podem ajudar nessa transformação.
Discovery Sprint (ou Design Sprint)
Essa técnica consiste em uma semana de product discovery com o objetivo de enfrentar um problema ou risco específico do time. Essa técnica é útil não apenas para ajudar no momento de transformação, mas também como uma técnica de planejamento ou prototipação.
Durante essa semana vocês trabalharão intensamente no discovery e irão expor diversas ideias de produto diferentes com o objetivo de resolver determinado problema. Você terminará sua semana validando sua potencial solução com usuários reais e clientes, e todo o processo gerará valiosos insight e muito aprendizado. A recomendação é que você leia o livro “Sprint” para entender melhor.
Times pilotos
Uma das técnicas mais simples para facilitar mudanças no jeito de trabalhar da empresa é criar um time piloto. Você deve escolher um time de produto que queira testar essa nova forma de trabalhar voluntariamente e começar a implementar com eles novas técnicas por um período, lembrando de levantar formas de medir seu sucesso e efetividade. Se as coisas derem certo você provavelmente verá vários outros times querendo adotar as novas práticas.
Desmamando uma empresa de roadmaps
Empresas muito dependentes de roadmaps são dificultadores para que os times de produto passem pela transformação que estamos falando. Uma das formas de começar a tirar essa dependência é manter os roadmaps, mas alterar sua forma para que cada item do roadmap inclua um lembrete de qual é o resultado de negócio buscado. Garanta que depois do lançamento das features no roadmap você disponibilize o impacto dela no resultado esperado.
Se o resultado foi bom, maravilha, mas se não foi, sinalize o problema e proponha novas soluções para atingir o resultado esperado. O objetivo é que depois de um tempo a empresa passe a olhar mais para os resultados esperados do que para as features.
Processo em Escala
Quanto maior a empresa mais complexo os processos irão se tornando, o número de pessoas interessadas cresce e você precisará estar mais atento com algumas atividades, que falaremos a seguir.
Gestão de Stakeholders
Um stakeholder é qualquer pessoa que todos sentem que tem poder de dizer algo sobre o produto ou vetar alguma ação, impedindo você de lançar algo. Em grandes empresas você pode ter muitos stakeholders, alguns exemplos são: CEO, marketing, vendas, financeiro, jurídico, compliance, tecnologia.
É responsabilidade do Product Manager entender as considerações dos stakeholders e suas preocupações, trazendo essas informações para o time de produto. Também é crítico que você convença esses stakeholders que você está empenhado em trazer soluções que levem em conta suas considerações, criando assim um senso de confiança deles com o time de produto.
Sucesso em gerenciar stakeholders significa que eles respeitam você e sua contribuição, acreditando que você entende suas preocupações e está procurando uma solução que as considere. Para que isso aconteça você deve ter reuniões periódicas com eles, fazendo várias perguntas e trabalhando de modo receptivo e transparente. Garanta que os stakeholders vejam a solução antes de você construí-la, evitando frustrações em ambas as partes.
Não teste viabilidade através de apresentações, elas podem ser muito ambíguas e detalhes importantes podem ficar de fora. É mais assertivo que você use protótipos de alta fidelidade para isso.
Também tente não utilizar de reuniões em grupo para fazer validações, isso gera resultados medíocres. Use reuniões individuais e de a chance de cada stakeholder trazer sua contribuição individual. No mais, garanta que você não fiquem apenas em opiniões, tente levantar dados e trazê-los para debate quando necessário.
Comunicando Aprendizados de Produto
Quanto maior a empresa mais difícil se torna compartilhar os aprendizados de produto, mas uma forma de garantir que isso aconteça é estabelecendo um horário de 15 a 30 minutos toda semana ou a cada duas para que os times destaquem os maiores aprendizados obtidos. Essa reunião precisa ser rápida, produtiva e focada, sendo uma boa ideia que o VP de produto seja a pessoa a trazer toda a pauta. Essa prática é extremamente relevante, especialmente para a cultura da empresa.
Chegamos ao final da Parte 4! Curtiu? Estamos indo para a última parte do livro no próximo texto e nela vamos abordar aspectos da cultura de uma empresa de produto.
Este conteúdo foi escrito por Letícia Rezende, aluna da PM3 e também Product Manager na Zup Innovation.
Que tal um pouco de Product Discovery na prática?
Falando em técnicas de Product Discovery, se você quer saber como começar a aplicar o Discovery na prática, assista a PM3 Lives com a Iris Sayuri, Product Manager na Easynvest. Nessa Live ela mostra como eles desenvolvem um Product Discovery com qualidade na Easynvest, uma das maiores corretoras do país e a primeira que se lançou na corrida online no segmento. Assista agora!
Curso online de Product Discovery!
Estude com a gente no nosso curso online de Product Discovery. Uma oportunidade incrível de aprender como fazer um bom Product Discovery, aprendendo com profissionais de empresas como Nubank, PicPay, Booking.com, Tapps Games entre outras. São mais de 30 horas de conteúdo em vídeo-aulas, artigos cuidadosamente selecionados e 14 instrutores altamente qualificados. Confira a ementa do curso!
