Quero compartilhar algumas lições aprendidas ao adaptar um produto digital existente para novos segmentos de clientes. Não deixei o email ligado ao produto mas ao processo de construção e até o momento presente.
Será descrito da seguinte forma:
- Definindo a visão de produto
- Tenha as pessoas a bordo (stakeholder management) para fazer acontecer
- Como falar com outras áreas para chegar até a visão
Por que definir a Visão de Produto é tão importante?
“Gerente de Produto Alice”- Sem Visão de produto, qualquer direção é válida.
Como gerente de produto, você deve saber e ser hábil em comunicar aos outros que direções seu produto está seguindo. É claro, nem sempre estará certa(o), mas ter a intuição irá te ajudar a tomar decisões melhores e garantir que as pessoas em volta estarão com você na mesma visão.
Isso é especialmente importante já que a vida diária da(o) PM é caótica, e é fácil ficar sobrecarregada(o) por pessoas pedindo funcionalidades ou dizendo as direções que o produto deve ir. Definir e documentar a visão de produto irá ajudar você e as pessoas ao redor a entender como avançar na visão do produto e da empresa como um todo.
Como eu criei a Visão de Produto
Para começar a pensar, primeiramente li muita coisa sobre como a tecnologia está mudando nos próximos 5 anos e tentei identificar que comportamentos/tendências parecem que vão persistir.
Essa pesquisa foi feita em áreas que são tanto direta ou indiretamente relacionadas ao meu produto. Até o momento, elas podem não convergir, mas é interessante imaginar como elas podem convergir se um problema pode ser resolvido de uma melhor forma.
Uma coisa importante a destacar é que essa pesquisa pode ser feita fora da internet. Por exemplo, se você quiser saber mais sobre reconhecimento de voz, encontre pessoas que estão trabalhando com isso para te dar uma "mini-aula" sobre seu trabalho atual e como área está evoluindo.
Depois disso, passei algumas semanas escrevendo como o futuro poderia ser. Para começar esse exercício, não me preocupei se teríamos dinheiro ou pessoas para fazer acontecer. O processo foi livre e sem restrições.
Para documentar as ideias, usei uma mistura de post-its, texto e algum tipo de conexão entre as ideias. Não é necessário ficar preso em alguma ferramenta em particular, mas usei o Miro para me ajudar com esse exercício. Entretanto, esse processo poderia ter sido feito facilmente em papel. Algumas vezes pode ser até melhor, já que limita as distrações nesse processo imersivo.
Uma coisa importante foi pensar sobre somente algumas horas por dia e não o dia inteiro. Isso ajudou a pensar de forma mais holística sobre o produto e me deu tempo para pensar de forma criativa sobre o produto em dias diferentes.
Por que é importante e o que pode ser um entregável "simples"
A visão do produto deve ser uma frase fácil de lembrar (slogan inspirador) e a estratégia do produto deve ser o trabalho que deve ser feito para se chegar a essa visão (mais sobre isso abaixo).
Como a(o) gerente de produto não é o gerente de ninguém, é importante que as pessoas confiem e entendam a visão que você as fornece. Isso é ainda mais necessário se sua empresa tem muitas áreas diferentes que não são integradas em equipes multi-funcionais, criando desafios para ter as pessoas a bordo. Isso também acontece porque outras áreas terão seu próprio roadmap, então levar as pessoas a se comprometerem com o seu pode ser desafiante caso se conflite com o roadmap de outros times.
Contando com as pessoas a bordo
É importante deixar claro que a(o) gerente de produto não pode entregar um produto por si só. A(o) gerente de produto irá entregar o produto com a ajuda de outras pessoas, então será mais fácil se você tiver uma ótima visão de produto e entender como transmiti-la utilizando o "idioma das outras pessoas".
Então, vou me aprofundar mais em alguns cenários do mundo real que usei para levar as pessoas a bordo para conseguir um produto melhor nas mãos dos clientes.
Fala um idioma que outras pessoas entendam
Você precisará de muita cooperação de pessoas diferentes de áreas diferentes, por isso é importante entender o que fará com que elas sejam bem-sucedidas, ajudando você.
Time de Sucesso do Cliente (Customer Success)
Imagine que você precisa fazer um Discovery para uma nova funcionalidade e é necessário um grupo para te ajudar a validar. Você sempre pode tentar abordar um cliente desconhecido e torcer para que tudo corra bem, ou simplesmente pedir ajuda à equipe da CS, cujo um dos trabalhos é conversar com os clientes todos os dias.
Idealmente, o time de CS terá um bom grupo de clientes que eles sabem que podem te ajudar ou que podem ser acessados no momento. Você também quer ter certeza de que entende o contexto do cliente - por exemplo, se o time de CS lhe apresentar um cliente frustrado com outra parte do seu produto, provavelmente não serão uma boa fonte de feedback para uma funcionalidade mais recente até que seus problemas iniciais atuais sejam resolvidos.
Então, nesse cenário, vocês dois irão se beneficiar. Você poderá conversar com alguém que possa fornecer um feedback interessante, e a pessoa de CS pode melhorar o health score do cliente, mostrando como o produto está evoluindo.
Time de Engenharia
Como PM,é necessário fornecer ao time de engenharia o máximo de contexto possível sobre o produto que estão ajudando a construir: estratégia de negócios, pessoas envolvidas, mercado atual, expectativas do C-level, métricas financeiras atuais e assim por diante.
Ao contextualizar sobre o que estão fazendo, será mais fácil explicar em que direção o produto está indo e, o mais importante, por que o produto está indo nessa direção. Ao fazer isso, o time será mais autônomo em decisões técnicas e não irão precisar do PM para tomar 100% das decisões.
Se você é responsável por fazer planejamento de sprint e descrever o que precisa ser feito nas próximas semanas, irei compartilhar algumas dicas importantes:
1 - Cada história/card/épico deve ter métricas associadas:
Por exemplo, nosso produto precisava enviar emails para clientes. Mas, as pessoas não estavam abrindo nossos emails numa taxa que estávamos esperando. Então, ao invés de propor uma solução para o time (por exemplo, pedir que os emails fossem enviados durante o dia no horário útil de trabalho), nos comprometemos em uma sprint para "aumentar a taxa de abertura de e-mail". Quando refinamos essas histórias, o time foi capaz de pensar não apenas em muitas soluções para um período do tempo em específico, mas também em uma métrica para verificar se estavam tendo sucesso ou não.
Então, não apenas tendo o contexto de negócios em mente, mas uma métrica clara (e fácil de medir) associada foi a nossa linguagem comum
2 - Tenha objetivos de negócios para cada sprint
Isso parece óbvio, mas geralmente o Jira ou o Trello (nossas ferramentas mais usadas para controlar o sprint) não tem um lugar específico para isso.
Então, em cada planejamento de sprint, escrevemos o que o negócio espera daquela sprint. Por exemplo: "usuário deve poder enviar um email". Para conseguir isso, talvez seja necessário desenvolver várias coisas tanto no back quanto front-end, sendo divididos em histórias menores. Então tendo objetivos "em nível de usuário" ou "em nível de negócio" definidos, o time pode entender melhor como as coisas podem ser encaixadas e por que. Essa dica é uma junção com a primeira, mas acredito que são tão importantes que devem ser descritas em visões separadas.
3 - Se você usar Scrum, tenha uma agenda consistente
Novamente, parece óbvio, mas se você se comprometer a ter uma daily às 09:30 AM, deve fazer isso nesse horário específico. Um produto levará tempo para ser feito e é necessário disciplina para isso. Ser consistente com o time de engenharia com uma agenda ajudará a manter as coisas nos trilhos.
Time de vendas
É um bom exercício conversar com as pessoas que trabalham no time de vendas para lhe explicarem o fluxo de trabalho diário e mensal. Poderá ver que o trabalho de vendas pode ser muito estressante. O time de vendas sempre tem uma meta de vendas a atingir, precisa apresentar um produto para um mercado que muda todos os dias, e entender seus clientes para ver se o produto irá resolver suas necessidades (entre outras coisas).
Com isso em mente, é muito importante que o time realmente entenda o que o produto faz, como deve ser apresentado, como difere dos concorrentes, como eles podem cobrar dos clientes e quais são os custos atuais do produto.
Para atingir esse objetivo, criei uma planilha que contém:
- Custos atuais do produto: infra-estrutura, custo de outras ferramentas que usamos (e como esses custos aumentam à medida que os clientes chegam), pessoas envolvidas (engenheira(o)s, designers, PM)
- Concorrentes atuais e como cobram por seus produtos
- Uma proposta de plano de preços: apresentando preços diferentes e quais funcionalidades devem ser incluídos em cada plano
Com esta planilha, pudemos falar sobre o que nosso produto pode fazer para diferentes tamanhos de empresa, como pode ser apresentado e como o time de vendas podem demonstrá-lo da melhor forma para seus clientes.
Depois disso, pudemos conversar um com o outro em termos que ambos entendamos.
Recursos escassos
Uma coisa que muitos PMs enfrentam é como realizar uma visão de produto com recursos limitados. Nem sempre terá todos a(o)s engenheira(o)s, todos a(o)s designers, todo o marketing e assim por diante. Portanto, quando você não estiver encarregado de contratar mais pessoas e a empresa não conseguir fazer isso por um tempo, você precisará encontrar maneiras e ser criativo.
Por exemplo, no momento não temos um Product Designer dedicado o time, mas um dia, quando estava conversando com o time, ouvi dizer que nosso desenvolvedor front-end lia muito sobre UX/UI e queria fazer mais trabalhos de design. Por enquanto, ele é nosso novo designer e está sendo treinado pelo Head de Design.
Portanto, quando conversar com as pessoas que estão trabalhando no produto, pode identificar algumas áreas deficientes no desenvolvimento do produto e saber o que as pessoas gostam e são capazes de fazer. Quando você tem escassez no seu produto (e você o terá), ter essa capacidade de ouvir e adequar as pessoas o ajudará a entregar um bom produto com sua equipe atual.
Um produto que todo mundo participa
Como um gerente de produto só entrega um produto com outras pessoas de diferentes áreas e formações, eu quis mostrar o quanto é importante atrair pessoas para isso e que formato pode ser apropriado para cada um.
Obviamente, esse modelo deve ser adaptado em outras empresas, mas esse exercício para descobrir como você pode se aproximar de outras pessoas é uma grande parte do trabalho de gerente de produto!
PS1: Este artigo foi feito com a orientação de Matt Grierson. No primeiro semestre de 2020, tive a oportunidade de participar como mentorado em um programa chamado The Product Mentor, um programa criado por Jeremy Horn para parear mentores e mentorados de produtos de todo o mundo, desde startups até grandes empresas, guiada por objetivos fundamentais: Melhores decisões. Melhores produtos. Melhores pessoas de produto.
Estou extremamente agradecido por ter essa orientação por tanto tempo.
PS2: No processo de criação deste artigo, li muitos artigos, principalmente de Marty Cagan e Melissa Perri, e também tive novas experiências no meu trabalho. Além, é claro, da orientação mencionada.
Sempre que lia um novo texto ou tinha uma outra experiência, quis alterá-lo, dificultando a "conclusão". Portanto, este texto não é a versão final, mas a atual (ou a versão 1.0).
PS3: Esse artigo foi originalmente publicado em inglês nesse link: https://productcoalition.com/product-vision-speak-language-people-will-understand-6654e8799b80
