*O gerenciamento de preferências é parte integrante de uma grande infraestrutura de notificação, o que o torna uma peça muito importante do quebra-cabeça aqui no Courier. Isso também significa que houve muito aprendizado e oportunidade de construção de experiência para o estagiário do projeto, Denis Tatar. O estágio de Denis durou apenas alguns meses, mas ele conseguiu causar um enorme impacto como gerente de produto do recurso Courier's Preferences.

Queríamos saber mais sobre a experiência de Denis, então perguntamos se ele estaria disposto a escrever um artigo para nós. Então o que ele inventou foi tão bom que achamos que seria uma boa ideia compartilhar com todos vocês! Esta postagem abordará o fluxo de trabalho de Denis, desde o planejamento até a execução do projeto Preferences, bem como sua experiência de trabalho especificamente com a equipe Courier. Vamos deixar Denis assumir daqui!

Qual era o problema?

O problema que enfrentamos na Courier era que oferecíamos Preferências (V3) aos nossos clientes, mas toda a estratégia de recursos do produto não estava totalmente desenvolvida. Acredito que o V3 foi um grande trampolim para o V4, mas fundamentalmente tinha falhas em certas partes de sua estratégia. Permitir apenas opt-in/out global é um exemplo disso. Outro problema foi que o V3 não ganhou muita tração, o que, acredito, aponta para a falta de uma estratégia totalmente pensada.

Em maio, as Preferências (V3) permitiriam apenas que os usuários aceitassem e cancelassem suas preferências de escolha globalmente. A V3 de Preferências permitia apenas que nossos clientes (e seus clientes) aceitassem/não recebessem notificações, e os clientes globalmente também podiam decidir se certas notificações eram necessárias ou não. O V3 ajudou a dar aos nossos clientes a capacidade de começar a brincar com a ideia de ter preferências. No entanto, optar/sair globalmente é um problema porque restringe as opções de notificação dos usuários finais. Era tudo ou nada, sem meio termo. Semelhante em teoria ao Pokémon dizendo: "Pegue um, pegue todos". Um problema com isso, porém, é a inundação da caixa de entrada. A aceitação global permitiria que as caixas de entrada dos usuários finais fossem inundadas com todas as notificações de produtos, o que é problemático porque pode facilmente afastar os usuários do seu produto.

O opt-in/out global foi resolvido rapidamente, permitindo que os usuários selecionassem o conteúdo sobre o qual desejavam ser notificados e os canais de sua preferência. Essa tendência geral do mercado é usada por milhares de empresas (produtos B2B e B2C), especialmente no espaço de tecnologia.

A visibilidade se tornou um problema sério com a V3. Os usuários finais nunca tiveram a opção de selecionar o tipo de conteúdo e canal que desejavam. Os usuários seriam questionados se estavam interessados em receber notificações em geral. Não oferecer opções é problemático, pois restringe a visibilidade do que você receberá por meio de notificações. Os usuários finais também não gostam de surpresas quando se trata de notificações de produtos. Ter clareza é fundamental porque permite que os usuários finais tenham controle sobre suas notificações.

Com a V4, resolvemos o problema de visibilidade, que era a principal “falha” da V3. Nossos clientes e seus usuários finais agora podiam controlar o conteúdo que recebiam e os canais de sua preferência.

V4 foi uma boa maneira de notificar estrategicamente os usuários finais.

Plano

Houve três fases que seguimos como uma equipe ao criar Preferências.

1. Pesquisa Na fase um, gastei um bom tempo olhando o que está atualmente disponível no mercado em termos de centros de preferência. Eu constantemente me fazia as duas perguntas a seguir:

   “Como a [insira o nome da empresa] gerencia as notificações? Como é o centro de preferência deles?”

   Essas perguntas foram fundamentais. Eles me ajudaram a mergulhar na pesquisa necessária que me ajudou a entender muitas tendências importantes do mercado. De todas as tendências encontradas, porém, houve uma que mais se destacou.

2. Tendência: a seleção de canal e conteúdo por meio de um layout de estilo de alternância/grade para centros de preferência é obrigatória. Essa tendência se tornou a espinha dorsal do nosso projeto de verão. Era importante oferecer opções de preferência aos usuários.

