Product Oversee

Anotações Teresa Torres na Digital Product Week 2021

Essas são meus comentáriso e anotações da palestra sobre Continuous Discovery da Teresa Torres

Imagem de destaque de Anotações Teresa Torres na Digital Product Week 2021

Essas são as minhas anotações e comentários sobre a palestra da Teresa Torres no evento Digital Product Week da Tera, que aconteceu no dia 05/10/2021.

A Teresa é bastante conhecida pela formação do framework Continuous Discovery. Product discovery é feito para decidir o que construir. Product Delivery é como construir isso. E para definir o que é Continuous Discovery ela usa as seguintes quatro frases:

  • Pontos de contato semanais com os clientes,
  • Pelo time que está construído o produto,
  • Onde eles conduzem pequenas pesquisas,
  • Procurando qual é o outcome desejado no produto.

Weekly touch points with customers

A ideia é termos um feedback dos usuários de forma regular. E essa forma regular é necessária por que nós tomamos decisões de produto todos os dias.

Conforme trabalhamos nos produtos, nós sabemos como nosso produto funciona. O ponto é que conforme aumentamos nossa expertise do nosso produto, nós também aumentamos nosso viés, então, é importante perguntar para os usuários, que ainda não tem esse viés.

Nós precisamos engajar com os consumidores pelo menos uma vez por semana

A etapa de validação não é a única forma de validar suas ideias. Nós podemos ter feedback dos clientes de diversas maneiras, inclusive das maneiras mais baratas (não só do ponto de vista de grana, mas também de operação e processo). O objetivo é estimular a co-criação com os consumidores.

Nós não perguntamos para os clientes “o que você quer”. Essa é a abordagem errada. Quem define o que construir para o desejo dos clientes somos nós, de produto A ideia é entender de fato se o que estamos prestes a construir tem potencial de sucesso.

Não acho que tenhamos que falar todas as semanas com os clientes, também não acho que todo mundo saiba falar com o cliente excluindo totalmente os vieses, e interpretando corretamente as entrelinhas do que o cliente quer dizer.

Com quantos clientes você consegue entrar em contato na semana? Qual a amostragem ideal para sabermos que as percepções que ouvimos fazem sentido para base como um todo? Além disso, como balancear isso tudo com o dia a dia é mais difícil do que parece.

By the team building the product

É muito importante que o mesmo time que esteja construindo produto seja o time que entre em contato com os clientes. Aqui tem uma observação importantíssima da Teresa: geralmente nós usamos dois times para executar o Dual Track Agile (meu deus, gente…): um time para discovery e outro para delivery. Não é isso que queremos. O mesmo time precisa trabalhar nas duas trilhas.

Eu trabalho com esse trio de profissionais há muito tempo. É o óbvio e é o que funciona até hoje (depois de uns 10 anos trabalhando nessa indústria vital). Eu ainda colocaria alguém de dados. Então, para mim não seria mais um trio, mas um quarteto. O meu pensamento seria:

  • PM consegue ter visão cruzada do negócio + produto, detendo a visão de adaptability e feasibility;
  • Design Lead consegue ter visão de experiência de uso e também desirability;
  • Tech Lead detém a visão de viability e principalmente e escalabilidade técnica;
  • Data Lead detém a visão de feasibility (junto com o PM), além de validações mais estratégicas (inclusive o que vem antes do discovery);

Esse quarteto, para mim, seria o ideal. É muito difícil termos isso rodando na maioria das vezes em um time de produto e o quarteto pode mudar. Se o produto é muito direcionado por marketing, faz sentido ter alguém aí de marketing, talvez, substituindo o Tech Lead. Várias combinações podem funcionar aí. É o que eu chamo de Núcleo de Produto. Onde a pessoa que faz a gestão do produto direciona a visão de produto conectada à estratégia da sua linha de negócio.

O trio da Teresa é o mínimo com que você deve trabalhar e é muito possível de alcançar. O quarteto é um pouco mais difícil, mas eu acho que também é possível.

Ela representa uma composição de time nessa imagem:

A Teresa ainda diz que algo comum de acontecer na comunicação desse trio é o famoso waterfall. Isso não deve acontecer. É muito fácil de acontecer que os dvs fiquem uns 5 ou 6 passos longe do cliente e isso é ruim porque eles perdem contexto e constróem a coisa errada.

Outro ponto que ela coloca é que não é necessário trazer todo mundo para o discovery, ser não as entregas ficam mais devagar, obviamente. É legal ter um rodízio aí.

Where they conduct small research activities, In pursuit of a desired product outcome

O objetivo com esse “statement” é que sejam pesquisas pequenas. Então, não vamos descobrir o produto inteiro, só pequenas partes. Nós vamos fazer pesquisas para criar valor para o cliente, que por sua vez criam valor para o negócio.

