Stories by Jessica Esquenazi Hollander on Medium

(Quase) tudo o que você precisa saber para gerenciar stakeholders

Jessica Esquenazi Hollander — Thu, 01 Oct 2026 11:45:29 GMT

Como se destacar no trabalho, acertando nos detalhes importantes da relação com stakeholders.

Capa do filme Divertida Mente 2

Índice

Por que vale a pena falar sobre gestão de stakeholders?
Como gerenciar Stakeholders
Alinhamento de objetivos
Construção da relação
Comunicação assertiva
Material de Leitura

Visibilidade na carreira precisa extrapolar o time de produto, mas, pra isso, é preciso se destacar perante stakeholders.

Infelizmente, existem ainda muitas empresas que — por motivos que são mais complexos do que cabe nessa curta introdução — os times de produto e tecnologia têm uma relação já muito calejada e frustrada com outras áreas da empresa. Fica um relacionamento marcado por richas e por falta de confiança.

Resolvi abordar esse tema por aqui, pois qualquer pessoa de produto que quer verdadeiramente se destacar precisa aprender a trabalhar muito bem com stakeholders e carregar consigo a responsabilidade de não propagar uma cultura de disputas e frustrações.

A intenção é que você saia daqui entendendo profundamente o que é uma relação com stakeholders saudável, produtiva e capaz de te destacar na sua carreira, e o que você precisa fazer para conquistá-la.

**Por que vale a pena falar sobre gestão de stakeholders?**

Uma (não tão) pequena lista de motivos, porque:

Essa relação é central e constante durante toda a sua carreira de produto,
Uma boa relação com stakeholders depende do aprimoramento de outras habilidades fundamentais para Product Managers,
O elogio de stakeholders vale muito mais do que um elogio do seu chefe,
A grande maioria de Product Managers considera essa a parte mais difícil ou custosa do trabalho, e
Sem o apoio de stakeholders, sucesso não é possível.

Vamos começar pelo básico e alinhar a terminologia?

Pode ser que você já esteja há anos trabalhando com produto e queira desesperadamente pular essa parte (e tá tudo bem), mas, como a ideia do artigo é permitir uma troca de ideias e conhecimento com pessoas vindas de diferentes trajetórias e momentos de carreira, vamos repassar rapidamente ao que nos referimos no mundo de produto quando falamos de stakeholder.

Apelando para a tradução ao pé da letra: stakeholder é quem carrega o risco (stake: risco, holder: aquele que carrega).

Um jeito simples de definir stakeholders é considerar todas as pessoas impactadas direta ou indiretamente pelo seu trabalho.

O único problema dessa definição é acabar, sem querer, caindo na armadilha de ter stakeholders demais, o que aumenta significativamente a complexidade de qualquer funcionalidade.

Alegria sobrecarregada pela quantidade de memórias espalhadas na mente

Uma definição de stakeholder que considero saudável é a usada pelo Marty Cagan em seu texto Stakeholder Management:

“O principal teste para saber se uma pessoa é um stakeholder é se ela tem ou não poder de vetar ou de impedir de alguma forma o lançamento do seu trabalho (seja um novo produto ou funcionalidade). Mais especificamente, cada stakeholder representa alguma parte essencial do negócio.” (tradução livre)

Com base nas ressalvas trazidas por Marty Cagan na categorização dos stakeholders para evitar certas armadilhas, mas considerando a importância de abordar todos os possíveis componentes de alinhamento para o sucesso de um produto, proponho a seguinte terminologia de classificação de Stakeholders:

Stakeholders: pessoas-chave para as quais devemos atribuir diferentes papéis na concepção de um produto ou funcionalidade para garantir o sucesso de seu lançamento.

Note que os principais pontos que desejo ressaltar com esta definição são:

Ao definir seus stakeholders, veja cada um como um indivíduo, e não como um grupo ou departamento. Escolha pessoas-chave, pois isso ajuda a garantir o sucesso da comunicação.
Considere a participação dos stakeholders — atribua papéis a cada um — ; alguns terão papéis ativos, outros passivos.
Reconheça que, sem os stakeholders devidamente alinhados, é impossível garantir o sucesso do seu lançamento.

Esta definição de stakeholders nos leva a uma segunda pergunta: quais os diferentes papéis a serem atribuídos? Segue abaixo minha sugestão de classificação de stakeholders:

Patrocinador

Idealmente apenas uma pessoa que represente o departamento que será mais profundamente impactado pelo produto/funcionalidade.

Acumula, obviamente, papéis de decisor, contribuinte e observador, destacando-se por ter o poder de decisão sobre todos os aspectos do projeto. Além de ser o stakeholder mais importante, na maioria das vezes, é o mais desafiador de gerenciar.

Decisor

Aqui podemos ter mais de um decisor, desde que cada um tenha poder de decisão sobre um aspecto específico do produto.

Por exemplo, na grande maioria dos projetos, um representante do time jurídico terá poder de decisão sobre os aspectos legais de um produto ou funcionalidade.

Outro exemplo seria um representante do time de tecnologia, com poder de decisão sobre como o produto será desenvolvido tecnicamente. Decisores acumulam também os papéis de contribuinte e observador.

Contribuinte

Aqui entram todas as pessoas envolvidos diretamente no produto, que possuem conhecimento ou experiência relevante para agregar valor às decisões.

Na maioria das vezes, são colaboradores que trabalham próximos aos decisores e patrocinadores, mas também podem incluir representantes de áreas que, embora não tenham poder de decisão sobre o produto, são diretamente impactadas por ele.

Embora esse grupo possa ser mais abrangente, é crucial escolher cuidadosamente os participantes para evitar um excesso de contribuintes, o que pode prolongar discussões e desviar o foco das questões essenciais.

Observador

Todos os que precisam estar por dentro dos principais avanços do produto/funcionalidade. Muitas vezes são áreas que não tem poder decisão, nem valor de contribuição, mas serão impactadas pelo produto.

Um ótimo exemplo seria o time de marketing, que precisa se planejar para preparar uma campanha de lançamento.

Essa lista pode ser um pouco mais abrangente, desde que você saiba, dentro deste grupo, quais precisam confirmar/acusar o recebimento e a ciência dos avanços.

**Vamos explorar alguns exemplos de stakeholders?**

Para fins didáticos, imagine que uma Product Manager da Uber precisa definir os stakeholders para uma funcionalidade semelhante ao '99Negocia'.

Telas da funcionalidade 99Negocia

Esta Product Manager poderia então:

Mapear diferentes departamentos/setores da Uber impactados pela nova funcionalidade (identificação),
Refletir sobre como cada um participaria do projeto (classificação), e
Escolher uma pessoa como Stakeholder (atribuição).

Atenção:
A tabela abaixo não representa a relação real de departamentos da Uber, muito menos um caso real de mapeamento de stakeholders, sendo simplesmente um exemplo hipotético para fins didáticos.

Idealmente a coluna 'atribuição' seria preenchida com o nome da pessoa. Para fins didáticos, deixei exemplos de possíveis cargos de pessoas que poderiam ser eleitas como representantes.

Repare que, na coluna de atribuições temos alguns cargos no plural, mostrando a possível abrangência de cada classificação.

| **Identificação**          | **Classificação** | **Atribuição**
| Time de Novos Negócios     | Patrocinador      | Head de novos negócios
| Alta Liderança             | Decisor           | CRO
| Produto & Tecnologia       | Decisor           | PM & Tech Lead
| Jurídico                   | Contribuinte      | Especialista Senior
| Atendimento ao Motorista   | Contribuinte      | Gerentes
| Atendimento ao Passageiro  | Contribuinte      | Gerentes
| Marketing                  | Observador        | Coordenador e sua equipe
| Financeiro                 | Observador        | Gerentes e coordenadores
| Operações                  | Observador        | Gerentes e coordenadores

Ter um entendimento básico de quem são stakeholders e como classificá-los é essencial para um gerenciamento de sucesso, mas é só o primeiro passo…

Como gerenciar Stakeholders

Vamos ao que interessa?

Identificação, classificação e atribuição nós já abordamos 🙌, mas agora sim vem a parte mais desafiadora: gerenciar!

Existe uma “matriz de poder e interesse” para gerenciar Stakeholders que já vi circular por alguns materiais. Acho relevante citar aqui, levantando um ponto de atenção:

A abordagem da matriz é mais de como “administrar” um problema do que de como usar os stakeholders e sua comunicação com eles como um instrumento para o seu sucesso de forma colaborativa e ativa.

Matriz de influência por interesse (Fonte)

Ao invés de dissecar esta matriz, faremos um movimento diferente de nos distanciar de frameworks e criar um entendimento profundo do tema, para pensarmos por conta própria, criando nosso próprio modelo mental para gerenciar stakeholders.

Seguem os pontos que vamos abordar:

Alinhamento de objetivos: todos remando na mesma direção
Construção da relação: exercer a escuta ativa e ganhar a confiança
Comunicação assertiva: linguagem, formato e frequência com cada stakeholder.

Alinhamento de objetivos

Quando falamos sobre a importância de alinhar os objetivos, esse é um momento em que precisamos realmente parar e refletir sobre experiências passadas e entender o que poderíamos ter feito diferente. A resposta pode até ser não ter nem começado a desenvolver um produto ou uma funcionalidade.

Posso compartilhar um exemplo muito claro de uma funcionalidade que não foi para frente por falta de alinhamento de objetivos entre stakeholders.

Na ocasião, eu havia sido contratada diretamente pela CEO e fundadora da empresa para dar início a um produto de comunidade. O patrocinador era a head do time de marketing e os principais decisores eram o time de eventos e de diversidade.

A grande problemática que quero levantar é a seguinte: apesar de ter um forte patrocinador, o produto não estava alinhado com os objetivos do time de marketing. O objetivo do time de produto era retenção, enquanto o time de marketing estava totalmente e 100% focado em aquisição.

Apesar de definir pessoas-chave como stakeholders e incluí-las nas discussões, receber e considerar suas sugestões, uma vez lançada a comunidade, o time de marketing fez uma tímida campanha orgânica de divulgação… e ficou por isso.

Lançamos um produto que não era uma prioridade para nossos stakeholders. Apesar da CEO ter convicção de que o produto traria muito sucesso para a empresa, não estavam alinhados com os objetivos do patrocinador.

Cena de Divertida Mente

Podemos tirar algumas outras lições desta história, mas, para este “capítulo”, tiramos o seguinte: se todos não estiverem remando na mesma direção, a canoa não sai do lugar.

Antes de chegar perto de definir a solução, garanta que seus stakeholders estão alinhados com o problema e têm os mesmos objetivos que você.

É claro que o nível de alinhamento de objetivos vai variar de acordo com o tipo de stakeholder. Segue uma sugestão, lembrando que, no fundo, o ideal é que nenhum time ou departamento da empresa esteja remando em direção contrária.

| **Classificação**   | **Alinhamento**
| Patrocinador        | Idealmente compartilha o mesmo conjunto de OKRs
| Decisor             | Compartilha de pelo menos um de seus OKRs
| Contribuinte        | Beneficiado diretamente pelo sucesso do seu OKR
| Observador          | Alinhado aos mesmos objetivos estratégicos

Aqui vale ressaltar os seguintes pontos:

Considere que o problema que você trouxe pode não ser um problema real para seu stakeholder, ou que ele possa resolver o problema dele sem o time de produto. Portanto, escolha dedicar recursos de produto para um objetivo que seja importante para seu stakeholder e que você, como time de produto e tecnologia, esteja em uma posição vantajosa para resolver.
Ao se comprometer em alinhar os objetivos, lembre que o alinhamento pode caminhar tanto para um lado quanto para o outro: abra sua mente, não entre em um modo de “defensor” do time de produto, e chegue a um acordo com participação das lideranças de qual objetivo/meta terá o melhor impacto para a empresa.
Não defina os objetivos por alto. Esse alinhamento precisa ser estrutural. Para garantir o sucesso do produto, o alinhamento de objetivos precisa ser registrado na forma de metas ou OKRs. Se os principais OKRs de seu patrocinador não forem os mesmos, ou não estiverem na mesma direção dos seus, então já estão começando de forma errada. Por isso, inclusive, a importância de poucas metas, pois assim aumentamos o foco e a garantia de que todos estão na mesma direção.

É claro que, para ter essas conversas difíceis, se abrir, deixar o ego de lado e alinhar objetivos e metas, é fundamental ter uma boa relação com os stakeholders, sobretudo com o patrocinador e os decisores.

Observação:
Estou dedicando mais foco aos itens que você como product manager consegue atuar sobre e impactar diretamente, mas muitas vezes a própria forma como a liderança de uma empresa é estruturada e seu processo de definição de metas, tradução do plano estratégico para tático, ou até mesmo fatores culturais, podem influenciar e dificultar este alinhamento.

Caso identifique que fatores estruturais como os mencionados acima estão impedindo o alinhamento de objetivos, minha recomendação é dar visibilidade para este problema de forma didática aos seus stakeholders e propor que juntos iniciem o processo de mudança necessário.

Se deseja se aprofundar no tema, recomendo a leitura do livro Transformed do Marty Cagan.

Construção da relação

Eu diria que, apesar desta parte ser um tanto óbvia, é bem desafiadora no dia a dia de uma pessoa de produto. Temos muitas responsabilidades, muitas vezes tocamos diversos projetos ao mesmo tempo, e precisamos construir novas relações com muita frequência. Estamos habituados a ter a "cada de pau” de chegar em diferentes pessoas em diferentes níveis de liderança, conversar de igual para igual e coletar as informações necessárias para nossos projetos.

O problema é que, apesar destas interações serem frequentes e termos facilidade na comunicação e no relacionamento, isso não significa necessariamente que ganhamos a confiança do Stakeholder nem que estamos verdadeiramente escutando e absorvendo o que ele tem a dizer (escuta ativa). Isso pode acabar tornando nosso processo de concepção e desenvolvimento de produto infinitamente mais desafiador.

Praticando a escuta ativa

Os Stakeholders patrocinadores, decisores e contribuidores foram selecionados por um motivo: todos eles têm o conhecimento necessário para consultar (e, no caso dos patrocinadores e decisores, tomar decisões) que ditarão o sucesso do produto.