Durante esta fase, li muitos estudos de caso. Fiquei surpreso ao ver quantos existiam sobre esse assunto. Cada um ajudou a me iluminar com soluções para o problema que estávamos enfrentando. Aprendi com os erros dos outros, absorvendo lições valiosas.

Conversar com os clientes foi extremamente útil nessa fase. Pude atender várias ligações com nossos clientes e ouvir suas perspectivas sobre esse problema. Eu fazia perguntas e mostrava exemplos do que tínhamos em mente para uma solução. Isso ajudou a adaptar um POC. Quanto melhor entendermos as perspectivas de nossos clientes, mais fácil será começar a projetar algo que eles usariam.

3. Desenhar um POC Gostei muito desta fase. Assistir a pesquisa se tornar um POC real foi incrível e muito divertido. Pegamos todo o feedback que reuni e criamos várias iterações de designs.

Depois de criarmos um POC, era essencial voltar aos nossos clientes e garantir que era algo que eles imaginavam para as Preferências. Nossos clientes também eram pessoas adoráveis com quem trabalhar, sempre disponíveis para fornecer o feedback tão necessário.

Freqüentemente, eu tinha uma quantidade razoável de sessões de brainstorming com Ian. Analisaríamos nossa pesquisa e o que nossos clientes tinham a dizer e combinaríamos essas fontes em um POC. Foi um processo perspicaz de se fazer parte.

Essa fase durou várias semanas até que finalmente chegamos a um POC que satisfez todos os clientes com quem conversamos desde maio de 2022.

4. Construindo um MVP Uma vez que tínhamos um POC e projetos totalmente concluídos, começamos a construir nosso recurso de produto. Esta fase me ensinou duas lições vitais…

   
   

Ser organizado é extremamente importante.

e...

Como gerente de produto, você precisa ficar uma semana à frente de sua equipe.

Enquanto trabalhava na Courier e delegava tarefas, percebi que quanto mais organizado você era, mais fácil era trabalhar com outras pessoas. Minhas habilidades organizacionais afetariam a clareza com que nossos designers e engenheiros entenderam nossos objetivos e tarefas delegadas individualmente. Quanto mais organizados fôssemos, mais rápido e eficiente trabalhávamos. Descrever as tarefas que nossa equipe precisava concluir e explicar por que essas tarefas eram necessárias ajudou muito. Trouxe clareza para todos, inclusive para mim.

A segunda lição aqui foi dada a mim por nosso CEO, Troy. Ele me ensinou como é importante pensar na semana atual e na seguinte. Troy mencionou isso porque, como gerente de produto, você deseja manter sua equipe informada sobre quais projetos e tarefas estão em andamento. Um gerente de produto que não tem essa mentalidade pode rapidamente se tornar um obstáculo para sua equipe. Assumir essa mentalidade trouxe clareza e me deixou menos estressado com nosso projeto. Eu gastaria tempo planejando cada semana e estimando onde a equipe deveria estar no final de cada semana (ciclo).

Essas duas lições ajudaram quando estávamos construindo um MVP. Progredimos em cada semana como uma equipe, com as tarefas de cada semana delineadas, junto com as metas semanais que precisávamos alcançar. Trabalhar com a equipe da Courier foi incrível, todos foram compreensivos e absolutamente brilhantes. O que eu mais amava era que todos tinham uma opinião. Engenheiros e designers perguntavam se tarefas específicas eram prioridades antes de criá-las, o que nos permitiu construir o MVP e colocá-lo em funcionamento rapidamente. Essas perguntas ajudaram a orientar as prioridades e a tomada de decisões.

Execução: O que eu fiz exatamente

Ao longo deste estágio, todos os dias foram diferentes. Minha semana envolveria falar com clientes, delegar tarefas a nossos engenheiros e designers e reservar um tempo para pensar no futuro, duas a três semanas antes da semana atual. Também trabalhei em estreita colaboração com engenheiros e designers, garantindo grande sinergia entre as duas equipes.

Havia quatro responsabilidades principais que incorporei ao longo do meu estágio de gerente de produto na Courier:

Ser o especialista interno sobre o que o mercado (clientes e prospects) deseja dentro do meu foco.

Ser o especialista interno sobre o que o recurso do meu produto já oferece (e, portanto, o delta para a responsabilidade principal acima). A capacidade de priorizar o caminho que leva o Courier do estado atual ao estado desejado.

