Muito tem se debatido como criar produtos digitais que sejam inovadores, resolvam os problemas de clientes e atendam as necessidades de negócio da empresa. Um método que pode ser muito útil para garantir que o produto seja realmente eficaz é o Product Discovery.
Segundo a CB Insights, um dos maiores motivos de Startups morrerem é por construírem soluções que não resolvem um problema real das pessoas. Quando pensamos em Startups também pensamos em Produtos e Funcionalidades. Isso se conecta muito com um outro dado onde, aproximadamente 64% das funcionalidades desenvolvidas quase nunca são usadas.
Grande parte disso se deve ao foco maior em entregas do que nos resultados buscados. É o famoso Outputs vs Outcomes. Ou seja, as equipes e organizações se dedicam com maior afinco a produzir e entregar algo (Outputs) do que no resultado de utilização daquela feature, aplicação ou produto (Outcomes). Veja na seção a seguir um exemplo prático e do dia a dia de qualquer pessoa sobre depositar o foco em Outputs ou Outcomes.
Outputs vs Outcomes
Por exemplo, imagine uma situação em que o aniversário de uma pessoa muito querida está chegando e você pretende presenteá-la. Assim, você procura algo, sem se importar em saber o que, de fato, ela precisa ou gostaria de ganhar e entrega o presente só para não passar a data em branco.
Neste cenário em que a preocupação foi entregar algo, pode ser que a pessoa não fique satisfeita com o presente e o resultado seja negativo.
Idealmente o objetivo deve ser o resultado positivo e, nesse caso, você deveria buscar informações sobre o que essa pessoa precisa ou deseja. Deveria investigar com pessoas mais próximas a ela, conhecer suas necessidades daquele momento etc. Basicamente deveria fazer uma pequena pesquisa ou descoberta pensando em aumentar a chance de agradar a pessoa presenteada e, obter um resultado melhor de sua ação.
Em Gestão de Produtos, chamamos este trabalho de Product Discovery. Desta forma, a chance de chegar a um resultado positivo seria maior.
Além do foco no resultado, outro ponto para se atentar é tratar ideias como uma solução certa, sem investigar e/ou olhar para “fora de casa”.
Ideia é hipótese de solução
Seguindo essa linha, outro grande problema é quando temos stakeholders com uma ideia pronta, muito focada no negócio, pouco focada em clientes e, já tomam a decisão que a solução deve ser implementada sem mesmo ouvir a visão do time de produto.
Mesmo que a solução seja muito criativa e boa para o negócio, é preciso investigar a real necessidade de clientes, pois se isso não acontecer há grandes chances do produto ir para mercado de uma forma que não funcione como esperado.
O ideal nesse caso é receber a ideia de stakeholders como hipótese de solução, entender o problema que isso resolve ou oportunidade que pode ser aproveitada, buscar dados, informações, insumos e evidências que validem ou refutem a hipótese. Ou até mesmo chegar a conclusão que a ideia pode ser lapidada de forma que se encaixe melhor com a necessidade de clientes.
Pode ser que mesmo assim ainda recebemos um “não” de stakeholders, mas temos o dever de fazer um trabalho para reduzir o risco de desenvolver algo que não faça sentido para clientes e evidenciar tudo.
Antes de avançar, o que é Product Discovery?
Product Discovery é o processo que busca descobrir dores e necessidades ainda não conhecidas, identificar oportunidades relevantes, até chegar em soluções que resolvam o problema certo gerando valor aos clientes e ao negócio.
É o momento em que dados e informações são reunidas, hipóteses levantadas e, experimentos feitos para validar ou refutar as hipóteses. Sempre focado no aprendizado acima do plano que, consequentemente, irá reduzir riscos e desperdícios antes de desenvolver algo.
De acordo com o produto e desafios do time, o processo de Product Discovery pode ser simples e rápido ou mais complexo.
E Product Delivery?
Já Product Delivery é o processo que acontece após ou junto ao Product Discovery, em que a hipótese de solução validada é desenvolvida e entregue às pessoas usuárias. Durante o Product Delivery o time também pode se dedicar a desenvolver experimentos que atendam as necessidades do Product Discovery.
| Product Discovery | Product Delivery |
|---|---|
| Problemas e Necessidades | Desenvolvimento |
| Oportunidades | Ritos de Agilidade |
| Pesquisa | Tecnologia |
| Dados e Informações | Definition of Ready (DoR) e Definition of Done (DoD) |
| Mercado | Deploy |
| Hipóteses | Go to Market |
| Experimentos / Testes / Protótipos | Observability |
| Aprendizado | Aprendizado |
Construir o produto certo com eficiência
A agilidade surgiu com o propósito de entregar mais valor a clientes e ser o mais eficiente possível. E este objetivo tem total relação com a cultura de produtos que vem sendo implantada nas organizações mais bem sucedidas no mercado atual. Porém, muitas empresas “brilharam os olhos” apenas para a parte do objetivo que trata da eficiência e encaram a agilidade como a grande solução para os projetos de tecnologia que ficavam anos em desenvolvimento.
Essa situação fica clara quando nos deparamos com pessoas discutindo a agilidade apenas com foco no processo de Product Delivery (com uma visão somente de projeto), desvirtuando completamente a essência da agilidade.
Claro que ter um processo de desenvolvimento com o Product Delivery eficiente é muito importante e, deve ser uma preocupação para os times de produtos, porém o produto não é só Product Delivery.
Problemas de não se investir em descoberta
Quando uma equipe se preocupa apenas com a as entregas, sem investir em descoberta, podemos ter problemas, por exemplo:
1 – Cuidar de um produto como se ele fosse um projeto
Trabalhar com projeto é normal e sempre vai existir. Isso não é um problema. Se o que está trabalhando tem características de projeto, tudo bem. O problema maior é quando temos um produto na mão e o tratamos como projeto. Se isso acontece, a necessidade de clientes não é atendida, o mercado deixa de ser acompanhado e o produto morre.
Inclusive, temos um episódio do Zupcast sobre gestão de produto x gestão de projetos. Está bem bacana:
2 – Não colocar energia para descobrir o que deve ser desenvolvido, antes mesmo de iniciar o processo de product delivery
Antes de começar a construir algo, é importante saber o que deve ser construído. Algo que seja relevante para clientes e que traga resultado para o negócio. Devemos descobrir o que é importante para as pessoas usuárias e para a empresa e então, construir.
Antes de pensar em desenvolver com muita eficiência, temos que saber se vamos construir o produto certo. Por isso, é importante fazer Product Discovery.
Equilíbrio entre Product Discovery e Product Delivery
A fase do Product Delivery é muito valorizada, sendo aceitável gastar mais tempo neste momento. Mas e o Product Discovery?
- Será que devemos gastar menos tempo fazendo Product Discovery do que fazendo Product Delivery?
- Será que não estamos gastando mais energia, tempo e dinheiro desenvolvendo soluções que não fazem sentido?
- Será que o processo de desenvolvimento não será mais eficiente se gastarmos mais tempo diminuindo o risco de escolhermos soluções que não atendam as necessidades?
Um exercício interessante seria equilibrar mais o tempo investido em Product Discovery e Product Delivery. Claro que de acordo com o contexto do time, pode ser que o Product Discovery seja maior, mas em um cenário “normal” tentar equilibrar pode ajudar a tirar algumas conclusões.
Descobrindo e reduzindo riscos no Product Discovery
Entre o problema e a solução pronta temos que descobrir o que deve ser desenvolvido, e para isso precisamos reduzir riscos e desperdícios.
O Product Discovery nos ajuda a reduzir alguns riscos e segundo Marty Cagan, temos quatro principais riscos que o guiam:
- Risco de Valor
- Risco de Usabilidade
- Risco de Desenvolvimento
- Risco de Negócio
Claro que existem vários outros para mitigar como, jurídico, ético etc, mas esses quatro são a base do Product Discovery.
Risco de Valor
Esse é normalmente o principal entre os quatro, pois é quando descobrimos se clientes vão ver valor no que vamos entregar. Se vai fazer sentido para as suas necessidades. É o momento de saber se as pessoas têm a percepção que estamos resolvendo o problema delas e, se nossa ideia é melhor que outras possíveis soluções disponíveis.
Aqui fazemos algumas perguntas, por exemplo:
- As pessoas vão escolher usar a solução?
- As pessoas vêem valor na nossa solução?
- Como a pessoa usuária resolve o problema atualmente? Ela trocaria isso pela nossa solução?
- As pessoas pagariam o preço necessário pela nossa solução?
Risco de Usabilidade
Quando entregamos uma solução para as pessoas, precisamos saber se elas vão saber como usar. Assim, o risco de usabilidade é tão importante que, se não bem mitigado, pode inviabilizar uma grande solução.
De nada adianta uma ideia linda e inovadora, se as pessoas não sabem como usar. Ou se a dificuldade de uma pessoa usuária completar uma tarefa seja tão grande que ela desista de usar. Ou se a jornada é tão complexa que a percepção de valor (risco anterior) fica prejudicada.
Quando falamos de usabilidade não quer dizer somente a navegação de uma tela, e sim toda a experiência envolvida.
Por exemplo: Em um aplicativo de compra de ticket de metrô, onde o bilhete fica na tela como QR Code:
- A pessoa usuária vai saber como colocar a tela do celular no leitor da catraca?
- As pessoas vão entender como fazer?
- Qual é o risco que temos de inviabilizar a solução?
- Qual o risco de aumentarmos muito a fila por as pessoas ficarem presas tentando ler o bilhete?
- Como podemos diminuir esses riscos?
Aqui fazemos algumas perguntas, por exemplo:
- As pessoas vão conseguir usar?
- As pessoas vão entender como funciona?
- A pessoa usuária conseguiu realizar as tarefas fundamentais?
- A pessoa usuária tem dificuldades?
Risco de Desenvolvimento
Além de nos preocupar se estamos entregando valor, se as pessoas vão conseguir usar, também temos que saber se somos capazes de construir a solução. Analisar o risco de desenvolvimento é olhar, por exemplo, para a tecnologia disponível, as ferramentas que temos, a capacidade do time e o orçamento.
Um exemplo bom é quando as criptomoedas entraram no hype e muitas empresas quiseram construir soluções em Blockchain, porém era uma tecnologia complexa, com pouca documentação disponível, uma comunidade ainda tímida e poucos profissionais especializados. Nesse contexto, o risco de desenvolvimento era alto.
Outro exemplo é desenvolver soluções em sistema legado, onde há muitas variáveis que aumentam a complexidade.
Aqui fazemos algumas perguntas, por exemplo:
- Vamos conseguir desenvolver essa solução?
- Temos pessoas preparadas?
- Temos acesso a essa tecnologia?
- Vamos conseguir escalar a solução?
Risco de Negócio
Entregar valor para clientes é extremamente importante, mas também é necessário trazer resultado ao negócio.
Buscamos diminuir esse risco entendendo se estamos indo para o mesmo caminho que a empresa, se está conectado com o negócio, se é o momento ideal para o mercado que estamos inseridos, se está alinhado com propósito e se os resultados planejados são o esperado.
Uma forma que não elimina, mas mitiga esse risco é trabalhar com OKRs, uma metodologia de gestão que ajuda no alinhamento dos times com objetivo da empresa.
Aqui fazemos algumas perguntas, por exemplo:
- Faz sentido para o nosso negócio?
- Está alinhado com os objetivos da companhia?
- Stakeholders vão apoiar?
- O negócio consegue dedicar tempo, pessoas e dinheiro?
Como fazer Product Discovery?
“…Precisamos entender suas necessidades, pontos problemáticos, desejos, vontades, objetivos e motivações…”
Teresa Torres
Como tudo no mundo de Produtos, não existe uma fórmula mágica ou bala de prata que estabeleça um processo único para Product Discovery. Então, o que é apresentado a seguir é um conjunto de etapas e ações sugeridas que normalmente se encaixam em um roteiro de descoberta de um produto.
| Problema / necessidade / resultado esperado | Oportunidades | Hipóteses de solução | Validação da hipótese | Delivery | Acompanhamento |
Como pontapé inicial e direcionador podemos ter problemas para resolver, necessidades para entender, e/ou um resultado de negócio esperado para ser entregue.
Logo seguimos buscando identificar oportunidades que possam entregar estes resultados esperados pelo negócio e consequentemente resolver problemas ou atender necessidades levantadas anteriormente.
Depois pensamos em identificar hipóteses de soluções que aproveitem essas oportunidades.
E para decidirmos se vamos desenvolver uma solução, buscamos validar ou refutar essas hipóteses. Se é validada, seguimos para o desenvolvimento de fato, se não, voltamos e mudamos o caminho. Embora existam várias formas de validar ou refutar essas hipóteses, um ótimo caminho é realizar experimentos em ambiente controlado para assegurar o menor investimento e baixo risco nesta etapa.
Com a hipótese validada, seguimos para o processo de Product Delivery onde de fato entregamos a solução para clientes. Porém, isso não significa que o Product Discovery esteja finalizado!
Seguimos acompanhando e medindo para saber se aquela solução validada anteriormente em um ambiente de experimentos controlados funciona bem para uma quantidade maior de usuários em contextos diferentes. Pensando algo básico como estabilidade e bugs, até algo mais específico como a conversão de uma determinada jornada.
Esse acompanhamento pode nos trazer pequenos ajustes e correções no produto, mas também novos grandes problemas, necessidades, novas oportunidades a serem exploradas e novos indicadores para seguir.
No momento em que estamos trabalhando em oportunidades que conectem com problemas, necessidades, resultados desejados e, testando possíveis soluções, estamos fazendo o Product Discovery. E para que os julgamentos e decisões ocorram baseados em fatos e menos em suposições, é necessário trabalhar com dados, informações, insumos e evidências que nos dê segurança para seguir com o Product Delivery.
Bem, dado isso temos que interpretar o que pode ser mais útil de acordo com cada situação. Pensando em tudo que está disponível atualmente e o que pode surgir amanhã. Além de podermos adaptar as opções existentes.
Ferramentas e métodos que podem ser úteis
Embora já tenhamos falado que não existe uma regra geral que se encaixe bem para qualquer tipo de situação, abaixo estão algumas ferramentas e métodos que comumente são utilizados em um processo de Product Discovery.
Cabe ao time envolvido no processo de gestão do produto conhecer e analisar como cada uma destas se aplica no contexto específico.
- Documentação
- Experimentações
- Matriz CSD
- Entrevistas
- Pesquisas (Survey)
- Jobs to be done
- Mapeamento de experiência
- Análise de comportamento de usuário
- Análise de dados
- Teste de usabilidade
- Usuários internos
- Benchmark
- Pesquisa de gabinete (Desk research)
- Priorização
Independente de qual ferramenta usar, o importante é se adaptar ao contexto, encontrar a melhor forma de trabalhar e chegar ao resultado. Temos que usar somente o necessário e não nos apegar a frameworks. Apesar de existir muita lógica em torno de um produto digital, há muita interpretação de acordo com o contexto de atuação. Entre zero e um não há nenhum número inteiro. Entre #FFFFFF e #000000, há muitos hexas.
O quanto se dedicar ao Product Discovery?
Atualmente na comunidade de produtos se discute muito sobre quando fazer Product Discovery.
- Será que é necessário fazer sempre?
- Temos que fazer para todas as situações?
Primeiro ponto sobre isso. Qualquer ação que você faça para tentar descobrir se faz sentido seguir por um caminho ou outro, desenvolver uma determinada solução ou não, faz parte de um Product Discovery. Conversar com uma pessoa ou analisar alguns dados, pode ser considerado um discovery. A diferença será se esse conjunto de ações está, de fato, reduzindo um risco.
Dado isso, a minha interpretação sobre quando fazer Product Discovery se baseia no tamanho do risco que você tem.
Quanto menor o risco, menor a energia colocada no Product Discovery, quanto maior o risco, maior o tamanho do discovery.
E se o grau de incerteza sobre o risco é alto, entendo ser necessário colocar mais energia para descobrir.
Conclusão
Concluímos que muitos produtos morrem por não resolverem um problema certo ou não entenderem as necessidades das pessoas. Isso normalmente se dá por conta de um grande foco na entrega, e não no resultado. O ideal é que os times de produtos foquem no resultado.
Quando tivermos uma ideia pronta, devemos encarar ela como uma Hipótese, e então buscarmos evidências para validar ou refutar, além de analisar os possíveis problemas que a solução deve resolver.
Esse trabalho todo chamamos de Product Discovery, que tem como objetivo descobrir o que deve ser desenvolvido para entregar valor para as pessoas e a empresa. Já o Product Delivery é o processo de construção do que foi descoberto.
No desenvolvimento de produto como um todo, temos que nos preocupar em encontrar o que devemos desenvolver (Discovery), e depois como desenvolver com eficiência (Delivery).
Para colocar o Discovery em prática, existem várias ferramentas e formas que nos ajudam entender melhor os problemas e necessidades de clientes, como chegar às oportunidades e priorizá-las. Também podemos encontrar técnicas para definirmos hipóteses e testá-las. É muito comum adaptarmos as ferramentas e técnicas de acordo com o contexto em que estamos. Para o time mais importante não deve ser qual ferramenta ou técnica usar, e sim o resultado que buscam alcançar.
E para saber o quanto colocar energia do time no Product Discovery, minha sugestão é avaliar o risco que o cenário representa: quanto maior o risco, mais o time deve se dedicar.