Por esse motivo, a principal qualidade de um Product Manager que sabe gerenciar Stakeholders é a capacidade de escuta ativa. Não apenas pare, preste atenção e reflita sobre as ponderações de seus Stakeholders, mas faça questão de mostrar que você está os escutando ativamente.

Um dos maiores erros cometidos por Product Managers é não entender corretamente o problema do seu Stakeholder patrocinador. É muito falado que bons product managers e product designers conseguem entender o que o stakeholder precisa de fato, em vez de apenas executar o que ele pede. Mas muitos Product Managers interpretam isso da forma errada e acabam duvidando até mesmo do próprio problema apresentado pelo Stakeholder, propõem que o problema seja outro e desenvolvem uma funcionalidade que acaba sendo inutilizada. Soa familiar?

Conquistando a confiança

Ao não conseguir construir uma relação de confiança, você acaba perdendo a atenção do seu stakeholder e não será valorizado ou escutado. Além de a falta de confiança ser problemática para discussões relevantes e enriquecedoras, pode ser extremamente desagradável e frustrante em um nível pessoal, tornando o dia a dia do trabalho pesado e desmotivante.

Cena do filme Divertida Mente

Construir confiança não é algo simples e pode levar tempo. Mapeei três pontos que considero fundamentais para essa construção:

O primeiro deles é a relação. Para confiar em você, o stakeholder precisa te conhecer, então lembre de se apresentar como uma pessoa, para além de um profissional, com objetivos pessoais alinhados com os da empresa. Interprete sua primeira interação com o Stakeholder Patrocinador como uma entrevista de emprego, na qual ele criará as primeiras impressões e irá refletir sobre se acredita que você tem o que será necessário para ajudá-lo a atingir seus objetivos.

O segundo ponto é a aquisição de conhecimento. Na maioria das vezes, product managers precisam mergulhar em um contexto no qual os stakeholders patrocinadores, decisores e contribuintes já são especialistas. Nessa fase, faça o máximo de perguntas possível. Compartilhe seus aprendizados e pergunte se está no caminho certo. Além disso, use a posição de aprendiz para construir um vínculo ainda maior com seu stakeholder. Se colocar em uma posição de humildade e escuta ativa, abrirá muitas portas! Se os seus stakeholders participarem e forem testemunhas do seu processo de aprendizagem, irão confiar muito mais nos seus levantamentos.

O terceiro é trazer embasamento para todos seus levantamentos. No fundo, aqui, estamos falando de dados. Significa estudar o problema a fundo e ter referências o mais científicas possível para suas opiniões e constatações. Esta não é uma tarefa apenas para ganhar a confiança dos stakeholders, mas uma habilidade fundamental para seu sucesso como product manager. É uma forma de se colocar à prova, garantindo que trará contribuições coerentes.

Vou deixar abaixo algumas dicas gerais para se relacionar com stakeholders:

Durante as interações, faça contato visual e utilize linguagem corporal para demonstrar que está prestando atenção.
Entenda quais as métricas que ele olha e quais ele gostaria de ter visibilidade. Crie familiaridade com essas métricas; assim, conseguirá por si só identificar os problemas que seu Stakeholder já nota.
Sempre que for pedir algo, explique sua intenção por trás. Ajude o Stakeholder a entender o que você quer e por que você quer.
Da mesma forma, quando um Stakeholder lhe pedir algo, faça as perguntas corretas para entender a intenção por trás do pedido e seja genuinamente prestativo. Esteja a serviço e disposto a ajudar. Sempre que não puder ajudar, explique o porquê.
Não tenha medo de fazer “perguntas bobas”. Muitas vezes, dessas perguntas podem sair ótimas reflexões e novos pontos de vista.
Considere fazer sessões de shadowing do stakeholder e/ou seu time para sentir na pele o dia a dia do seu stakeholder. Não o interrompa, deixe que ele tome a iniciativa de fazer ressalvas, adicionar contexto e pontuar o que for relevante. Caso tenha dúvidas, anote e pergunte em outra ocasião: uma reunião 1:1 entre vocês.

Comunicação assertiva

Falamos da construção da relação e da importância de conquistar a confiança por meio do compartilhamento de conhecimento e embasamento. Isso lhe permitirá ser verdadeiramente ouvido e considerado em suas observações. Um grande passo para garantir o sucesso do produto.

No entanto, o maior gerenciamento de Stakeholder acontece no dia a dia, na comunicação.

Primeiro, vou mostrar uma sugestão de comunicação adaptada para a definição dos 4 tipos de Stakeholders definidos neste artigo. Ela é um tanto simplória, mas cumpre uma função didática. Depois vou entrar um pouco mais no detalhe de como definir a frequência, o canal, adaptar a linguagem e o formato da comunicação com cada um dos stakeholders, além de deixar algumas dicas sobre cadências de reuniões.

Definir a frequência

Para pensar na frequência ideal de cada comunicação, reflita sobre seu objetivo e tipo de Stakeholder.

O quão envolvido ele precisa estar no produto? Com qual frequência você terá atualizações importantes? A cada sprint? Mensalmente? Trimestralmente?

Pense no objetivo da comunicação:

Se o stakeholder precisa estar profundamente envolvido no andamento do produto, como um decisor, comunicações mais frequentes, como uma ou duas vezes por semana, podem ser necessárias para garantir alinhamento contínuo.

Os líderes técnicos são Stakeholders decisores e costumamos ter múltiplas reuniões com eles ao longo de uma Sprint para tomar decisões de execução e priorização.

Outros stakeholders decisores podem ser representantes da mesma área de negócio à qual pertence nosso patrocinador, que acompanham o produto de perto e ajudam com decisões do dia a dia que requerem sua expertise.

Já para stakeholders mais estratégicos, como patrocinadores, atualizações quinzenais ou mensais podem ser suficientes, focando em resultados e métricas de progresso.

Por último, stakeholders passivos podem ser comunicados apenas quando surgir necessidade: o alcance de uma meta importante ou avanço significativo no desenvolvimento de um produto ou funcionalidade.

Adaptar a linguagem

Quando falamos de linguagem, devemos considerar com quem estamos nos comunicando.

Cena extraída do filme Divertida Mente

É uma pessoa mais tática ou mais estratégica?

Pessoas com foco mais estratégico tendem a preferir comunicações diretas, embasadas em dados. Evite explicações longas e detalhadas de como chegou às suas conclusões. Foque na conclusão, decisão tomada e dados de embasamento. Anexe/linke materiais de leitura complementar e deixe que o próprio Stakeholder entre em contato se sentir necessidade de uma explicação mais detalhada.

Pessoas mais táticas valorizam o máximo de contexto possível, pois estão mais envolvidas na execução e implementação. Para elas, é importante entender não apenas o “o quê”, mas também o “como” e o “porque” das decisões. Nesses casos, ofereça uma comunicação mais detalhada, explicando o raciocínio por trás das suas conclusões, as alternativas consideradas e as implicações práticas. Esse nível de transparência ajuda a garantir que as pessoas táticas possam executar suas tarefas de maneira mais alinhada e eficaz. Além disso, incentive a troca de perguntas e feedbacks para ajustar os detalhes de forma colaborativa.

Definir o canal

Hoje em dia, principalmente com a popularização do trabalho remoto, os canais de comunicação de uma empresa podem ser dos mais diversos. Somente fazendo referência ao Slack, podemos listar: canais abertos, canais fechados, mensagens diretas, mensagens em grupo e até mesmo bots. Além disso, temos o ainda muito utilizado e-mail e até mesmo blogs corporativos.

Para quem é sua comunicação? É apenas um aviso ou é um convite à colaboração? É um report enviado periodicamente ou uma comunicação espontânea? Possui alguma informação confidencial? Precisa que todos confirmem recebimento?

Essas são perguntas fundamentais para a escolha do canal adequado para cada comunicação. Fique atento também a aspectos como cultura organizacional para escolher o melhor canal.

Adaptar o formato

Além de canais, precisamos considerar os possíveis formatos de comunicação: texto corrido, texto em tópicos. Texto com imagens. Vídeos explicativos, reunião… por aí vai.

A escolha do formato depende do objetivo da comunicação:

Texto corrido é útil para explicações detalhadas
Texto em tópicos ajuda a organizar informações de forma concisa e facilita a leitura rápida.
Incluir imagens, gráficos ou infográficos pode tornar dados complexos mais acessíveis.
Vídeos explicativos são uma boa opção quando é necessário demonstrar algo visualmente ou quando o conteúdo pode ser melhor compreendido com exemplos práticos.
Reuniões, por outro lado, são recomendadas para discussões interativas ou quando é necessário um alinhamento em tempo real.

Parte da escolha do formato e do canal requer o entendimento de se uma comunicação deve ser síncrona ou assíncrona.

Comunicação síncrona (reuniões ao vivo):

Principalmente quando lidando com pessoas muito ocupadas, precisamos pensar algumas vezes antes de marcar uma reunião. Para utilizar e respeitar o melhor o tempo de todos, marque reunião apenas quando há necessidade de interações em tempo real, troca de ideias imediata ou decisões rápidas. Tenha certeza de que todos presentes entendem o objetivo da reunião e estão preparados para contribuir.

Seguem alguns exemplos de quando utilizar comunicação síncrona:

Reuniões de planejamento ou alinhamento: definição de prioridades e expectativas. Nesse caso, chegue com o material pronto e use o tempo para debater os diferentes caminhos e seus prós e contras.
Reuniões de decisão importante: quando for crucial ter todos os principais stakeholders presentes para discutir e decidir questões estratégicas.
Sessões de brainstorming: colaboração em tempo real.
Reuniões de feedback: precisam de alinhamento imediato e olho no olho.

Comunicação assíncrona (e-mails, Slack, documentos compartilhados):

A comunicação assíncrona é ideal para quaisquer comunicações que não exigem resposta imediata e informações que podem ser processadas de forma independente. Inclusive podem ser interativas, como o caso de documentos compartilhados ou threads no Slack.

Seguem abaixo alguns exemplos de quando utilizar comunicação assíncrona:

Atualizações de status: relatórios de progresso, métricas ou resultados que podem ser revisados a qualquer momento.
Discussão de tópicos não urgentes: debates ou decisões que não precisam de uma resposta imediata e podem ser feitas ao longo do tempo (documentos compartilhados, threads no Slack).
Documentação e materiais de referência: documentos técnicos, roadmaps, relatórios e FAQs que os stakeholders podem acessar conforme necessário.

Lembre-se de que as comunicações assíncronas, quando bem feitas, não somente são mais produtivas e assertivas, como evitam reuniões desnecessárias. Use e abuse da comunicação assíncrona!

Cena extraída do filme Divertida Mente

E aí? Está fazendo sentido? Espero que sim! Esse é um bom momento para refletir sobre como você pode melhorar já a partir de amanhã sua comunicação com Stakeholders!

Por fim, gostaria de deixar algumas dicas finais e recomendações de leitura! Fica também o convite para conversarmos e trocarmos ideias sobre o assunto… Pode ser de forma síncrona, assíncrona… O que fizer mais sentido conforme o objetivo da comunicação.

Dicas finais

Escreva por extenso suas ideias, pensamentos e conclusões, antes de solidificar suas opiniões. Slides, planilhas, templates do Miro… todos ajudam a comunicar uma ideia, mas, para preencher as lacunas e garantir a coerência, teste sentar e escrever sobre o problema, o tamanho da oportunidade e as possíveis alternativas. Esse exercício não somente permitirá um conhecimento mais profundo e te ajudará na comunicação com Stakeholders, como pode se tornar um material colaborativo com decisor, contribuintes e até mesmo com o patrocinador.
Na comunicação com Stakeholders, é melhor pecar pelo excesso. É claro que sobrecarregar os canais do Slack ou caixas de e-mails pode fazer com que você seja visto como “irritante”. No entanto, é muito pior deixar o stakeholder na posição de ter que te cobrar por atualizações e decisões, ou, ainda pior, ser pego de surpresa por uma mudança no projeto que aconteceu há meses sem que ele fosse informado. Se for para correr algum risco, prefira o de receber feedback pedindo para reduzir a comunicação. Esse tipo de feedback é muito mais fácil de gerenciar do que deixar seu stakeholder desinformado.
Um elogio de um stakeholder vale MUITO mais do que um elogio do seu chefe. Gerenciar stakeholders é uma oportunidade incrível de ter visibilidade em diferentes setores da empresa (muitas vezes com figuras de lideranças), então se esforce para se mostrar prestativo, interessado e causar boas impressões. Seu chefe tem todos os motivos para te valorizar e te elogiar. Na hora de defender uma promoção, todos vão esperar elogios e defesas vindas do seu chefe. Quando vierem também de Stakeholders, é aí que você se destaca!
Crie empatia e sinta-se parte do time do seu Stakeholder patrocinador. Muitos product managers cometem o grande erro de entrar em quase uma rixa com o Stakeholder, sentindo que o time de produto precisa “vencer” nos debates e decisões. Infelizmente, tenho vergonha de admitir que já estive nessa posição, mas um alívio ter aprendido com essa experiência e visto como faz muito mais sentido entender seu Stakeholder profundamente e trabalhar como se fossem do mesmo time (porque vocês são!).

Obrigada a você que leu até aqui! Espero que tenha gostado! 🥳

Material de leitura

O conteúdo desse artigo é um misto de estudos, experiências pessoais e trocas com colegas de trabalho e amigas da comunidade Mulheres de Produto. Deixo abaixo algumas recomendações de leitura para os que desejam se aprofundar no tema. :)

Artigos

10 Books to improve your Stakeholder Management game as a Product Manager — Chetana Didugo
Stakeholder Management — Marty Cagan
Pledge To Stakeholders — Marty Cagan
Matriz de Stakeholders e como utilizar — Silvio Costa

Livros

Transformed — Marty Cagan

(Quase) tudo o que você precisa saber para gerenciar stakeholders was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Striking the Right Tone: Assertiveness vs. Rudeness in Product Management

Jessica Esquenazi Hollander — Thu, 11 Jul 2024 05:06:34 GMT

How to navigate stakeholders and teams communication with clarity, confidence, and respect.

Assertiveness is a really valuable skill to cultivate for any career development, and truly vital if you are a Product Manager, dealing with multiple Stakeholders and leading a cross-functional team (usually leading by influence).

The catch here is that there is a fine line between an assertive speech, and rudeness. Maybe you are here reading this, because you recently found out that this line may not be that obvious for you. You might already be naturally assertive but find yourself perceived as rude or maybe you’re more introverted, and may struggle with speaking up confidently, scared you’ll come across as rude in the process. Either way, stick around as my experience can really help you develop an assertive, but also respectful communication that will impress your leaders and coworkers.

Importance of being assertive

But why is being assertive so important? Why not simply hold back, let others speak and avoid all together the chances of being considered rude?

People who are assertive are heard. As just another employee in a medium to big company, being assertive might be that extra touch for you to be seen as a candidate for a promotion, as someone who is ready to take on more responsability and whose way of thinking and communicating are invaluable to the company. If you always hold back and let your leader speak, coming from the assumption that they are simply more senior and more prepared, how will they see that you are also capable of handling these scenarios? Maybe when they see that, they will notice they can miss that call next week, because they trust that you got it. This is the path to a promotion being forged.

As a Product Manager, some might argue that being assertive is not just an extra touch, but it is fundamental, and the lack of assertiveness could get you in trouble. A Product Manager who is assertive is perceived as confident and knowledgeable on their field of domain, which is an important image to maintain in order to be respected and heard by multiple stakeholder.

You might have heard often times throughout your career in Product about the importance of learning to say no, and how great product comes for saying no to most things, and yes to the right things. In order to constantly deny ideas to maintain an outcomes driven roadmap, being assertive, confident, and respectful is key.

Now that we are on the same page on how fundamental it is to master the art of being assertive without seeming rude, let's dive into how to distinguish these two behaviors.

Identifying rude vs. assertive behaviors

Fortunately for you, and arguably for me as well, given that I’ve overcome this challenge, I’ve mastered the skill of assertiveness without rudeness and can share insights from a firsthand perspective.

First of all: I have always been one to position myself, the problem was…Sometimes I would focus so much on going straight to the point that my communication could be perceived as honestly a bit rude. At least that is the feedback I once received and worked hard to overcome. It was a really hard feedback to take in, and truthfully, a bit difficult to absorbe as most people usually acknowledge my great communication rather than point out rudeness. I have always been very good at creating meaningful connections not only at work, but in life in general, and I am overall a very sweet and kind person, as I am told. Not only that, but also I have the tendency to avoid conflict and I am a big fan of non-violent communication principles. With this contextualization, you can imagine I was a bit shocked to receive this feedback.

I will share how I learned to identify this behavior and eventually solved it to the point where I was being complimented on my great communication, and as an advocate of non-violent communication.

The first thing to point out is, if you are in a similar situation to the one I was about a year ago, where you received such feedback, it is crucial that you receive this feedback, as difficult as it may be, with an open mind and an open heart. Make sure you thank the person who gave you this hint, as it is not an easy feedback to share, and it probably took them a lot of courage and care for you to go through the trouble of helping you improve this key aspect of your professional development.

Ask them if they can share some examples of moments you might have been rude and if they would be willing to call you out discritely, via slack or the written medium of communication of your company's choice.

Of course depending on a friend or coworker to ping you everytime you are rude is not the most effective way of identifying this behavior. There is a need to better observe yourself, and you can do this differently in distinct scenarios:

In a meeting:

Pay attention to people's reaction when you speak. If you are being rude, you will notice a disconect on your coworkers faces or even voices. When you notice that disconnect, take a note. Do this process for a week, and notices how many times you observed this disconnect and feeling of causing disconfort. Reflect on not only the content of your communication, but your tone and the context.

In a written conversation:

The most amazing thing about written communication, is that you will not be held accountable until you send it, and different from a live meeting, you actually have the time to think before you speak (or in this case write). If you are already assertive, you probably type and hit enter, as you want to be quick and resolve the problem, but maybe in these cases you are being rude without noticing, and that could be avoided. Try to create the habit of reviewing your messages before sending, and even giving it a thought on rather it sounds rude or not. If you are heated by a stressful subject, with the technology available now a days, you could even copy and paste your already typed answer to chat-GPT, and ask if you sound rude.

Here is an example of a very small thing that I noticed I could improve, that came from being assertive, and from a good place, but was making me sound rude: I would often skip a proper ‘hello/ how are you’ on slack before asking for something, or even answering another persons request. I remember one conversation that hit me very hard when I read it a few weeks later:

Senior Director: Hey Jess! How are you doing my data buddie? 
I have been working on an important analysis and need the link to that XYZ report.
Do you have it by any chance?

Product Manager(me): https://docs.google.com/spreadsheets/d/report-hash-here-3948rh9f8/edit?gid=0#gid=0

I was motivated by being direct to the point and quickly providing the director with the information she needed. Indeed I was very successful and quickly sharing the needed report, but I forgot to say hi, and to have an actual human communication with them.

In parallel to practicing self-observation, here are some examples to better streamline the difference between being assertive and being rude via the following aspects:

Intent:

Was your communication fully focused on expressing yourself cleary, and being heard, or did it carry with it any feeling of frustration that brought an intention to provoke or 'put someone in their place'?

Assertive: “I understand your viewpoint, but I need to express my concerns about this project.”
Rude: "This is a bad idea. This project will never work like this."

Tone:

Being assertive doesn't require an agressive, sarcastic or overall disrespectful tone. It is possible to be firm on your communication without making the other person feel attacked. Are you raising your voice? This is the first and easiest evaluator of an agressive/rude tone.

Assertive: “I feel frustrated when meetings start late because it impacts our productivity.”
Rude: “You’re always late! You really need to be on time.”

Empathy:

As you are assertive, there is space to aknowledge where the other person might be coming form, validate their feelings and/or opinions, and still share a different perspective. Rudeness happens when you speak with disregards for the other persons feelings or perspective.

Assertive: “I see where you are coming from. Let's discuss this at another moment and proceed with the meeting agenda."
Rude: "Let's move on and not talk about this now."

Timing

This is a great place to fit that famous saying of "praise in public, critize in private". If you understand the context, and choose wisely the timing of your communication you can easily avoid having your intentions be mistaken with rudeness.

Assertive: "Could we review these numbers and regather this group for more insights?"
Rude: "These numbers are wrong. Where are the correct ones?"

Outcome

An assertive communicator has a noble intention. The outcome is usually resolving a conflict, clarifying a misunderstanding or setting boundaries in a positive and constructive manner, still maintaing a good relationship. The outcome of a rude communicator is usually steaming up a conflict, pointing a finger and attacking the person at the other side of the communication.

Assertive: "To make sure we are all aligned, could we confirm the problem we are trying to solve? I have the feeling we might be solving different problems"
Rude: "What is the problem you are trying to solve? This is not the right solution."

Practicing a respectful and assertive communication

Once you have clearly mapped and identified the moments in which your communication needs improvement, its time to take action. Here are some things to practice!

Principles of an assertive communication:

Listen, listen, listen, and did I mention… Listen?
Explain the reasoning of your intervention/positioning
Focus on solving the problem, not on pointing finger
Be clear
Own your statements
Be direct, with respect
Pay attention to your body language

This is a self-paced process of observing and practicing the principles above. It might be hard at first not only to accept this feedback, but to start noticing the scenarios where you can start to improve your communication. For a more in depth study on non-violent communication I recommend Dr. Rosenberg's book: Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships.

Being assertive is key for your professional growth, and so is being recognized as a kind and respectful team member. Master this balance and you will be on the path to amazing things!

I wish you luck on your journey and would love to hear in the comments section about the first step you will take to walk the fine line between being assertive and being rude.

Feel free to connect with me at https://www.linkedin.com/in/jesshollander/.

Striking the Right Tone: Assertiveness vs. Rudeness in Product Management was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Desbloqueie a escritora dentro de você!

Jessica Esquenazi Hollander — Thu, 20 Jun 2024 00:10:07 GMT

Essa é para você que quer escrever, mas não consegue começar…

Primeiramente parabéns por ter chegado até aqui e estar disposta e motivada (ou tentando ficar motivada) a escrever seu primeiro artigo! Não é fácil tomar a decisão de se expor e expor suas ideias e pensamentos, no entanto, é uma ótima forma de se desenvolver, então aproveite esta oportunidade e vem com a gente!

Sei bem como a correria do dia-a-dia muitas vezes rouba de nós aquele tempinho valioso para focar e escrever. Sei também como olhar para a tela branca acaba esvaziando nossa mente, e como a síndrome do impostor vem com força bem quando finalmente paramos e decidimos começar:

Será que vão gostar do meu artigo? E se eu falar besteira? E se ninguém ler?

Hoje vou te ajudar a vencer cada uma das objeções acima!

https://medium.com/media/0153d6c397522ad47e69c29f2fed370f/href

Não tenho tempo para escrever!

Quando estamos mergulhadas em nossa rotina, fica difícil realmente enxergar um momento para escrever, mas tempo é questão de planejamento e priorização.

Se escrever é importante para você, olhe para as suas outras atividades e encontre uma que possa ser deixada de lado, pelo menos temporariamente, para abrir espaço para a escrita. Comece reparando quanto tempo você passa no celular, se distraindo com mensagens, ou redes sociais. Será que poderia utilizar esse tempo para escrever um artigo?

Reflita também sobre quanto tempo você poderia dedicar por dia, e encaixe a escrita em pequenos intervalos:

Separe um primeiro momento somente para definir o tema e a abordagem, por exemplo:

Vou abordar a árvore de oportunidades de Teresa Torres, explorando os erros mais comuns cometidos por iniciantes ao aplicar este framework.

2. Separe um segundo momento para montar a estrutura do seu artigo, dividindo as partes. Se seguirmos com o exemplo acima, as partes seriam introdução, cada um dos erros (erro, descrição, como identificá-lo e evitá-lo/corrigí-lo), conclusão, referências.

3. Para cada parte, separar um momento para estudar o assunto e resumir em tópicos os itens a abordar na parte. Sugiro deixar a introdução e a conclusão para o final.

4. Separar mais um momento para cada parte, para transformar os tópicos em texto corrido.

5. Separe um último momento para revisar. Uma sugestão é se utilizar das ferramentas que tiver disponíveis em seu alcance, como o Grammarly ou o chat-GPT para receber sugestões de melhoria. Cuidado para não perder na revisão a sua voz e forma única de se expressar!

Não sei sobre o que escrever

Aqui vão algumas dicas de como escolher um tema para escrever seguidos de exemplos reais de artigos publicados por mulheres da comunidade!

Fale sobre sua transição de carreira: "Transição de CX para área de produtos, qual caminho eu percorri?" Hellen Damasceno, "Minha transição de carreira: como se tornar uma product manager?" Aline Medeiros Gorga
Escolha um tema que você já tem vontade de estudar e faça um resumo: "Como fazer uma jornada de usuário" Danielle Malty.
Compartilhe uma experiência pessoal: "A Squad dos sonhos: Lições de um Time que Deu Certo" Ana Forato, "Programa de embaixadoras: desafios e aprendizados" Talita Morais
Faça um resumo e/ou uma crítica de um conteúdo já disponível. Pode ser um livro, um vídeo, ou até mesmo outro artigo do Medium: "Um resumão do livro ‘Continuous Discovery Habits’ da Teresa Torres" Emilia Siqueira
Compartilhe sua opinião sobre uma notícia/novidade no mundo de produto: "O Chat GPT vai acabar com Product Managers?" Jessica Esquenazi Hollander

https://medium.com/media/e7d43a8cf676e0777c07dc026abe663c/href

Está se sentindo um pintor olhando para um quadro branco? Sem problemas! Aqui está um exercício para fluir sua criatividade. Lembre-se! Primeiro quantidade, depois qualidade!

Pegue uma folha de papel em branco
Dobre na metade duas vezes, de forma que a folha seja separada em quatro quadrantes
Coloque uma música agiatada para tocar
Primeiro quadrante: por dois minutos, liste o máximo de temas da área de produto possíveis — foque em quantidade!
Segundo quadrante: por três minutos pense em diferentes abordagens que você poderia utilizar para falar de cada um dos temas circulados— foque em quantidade!
Terceiro quadrante: use cinco minutos para quebrar e especificar mais ainda os itens circulados no primeiro quadrante — pode puxar uma ou mais setas de cada item circulado — foque em qualidade!
Quarto quadrante: use cinco minutos para conectar os itens do terceiro quadrante com as abordagens do segundo quadrante. Você vai sair com mini "rascunhos de títulos" para artigos. Escolha o que te der mais vontade de explorar! — foque em qualidade!

Tenho medo do meu conteúdo ser ruim

Se você chegou até aqui, é porque você quer MUITO escrever, então deixa o medo de lado, escreve seu artigo, e se estiver MUITO insegura, lembre que nós mulheres voluntárias da comunidade vamos revisar seu artigo e a gente promete que não vamos deixar você passar vergonha. Vem com a gente!

Desbloqueie a escritora dentro de você! was originally published in Mulheres de Produto on Medium, where people are continuing the conversation by highlighting and responding to this story.

O Chat GPT vai acabar com Product Managers?

Jessica Esquenazi Hollander — Thu, 30 Mar 2023 23:21:48 GMT

Pedi ao Chat GPT para fazer meu trabalho e esse foi o resultado…

Fonte da imagem: Mundo conectado

Não consegui escapar da modinha do Chat GPT e me encontrei “brincando” com a ferramenta diversas vezes durante o meu trabalho. Descobri que a ferramenta é realmente muito poderosa e com certeza pode fazer com sucesso boa parte das tarefas de um Product Owner e até de um Product Manager.

Ler essa conclusão pode ser um tanto assustador… Mas fique tranquila, o Chat GPT tem muitas limitações e nossos empregos não correm risco…ainda?

Aqui vai um resumo das atividades que pedi ajuda para o chat GPT e uma análise do resultado… Mas antes disso, gostaria de levantar algumas ressalvas importantes:

Cuidado com informações confidenciais e estratégicas. Todos os dados de clientes, parceiros ou fornecedores da sua empresa precisam estar protegidos. Ingetá-los no chatGPT ou outras ferramentas abertas de inteligência artificial provavelmente viola as regras de segurança da informação e podendo resultar em consequências graves para os funcionários.
Lembre-se de que a Open AI aprende com o conteúdo disponibilizado majoritariamente na internet, portanto confiar 100% em suas conclusões não é algo sábio a se fazer. Use o Chat GPT como um acelerador e não um substituidor do seu trabalho.

Pesquisa de Mercado e Posicionamento de Produto

Pedi para o Chat GPT me ajudar a entender melhor o mercado da minha empresa, quais os principais concorrentes e como estamos posicionados. Para não expor meu trabalho, vou replicar a pergunta neste artigo usando o próprio Medium como exemplo:

Pergunta: Como o Medium.com se compara a outras empresas que seguem o mesmo modelo de negócios?

Resposta do Chat GPT:

O Medium.com é uma plataforma de publicação online que permite que os usuários publiquem conteúdo e se conectem com outros usuários com interesses semelhantes. Embora existam outras empresas que oferecem serviços semelhantes, o Medium se destaca por sua interface simples e elegante, pela qualidade do conteúdo publicado e pela comunidade ativa de escritores e leitores.

Entre as empresas que seguem um modelo de negócio semelhante ao do Medium, podemos citar o LinkedIn Pulse, o Quora, o Tumblr e o WordPress.com. Cada uma dessas plataformas tem suas próprias características distintas e públicos-alvo.

O LinkedIn Pulse, por exemplo, é uma plataforma de publicação profissional, com foco em conteúdo relacionado a negócios e carreira. Já o Quora é um site de perguntas e respostas que permite aos usuários compartilhar conhecimento e experiência. O Tumblr é uma plataforma de microblogging que permite a publicação de diversos tipos de conteúdo, incluindo imagens, vídeos e GIFs. O WordPress.com é uma plataforma de blogs que permite aos usuários criar e publicar seu próprio conteúdo.

Em termos de popularidade e alcance, o Medium é uma das principais plataformas de publicação online, com milhões de usuários em todo o mundo. No entanto, cada uma dessas empresas tem sua própria base de usuários leais e oferece uma experiência única para seus usuários.

Análise SWOT

Pedi ao Chat GPT para fazer uma análise SWOT da minha empresa. Isso me ajuda a entender como posso alinhar meu Roadmap e propostas de novos produtos com a estratégia da empresa. Novamente segue a mesma pergunta, mas sobre o Medium:

Pergunta: Poderia fazer uma análise swot do Medium?

Resposta:

Certamente! Aqui está uma análise SWOT (Forças, Fraquezas, Oportunidades e Ameaças) do Medium:

Forças:

Qualidade do conteúdo: o Medium é conhecido por seu conteúdo de alta qualidade, escrito por escritores profissionais e amadores que são apaixonados por seus assuntos. Isso ajuda a atrair leitores interessados e aumenta a visibilidade da plataforma.

Interface simples: a interface do Medium é limpa e intuitiva, tornando-a fácil de usar para escritores e leitores.

Comunidade ativa: o Medium tem uma comunidade ativa de escritores e leitores, que se engajam em discussões, compartilham seus escritos e interagem uns com os outros.

Personalização: a plataforma permite que os usuários personalizem sua experiência de leitura, escolhendo os tópicos e autores que desejam seguir.

Fraquezas:

Monetização: o Medium ainda não encontrou uma maneira eficaz de monetizar sua plataforma, o que pode levar a problemas financeiros a longo prazo.

Competição: existem outras plataformas de publicação online que oferecem serviços semelhantes, o que pode reduzir a participação de mercado do Medium.

Necessidade de conta: para interagir plenamente com a plataforma, os usuários precisam criar uma conta, o que pode ser uma barreira para novos leitores e escritores.

Oportunidades:

Parcerias: o Medium pode formar parcerias com outras empresas e organizações para aumentar sua visibilidade e alcance.

Conteúdo exclusivo: o Medium pode oferecer conteúdo exclusivo para seus usuários, como entrevistas com escritores e acesso a eventos de escrita.

Expansão internacional: o Medium pode expandir sua presença em países onde a plataforma ainda não é muito conhecida.

Ameaças:

Regulamentações: as regulamentações governamentais podem afetar a capacidade do Medium de operar em certos países ou de oferecer certos serviços.

Desinteresse em leitura: a crescente preferência por conteúdo de vídeo e áudio pode reduzir o interesse em plataformas de leitura como o Medium.

Mudanças no algoritmo de pesquisa: o algoritmo do Google pode mudar, o que pode afetar a visibilidade do Medium nos resultados de pesquisa.

Em resumo, o Medium tem uma forte base de usuários leais e uma reputação de oferecer conteúdo de alta qualidade. No entanto, a falta de um modelo de negócios sustentável e a concorrência podem ser desafios significativos para a empresa. Se o Medium conseguir encontrar uma maneira de monetizar sua plataforma e continuar a inovar para atender às necessidades dos usuários, poderá manter e até expandir sua posição de liderança no mercado de publicação online.

Pedi também uma análise SWOT da concorrência e esse foi o resultado…

E não, não foi erro meu, o Chat GPT realmente parou de digitar no meio da resposta:

Pergunta: Agora pode fazer o mesmo para os concorrentes que listou acima?

Resposta:

Claro, aqui está uma análise SWOT para alguns dos concorrentes do Medium que foram mencionados anteriormente:

LinkedIn Pulse:

Forças:

Público alvo profissional: o LinkedIn Pulse se concentra em conteúdo profissional, atraindo usuários que buscam informações e notícias relacionadas a negócios e carreiras.

Maior alcance: o LinkedIn Pulse é acessível para todos os usuários do LinkedIn, o que significa que ele tem um público mais amplo do que o Medium.

Forte presença de marca: o LinkedIn é uma marca estabelecida, o que dá credibilidade ao LinkedIn Pulse.

Fraquezas:

Interface desatualizada: o design e a interface do LinkedIn Pulse são considerados desatualizados em comparação com plataformas mais modernas, como o Medium.

Foco estreito: o foco do LinkedIn Pulse em conteúdo profissional pode limitar seu apelo a outros públicos.

Oportunidades:

Aproveitar a base de usuários existente: o LinkedIn Pulse pode atrair mais usuários para a plataforma, aproveitando a base de usuários existente do LinkedIn.

Personalização de conteúdo: o LinkedIn Pulse pode permitir que os usuários personalizem sua experiência de leitura com base em seus interesses e preferências.

Ameaças:

Concorrência: o LinkedIn Pulse enfrenta concorrência de outras plataformas de publicação profissional, como o Quora e o Medium.

Regulamentações: as regulamentações governamentais podem afetar a capacidade do LinkedIn Pulse de operar em certos países ou de oferecer certos serviços.

Quora:

Forças:

Foco em perguntas e respostas: o Quora é conhecido por ser um local para obter respostas para perguntas específicas, o que pode atrair usuários que estão procurando informações específicas.

Comunidade ativa: o Quora tem uma comunidade ativa de usuários que estão dispostos a compartilhar seus conhecimentos e experiências.

Tópicos diversificados: o Quora oferece uma ampla gama de tópicos para os usuários explorarem e discutirem.

Fraquezas:

Qualidade do conteúdo: o Quora é conhecido por ter um grande volume de conteúdo, mas a qualidade pode variar.

Interface confusa: a interface do Quora pode ser confusa e difícil de usar para usuários novos na plataforma.

Limitações de monetização: o Quora ainda não encontrou uma maneira eficaz de monetizar sua plataforma.

Oportunidades:

Personalização de conteúdo: o Quora pode permitir que os usuários personalizem sua experiência de leitura com base em seus interesses e preferências.

Parcerias com empresas: o Quora pode formar parcerias com empresas para aumentar a visibilidade e expandir seu alcance.

Ameaças:

Concorrência: o Quora enfrenta concorrência de outras plataformas de perguntas e respostas, como o Yahoo Respostas e o Stack Overflow.

Regulamentações: as regulamentações governamentais podem afetar a capacidade do Quora de operar em certos países ou de oferecer certos serviços.

Tumblr:

Forças:

Diversidade de conteúdo: o Tumblr permite a publicação de diversos tipos de conteúdo, incluindo imagens, vídeos e GIFs.

Comunidade

Roadmaps de melhoria e de inovação

Esse aqui seria o mais controverso…? Pedir ao Chat GPT para montar seu roadmap… Aqui está o resultado:

Pergunta: Com base na análise que fizemos até o momento, poderia preparar um roadmap de melhorias para o site do Medium?

Resposta:

Sim, com base na análise SWOT do Medium, aqui está um roadmap de melhorias que poderiam ser implementadas no site:

Fortalecer a marca:

Investir em campanhas de marketing para aumentar a visibilidade da marca Medium.

Trabalhar em uma identidade visual mais forte e coesa.

Aprimorar a experiência do usuário:

Melhorar a navegação do site, tornando-a mais intuitiva e fácil de usar.

Oferecer mais opções de personalização de conteúdo para os usuários.

Desenvolver aplicativos para dispositivos móveis que ofereçam uma experiência de usuário aprimorada.

Aumentar a qualidade do conteúdo:

Implementar um sistema de revisão de conteúdo para garantir que apenas conteúdo de alta qualidade seja publicado na plataforma.

Aumentar a diversidade do conteúdo publicado para atrair uma audiência mais ampla.

Expansão da plataforma:

Expandir a plataforma para atrair um público global, incluindo oferecer suporte para múltiplos idiomas.

Explorar a possibilidade de parcerias com empresas e outros provedores de conteúdo para expandir o alcance da plataforma.

Monetização:

Explorar maneiras de monetizar o conteúdo do Medium, oferecendo aos escritores mais incentivos para publicar na plataforma.

Oferecer opções de publicidade mais sofisticadas para anunciantes.

Integração com redes sociais:

Integrar mais recursos de compartilhamento de conteúdo com as principais redes sociais, como Facebook, Twitter e LinkedIn, para aumentar a exposição do Medium.

Ao implementar essas melhorias, o Medium pode fortalecer sua posição no mercado e aumentar sua base de usuários, melhorando a experiência do usuário e oferecendo conteúdo de alta qualidade.

Pergunta: Poderia preparar agora um roadmap de inovação, focando em novas funcionalidades

Resposta:

Claro, aqui está um roadmap de inovação com foco em novas funcionalidades que o Medium poderia considerar:

Introduzir novas formas de interação entre escritores e leitores:

Criar fóruns de discussão ou espaços de comentários mais interativos que permitem que os usuários discutam ideias de forma mais colaborativa.

Desenvolver um sistema de mensagens privadas para permitir que os usuários se comuniquem diretamente uns com os outros.

Investir em tecnologia de IA:

Introduzir um sistema de recomendação de conteúdo mais sofisticado baseado em aprendizado de máquina e análise de dados.

Desenvolver uma ferramenta de edição assistida por IA para ajudar os escritores a aprimorar seus textos.

Ampliar as formas de conteúdo:

Expandir a plataforma para incluir outros tipos de conteúdo, como vídeos e podcasts.

Adicionar uma função de leitura offline, permitindo que os usuários leiam o conteúdo do Medium sem conexão à internet.

Criar mais oportunidades para escritores monetizarem seu trabalho:

Adicionar um sistema de assinaturas ou um programa de afiliados para incentivar os escritores a publicarem na plataforma.

Oferecer a possibilidade de pagamento direto aos escritores pelos seus conteúdos.

Melhorar a experiência do usuário em dispositivos móveis:

Desenvolver um aplicativo móvel com recursos adicionais, como notificações personalizadas e opções de leitura offline.

Otimizar o site para dispositivos móveis, oferecendo uma experiência mais amigável para smartphones e tablets.

Implementar recursos de aprendizado:

Oferecer cursos online gratuitos sobre escrita e outras habilidades relacionadas à produção de conteúdo.

Fornecer análises de desempenho para escritores, permitindo que eles possam ver o engajamento dos leitores em seus conteúdos.

Ao implementar essas novas funcionalidades, o Medium poderá inovar em relação a outras plataformas de conteúdo, fornecendo novas formas de interação e monetização, além de melhorar a experiência do usuário com novos recursos e tecnologias.

Priorização de backlog

Será que até priorizar nosso backlog o Chat GPT sabe fazer? Eu fiquei surpresa com o resultado! Não esperava que ele fosse criar uma tabela e tudo!

Pergunta: Poderia definir uma ordem de prioridade para as funcionalidades acima usando uma matriz de esforço e impacto?

Resposta:

Sim, para definir a ordem de prioridade das funcionalidades acima, podemos usar uma matriz de esforço e impacto. Essa matriz classifica as iniciativas com base no esforço necessário para implementá-las e no impacto que elas teriam no negócio. Quanto maior o impacto e menor o esforço necessário, maior será a prioridade.

Aqui está uma matriz de esforço e impacto com base nas funcionalidades propostas anteriormente:

Tabela, pois não consegui formatá-la aqui no Medium

Com base na matriz acima, podemos observar que as funcionalidades com maior prioridade seriam aquelas que têm um alto impacto e um esforço relativamente baixo. Isso significa que a prioridade seria para as funcionalidades “Investir em tecnologia de IA” e “Ampliar as formas de conteúdo”, pois ambas têm um alto impacto e um esforço baixo. A funcionalidade “Introduzir novas formas de interação entre escritores e leitores” tem um alto impacto, mas requer um esforço médio, tornando sua prioridade média. As demais funcionalidades, “Criar mais oportunidades para escritores monetizarem seu trabalho”, “Melhorar a experiência do usuário em dispositivos móveis” e “Implementar recursos de aprendizado”, têm um impacto médio a baixo e um esforço médio a alto, tornando sua prioridade baixa.

Detalhamento de Histórias de Usuário

Fiz 3 perguntas para me ajudarem a elaborar as histórias de usuário… A última foi a que mais me impressionou!

Pergunta: Poderia quebrar a funcionalidade com maior nivel de prioridade em histórias de usuário?

Resposta:

Claro! Vou quebrar a funcionalidade “Investir em tecnologia de IA” em histórias de usuário:

Como usuário, quero receber recomendações de conteúdo mais precisas e personalizadas com base nas minhas preferências e interesses.

Como escritor, quero ter acesso a uma ferramenta de edição assistida por IA que me ajude a melhorar a qualidade do meu texto e a aumentar o engajamento do leitor.

Como usuário, quero ver menos conteúdo irrelevante e mais conteúdo de alta qualidade na minha página inicial.

Como escritor, quero ter acesso a uma análise detalhada do desempenho do meu conteúdo para entender como posso melhorá-lo com a ajuda da tecnologia de IA.

Como usuário, quero receber notificações personalizadas quando novos conteúdos relevantes forem publicados com base nas minhas preferências e histórico de leitura.

Essas histórias de usuário podem ajudar a equipe de desenvolvimento do Medium a entender melhor as necessidades e expectativas dos usuários em relação à tecnologia de IA e a criar funcionalidades que atendam a essas necessidades.

Pergunta: Poderia listar os requerimentos para que a primeira história de usuário seja desenvolvida com sucesso?

Resposta:

Claro! Com base na primeira história de usuário que quebrou para a funcionalidade “Investir em tecnologia de IA”, aqui estão alguns requisitos que seriam necessários para o seu desenvolvimento bem-sucedido:

Identificar as preferências e interesses do usuário: é necessário que a plataforma tenha acesso aos dados de comportamento do usuário, como histórico de leitura, curtidas, comentários, entre outros, para entender suas preferências e interesses.

Utilizar algoritmos de aprendizado de máquina: é necessário utilizar algoritmos de aprendizado de máquina para analisar os dados de comportamento do usuário e gerar recomendações precisas e personalizadas de conteúdo.

Permitir que os usuários indiquem seus interesses: além da análise dos dados de comportamento, é importante permitir que os usuários indiquem seus interesses por meio de categorias, tags ou outros mecanismos de seleção de conteúdo.

Testar e ajustar o algoritmo: é importante testar o algoritmo de recomendação em um ambiente de produção para avaliar sua eficácia e ajustá-lo com base no feedback dos usuários.

Proteger a privacidade do usuário: ao coletar e analisar dados de comportamento do usuário, é importante garantir a privacidade e a segurança desses dados, seguindo as melhores práticas de privacidade de dados.

Pergunta: Obrigada! E poderia criar cenários de testes para essa funcionalidade?

Resposta:

Claro! Aqui estão alguns cenários de teste que poderiam ser usados para testar a primeira história de usuário “Como usuário, quero receber recomendações de conteúdo mais precisas e personalizadas com base nas minhas preferências e interesses”:

Cenário de teste: recomendação de artigos relevantes

Passo 1: O usuário acessa a página inicial do Medium.

Passo 2: O sistema coleta dados de comportamento do usuário, incluindo histórico de leitura e preferências de conteúdo.

Passo 3: O sistema utiliza algoritmos de aprendizado de máquina para gerar uma lista de recomendações de artigos relevantes.

Resultado esperado: O sistema apresenta uma lista de artigos que correspondem às preferências do usuário.

Cenário de teste: recomendação personalizada de autores

Passo 1: O usuário acessa a página de um autor que ele já segue.

Passo 2: O sistema coleta dados de comportamento do usuário, incluindo histórico de leitura e preferências de conteúdo.

Passo 3: O sistema utiliza algoritmos de aprendizado de máquina para gerar uma lista de recomendações personalizadas de autores relacionados ao autor que o usuário está visualizando.

Resultado esperado: O sistema apresenta uma lista de autores que correspondem às preferências do usuário.

Cenário de teste: recomendação com base em uma categoria específica

Passo 1: O usuário acessa a página inicial do Medium.

Passo 2: O sistema coleta dados de comportamento do usuário, incluindo histórico de leitura e preferências de conteúdo.

Passo 3: O usuário seleciona uma categoria específica de interesse, como “Negócios”.

Passo 4: O sistema utiliza algoritmos de aprendizado de máquina para gerar uma lista de recomendações de artigos relacionados à categoria selecionada.

Resultado esperado: O sistema apresenta uma lista de artigos que correspondem à categoria selecionada e às preferências do usuário.

Esses cenários de teste ajudariam a avaliar se a funcionalidade de recomendações personalizadas do Medium está funcionando corretamente e fornecendo ao usuário conteúdo relevante e de qualidade com base em suas preferências e interesses.

Conclusão

Bom, o trabalho de uma gerente de produtos é bem complexo, e fazemos tanta coisa, que poderia fazer um artigo com o triplo do tamanho… mas acredito que já deu para passar a ideia…

Pros:

Respostas muito completas e de qualidade, que superam a expectativa.
Abrangência de temas e conhecimento surpreendentes: consegue compreender tudo que é pedido, mesmo sendo de diversos temas diferentes.
Permite continuar uma conversa em um mesmo contexto: soube identificar itens mencionados em repsostas anteriores e se referir aos mesmos em uma nova resposta.
Pode confirmar ideias e ajudar a alimentar o cérebro com mais referências que aguçam nossa criatividade.

Contras:

O Chat GPT fala abertamente que sua base de conteúdo está mais a tualizada até 2021, e fatos ocorridos após esta data podem não ser considerados na resposta.
O Chat GPT tem um limite de “tokens” por pergunta, e em alguns casos para de digitar e interrompe o racicínio do meio da resposta, sem dar qualquer satisfação.
Dificilmente terá uma ideia totalmente original/única, pois trabalha com probabilidade e referências.
Não podemos garantir que sua resposta é veridadeira, ou correta e precisamos validar com outras fontes e também com nosso próprio conhecimento.

Observações Finais:

O Chat GPT com certeza pode te ajudar bastante a realizar pesquisas, ter ideias, priorizar seu roadmap e até mesmo escrever histórias de usuário! O potencial é muito grande quando pensamos na oportunidade de reduzir nossa carga de trabalho, aumentar nossa produtividade e até mesmo a qualidade de nossas entregas.

Um aprendizado que tive foi que o que faz uma grande diferença no uso do Chat GPT é fazer as perguntas certas — bem elaboradas e com contexto, e utilizar de uma mesma conversa, para que o Chat GPT tenha como utilizar das respostas anteriores como conhecimento/contexto adicional para completar sua pergunta.

O que fica como uma bandeira importante de se levantar é que o Chat GPT constrói suas respostas com base em inteligência artificial e uma base de conhecimentos e contexto que são diferentes do seu. Assim como tem coisas que o Chat GPT saberá responder muito bem, tem contextos internos na estratégia e operação de sua empresa o Chat GPT simplesmente não tem conhecimento.

Bônus 🎁

Pergunta: Com base em nossa conversa, poderia preparar uma conclusao sobre os pros e contras de usar o chat GPT para auxiliar no trabalho como gerente de produto?

Resposta:

Sim, com base em nossa conversa, aqui está uma conclusão sobre os prós e contras de usar o Chat GPT como auxiliar no trabalho de gerente de produto:

Prós:

O Chat GPT pode fornecer informações relevantes e detalhadas sobre uma variedade de tópicos relacionados à gerência de produto, como análise SWOT, roadmap de melhorias e inovação, entre outros.

O Chat GPT pode ajudar a identificar problemas e oportunidades de maneira rápida e eficiente.

O Chat GPT pode gerar ideias e soluções para desafios de gerenciamento de produto de maneira criativa e inovadora.

Contras:

O Chat GPT não tem capacidade de pensamento crítico e nem inteligência emocional, o que pode limitar sua capacidade de fornecer insights profundos e compreensão de nuances complexas relacionadas ao gerenciamento de produtos.

O Chat GPT pode fornecer informações imprecisas ou irrelevantes se a entrada de dados não for precisa ou se a análise de dados do modelo não for precisa.

O Chat GPT não substitui a experiência e a intuição do gerente de produto em tomar decisões estratégicas importantes.

Em resumo, o Chat GPT pode ser uma ferramenta útil para auxiliar no trabalho de gerenciamento de produtos, mas é importante lembrar que ele não deve ser visto como uma substituição para a experiência e intuição do gerente de produto. O Chat GPT pode ajudar a identificar problemas e oportunidades e gerar soluções criativas, mas é importante avaliar criticamente suas respostas e combiná-las com a análise e a intuição humana para tomar decisões informadas e bem-sucedidas.

E aí? Qual conclusão ficou melhor? 👀

Me conta nos comentários!

Experimentação

1 pauta de diversidade que ama de paixão

Vieses inconsciente

1 mulher que te inspira na sua carreira

Anitta

Dica de ouro para mulheres entrando agora em produto e tecnologia

Construa sua rede de apoio e peça ajuda

Diana Fournier (Ela/Dela)

https://www.linkedin.com/in/dianafournier/

Dica de ouro para mulheres entrando agora em produto e tecnologia

Criem seus produtos, criem suas oportunidades

Luciana Nunes (Ela/Dela)

https://www.linkedin.com/in/lcnunes09/

Neurodiversidade

1 mulher que te inspira na sua carreira

Mônica Magalhães

Dica de ouro para mulheres entrando agora em produto e tecnologia

Seja curiosa, não foque apenas em uma área, lembre-se que um bom produto é feito do equilíbrio entre negócios, tecnologia e experiência do usuário.

E aí, você conhece uma das nossas autoras? Comente aqui!
Todas elas fazem parte da nossa comunidade que contribue para maior representatividade de mulheres na tecnologia. Se você quer fazer parte da ONG Mulheres de Produto, inscreva-se na nossa newsletter!

Conheça mais ações da ONG Mulheres de Produto

Quem são as mulheres por trás do livro ‘Gestão de Produtos como você nunca viu’? was originally published in Mulheres de Produto on Medium, where people are continuing the conversation by highlighting and responding to this story.

Como o refinamento de backlog pode salvar sua squad

Jessica Esquenazi Hollander — Wed, 20 Jul 2022 10:01:25 GMT

Como o refinamento de backlog DEEP pode salvar sua squad

Aprenda a construir um backlog DEEP e a conduzir refinamentos produtivos para manter a felicidade e agilidade do time.

Time refinando o backlog em conjunto

Vamos começar com uma reflexão. As perguntas abaixo vão te ajudar a entender se o seu time está ou não sofrendo dos problemas estruturais de um backlog mal refinado:

Vocês estão conseguindo terminar as histórias dentro de uma sprint, ou as histórias passam frequentemente de uma sprint para a outra?
As tarefas são bem distribuídas entre os integrantes do time, ou alguns estão sobrecarregados, enquanto outros com pouca demanda?
Quando começa a sprint, todos conseguem colocar a mão na massa, ou alguns precisam dedicar tempo inicial para tirar dúvidas sobre as regras de negócio e ainda definir qual será a melhor forma de implementar a história?
Quanto tempo duram suas plannings? Sente que são intermináveis e que você, como Product Owner ou Product Manager, é uma figura indispensável para esse encontro?

O que você observou ao responder às perguntas acima? Se suas respostas te preocuparam, provavelmente você precisa melhorar seu trabalho ao refinar o backlog e conduzir as cerimônias de refinamento.

Um backlog mal refinado causa uma série de problemas para o time. Você, como responsável pelo backlog, precisa criar uma certa distância entre as funcionalidades e histórias de usuário que ainda estão sendo definidas, e as que estão prontas para entrar para a próxima sprint. Quando os problemas ressaltados pelas perguntas acima acontecem, é normalmente porque o backlog está ou muito curto, ou seja, a Product Manager está sempre se apressando para definir tudo a tempo da próxima sprint, ou as histórias já estão definidas, porém não foram discutidas o suficiente com os desenvolvedores.

O Backlog DEEP

Fonte: https://blog.iteris.com.br/backlog-deep-voce-sabe-o-que-e-isso/

O Roman Pichler espalhou a ideia de um backlog DEEP (traduzindo para o português: profundo) em seu artigo Faça seu Product Backlog DEEP. Para ter um backlog DEEP, é preciso estar sempre a frente do desenvolvimento, tendo tempo para definir e discutir as histórias com o time antes que entrem para a sprint. Se você está sempre em uma corrida com o time de desenvolvimento para ter tudo pronto e definido a cada sprint, então você não tem tempo para melhorar a qualidade do seu backlog, e assim a bola de neve vai virar uma avalanche.

O primeiro passo para consertar os problemas do seu backlog é criar certa profundidade, e, para isso, as reuniões de refinamento terão um papel fundamental.

Para que serve o refinamento de backlog?

Para qualquer reunião, seja ela recorrente ou não, é muito importante existir clareza sobre o que é considerado sucesso ao final do encontro.

No caso do refinamento de backlog, gosto muito da definição de sucesso proposta pela Maria Chec no artigo Refining the Refinement. Backlog refinement basics:

The goal is to achieve a shared understanding of the work that will be done and that each team member is aware of the scope and nature of the tasks they will face in the next sprint.

Traduzindo para o português: “o objetivo é alcançar um entendimento comum do trabalho a ser feito e que cada membro da equipe tenha consciência do escopo e natureza das tarefas que irão enfrentar na próxima sprint.”

Mesmo estando claro que o ato de refinar o backlog é um trabalho constante e de responsabilidade da Product Manager, é especialmente durante a reunião de refinamento que as funcionalidades e histórias são compartilhadas com o time, que contribuem com o refinamento de acordo com seu papel. Em minha experiência, é assim que cada membro do time deve exercer seu papel durante a cerimônia:

Desenvolvedores

Developers Created by vectorjuice — www.freepik.com

O papel dos desenvolvedores no refinamento de backlog é:

Tirar todas as dúvidas sobre as regras de negócio, até que estejam 100% claras;
Definir qual será a estratégia de implementação da história;
Questionar a Product Manager sobre o que é extremamente necessário para uma primeira release, e o que poderia ser quebrado em outras histórias e priorizado como futuras iterações;
Mapear se há alguma definição, ou outra pendência a ser resolvida antes que a história possa ser considerada pronta para desenvolvimento.

Em casos onde a estratégia de implementação pode ser mais complexa, ao invés de usar o tempo do refinamento de backlog para defini-la, cria-se um novo encontro com este propósito.

Engenheiros de qualidade

Quality check vector created by storyset — www.freepik.com

Os analistas de qualidade tem o dever de:

Verificar se a PM não esqueceu de mencionar nenhum fluxo ou funcionalidade que pode ser impactado pelo novo desenvolvimento;
Verificar se a PM contemplou todos os cenários possíveis durante a jornada do usuário com a nova funcionalidade;
Listar os casos de teste que precisarão ser contemplados;
Avaliar se a alteração proposta pela história de usuário requer um teste de regressão.

Engenheiros de dados

Vector created by storyset — www.freepik.com

Se o seu time possui uma pessoa engenheira de dados, ela pode ajudar da seguinte forma:

Verificar se existe algum novo dado sendo adicionado ao banco de dados que precisa ser mapeado e sincronizado com o datalake. Pode ser que seja necessário também incluir o novo dado em relatórios existentes.
Checar se todas as métricas que a PM deseja acompanhar para avaliar o sucesso da nova release já estão disponíveis. Caso não estejam, a engenheira de dados deve traçar um plano junto da PM para passar a coletar/disponibilizar os dados necessários.

Designers de produto

Product designer vector by freepik.com

Eu diria que existe uma certa polêmica no mercado sobre se os designers de produto devem ou não participar dos refinamentos de backlog. E há uma polêmica ainda maior sobre se o backlog contempla tarefas de design ou não, e se designers são parte da sprint ou não.

De acordo com minha experiência até o momento, tendo trabalhado em três diferentes empresas que faziam produto e desenvolvimento de formas sutilmente diferentes, designers devem ser próximos dos desenvolvedores e engenheiros de qualidade, mas seu trabalho não necessariamente precisa ser acompanhado dentro da sprint. Os designers de produto muitas vezes são encarregados de todas as responsabilidades do universo de UX, desde a pesquisa, até os protótipos e desenho da interface tornando muito complicada a quebra em tarefas como quebramos tarefas de desenvolvimento que já estão definidas.

Em alguns casos, quando o design é uma parte crucial da nova funcionalidade, ou seja, há novos componentes ou iterações que precisam ser adicionadas, que ainda não fazem parte do design system ou do projeto de código. Nesses casos é sim valioso trazer a designer de produto para a reunião de refinamento, para ajudar a esclarecer quaisquer dúvidas e até mesmo entender se o time de front-end precisa fazer algum ajuste no design para entregar a funcionalidade no tempo previsto.

Como Product Managers devem conduzir a cerimônia de refinamento?

Seu trabalho começa antes mesmo da reunião, garantindo que você já trabalhou pelo menos no D (detalhado) e P (priorizado) do seu backlog DEEP.

Você deve comparecer à reunião já com uma ideia clara das prioridades das próximas sprints e quanto maior a prioridade, mais detalhada deve estar a história e/ou funcionalidade.

Como responsável por conduzir o refinamento de backlog, seu papel é percorrer cada uma das histórias de usuário priorizadas para a próxima sprint e repetir os passos a seguir:

Apresente a história ao time, compartilhando três pontos-chave: O motivo pelo qual a história será desenvolvida, seus requerimentos e como o sucesso será medido. Se ela fizer parte de uma nova release/funcionalidade/épico que o time ainda não conhece, comece dando o contexto maior do que será desenvolvido, antes de entrar na apresentação da história.
Convide o time a fazer compartilhar seu entendimento da história, fazer perguntas e propor estratégias de implementação.
Continue guiando a conversa entre desenvolvedores, analistas de qualidade e outros membros do time, até que a história esteja 100% clara para o time, assim como sua definição de pronto e os desenvolvedores estejam seguros com seu tamanho. Note que muitas vezes a história será quebrada em histórias menores e/ou sub-tarefas.

É provável que durante as discussões o time perceba que uma história precisa de mais pesquisa, definição, ou da solução de alguma pendência externa. Nesses casos é papel do PO entender se vale a pena/há como solucionar a questão em tempo, ou se é melhor rever a priorização.

Como líder da cerimônia, é muito importante que você se atente ao tempo para que seja possível discutir todas as histórias previstas para a sprint. Quando a PO ainda está no processo de atingir uma boa profundidade de backlog, é comum o time não dar conta de revisar toda a sprint em uma reunião, mas conforme essa habilidade é aprimorada, chega um momento em que o time consegue refinar as histórias de duas ou três sprints futuras.

Quando um time já está com a maturidade de um backlog com três ou mais sprints refinadas, é muito comum iniciar o refinamento passando rapidamente pelos itens já refinados, apenas para verificar se é necessária alguma alteração na estimativa de pontos, re-priorização, ou mesmo a remoção de itens não mais relevantes.

Qual a frequência ideal de um refinamento de backlog?

Acredito que a frequência do refinamento de backlog depende de nível de profundidade de backlog (não só mente em termos de tamanho, mas de qualidade, seguindo o backlog DEEP do Roman Pichler).

Na minha experiência, times que já possuem um backlog de qualidade, e que, ao invés de sempre refinar a próxima sprint, já estão refinando uma ou duas sprints a seguir, atingiram um nível de maturidade onde o refinamento de backlog pode ocorrer com segurança uma vez a cada sprint.

No entanto, times que estão começando agora a criar mais profundidade de backlog, podem acabar precisando de reuniões mais longas ou mais frequentes (duas vezes por sprint) até atingirem esta maturidade.

Conclusão

A cerimônia de refinamento de backlog, por mais que não seja considerada uma das cerimônias oficiais e obrigatórias do SCRUM, segundo o guia oficial da Scrum.org, é uma das mais importantes para manter um time saudável.

É por meio deste evento que o squad tem maior espaço para compreender a estratégia, os próximos passos, e ainda contribuir com o plano de implementação.

Se o seu time ainda não pratica reuniões de refinamento de backlog, recomendo fortemente que proponha esta mudança em uma das reuniões de retrospectiva, mesmo que como um experimento inicial. Se você conseguir conduzir o evento de acordo com as orientações detalhadas acima, o time rapidamente irá perceber o ganho nas sprints e se tornar adepto a esta prática.

Referências

Faça seu Product Backlog DEEP Artigo oficial do Roman Pichler em Inglês.
Backlog DEEP: você sabe o que é isso? Ótimo resumo do conceito do Pichler, em português e unindo algumas técnicas de priorização
Refining the Refinement. Backlog refinement basics.
Guia oficial da Scrum.org

O UX Collective doa US$1 para cada artigo publicado na nossa plataforma. Esse artigo contribuiu para a World-Class Designer School: uma escola de design gratuita de nível universitário, com foco em preparar designers africanos jovens e talentosos para o mercado de produtos digitais local e internacional. Construa a comunidade de design na qual você acredita.

Como o refinamento de backlog pode salvar sua squad was originally published in UX Collective 🇧🇷 on Medium, where people are continuing the conversation by highlighting and responding to this story.

Como liderar por influência.

Jessica Esquenazi Hollander — Tue, 12 Jul 2022 12:33:03 GMT

Toda PO/PM precisa aprender a conquistar a confiança e o respeito do time de desenvolvimento.

Conversando com uma de minhas mentoradas essa semana, percebi que um desafio muito comum entre Product Owners e Product Managers juniors é conseguir assumir uma posição de liderança na equipe.

Para nosso sucesso como profissionais, nós, mulheres de produto, precisamos ser especialistas em liderança por influência. Ainda mais considerando que temos de lidar não somente com o desafio de liderar um time que não gerenciamos, como fazer isso driblando o preconceito e pré-julgamento que sofremos simplesmente como mulheres no mercado de trabalho.

Poderia dedicar um artigo inteiro explicando a diferença entre liderar por influência e outros tipos de liderança, mas para o fim deste artigo, podemos nos satisfazer com as seguintes afirmações:

A liderança por influência é uma das mais difíceis de se exercer, porém, definitivamente, a mais eficiente.
É a liderança ideal para Product Managers e Product Owner, que não são gestores das pessoas com quem trabalham, porém precisam tomar decisões e dar direcionamentos sob uma posição de autoridade.
Ter autoridade é diferente de ser autoritária. A autoridade é uma percepção que o outro tem de você, que o torna mais propício a confiar em suas ideias e decisões, enquanto o autoritarismo é um modelo de gestão que se baseia na obediência absoluta.
A liderança por influência coloca você em uma posição de autoridade, por meio da inspiração e do respeito.

Preciso confessar que nunca me aprofundei em livros e artigos sobre o tema de influência, justamente por ser uma habilidade forte, que desenvolvi desde muito jovem. Nos parágrafos abaixo vou dar algumas dicas sobre comportamentos que vão te ajudar a conquistar uma posição de liderança no time, que aprendi ao longo da minha vida pessoal e profissional.

Transmita confiança e clareza em suas comunicações

Essa primeira dica pode parecer um pouco óbvia (e é), porém é uma das mais difíceis de se aprender, pois depende de um atributo muito escasso na comunidade feminina: auto confiança. Para transmitir confiança, é necessária estar confiante, e para a comunidade de mulheres que passou e passa diariamente por situações de opressão, a busca pela auto confiança rende anos e anos de terapia.

Quando eu tinha 11 anos, já possuía um nível de inglês acima da média, pois minha família é de imigrantes, fugitivos do Holocausto, e sempre me comuniquei em inglês com minha avó e alguns outros familiares. Para transformar meu privilégio em algo produtivo para a sociedade, comecei a dar aulas voluntárias de Inglês para alunos do ensino médio de um colégio da comunidade de Heliópolis, em São Paulo.

Conseguem imaginar uma menina de 11 anos dando aula para estudantes de 15 a 18 anos? Eu precisei criar uma autoridade que eu não possuía. Como fazer um grupo de adolescentes respeitar uma menina? Não foi fácil, mas eu aprendi que a confiança vem de dentro para fora, e não o contrário. A vontade que eu tinha de ajudar esse grupo de adolescentes a aprender inglês era maior do que o meu medo de ser julgada, ou criticada.

Essa mesma mentalidade precisa ser aplicada quando você for se posicionar na frente da sua equipe: o que é mais forte? seu medo de passar vergonha, ou estar errada, ou sua vontade de ver o produto evoluir e o time crescer e se desenvolver?

Fortaleça o propósito e levante a moral do time

Muitas vezes a dificuldade de comunicação e liderança vem da falta de um "pacto", um senso de propósito comum, entre a líder de produto e o time. Se você está assumindo uma nova equipe, ou já trabalha há anos na mesma equipe, não importa: reforce o propósito do time, crie no time uma vontade de se destacar pelo trabalho na empresa, de se tornar um exemplo e uma referência interna.

Pode parecer exagero, mas eu fiz e continuarei fazendo isso com todos os meus times. Sempre que assumo um novo time deixo claro que minha intenção é construir um time que é amigo, que trabalha junto e que se torna referência para os outros squads. Deixar claras as suas intenções de construir um bom time, que rema junto, faz sim diferença na hora de conquistar o respeito mútuo.

Compartilhe seu conhecimento de produto e envolva o time no negócio

Um ponto essencial para comprar o time é ter um roadmap e uma estratégia de produto inspiradora. Compartilhe sua pesquisa com o time, compartilhe seu conhecimento e deixe o time por si só que você tem uma ótima visão para o futuro do produto.

Quanto mais o time souber sobre o que você faz, mais respeito vão construir perante seu trabalho.

Sempre que aprender algo novo sobre o produto, sobre o negócio e sobre seus usuários, compartilhe com o time, peça a opinião deles, e os envolva na solução de problemas.

Valorize e construa uma relação com cada membro do seu time

Assim como para você, ser mais confiante te ajuda a melhorar como profissional, o mesmo se aplica para cada membro do seu time. Uma boa líder sabe levantar a auto estima de cada integrante de sua equipe, elogiando em público, valorizando e construindo uma relação.

Algo que considero de extrema importância quando se assume a liderança de um time é assumir a responsabilidade pela felicidade do mesmo. Sim, a Scrum Master é responsável pela saúde do time, mas você como líder, também precisa assumir essa responsabilidade para com a equipe.

Como fazer isso? O primeiro passo é construir uma relação pessoal: marque momentos divertidos, como cafés, noite de jogos, dentro outros momentos de conexão, seja de forma presencial ou remota.

O segundo passo é construir uma relação profissional: comunique ao time quer conhecer melhor cada um para entender seu momento profissional, onde querem chegar, o que gostam no time e empresa atual e o que pode melhorar. Isso é um pouco o papel de um gestor, e você, por não ser gestora do time, não poderá dar uma promoção, ou um aumento, mas o gestor de cada pessoa do time com certeza irá de procurar na hora de do feedback.

O terceiro passo deve ser praticado com certa constância e é valorizar a pessoa que trabalha com você, sempre perguntando como cada um está, como foi o final de semana, e como está o trabalho. Quem pergunta, é quem se importa, e normalmente quando nos importamos com alguém e demonstramos nosso interesse genuíno, o mesmo carinho é retribuído.

O último ponto é sempre lembrar de elogiar em público quando alguém do time faz algo legal. Não precisa ser nada muito grande, quanto mais elogios melhor. Se puder, mostre sua gratidão e apreciação pelo seu time em espaços maiores que o do squad, pois assim você promove seu time para a empresa e o time vai perceber que pode contar com você para dar a visibilidade que merecem.

Seja receptiva quando alguém discordar de você

Uma das piores atitudes de uma pessoa em posição de liderança é ter a certeza de que está certa e sempre ter um roteiro pronto para invalidar quaisquer argumentos divergentes. Uma qualidade incrível de bons líderes é saber a hora de escutar, a hora de falar "não sei" e a hora de falar "vamos repensar".

Líderes inteligentes aprendem com seu time, e deixam que o time fale, se posicione, e ajude a melhorar o trabalho. Um líder que assume a necessidade de sempre ter todas as respostas perde o respeito, o engajamento e a empatia do time.

Saiba quando é necessário dar a palavra final

Líderes por influência não mandam no time, mas sim fazem propostas e influenciam o time a aceitá-las, fundamentando suas ideias e deixando claro o resultado esperado com a mudança. No entanto, isso não significa que a líder de produto não terá a palavra final.

Quando abrir temas para discussão, se perceber que o time não está naturalmente chegando em um consenso, tome a iniciativa de apontar para o time que a discussão não está fluindo e se encarregar de tomar uma decisão final que terá de ser respeita pelo time. Faça um combinado com o time: se comprometa a sempre escutá-los e tomar decisões fundamentadas, se o time se comprometer a respeitar a sua decisão final, quando não há um consenso.

Não mande, proponha

Uma das coisas mais difíceis de se fazer em uma posição de liderança é conduzir mudanças: novos processos, novas atividades, novas formas de se pensar.

é muito fácil chegar para o time e falar: a partir de agora vamos trabalhar assim. No entanto, uma líder por influência, precisa, literalmente, influenciar o time a mudar, ao invés de impor a mudança.

Um ótimo exemplo que vem em mente é o de introduzir uma nova reunião para o time de desenvolvedores. Quem já tem alguma experiência em produto sabe que desenvolvedores são, em geral, extremamente resistentes a participar de novas reuniões, e com motivo.

Como usar a ideia de propor ao invés de mandar, para por exemplo, introduzir num time o hábito de fazer cerimônias de refinamento de backlog?

Saiba introduzir o tema como uma sugestão e não uma mudança obrigatória, que precisam “engolir”.

Apresente a proposta do refinamento de backlog no melhor momento para isso: a retrospectiva, já associando o refinamento com os problemas que acontecem quando não o executamos corretamente:

Histórias gigantes que se arrastam de sprint em sprint;
Time com tarefas mal distribuídas (alguns desenvolvedores sobrecarregados, outros sem atividade);
Histórias que precisam de discovery (seja ele técnico ou de negócio) durante a sprint de desenvolvimento;
Plannings extremamente longas e exaustivas.

Não imponha o refinamento de backlog como uma nova mudança oficial, traga como uma proposta, um experimento a ser testado para solucionar os problemas atuais do time, e que pode ser aprimorado pelo time com o tempo.

Durante as primeiras reuniões, peça feedback instantâneo ao time, para saber como juntos podem melhorar o sucesso da reunião.

Como liderar por influência. was originally published in Mulheres de Produto on Medium, where people are continuing the conversation by highlighting and responding to this story.

How DEEP Backlog Refinement Can Save Your Squad

Jessica Esquenazi Hollander — Mon, 11 Jul 2022 12:41:13 GMT

Learn how to build a DEEP backlog and conduct productive refinement calls in order to maintain a happy and agile team.

Let's start with a reflection. The questions to follow will help you understand if your team is or not suffering from the structural problems caused by a poorly refined backlog:

Is your team able to finish the user stories within the sprint, or are the stories frequently dragged from one sprint to another?
Is the work well distributed throughout the team, or are some overwhelmed while others with too much spare time?
When a sprint starts, are all team members able to work on their tasks right away, or do some already start the sprint blocked by personal doubts about the work, missing requirements, or even waiting for final decisions from the business team?
How long do the planning sessions last? Do they feel long and tiring? Do you feel that you as product manager are a crucial figure during the planning? Or is the technical lead aligned enough on the upcoming sprint items to conduct the call?

What did you learn from answering the questions above? If your answers give you cause for concern, you probably need to do a better job refining your backlog and conducting a backlog refinement meeting.

A not well refined backlog causes many problems for the team. As the owner of the backlog, you need to create some distance between the features and user stories that you are defining and the user stories going into the sprint. When these problems highlighted by the questions above happen, is usually because the backlog is either too short, meaning the product manager is always rushing to get everything defined before the sprint starts, or the stories are already defined, but haven't been discussed enough with the developers.

Source: https://www.romanpichler.com/blog/make-the-product-backlog-deep/

The DEEP backlog

Roman Pichler discussed the idea of a DEEP backlog with his article Make Your Product Backlog DEEP. In order to create a DEEP backlog, you need to be always ahead of development, having time to define your stories and discuss with the team a few sprints before it actually goes into development.

If you are always in a race with the development team, to have stories ready and defined sprint by sprint, then you won't have time to improve the quality of the backlog, and the snowball will become an avalanche. The first step into fixing your backlog problems is to create some depth, and for that the backlog refinement calls will play a key role.

The backlog refinement call

For every meeting, be it recurring or not, it is very important that there is clarity around what is considered success for that encounter.

In the backlog refinement's case, I really like the definition of success proposed by Maria Chec in the article Refining the Refinement. Backlog refinement basics:

The goal is to achieve a shared understanding of the work that will be done and that each team member is aware of the scope and nature of the tasks they will face in the next sprint.

Even though it is clear that the act of refining a backlog is a constant work and responsibility of the product manager it is specifically during the refining meeting that the features and stories are shared with the team, that contributes according to their role. In my experience this is how each member of the team should play their part in the meeting:

Developers

The developers role in a backlog refinement call are the following:

Clarify all the doubts regarding the business logic and requirements. Make sure the items being refined are 100% clear to them;
Define what will be the implementation strategy of the items being refine;
Question the product manager on what is extremely necessary for a first release (must have) and what can be broken in smaller stories and prioritized for future iterations (should have);
Map of there is any definition, dependency or blocker that needs to be solves before the story can be considered ready to develop.

In some cases, the implementation discussion can take longer than expected. For these scenarios, it is important to recognize it is a complex task, and that it might require another meeting dedicated to discuss its technical implementation.

Quality assurance engineers

During the refinement call, the QA engineers have the duty of:

Verifying if the PM forgot to mention any flow or functionality that can or will be impacted by the new development being discussed;
Verifying if the PM contemplated all possible scenarios during the user's journey through the new functionality;
Listing all test cases that will need to be considered;
Evaluate if the proposed new development will require regression tests.

Data engineers

If your team is equipped with data engineers, they can help with the following:

Verifying if any new data is being added to the database that should be mapped and synced with the data lake.
Check if all metrics the PM wishes to track to evaluate success of the new release are already available. If not, help the PM plan how to make this data accessible.

Product designers

I would say there may be different opinions in the industry about rather product designer should or should not be part of the backlog refinement call. And there is an even bigger divergence about rather the product backlog contemplates design work or not, and if the designers are part of the sprint or not.

In my experience so far, having worked at three different companies, all doing product and development in a slightly different way, designers should be close to the developers and QA engineers, but their worked should not necessarily be tracked inside the sprint. Product designers often are responsible for all UX responsibilities, from research to prototypes and UI designs, making it complicated to break down their work as we would break down a feature that is already defined.

For this reason, I prefer to have the product manager and product designer aligned and working closely together, guaranteeing that even if the product designer don't attend refinement calls, they have a clear understanding of the backlog and their priorities. In my opinion, most of the time they won't benefit or contribute as much to the backlog refinement call, making it more valuable to have them focus on their tasks.

In some cases, when the design is a huge part of the new feature, meaning we are adding new components or interactions to the code project, that were not yet documented in the design system. In these cases it is valuable to bring the product designer into the refinement call to help clarify any doubts and even understand if the frontend team needs any adjustments to the screens in order to deliver on time.

How should product managers conduct a refinement call?

Your work begins even before the call starts, making sure you have worked at least on the D (detailed) and P (prioritized) of your DEEP backlog.

You should come to the call with already a clear idea of the next few sprints priorities, and the highest the priority, the most detailed the user stories and features.

As the person responsible for conducting the refinement, your role is to go over each of the highest priority items of the backlog and repeat the following steps to each of the items:

Share the story with the team and make sure you mention three key aspects: the motive behind the story, the requirements, and how success will be measured. If the story is part of an entire new feature/epic/release, then first give a broader context of what we aim to build before jumping into the stories.
Once you have shared all key aspects of the item, invite the team to share their understanding, ask questions, and propose implementation strategies.
Continue to guide the discussion between the squad, making sure each team member is playing their expected role in the item refinement, until the story is 100% clear to all, with a definition of done and with the developers being satisfied with the size of the story. Note that many times, during the discussion, a story will be broken down into smaller stories or sub-tasks.

It is likely that during the discussion the team realizes that a story needs more research and defining, or that it is blocked by an external dependency. In these cases, it is the PM's role to understand that it might be best to re-prioritize other items, and come back to this one when it is indeed ready for a tech discussion.

As leader of the ceremony, it is very important that you pay attention to the timing of the call, to make sure all tasks that need to be discussed for next sprint have been covered. As your team grows mature in backlog refinement, you will be refining two or three sprints ahead, instead of always refining tasks of the next sprint. This is great maturity, as it guarantees that a sprint will never be jeopardized because of lack of defining or refinement.

Once you have achieved this maturity, you will start each refinement meeting with already a few sprints of refined and even roughly estimated user stories. When this is the case, usually the team starts the call by quickly going over the already estimated stories, to make sure there are no new learnings or changes in priority that might require new estimation or reprioritization.

What is the ideal frequency of a refinement call?

I believe this frequency will always vary according to the teams maturity and depth of backlog.

In my experience, teams that already have achieved this maturity, and that are already refining a few sprints ahead, will be very safe and comfortable with one refinement call per sprint, which is the frequency proposed by SCRUM. It should also not take more than one hours per week of sprint (if a sprint has one week, your refinement call should be max 1 hour, but if it has two weeks, than the call should have no more than 2 hours).

When a team is still reaching for this maturity, sometimes they might require longer and/or more frequent refinement calls, only until they are caught up. If that is your case, just be careful to get caught up fast, as long and frequent calls are very bad for your teams health.

Special thanks to Tremis Skeete, Executive Editor at Product Coalition for the valuable input which contributed to the editing of this article.

How DEEP Backlog Refinement Can Save Your Squad was originally published in Product Coalition on Medium, where people are continuing the conversation by highlighting and responding to this story.

Tudo no meu tempo e na minha cultura.

Jessica Esquenazi Hollander — Tue, 28 Jun 2022 21:02:24 GMT

O que aprendi sobre diversidade, equidade, inclusão e pertencimento trabalhando em uma equipe global.

Até começar a pandemia, eu fazia parte do grupo que nunca havia trabalhado de casa. Estava acostumada a levantar cedo, pegar o metrô até o trabalho e ter aquele dia clássico de uma pessoa de produto no escritório, me movimentando entre diferentes áreas. Na maioria das empresas em que trabalhei a área de negócios e a área de tecnologia não ficavam no mesmo andar, e , em especial quando trabalhei para um banco multinacional em São Paulo, não ficavam nem se quer no mesmo prédio.

Assim que comecei a trabalhar remoto por conta das restrições da pandemia, comecei a perceber uma série de benefícios do home office, mesmo estando em uma empresa que não estava acostumada com esse modelo e precisou se adaptar rapidamente. No entanto, foi somente quando entrei para uma empresa global que já era 100% remota antes da pandemia, que aprendi que algumas coisas podem ser (e são) muito diferentes, quando se respeita o tempo e a cultura de cada um.

Tudo bem se alguns trabalham enquanto outros dormem.

Empresas que estão apenas começando com a cultura do home office, ou apenas tolerando esta realidade por conta da pandemia, exigem que a equipe esteja sempre trabalhando no mesmo horário, mesmo quando é possível realizar o trabalho se forma assíncrona. Muitas empresas fazem a clássica primeira reunião do dia no horário de início do expediente de propósito, para garantir que todos iniciaram o dia de trabalho juntos e possivelmente observar e punir os atrasados.

Empresas acostumadas com o trabalho remoto, sobretudo com equipe em diferentes fusos, sabem que em muitos tipos de trabalho, o time não precisa estar trabalhando ao mesmo tempo, apenas ter uma ou duas horas de expediente em comum caso haja necessidade de esclarecer algum ponto de forma síncrona. Em empresas com esse nível de maturidade, cada pessoa é livre para escolher suas horas de trabalho e conciliá-las com suas outras responsabilidades na vida. Um time avaliado pelo seu desempenho saberá organizar suas responsabilidades em um trabalho flexível.

Existem pessoas que rendem melhor trabalhando à noite e preferem passar o dia com os filhos, ou estudando, ou fazendo outras atividades, e está tudo bem. Tem pessoas que preferem acordar super cedo e usar a parte da tarde para cuidar da casa e dos filhos. Tudo bem também. Uma vez que se quebra a necessidade de colocar um time inteiro que trabalha de forma independente para trabalhar ao mesmo tempo, se permite que cada pessoa se organize para trabalhar da forma que irá render melhor e aproveitar mais a vida pessoal e profissional.

Essa lógica de permitir que cada um trabalhe no seu horário também ajuda a diminuir as interrupções. As exigências de que tudo seja respondido na hora (até mesmo o que não é urgente). Em um time em que uns trabalham em quanto outros dormem, uma pessoa sim, enviará mensagem para outra enquanto ela estiver dormindo e vice-versa. Isso cria uma maturidade no time de confiar que será respondido quando a pessoa estiver disponível, assim como saber que está no direito de não responder mensagens fora do seu horário de trabalho.

Uma empresa experiente em trabalho remoto sabe que bons funcionários são aqueles que sabem a hora de trabalhar e a hora de se cuidar, construindo assim um time feliz, comprometido e de baixo turn over.

No time de tecnologia ainda existe uma vantagem interessante em ter pessoas trabalhando enquanto outras dormem — sempre terá alguém disponível pra fazer o deploy no horário mais seguro, quando o sistema sai do ar, ou algum outro imprevisto acontece.

Nos meus primeiros meses como Product Manager na Powertofly, decidi experimentar o horário das 7 da manhã às 15 horas. A grande maioria do meu time estava do outro lado do oceano atlântico e, portanto, começavam a trabalhar enquanto eu ainda estava no início da minha noite de sono.

Pensei que dessa forma teria mais tempo com o time e ainda mais horas livres ao longo do dia para fazer atividade física. Testei por um mês e não me adaptei. Descobri que prefiro surfar ou ir para academia de manhã, já começando o dia ativa, ao invés de fazer essas atividades após um expediente inteiro de trabalho. Também percebi que o time já estava bem treinado em comunicação assíncrona e não havia muita necessidade em ter mais de uma ou duas horas de trabalho em comum.