A capacidade de educar o resto da empresa sobre o produto atual, o produto que está sendo construído e nossa visão final do produto para que todos possam estar na mesma página sem serem especialistas.

Como a cola que garante que a equipe esteja trabalhando junta na coisa certa pelos motivos certos, o sucesso deles é limitado pela minha eficácia em um e dois. Não posso educar com precisão os colegas de equipe sobre o que eu mesmo não entendo profundamente.

Troy foi um mentor fantástico durante todo o meu tempo na Courier. Ele chamou minha atenção para essas quatro responsabilidades essenciais, que se tornaram parte integrante do meu estágio. O que mais ressoou em mim foi ser a cola entre todas as equipes. A princípio, olhei para esse conceito e fiquei intimidado por ele. Mas, eu me diverti muito ao me tornar essa figura de cola entre as equipes. Definitivamente não foi algo fácil de realizar, mas gostei do desafio. Consegui fazer muitos grandes amigos ao longo do caminho também!

Que trade-offs eu experimentei?

Houve muitos trade-offs durante todo o meu estágio. Os principais que experimentei estavam relacionados com o seguinte conceito “faça funcionar -> faça bem -> faça rápido”, que ouvi muitas vezes ao longo do meu estágio. Muitas vezes, pequenos recursos que poderiam destacar nossa UI/UX realmente desaceleravam a equipe.

Trocas como essas eram necessárias. Eles me fizeram questionar se nos concentramos nos detalhes essenciais ou deixamos o recurso de lado e nos concentramos em fazer um produto que funcione e faça o trabalho? A última parte dessa pergunta foi frequentemente escolhida como nossa estratégia. É difícil fazer essas chamadas porque você sabe que a equipe pode desenvolver um excelente produto construído com componentes UI/UX fenomenais, mas nossa construção deve realizar o que deve fazer em primeiro lugar.

O objetivo principal era lançar nosso MVP, garantir que tivéssemos feedback do cliente, melhorar todos os recursos principais e, em seguida, focar em prioridades menores que afetam a interface do usuário/UX deste produto.

Como foi trabalhar com a equipe?

Eu me diverti muito trabalhando com a equipe do Lifecycle em Preferências. Todos foram muito gentis e ofereceram um feedback fantástico. Mencionei isso várias vezes no escritório e em ligações com colegas de trabalho. Trabalhar na Courier não parecia trabalho; parecia que eu estava trabalhando em um projeto paralelo com amigos próximos. Eu realmente acho que é por isso que consegui produzir o trabalho que fiz na Courier, por causa do meio ambiente. Courier é descontraída, extremamente amigável e orientada para resultados.

Outra coisa que eu realmente amei na equipe foi que eles sempre pensaram em mim. Se houvesse tarefas que engenheiros ou designers fariam que fossem consideradas uma 'norma' para eles, eles me perguntariam se eu gostaria de tentar para ver como é. Tenho três exemplos disso.

Ao projetar uma dica de ferramenta específica para uma parte do projeto Preferências, Ian (designer sênior) durante uma de nossas ligações perguntou se eu queria uma chance de criar uma dica de ferramenta. Isso envolveu trabalhar com Frames in Figma, um conceito com o qual nunca trabalhei. Gostei muito de criar essa dica de ferramenta. Isso me fez sentir incluída.

Toda semana, a equipe teria nossas reuniões de planejamento do ciclo de vida da equipe. Falávamos sobre ingressos e os escrevíamos. Foi no início do meu estágio que Suhas (engenheiro sênior) me perguntou se eu queria tentar redigir vários tickets no Linear. Eu sabia que isso era algo que a maioria dos PMs normalmente faria, mas tinha muito respeito por Suhas por trazer isso à tona e estava disposto a me ensinar como criar tickets corretamente no Linear.

Uma vez que a equipe tinha algo solidificado para Preferências, comecei a perguntar internamente para saber se havia alguma empresa interessada em ouvir sobre meu projeto. Nathan (executivo de contas) entrou em contato comigo para me informar sobre um cliente interessado neste recurso de produto. Nathan me encorajou MUITO quando se tratava de me comunicar com esse cliente. Pude sair da minha zona de conforto por causa do incentivo de Nathan. Nunca conversei com um cliente antes em nenhuma das minhas experiências anteriores de estágio e aprendi muito sobre os clientes e a maneira como eles percebem o Courier.

