Product Manager (Gerente de Produto) é a pessoa que define o quê, quando e porquê um produto/funcionalidade deve ser criado.
Em startups pequenas, esse papel geralmente é desempenhado pelo CEO ou líder de tecnologia e, em empresas grandes, cada subconjunto dos produtos oferecidos podem ter um Product Manager coordenando os trabalhos.
Observe que eu não disse que é o Product Manager que define como um produto/funcionalidade deve ser criado, isso é trabalho da equipe de produto.
Os designers e programadores que devem encontrar os meios para executar a tarefa – e o papel do Product Manager é justamente coordenar essa equipe multi-funcional para entregar o melhor produto possível.
O que é Product Discovery
Product Discovery é o processo que os Product Managers usam para descobrir se o produto a ser criado está no “caminho certo”. Marty Cagan, uma importante figura de Product Management do Vale do Silício e autor de INSPIRED ¹ , diz que o processo de descoberta de um produto precisa ser ágil e precisa avaliar esses riscos:
- Risco de Usabilidade
- Risco de Valor
- Risco de Plausibilidade
- Risco de Negócio
Risco 1 – O cliente vai conseguir usar isso?
O risco
Esse risco é o mais direto de todos: se o cliente não conseguir usar o produto, jamais vai enxergar valor nele. Conhecido como risco de usabilidade, aqui precisamos avaliar se o usuário consegue realizar as tarefas que nossa solução propõe resolver e quanta fricção existe nesse processo.
Técnicas para avaliar o risco
Avaliar o risco de usabilidade é uma das atividades mais consolidadas de Product Management. Existe muita literatura disponível sobre o tema mas, sucintamente, tudo gira em torno do conceito de exibir protótipos para um ou mais consumidores potenciais do produto e observar seu comportamento de uso.
Quando exibimos o protótipo para o consumidor, estamos atrás de três casos:
- O usuário conseguiu realizar a tarefa sem nenhum problema e sem ajuda;
- O usuário se debateu e reclamou um pouco mas conseguiu realizar a tarefa;
- O usuário ficou tão frustrado que não conseguiu realizar a tarefa;
Fundamentalmente, estamos tentando entender como o usuário enxerga o problema com esses três casos e em qual ponto do protótipo existem gargalos ou inconsistências com a linha de raciocínio do usuário.
Risco 2 – O cliente vai comprar ou escolher usar isso?
O risco
Esse é conhecido como o risco de valor. Esse é o risco mais importante de ser avaliado e às vezes o mais negligenciado. É comum que equipes de produto se apaixonem pelas suas ideias, passem meses desenvolvendo-as para que no fim descubram que os usuários simplesmente não se interessam pela novidade.
É essencial que o Product Manager consiga determinar que a solução proposta, seja um novo produto ou uma nova funcionalidade, terá valor suficiente para os usuários para justificar o esforço de desenvolvimento.
Técnicas para avaliar o risco
No livro INSPIRED¹ , Marty Cagan cita três etapas para avaliar o risco de valor:
Testar a demanda
Um dos maiores gastos de tempo e recursos possíveis para uma empresa é fazer algo que ninguém quer ou precisa. Seja uma startup nova, seja um produto novo ou mesmo uma funcionalidade nova (esse último é o mais comum – quantas funcionalidades pedidas por clientes grandes, que geraram uma alta demanda no time de desenvolvimento, não foram usadas no fim?).
O primeiro passo para o Product Manager é, portanto, descobrir se o público alvo precisa da solução. Essa descoberta é baseada nas próximas duas etapas.
Testar o valor qualitativamente
Um teste qualitativo de valor é feito para entendermos o que está acontecendo e não o porquê (para isso serve o teste quantitativo). Esse tipo de teste é, geralmente, conduzido através de uma entrevista com o consumidor, ou um grupo de consumidores do produto e é acompanhado de um teste de usabilidade.
Cagan propõe alguns tipos de técnica para demonstrar o valor durante a entrevista. Uma delas é usar o dinheiro para demonstrar valor. Essa técnica se resume a pedir um comprometimento do consumidor, durante a entrevista, sobre a aquisição do produto (mas nós não queremos de fato o comprometimento).
Outra técnica é reputação para demonstrar valor. Essa é uma técnica para avaliar o risco de valor cuja premissa é simples: o quão inclinado o consumidor estaria para recomendar o produto que está sendo exibido para ele?
Aqui é possível pedir que o consumidor compartilhe nas redes sociais dele sobre o produto ou divulgue e-mails de colegas (novamente, não queremos os emails e sim avaliar quanto valor está sendo percebido).
Testar o valor quantitativamente
Enquanto o teste qualitativo é sobre aprendizado, esse teste é sobre coleta de evidências. A ideia é coletarmos dados estatísticos significantes para justificar decisões sobre o produto. Técnicas famosas para esse tipo de teste são:
- teste A/B, onde duas versões do mesmo produto são disponibilizadas para grupos de consumidores. Aqui o objetivo é avaliar o uso cotidiano do usuário sem que ele saiba que está participando de um teste;
- programas de teste por convite, onde convidamos alguns usuários do produto a testar a funcionalidade nova, informando que ela está em estágio beta. Esse tipo de teste é considerado um pouco inferior ao A/B pois os usuários estão cientes que estão testando.
Risco 3 – Nós conseguimos criar isso?
O risco
Conhecido como risco de plausibilidade, esse risco gira em torno da equipe de programação: dado que o usuário vê valor no protótipo e consegue usar, será que a equipe consegue criar um produto em cima disso? Nesses momentos, algumas das perguntas levantadas são:
- Nós sabemos construir isso?
- Nós temos as habilidades para construir isso?
- Nós temos tempo para construir isso?
- Como isso influencia nossa infraestrutura atual?
- Teremos problemas de performance?
- Isso é escalável?
Técnicas para avaliar o risco
Aqui entra a importância de se incluir os programadores nos ciclos de Product Discovery. No desenvolvimento do protótipo para os testes de usabilidade e valor, algumas dessas questões podem ser facilmente respondidas e observações levantadas sobre possíveis gargalos. A ideia é evitar que, no meio do projeto de desenvolvimento, alguma dificuldade técnica que não estava prevista venha atrapalhar a conclusão.
Outro ponto importante é permitir (leia-se alocar tempo) que a equipe explore a viabilidade do produto/funcionalidade. Quando pressionadas com uma pergunta do tipo “Vocês conseguem fazer isso?” sem tempo para testar ou considerar opções, a maioria das equipes de desenvolvimento vai dar uma resposta conservadora.
Risco 4 – Essa solução funciona para nosso negócio?
O risco
Como se não fosse suficientemente difícil encontrar uma solução que seus consumidores queiram usar, vejam valor e que seus programadores consigam construir, ainda precisamos avaliar se essa solução está alinhada ao seu negócio. Aqui o trabalho do Product Manager é garantir que todos os stakeholders entendam e estejam alinhados com produto.
Técnicas para avaliar o risco
Abaixo estão alguns exemplos de como os stakeholders precisam estar em sintonia com a equipe de produto no desenvolvimento de novas funcionalidades ou soluções:
Marketing
O interesse do marketing é propulsionar as vendas, garantir a visibilidade da marca e a reputação da empresa. Se a solução que você está propondo afetaria o canal de vendas ou então estaria potencialmente fora do que a marca da empresa prega, trabalhe com eles mostrando os protótipos que são exibidos nos testes para que qualquer problema possa ser identificado de antemão.
Vendas
Se sua empresa tem um canal direto de vendas, uma solução nova pode impactar altamente o desempenho da equipe de vendas. Aqui é preciso avaliar se o novo produto precisa de algum treinamento para habilitar os vendedores, ou se existe alguma restrição que pode prejudicar a performance comercial.
Customer Success (CS)
Algumas empresas de tecnologia podem dividir sua estratégia de customer success em dois: high-touch ou low-touch (as vezes conhecido como no-touch). Esse é um indicativo de quanto auxílio o consumidor do produto precisa para que consiga configurar seu uso.
Novamente, se o produto ou funcionalidade que você está propondo pode afetar a operação ou possa estar desalinhado com a estratégia, o ideal é que o Product Manager avalie os riscos com a equipe de CS.
Uma observação importante: em empresas high-touch, os membros da equipe de CS são excepcionais para auxiliar nos testes dos protótipos.
Financeiro e Jurídico
Aqui é preciso garantir que a solução encaixa nos budgets da empresa e que todos os termos legais sejam atendidos, tais como: privacidade, compliance, propriedade intelectual e competidores.
Conclusão
Avaliar esses riscos é o trabalho que o Product Manager precisa executar para garantir que o produto ou funcionalidade consiga agregar o valor real para a empresa. É um erro muito comum achar que apenas as opiniões internas são suficientes para garantir o valor do produto final, ou então subestimar obstáculos técnicos ou jurídicos e no fim ter uma grande dor de cabeça.
TL;DR (Em resumo):
- Crie protótipos das suas ideias antes de tentar implementá-las e apresente ao maior número de consumidores possíveis;
- Colha os dados de uso e avalie os gargalos de usabilidade;
- Dê tempo à sua equipe de desenvolvedores para testar todas as implicações técnicas da solução;
- Converse com todas as áreas da empresa sobre possíveis problemas com o produto/funcionalidade.