No mês seguinte, passei a começar a trabalhar às 10 e funcionou muito bem para mim. Enquanto eu preferi o horário convencional, aprendi que muitas pessoas do time são incrivelmente beneficiadas pela flexibilidade de escolher quando começar e parar. Para mim o exemplo mais extremo o de um colega de Bangalore, que começa a trabalhar as 18 horas e termina no meio da madrugada. Para ele, é a melhor forma de conciliar um trabalho integral com sua faculdade, e consegue encaixar boas horas de sono, porém não nos horários convencionais.

Cultura empresarial é diferente de contratar pessoas que pensam igual.

Se em uma empresa presencial — que faz um bom trabalho em cultivar a diversidade, equidade e inclusão — já encontramos pessoas com diferenças de criação como classe social, religião e educação, quando se abre as portas para o trabalho remoto, essas diferenças podem tomar uma escala global. Cada um enxerga o mundo através de sua própria lente. Essa divergência não é um problema, mas sim a solução. Um barco com pessoas que pensam igual afunda mais rápido que um barco com pessoas refletindo sobre um mesmo problema, cada uma com seu ângulo e perspectiva únicos.

É necessário uma empresa com muita maturidade em cultura empresarial para que cada membro da companhia, desde a CEO ao estagiário, reconheça e respeite as diferenças. Parece algo óbvio, que já estamos cansados de ouvir, mas ouso dizer que escutei isso a vida inteira em diversas empresas por que passei, mas nunca vi acontecer na prática.

O que mais vemos hoje no mercado de trabalho são empresas fazendo todo o tipo de publicidade para construir uma imagem de empresa que apoia e valoriza a diversidade, mas que não vão além disso: publicidade. O que acontece é que a empresa consegue contratar alguns poucos funcionários de criações diferentes da maioria da empresa, que após uma semana de trabalho já percebem que não se encaixam e passam a trabalhar em desconforto, prontas para aceitar a próxima oportunidade na esperança de encontrar uma empresa que verdadeiramente respeita e valoriza a diversidade cultural de sua equipe.

Na minha equipe atual, temos pessoas da Índia, do Egito, do México, do Peru, do Brasil e dos Estados Unidos. No meu dia-a-dia também interajo bastante com pessoas da Jordânia, Rússia, Nicarágua, Argentina e Ucrânia. São muitas as diferenças culturais. Para um time desse nível de diversidade — e não somos somente diversos em nacionalidade, mas também em gênero, idade, orientação sexual, classe social, religião e criação como um todo — é necessário dominar alguns conceitos que vou listar abaixo e que, é claro, deveriam ser um mantra para todas as empresas:

A forma como nos vestimos, arrumamos nosso cabelo, tatuamos nosso corpo e nos portamos de modo geral é parte de quem somos. Uma empresa nunca deve exigir de um funcionário que mude sua forma de ser. Tirar de uma pessoa sua própria identidade é uma agressão terrível que no Brasil chega a ser banalizada a ponto de histórias como a seguinte acontecerem todos os dias: trabalhadora negra é humilhada e demitida após denunciar racismo.
Profissionais de diferentes criações vão se comunicar de forma diferente. O que para uma cultura seria considerado grosseria, para outra pode ser apenas a forma comum de se expressar. A chave para receber equipes com culturas e criações diferentes, valorizando cada um, é exercitar a comunicação transparente e a vulnerabilidade. É papel da pessoa que interpretou uma grosseria, conversar abertamente com sua colega para perguntar se realmente sua interpretação estava correta. É papel da pessoa que foi considerada grosseira, após ser questionada pela colega, contar mais sobre sua cultura e sua forma de expressar.
Pessoas de religiões não Cristãs — ou da religião que não é a dominante da empresa/país — deveriam ter o claro e indiscutível direito de se ausentar do trabalho em suas festividades e cerimônias religiosas sem ter de pedir permissão para os superiores. Avisar? Claro! Sempre avisar, porém nunca pedir permissão.
Mães e pais vão sim precisar perder algumas reuniões e fazer horários mais flexíveis. Isso não os torna menos profissionais que pessoas que não precisam se preocupar em fazer esse malabarismo de tempo e responsabilidades. A chave aqui é fazer com que tanto a liderança quanto os colegas não julguem a pessoa por esses acontecimentos, mas tenham a empatia necessária para entender que o importante é combinar quais os resultados esperados e avaliar a pessoa com base no que foi definido.
Micro agressões são um problema verdadeiro que se não endereçado podem ferir uma pessoa profundamente. O que dói mais? Quebrar uma perna ou ser picado por um enxame de abelhas? A resposta é: não importa, os dois são terríveis e precisamos evitá-los. O que não falta no mundo são empresas que dizem respeitar diferente culturas, mas fazem piadas e brincadeiras de mal gosto. Cada brincadeira, por mais que para os autores não pareça, é mais uma picada de abelha para quem está do outro lado. Empresas que levam a sério a diversidade, a equidade, a inclusão e a construção do senso de pertencimento sabem a gravidade das micro agressões e ensinam ao time a importância de denunciar e não aceitar esse comportamento.

Por fim, gostaria de encerrar com uma reflexão: quantos dos pontos acima sua empresa pratica? Como você pode ajudar a sua empresa a se tornar um lugar melhor para mulheres, para a comunidade LGBTQA+, para a cultura negra, para pessoas de religiões não cristãs, para pessoas com deficiência, para imigrantes e para todas as outros grupos que ainda estão conquistando sua representatividade no mercado de trabalho?

Tudo no meu tempo e na minha cultura. was originally published in Mulheres de Produto on Medium, where people are continuing the conversation by highlighting and responding to this story.

The undervalued art of naming epics, releases, features, and user stories.

Jessica Esquenazi Hollander — Thu, 16 Jun 2022 20:50:15 GMT

How improving the names of your roadmap items can make you stand out as a product manager.

This article has a version in Portuguese: https://medium.com/@jess.esquenazi/a-subestimada-arte-de-nomear-%C3%A9picos-releases-funcionalidades-e-hist%C3%B3rias-de-usu%C3%A1rios-c5dc85dbc26d

If you are in the process of creating, refining, or reviewing your product strategy, then definitely this article is for you. I have not only experienced this myself, but seen great product managers fail to truly engage and thrill the leadership with the product strategy by poorly naming roadmap items. When this happens, an exciting strategy meeting becomes a translation session, where the product manager loses valuable time explaining what each item on the roadmap stands for.

As highlighted on the very title of this publication, naming roadmap items is an art form, meaning there is no exact way of doing it and every Product Manager eventually has their own style of naming epics, features and user stories.

My hope with this article is that you are able to understand what principles and best practices can be applied to this process to help your strategy and its implementation be as exciting to the stakeholders and developers as it is to you.

In the next few paragraphs we will go over a clear definition of what are Epics, Releases, Features, and User Stories, to whom they communicate, and go over tips to succeed at naming them. I hope the definitions bellow bring clarity and help other Product Managers better organize and communicate their roadmaps. For a better understanding of how to prepare and deliver a great roadmap presentation please refer to the article 10 ways to succeed with a product roadmap presentation from Atlassian.com.

Before we start, here is a flag I would like to raise:

There is a lot of different terminology on the product community regarding epics, releases, features, and user stories. In many places, what I will call an epic bellow, may be referred to as an initiative, theme, scope, or another term. The same goes for releases, features and user stories.

This article was written with the purpose of creating a product foundation training for new members of the Powertofly product team, therefore I will be focusing on our terminology. As you go through the definitions that follow, try reflect on what terminology is used on your company and not get too attached to the terminology I am using but to the description of the roadmap item, as this is something that truly varies depending on where you are working.

Epics

To describe the strategic goal of a product, you often need more than one feature or story. Rather, you need a group of features or stories to comprise this strategic goal. — Product School Glossary

Parent: Company wide initiative.
Child: Releases and Features.
Target audience: Business (leadership and stakeholders)
Timeframe: Can last for over a quarter.

All product strategies should be tied to major company initiatives, and an epic represents exactly what group of functionalities or even new sub-products will be released throughout the strategic roadmap to collaborate with those business initiatives that often go beyond the product itself.

In some companies epics can be composed of features and/or user stories. In other places they can be a group of just user stories, or as I will show in my example, of just features, having the features become the parent of the user stories.

That being said, an Epic is nothing more than a product initiative that is tied to a company-wide goal and is composed of a group of features that can be released and iterated on independently.

A good epic name will give you and all stakeholders a clear understanding of the value and excitement to see it come true. It will also help you better define and break down the features composing the epic and brainstorm ideas.

When naming an Epic, here are some key things to remember and reflect upon:

Make sure the epic name contains the core development that will be done and/or the reason why we are developing it.
Use simple language and avoid lingos/technical vocabulary.
If the epic has clear user value, make sure this is contemplated in the epic name.
Epics can (and should) be broad without being vague. This way the epics make the business team curious about the features, without being the need for the product manager to translate or describe all features in order for the epic to be valuable when read in the roadmap.
Make them short enough to fit in charts and roadmaps

Example of good epic names are:

Note: for all naming examples I will be using a platform that helps ordinary people lose weight.

Create a nutritionists space in our platform
Add missions to engage patients

Example of bad epic names are:

Diet Plan Creation
Gamification Strategy

For a deeper understanding of what is an epic and how to name them, check out What is an Epic and User Story? How to name Epics & User Stories? by Bindiya Thakkar.

Releases

A product release is the process of delivering a new product experience to your customers. — Aha!

Parent: Epic and Company wide initiative.
Child: Features.
Target audience: Business (leadership and stakeholders)
Timeframe: Is delivered within a quarter.

As product managers we hope to deliver constant value to our users. Even if we are sending our user stories to production every sprint, we still need an item to communicate milestones of the epic to stakeholders and end users.

The releases should be the prime material that our Product Marketing Managers will work with to promote our product. At this stage, as we are naming our releases and other roadmap items to the purpose of engaging the leadership and stakeholders with our product strategy, I really advise to let the marketing team later define how this release will be called publicly and focus on the name that best allows the business to understand the milestone accomplished.

Here are some things to consider when naming your releases:

They should be broad enough to contemplate all features inside it.
They should clearly state who is benefiting from the release (who is the end user) and the main value being delivered.
Should be simple enough for business and marketing team to understand and work on the best communication strategy.
Make sure you are using the same terminology used in the Epic. For example, in the Epic, I referred to a "nutritionists space", so bellow I'm using "space" as well, instead of "account" or "experience".

Example of good release names are:

Nutritionists space MVP
Gamification for patients iteration 2
Improvements to the patient website speed

Example of bad release names are:

Version 2.4.3.1
Android 2.5
Q2 Release

Features

‘An aspect of your product that delivers value by meeting a requirement of your customer — such as performing a function that helps solve your client’s problem or gets them closer to achieving the desired result’. — Product School Glossary

Parent: Epic.
Child: User Stories.
Target audience: Business and developers.
Timeframe: Are finished in a couple of sprints. A quarter should have multiple feature releases.

In a product strategy, the Features help us understand what different value is being created for the customer in order for the Epic to successfully achieve the business goal.

That means a Feature is simply a collection of functions that we should provide the user in order to consider the Epic complete.

When naming a Feature, here is what you should have in mind:

The name should contain what the feature does.
Keep it simple and focus on terms both business and developers would understand. For this you should avoid business and technical terms.
A tip I received from Amber Brown — Senior Director of Product at Powertofly — , and would like to share with you is to always check with developers and business if the name is clear and makes sense for them, as for business it will define how they prepare communication and go-to-market strategy and for developers it will not only help break down tasks but the name might be used internally in the code projects.
At this moment, don't worry about how the feature will be called to the end-user. Leave this mission to your Product Marketing Manager or in case you are fully responsible for go-to-market, choose the correct moment to worry about how you will call it to customers. This naming is for business and developers only. If you are at this moment worried on user facing feature naming, I recommend this incredible article by Linette Voller.
Make sure the name of the feature is different enough from the other features of the epic. this might sound silly to mention, but sometimes many stakeholders fail to distinguish features with similar naming.
Use the same terminology that was used in the parent roadmap items.
Here is another great tip from our team, this time given by Melissa Cox — Product Manager at Powertofly: when naming a feature, ask yourself "who is this for and what does it do?".

Example of good feature names are:

Allow nutritionists to create a diet plan
Allow nutritionists to add appointments to their calendar
Have patients choose missions to complete
Create dashboard to track patient missions

Example of bad feature names are:

Diet plan creator
Calendar integration
Mission's list
Mission's dashboard

User Stories

A user story is the smallest unit of work in an agile framework. It’s an end goal, not a feature, expressed from the software user’s perspective — Atlassian

Parent: Feature.
Child: Sub-tasks.
Target audience: Developers.
Timeframe: Are finished within a sprint.

The user story will be your main form of communication with the developers regarding what needs to be done.

Here are some tips for when naming your user story:

They are meant for developers, but should be understandable to anyone who comes across them. Always align with devs if the names are clear to them, as trying to be too focused on business here, you might fail to be clear on what is the objective.
Be careful when naming stories of a same feature. Make the name different enough so that the developer doesn't have to open the user story every time to remember which one it was.
Make sure the name contemplates the value to the user.
Use the same terminology that was used in the parent roadmap items.

Example of good user story names are:

Create form for nutritionist to save diet plan
Allow nutritionist to create draft and published plans
Send notification to patient when plan is created

Example of bad user story names are:

Diet plan interface
Public/private diet plan
diet plan notification

To conclude, every product manager will have their own style of naming, but all should make sure to follow a few DOs and DON'Ts that will really help not only to make your strategy stand out to the stakeholders, but also allow you to have more valuable break down of the child roadmap items.

Here is a quick guide that can be applied to any of the different roadmap items:

DOs

Use simple words and avoid lingos.
Clearly state who is the end user benefitting from it.
Make sure value to user is clear in the name.
Keep in mind who is the audience that will be reviewing this items.

DON'Ts

Abbreviate stuff to make name shorter.
Use different words for the same meaning on child and parent items.
Write items that could be confused with each other/possibly mean the same thing to who is reading it.
Give items absolutely vague names.

The undervalued art of naming epics, releases, features, and user stories. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.