Note que estes são apenas três exemplos das muitas oportunidades como esta ao longo do meu estágio. Eu quero dar um grande alô para Ian, Suhas e Nathan. Agradeço a vocês por me darem oportunidades de aprender e crescer, isso significa o mundo para mim.

Como trabalhei com designers?

Gostei de trabalhar com Ian (Designer Sênior). Tínhamos reuniões improvisadas por meio do recurso 'Huddle' do Slack (que foi renomeado internamente para 'Huggle' por causa de um erro de digitação que uma vez fez com que travasse). Essas reuniões foram ótimas para brainstorming e design de produto. Às vezes, Ian e eu recebíamos ligações mais tarde à noite porque era mais fácil ter ideias mais criativas. Tínhamos sessões de uma a duas horas e criávamos uma UI/UX realmente incrível para preferências . Isso é algo que nunca vou esquecer.

Ao trabalhar com Ian, eu tentava tornar tudo o mais fácil possível. Eu criaria uma lista de tarefas por meio do Google Docs ou Slack, para que Ian e eu estivéssemos cientes do que precisava ser concluído a cada semana.

Durante nossas ligações, Ian e eu também conversávamos sobre vários tópicos diferentes, nem sempre diretamente relacionados ao trabalho, o que era ótimo. Isso realmente ajudou a construir nossa amizade, tornando muito mais fácil colaborar e criar uma UI/UX limpa para Preferências. Costumo fazer uma boa quantidade de design de produto fora do horário de trabalho, e Ian sempre me dava conselhos fenomenais sobre design de produto e sobre Figma!

Como trabalhei com engenheiros?

Falei brevemente sobre isso, mas, ao trabalhar com engenheiros, ajudaria a criar tíquetes e organizar a aparência de cada semana. Eu ajudava nossos engenheiros sempre que eles estavam confusos sobre qualquer coisa relacionada a Preferências e explicava como eu criei nomes específicos, por que Ian e eu projetaríamos certas partes de nosso produto e os objetivos por trás desses projetos. Muitas dessas respostas vieram de meu extenso processo de pesquisa com clientes interessados em Preferências.

Enquanto trabalhava com engenheiros, aprendi muito sobre como dividir corretamente os tickets (eipcs) no Linear. Eu achava que tinha um domínio firme antes de trabalhar na Courier, mas aprendi muito mais depois de trabalhar com a equipe do Lifecycle. A chave para quebrar os tíquetes é ser capaz de pensar em cada detalhe ao lado dos engenheiros. Estar em um pequeno grupo ao fazer isso foi super importante porque cada indivíduo ajudou a trazer uma perspectiva muito importante sobre como decompor os tíquetes.

Durante meu estágio, Seth (Diretor de Tecnologia), Suhas (Engenheiro de Software Sênior) e Christian (Engenheiro de Software) me incentivaram a falar com a equipe de Experiência do Desenvolvedor da Courier e mostrar nosso projeto. O principal objetivo por trás disso era testar se a UI/UX de Preferências era intuitiva, se o design fazia sentido e se a equipe de Experiência do Desenvolvedor entendeu o objetivo por trás desse recurso do produto. Preparei um conjunto de slides explicando nosso projeto na íntegra. Essa foi uma ótima experiência porque me ajudou a me preparar para vender o Preferences para nossos clientes. Fazer apresentações perspicazes sobre produtos e “vender” seu produto aos clientes é uma habilidade tão importante e negligenciada pelos gerentes de produto . Falar com pessoas internamente também me ajudou a praticar e refinar essa habilidade.

Como resolvi o problema?

Antes do V4 Preferences, os clientes não tinham a opção de escolher o conteúdo que gostariam de ouvir e como gostariam de ouvir. Com as Preferências V4, os usuários agora podem expressar suas opiniões sobre esses dois assuntos. Esse novo recurso de produto permite que os clientes escolham o que gostam e querem ouvir. Especificamente por meio de sua preferência de canais.

Já se foram os dias de caixa de entrada lotada e os clientes se irritando com o número de notificações que recebiam. As preferências minimizam a frustração que os usuários finais experimentam com suas notificações.

Quer se candidatar a uma vaga na Courier? Confira nossa página de carreiras . Para conferir o que Denis ajudou a construir em ação, solicite uma demonstração aqui e peça para ver o recurso Preferências.