Para que os alinhamentos do cliente, produto e negócio estejam alinhados, ela fala da Opportunity Solution Tree, que faz parte do framework dela. Esse sim você deveria levar como padrão, porque na verdade é uma derivação do que já fazemos na vida de produto e principalmente de negócio.

Essa estrutura é basicamente a quebra de algo maior, que é o Outcome desejado do produto. Esses outcomes quebram-se em oportunidades que serão exploradas (no continuous discovery), e então você quebra para soluções que você quer validar e então cria vários experimentos para essa validação ou invalidação acontecer.

Ela usa o exemplo do Netflix porque todo mundo usa Netflix e fica fácil de entender:

  • Outcome de NEGÓCIO: Aumentar a retenção dos assinantes. Esse outcome de negócio é definido pela liderança (seja ela qual for: board, senior manager etc);
  • Outcome de Produto: Aumentar engajamento do viewer. Aqui há uma tradução do outcome de negócio para outcome de produto, que é o que impacta diretamente o outcome de negócio. Eu costumo dar o nome do outcome de negócio como GOAL. Esse outcome de produto é uma hipótese, uma TEORIA. O time aqui acredita que se aumentar o engajamento de quem assiste, vai aumentar a retenção dos assinantes.

Ela diz que trabalhar em cima de roadmaps de médio/longo prazo, é ruim porque os planos mudam. E concordo MUITO com ela. Outcomes de negócio (os Goals) mudam, por que o mercado muda, porque pandemias acontecem, novos entrantes ameaçam o negócio, regulamentos mudam etc… Então, não faz sentido fazer algo com um prazo muito grande. E essa é a graça de você seguir outcomes (resultados) e não outputs (entregas puras).

Dado que sabemos quais os outcomes, nós desdobramos para a oportunidade, que representam:

  • pain points dos usuários;
  • necessidades dos usuários;
  • desejos dos usuários;

Coletivamente, esses três pontos representam valor para o cliente. E o valor pro cliente, representa valor para o negócio.

Outro ponto importante que a Teresa destaca é que o problema de fazer discoveries constantes, é o recrutamento de usuários que participem da pesquisa. Se você já fez qualquer tipo de pesquisa na vida, seja de produto, seja específico de UX, você já percebeu que é muito difícil trazer os clientes para mesa.

O que ela recomenda, nesse caso, é automatizar o recrutamento com diversas técnicas. Eu gosto muito de abrir uma opção no produto para que os usuários interessados em serem beta testers, habilitem uma opção e pronto, conseguimos gerar uma base fiel de usuários que estão a fim de se submeter a testes direto na plataforma ou que querem experimentar funcionalidades ainda em fase de validação.

Mesmo assim, a ideia não é você ter um milhão de clientes para conversar nas semanas, mas ter o suficiente para que você possa conversar e fazer o pequeno research que ela cita acima.

Ela fala também sobre como fazer perguntas corretas para os clientes. Existem diversos vieses que queremos evitar e não queremos fazer perguntas diretas. Nós precisamos coletar histórias. Por exemplo, uma pergunta boa seria: “Qual foi a última vez que você assistiu Netflix?”. O principal aqui é que dentro da história, você consiga ouvir as respostas dos seus questionamentos e assim você consegue entender quais são as dores, desejos e necessidades dos clientes para completar o seu mapa de oportunidades.

Eu gosto bastante desses 3 riscos, eles são usados para mapear riscos de negócio muito antes de todo mundo fazer produto. E aí tá faltando ainda um outro risco importante que é Adaptability, que é a capacidade do negócio/produto se adaptar às novas configurações do mercado, clientes e ambientes externos ou internos.

Concluindo

Não estou dizendo o que é certo ou errado, pelo contrário, eu aprendi que em produto a resposta perfeita sempre é depende. Contudo, gosto de fazer questionamentos para que você não feche os olhos e acredite que Continuous Discovery é padrão de mercado, por que não é.

Eu gosto bastante da abordagem total, mas eu ainda gosto de capturar dados regularmente de forma automática e de forma secundária, chamar os usuários para fazer o research que a tereza diz. Ela até respondeu uma pergunta mais ou menos assim: “O survey do hotjar (ou similar) é considerado por você como um touchpoint com o usuário? É válido?”

Ela diz que é interessante para entender uma suposição, mas não substitui conversas e entrevistas com o usuário.

Adorei a talk, nada de realmente novo do que já tinha estudado, mas a Teresa é maravilhosa e realmente tem vários pontos importantes ali que direcionam os times de produto para uma construção mais saudável de algo que realmente terá resultados positivos para o produto e consequentemente para o negócio.

Referências: