Como pensar sobre os 4 grandes riscos de produto podem informar melhores decisões em produto.

Uma pergunta clássica que profissionais de produto se fazem é “quando o discovery está ‘pronto’? Quando eu posso botar a funcionalidade em desenvolvimento sem medo?” A resposta está na linha do que disse Leonardo Da Vinci sobre obras de arte:

“A arte nunca está terminada, é apenas abandonada.”

Porém artistas competentes, assim como profissionais de produto, sabem o momento certo de “abandonar” sua obra botando-a em produção. Porque, como dizia Steve Jobs, “artistas de verdade entregam”. 

Uma boa forma de saber quando parar a descoberta de produto é entender quais são os riscos de construir a solução baseado no que você sabe agora. No início de um discovery de um novo produto ou funcionalidade, praticamente tudo é incerto. Essas incertezas introduzem risco (ex: se você construir a coisa errada, vai gastar tempo e dinheiro e não vai conseguir chegar no objetivo desejado). O objetivo do discovery de solução é, óbvio, descobrir uma boa solução da maneira mais rápida/barata possível.

Marty Cagan popularizou 4 grandes categorias de riscos* que PMs deveriam mitigar durante o discovery de solução: risco de valor, risco de usabilidade, risco de viabilidade e risco de negócio.

Risco de Valor

As pessoas vão comprar/usar isso porque gera valor para elas? Isto resolve um problema real e importante?

Estas são as perguntas que mitigar o risco de valor deve responder. Muitas vezes este é o principal e mais importante risco, pois se a solução não gerar valor para os clientes, dificilmente o produto será bem sucedido.

Como em qualquer problema não estruturado, existem muitas formas de mitigar o risco de valor. Aqui vão algumas ideias de como explorar este risco:

• Insights existentes: quais são os problemas que nossos clientes reclamam no suporte? Por que perdemos algumas vendas? Quais problemas aparecem recorrentemente em reviews negativos? Algumas vezes estes problemas são no-brainers (ex: não consigo finalizar o checkout porque não aceita a bandeira do meu cartão de crédito por causa de um bug) e algumas poucas reclamações já podem responder a pergunta de valor.
• Feedback quantitativos: Qual o percentual de usuários que passa por este problema? Quantos usuários usam essa funcionalidade? Quantas vendas perdemos por este motivo?
• Funcionalidades fundamentais: também conhecidas como “table stakes”, algumas coisas precisam estar lá para que o produto seja adotado por certos tipos de clientes ou indústrias. Por exemplo, se o Calendly não integrasse com meu Google Calendar, eu jamais usaria ele. PS: é preciso tomar cuidado com o que é de fato fundamental, pois é fácil dizer que tudo que o concorrente mais bem sucedido tem é fundamental.
• Entrevistas com clientes: se ainda não tivermos certeza do valor, pode ser bom fazer algumas entrevistas com clientes para avaliar isto. Porém se você perguntar algo como “você pagaria por X” ou “você usaria o produto se ele fizesse Y” você vai receber respostas que vão estar erradas. No meu curso sobre Entrevistas de Discovery eu explico por que, além de ensinar como fazer entrevistas que extraem insights reais e úteis.
• Teste da porta falsa: consiste em mostrar algo que parece uma funcionalidade, mas ainda não está lá. Startups fazem muito isso colocando uma landing page no ar que explica o produto e vendo quantas pessoas clicam em “cadastrar-se”. Outra forma de fazer isso é colocando o que parece uma feature no ar, mas a funcionalidade ou não faz nada ou explica que ainda está em testes. O LinkedIn fez isso ao introduzir a funcionalidade de “divulgar para os recrutadores que estou aberto a oportunidades” – no início, o botão não fazia nada. Quando eles perceberam que as pessoas estavam dispostas a clicar no botão, eles construiram a feature.

Risco de Usabilidade

As pessoas que usam o produto vão saber utilizar isto? Elas vão entender?

É preciso tomar cuidado com as “certezas” de que algo é usável, pois muitas vezes o que é óbvio para nós (profissionais de tecnologia), não é óbvio para nosso público. 

Testes de usabilidade não precisam ser complexos. Alguns exemplos de como mitigar este risco:

• Teste não-moderado: é o tipo de teste mais escalável, por não precisar estar presente para rodá-lo. Uma coisa que UX Designers usam com frequência é mandar uma imagem do design junto a um formulário com perguntas sobre o que o usuário entendeu da imagem.
• Teste moderado: cara a cara ou remotamente, consiste em apresentar um protótipo ao usuário e testar o entendimento e uso. Não necessariamente precisa ser um protótipo de alta fidelidade, algumas vezes um wireframe em papel já é o suficiente para captar problemas de entendimento.

Risco de Viabilidade

Conseguimos construir isso com o tempo e recursos que temos disponíveis? Temos as habilidades necessárias para isto?

Normalmente, isso significa apenas uma conversa com alguém sênior de engenharia, por exemplo um engineer manager ou desenvolvedor sênior, para identificar potenciais armadilhas. 

Se for uma ideia tecnicamente desafiadora, pode exigir algum trabalho real de descoberta de engenharia para ajudar a identificar os riscos envolvidos em sua construção. Uma das maneiras de mitigar esse risco é construindo uma prova de conceito para as áreas onde a mais incerteza e risco. O maior risco aqui é fazer uma prova de conceito grande demais, o que vai demorar.

Risco de Negócio

Nossos stakeholders apoiam isso? Se um jornal escrevesse sobre o que estamos fazendo, isso seria bom ou mancharia nossa reputação? É legalmente correto fazer isso? É eticamente correto fazer isso? É viável financeiramente?

Em mercados pouco regulados, a maioria das coisas não vão ter risco de negócio, a não ser que sejam grandes apostas ou mudanças. Já em mercados mais regulados, como os que fintechs atuam, boa parte do esforço está em mitigatar riscos de negócio.

Para mitigar este tipo de risco, não tem muito segredo: é preciso conversar com os stakeholders, como executivos, departamento legal, financeiro, etc. 

Observação importante: não confunda mitigar os principais riscos com mitigar todos os riscos

Os principais riscos são aqueles que podem destuir a sua ideia ou negócio, seja por tomar uma direção errada ou por construir algo que não atinge o objetivo desejado. Isso não significa que todos os riscos devem ser mitigados.

Existe sempre um certo grau de risco até que algo de fato esteja na mão dos usuários. Você precisa tomar a decisão conscientemente se esse é um risco que é a) baixo; e/ou b) mesmo que seja real, pode ser facilmente contornado.

Outro exemplo onde mitigar risco pode não fazer sentido é quando mitigá-lo é mais custoso do que fazer a mudança. Exemplo: salvo seu aplicativo ter muito débito técnico de front-end, colocar uma tooltip explicando algo é um esforço baixíssimo, coisa de horas. Provavelmente levaria mais tempo recrutar usuários e fazer um teste de usabilidade do que fazer um teste A/B com a tooltip. 

Atenção sobre velocidade de discovery

Não confunda fazer discovery com um processo cascata. Uma boa descoberta de problema é iterativa, com dezenas de questões e riscos mitigados por semana. Pense na forma mais simples / rápida / baixo custo de mitigar algo. Quando seu foco está bastante direcionado a discovery, todos os dias você precisa fazer progresso. Nada de ficar escrevendo documentos longuíssimos por meses, heim?

* As vezes os nomes são um pouco diferentes. Algumas vezes também um 5o risco, de ética, é adicionado, porém o risco ético para mim está dentro do risco de negócio.