Monetizando Comunidades no Slack

Case Slack PM3
Desenvolvido por
https://www.linkedin.com/in/fabiano-rapkiewicz/
+ equipe
Fabiano Rapkiewicz

Product Management
Documentação do Contexto

O Slack tem como objetivo para os próximos quatro trimestres
monetizar uma nova vertical e, desta vez, a empresa quer focar
na vertical Comunidades/grupos pequenos informais.
Essa vertical tem uma oportunidade de resolver muitos
problemas com grupos que usam o Slack e estão
insatisfeitos, bem como de grupos que preferem usar
alternativas (Whatsapp, Telegram, Discord, etc).
Importante ressaltar que, nesse cenário hipotético, o Slack
priorizou como foco aumentar a aquisição e ativação
destes públicos, de preferência, em planos premium.
Contexto do Desaﬁo PM3
Case

Nos próximos slides eu apresento um planejamento para testar
hipóteses, meu roteiro para tal consistiu em:
1. Mapear alternativas existentes no mercado atualmente;
2. Mapear os principais riscos ao entrar na nova vertical;
3. Desenhar o modelo de negócio da nova vertical;
4. Deﬁnir um plano para atingir o product market ﬁt (aceitação
do produto no mercado).
Case PM3 - Etapa 1
Case

1. Opções de mercado
Análise competitiva

2. Riscos
Plano de mitigação de riscos

Para evitar que a vertical Comunidades construa um
produto ou funcionalidades que resolvem problemas
que não existem e com isso desperdiçar investimento
financeiro da Slack, frustrando seus usuários e até
mesmo inviabilizando os objetivos estratégicos da
empresa, optou-se por usar de algumas técnicas e boas
práticas de desenvolvimento de produtos para
responder às seguintes questões:
● O nosso cliente está disposto a comprar esse
produto?
● Os usuários veem valor no produto a ponto de
usá-lo?
● Existe demanda suficiente por aquele
determinado produto / feature?
● Ele resolve uma dor real?
Risco de valor
Então, para mitigação dos riscos de valor, optou-se
por:
- identificar e entender o público alvo;
- realizar uma dinâmica para levantar hipóteses de
problemas e dores do público alvo;
- montar uma árvore de oportunidades de solução
partindo dos potenciais problemas;
Dentro da árvore de oportunidades de solução (veja
sobre ela aqui), estão as técnicas usadas para validação
das hipóteses de problema e solução, tais como:
- Fake door;
- Teste A/B;
- Entrevistas;
- Pesquisas qualitativas.

Para evitar que a vertical Comunidades assuma o
compromisso de entregar funcionalidades que não
será capaz de entregar no tempo necessário para o
negócio, seja por indisponibilidade da tecnologia
necessária ou por falta de conhecimento da mesma, ou
ainda, por conta de problemas na gestão de delivery do
time de engenharia, algumas questões precisam ser
respondidas, tais como:
● Conseguimos construir essa solução com os
recursos que temos disponíveis?
● O que queremos construir é tecnologicamente
viável?
● Temos a arquitetura necessária para construir o
que queremos?
● Temos o tempo necessário para construir o que
queremos?
● Temos / conseguimos ter a infraestrutura
disponível para lidar com a escala?
Então, para mitigação dos riscos de viabilidade,
importante definir:
- perfil e tamanho mínimo do time de engenharia
necessário para analisar as demandas e definir a
stack de desenvolvimento necessária para setup
do projeto de desenvolvimento;
- definição clara de papéis dentro do time de
desenvolvimento de produto;
- uso de métodos ou frameworks para gestão do
trabalho.
Quanto ao uso de métodos ou frameworks para gestão
do trabalho, as opções mais comuns no mercado são:
Scrum, Kanban e XP. Indiferente qual delas será usada,
é recomendável que se use algumas práticas, como:
- divisão do fluxo de trabalho em Upstream e
Downstream: observando o conceito do cone
da incerteza de Barry Boehm;
- mitigação de incertezas de desenvolvimento
através de uso de demandas tipo spike e POCs;
- métricas de eficiência de fluxo.
Risco de viabilidade

Então, para mitigação dos riscos de negócio, optou-se
por:
- identificar onde estão as oportunidades de receita
a partir das soluções que estamos propondo;
- estimar os custos da estrutura necessária para
desenvolver, entregar e sustentar nossa soluções ;
- levantamento do preço praticado no mercado
pelos concorrentes que entregam soluções iguais
ou semelhantes às nossas;
- identificar e definir quais são as métricas de
negócio cruciais para medirmos nosso sucesso;
Como apoio para análise de riscos de negócio pode-se
usar o Lean Canvas desenvolvido para esse desafio,
assim como as demais técnicas listadas abaixo:
- Lean Canvas: concorrência; custo; retorno;
- Matriz de risco: probabilidade e impacto;
- PI Planning: sincronização de todas jornadas;
- Benchmark: custos, produtividade; lucro;
Para evitar que a nova vertical Comunidades gere
algum tipo de prejuízo, seja interno ou externo,
prejudicando a continuidade de alguma atividade
produtiva ou até mesmo a insolvência do negócio
como um todo, é importante buscar a resposta para
alguns questionamentos, como:
● Seu produto é capaz de gerar receita?
● Ele traz algum risco legal para o negócio?
● Ou algum malefício para outras áreas?
Risco de negócio

3. Modelo de negócio
Monetizando uma nova vertical: Comunidades

Na busca pelo modelo de
negócio para a nova vertical
Comunidades, um canvas foi
iniciado com ênfase nas
hipóteses que precisam ser
validadas. Está se buscando
um encaixe entre os
problemas de mercado e a
solução oferecida.
Post-its em laranja são
especíﬁcos para a persona
Zu Speaker e os amarelos
podem ser para ambas
personas. Não houve
preocupação em ﬁnalizar
todo o Canvas.
Lean Canvas
Ver canvas maior aqui
Vertical Comunidades

4. Product Market Fit
Em busca do PMF

Os passos em busca da aceitação do produto no mercado e
consequentemente o alcance do Product Market Fit, são:
1. descrever a grande ideia, hipótese ou solução de um
problema que se acredita que o usuário tenha;
2. conhecer o usuário, usando ferramentas, como: desk
research; mapa de empatia; ir a campo e conversar com
seu usuário; entrevista "Problema/Solução";
3. deﬁnir a estratégia do produtos fazendo as perguntas
certas para os usuários e pessoas internas da empresa;
4. mapear hipóteses de problemas e soluções;
5. validar hipóteses, algo como: mensurável; passível de
aprovação por experimento; ter uma razão clara;
participantes corretos e poucas variáveis;
6. conhecer o mercado e qual seu tamanho (TAM, SOM,
SAM)
7. conhecer a estratégia da empresa e como impactar
positivamente o negócio dela.
Product Market Fit - em busca da aceitação do produto
Os passos em busca da aceitação do produto no mercado e
consequentemente o alcance do Product Market Fit, são:
8. deﬁnir métricas de negócio, como por exemplo:
aquisição; ativação; retenção; receita; PMF Survey
9. medir e acompanhar as métricas essenciais para
saber se está havendo tração (estamos no caminho
certo)

Nessa etapa eu realizei uma análise para entender a visão do
público alvo em relação ao Slack, meu desafio aqui consistiu em:
1. Identificar o perfil de usuário com maior potencial de fit;
2. mapear as principais dores e motivações das pessoas e
indicar por que nossa solução é a melhor;
3. Contruir hipóteses e sugerir soluções para nova vertical.
Case PM3 - Etapa 2
Case

1. Perfil de usuário
Identificando perfil com maior potencial

Desk research partindo dos problemas informados, uma pesquisa em
fóruns da web mostrou que em relação ao Slack, temos:
Grupos que usam e
estão insatisfeitos
Grupos que preferem
usar alternativas
★ Enxergam o Slack apenas como uma
ferramenta de chat e por conta disso optam
por Whatsapp e Telegram;
★ Não gostam de perderem o histórico de
mensagens após um período curto de tempo;
★ Reclamam da pouca visualização do ﬂuxo de
trabalho;
★ Incapacidade de trabalhar simultaneamente
em diferentes contas;
★ Querem ter maior controle de quem participa
de cada discussão;
★ Sentem falta de conteúdo indexado, dizem
que as “micro threads” do Slack são
insatisfatórias.
★ Querem usar as funcionalidades pagas, mas
acham que o custo/ benefício não compensa;
★ Acham as funcionalidades de áudio e vídeo
confusas e insatisfatórias;
★ Dizem que falta maior controle de restrição na
adição de usuários em canais de terceiros;
★ Acham a busca de usuários confusa;
★ Acham que a informação ﬁca espalhada pelo
chat e que é difícil a busca de algo dito no
histórico da conversa.

Personas
O líder de comunidade O que quer começar uma comunidade
Zu Speaker
John Doubt

Levando em consideração o foco priorizado pelo
Slack, somado ao resultado da pesquisa de desk
research, selecionamos o perﬁl do que
denominamos de John Doubt. Os motivos seguem
abaixo:
● Para trazer o usuário John Doubt para o
Slack precisaremos resolver um problema
bem grave para o grupo de usuário que
hoje sequer consideram usar o slack,
justamente por entenderem que ele é
apenas uma ferramenta de chat;
● Ao resolver boa parte dos problemas para o
usuário John Doubt, também estaremos
agregando valor para o usuário tipo Zu
Speaker consequentemente, fazendo que
esse tipo de usuário passe a ver valor em
pagar para ter funcionalidades que o
facilitem seu dia a dia..
Justiﬁcativa do público alvo
John Doubt
Foco priorizado: aumentar a aquisição e ativação
destes públicos, de preferência, em planos premium
Escolha do público alvo
O que quer começar
uma comunidade

2. Dores e motivações
Mapeando principais dores e motivações

Hipóteses de problemas baseado nos dados de conhecimento da persona,
levantou-se num brainstorm alguns possíveis problemas
O líder de comunidade
Zu Speaker

Hipóteses de problemas baseado nos dados de conhecimento da persona,
levantou-se num brainstorm alguns possíveis problemas
O que quer começar uma comunidade
John Doubt

● Gosta de compartilhar conhecimento e de servir as pessoas através
da liderança de comunidades, certamente é alguém muito
comunicativo (e falante).
● Sua proatividade em ser colaborativo acaba lhe trazendo a
seguinte questão: como colaborar com todas essas frentes com a
devida qualidade e atenção a cada iniciativa?
Sintetizando os problemas
● Tem um desejo claro, um objetivo o qual não está conseguindo
alcançar por conta das dúvidas que o cercam, vem daí o nome
para representar esse perﬁl: John Doubt.
● Suas dúvidas são, basicamente, acerca das ações necessárias
para criar uma comunidade e sobre sua capacidade para
gerenciá-la com sucesso.
Zu Speaker
O líder de comunidade
John Doubt
O que quer começar uma
comunidade

A melhor opção
Criar e manter comunidades nunca mais será uma tarefa
a ser realizada só, é por isso que a nova vertical
Comunidades do Slack existe e seu produto é a melhor
opção de mercado para o seu público alvo.
community
● Fim das dúvidas de como iniciar uma comunidade;
● Fim do sentimento de estar em falta com algum grupo;
● Visão real do nível de engajamento e performance;
● Orientação de próximos passos e dicas de melhoria;
● Publicação dos bons resultados e ranking.

3. Hipóteses e sugestões
Hipóteses e sugestões de solução

Foi criado uma árvore para cada persona
e os critérios para selecionar as
oportunidades, foram: ser uma potencial
solução para resolver mais de um
problema do usuário e potencial para
cobrir os pontos levantados na pesquisa
de Desk Research.
Árvore de oportunidades aumentar a aquisição e ativação, de preferência, em
planos premium.
Acessar árvore de oportunidades
A partir das informações dadas a
respeito do público alvo e das
hipóteses de problema, foi montado
uma árvore de oportunidades, a ﬁm
de identiﬁcar quais são as soluções a
serem validadas por experimentação
e que podem trazer resultados
estratégicos para o negócio..
Critérios

Nesse momento, eu criei um planejamento a nível tático para por
em prática a visão estratégica, onde eu busquei deixar o plano
visualmente fácil de entender para poder comunicar com
stakeholders de diferentes tipos. Meu trabalho consistiu em:
1. Criar roadmaps, visando o público alvo a ser comunicado e
demonstrar os principais outcomes a serem alcançados no
próximo trismestre
2. Realizar a primeira release plan e mostrar o primeiro
conjunto de entregáveis que geram valor para a solução a
ser desenvolvida;
3. Deﬁnir as principais métricas a serem acompanhadas e que
servirão para medir o sucesso da solução..
Case PM3 - Etapa 3
Case

1. Roadmap
Principais outcomes a serem alcançados

Visão de futuro
O Slack tem como objetivo para os próximos quatro
trimestres monetizar uma nova vertical e, desta vez, a
empresa quer focar na vertical Comunidades/grupos
pequenos informais.
Visão do produto:
Encorajar a criação e facilitar a gestão de comunidades
virtuais de todos que desejam iniciar ou já são experientes na
liderança de pequenos grupos informais de trabalho
colaborativo..
O Slack priorizou como foco aumentar a aquisição e
ativação do público alvo, de preferência, em planos
premium.
Quais objetivos da empresa?
O que os usuários querem?
O que é possível fazer?

Visão completa ROADMAP = MOTIVAÇÃO + MÉTRICAS
Visão completa do planejamento do trimestre
Nessa visão completa estão todas as
informações necessárias para entender
desde quem são os responsáveis pelo
produto, as motivações e estratégias
para desenvolvê-lo, assim como os
principais indicadores, objetivos e, claro,
as principais features e o plano para
realizar a entrega ao público alvo.
Acessar visão completa
Com base nas informações a respeito
da visão do produto, estratégia da
empresa e oportunidades mapeadas,
foi desenvolvido uma ferramenta para
comunicar aos diferentes públicos
interessados o que está sendo feito e
o que se fará em relação ao produto.
Detalhes

Partindo do princípio de que o Roadmap é um ferramenta de comunicação, é importante que ele esteja
adequado ao seu público alvo. Por isso, a partir da visão completa do trimestre ﬁz as seguintes customizações:
Roadmap ROADMAP = MOTIVAÇÃO + MÉTRICAS
Comunicação para diferentes públicos
Roadmap para engenharia
Roadmap para time de produto
Roadmap para alta gestão
Roadmap para investidores

2. Release plan
Primeiros entregáveis de valor

Planejamento de releases Considerando o trimestre um período composto por seis
quinzenas e uso de Kanban como método de trabalho.
Sem entrega planejada
para esse período
Gestão de threads
Onboarding para criação
de comunidades
Dash de monitoramento
simples
Dash de monitoramento
completo
Gestão unificada de
comunidades
Dicas e planos de ação
1ª quinzena 2ª quinzena 3ª quinzena 4ª quinzena 5ª quinzena 6ª quinzena
Após entendido os objetivos do trimestre para nossa vertical junto à liderança de produtos e deﬁnido quais
oportunidades seriam trabalhadas, uma sessão de pré-working foi realizada junto ao time de engenharia e UX para
levantamento de riscos, priorização e estimativa a nível de funcionalidades. O resultado disso é planejamento de
entregas conforme mostrado abaixo:
No pré-working foram considerado os itens de baixa
granularidade, ou seja, a nível de funcionalidades,
sabendo-se inclusive que muitos dessas poderiam
sofrer alterações signiﬁcativas durante o processo de
Discovery ou até mesmo serem descartadas,
Acessar planejamento detalhado
Para visualizar uma simulação de primeiro Release plan
que irá gerar valor, acesse o mapa de Visão Completa.

3. Métricas
Medindo o sucesso da solução

Um conjunto de métricas será usado para medir o sucesso da solução. Para ajudar a selecionar essas métricas
optou-se em o framework AARR que tem muita aderência com a estratégia elaborada para alcançar o sucesso,
conforme mostrado a seguir:
Framework
Estratégia para o
sucesso
Aquisição
- dos usuários com perfil tipo John Doubt
Ativação
- dos novos usuários John Doubt
- reativação de usuários insatisfeitos (os tipo Zu Speaker)
Retenção
- amadurecer usuários tipo John Doubt p/ se tornarem Zu Speaker
- encantar usuários tipo Zu Speaker
Receita
- usuários ativos e engajados, principalmente com perfil Zu Speaker
AARR ou
Métricas piratas

Métricas Medindo o sucesso da solução
Aquisição Ativação
Retenção Receita
● # novos clientes no plano free;
● custo de aquisição de novos clientes;
● % de novos usuários que se tornaram
ativos em 30 dias;
● tempo médio para ativação
● # média de interações do usuário líder de
comunidade;
● net promoter score
● receita média por cliente;
● custo médio por cliente;

Nessa etapa, minha missão foi organizar a priorização do trabalho a
ser feito para que a equipe pudesse focar no delivery e demonstrar
a capacidade de acomapanhar e apoiar a equipe de
desenvolvimento. Para tal, eu tive a restrição de só poder construir
algo com 10 unidades de esforço por sprint e explicar com detalhes
o racional da priorização. Depois eu deveria considerar 12 unidades
de esforço por sprint.
Com isso, minhas ações se deram da seguinte forma:
.
1. Escrever user stories da primeira release;
2. Simular a atribuição das demandas e dar visibilidade do
trabalho em progresso;
3. Explicar como transformar a equipe numa equipe de
missionários.
Case PM3 - Etapa 4
Case

Racional de priorização
Estratégia para o sucesso
Aquisição
- dos usuários com perﬁl tipo John Doubt
Ativação
- dos novos usuários John Doubt
- reativação de usuários insatisfeitos (os tipo Zu Speaker)
Retenção
- amadurecer usuários tipo John Doubt p/ se tornarem Zu Speaker
- encantar usuários tipo Zu Speaker
Receita
- usuários ativos e engajados, principalmente com perﬁl Zu Speaker
Com base na estratégia pensada para alcançar o sucesso da solução para o próximo trimestre, foram selecionados
do mapa de oportunidades um conjunto de problemas que deram origem a iniciativas.
Iniciativas visando estratégia

Para priorizar as iniciativas foi usado um framework chamado ICE Score como inspiração, pois algumas adaptações
foram necessárias, conforme explicado abaixo.
ICE Score = Impact + Confidence + Effort - ou, em
português: Impacto + Confiança + Esforço
Para fins de exercício, substituímos o parâmetro
Confiança pela Importância, pois não temos dados
para embasar minimamente um voto do quanto
estamos confiante de que a iniciativa impactará
positivamente o negócio.
O parâmetro Esforço foi adaptado para Facilidade
para facilitar o entendimento e votação, pois, quanto
mais fácil for de implementar, maior será a nota.
Escala para cada parâmetro
Todos parâmetros recebem uma nota de 1 a 5, onde
Impacto, Importância e Facilidade podem ser:
1 = baixíssimo
2 = baixo
3 = médio
4 = alto
5 = altíssimo

Abaixo o resultado da primeira rodada de votação. O time entendeu que as iniciativas com ICE Score menor que 10
deveriam ser descartadas momentaneamente. Contudo, após a revisão das votação percebeu-se que ainda faltava
algum outro parâmetro para termos uma melhor priorização, pois muitas iniciativas estavam com o mesmo Score.
ID Iniciativas Impacto Importância Facilidade ICE Score
F001 Onboarding para criação de comunidades 4 5 3 12
F002 Campanhas divulgando novo Slack Community 3 3 5 11
F003 Gestão de threads 4 5 3 12
F004 Gestão unificada de comunidades 3 4 3 10
F005 Dashboard de monitoramento simples 4 5 2 11
F006 Dashboard de monitoramento completo 5 5 1 11
F007 Dicas e plano de ação 5 5 1 11
F008 Conexão para líderes experientes 3 2 2 7
F009 Recompensa em pontos para líderes ativos 2 1 2 5
F010 Mural de destaques 2 2 3 7

Foi adicionado o parâmetro Independência e a escala usada para votação foi exatamente a mesma dos demais
parâmetros. A independência de uma iniciativa é o quanto ela pode ser desenvolvida sem relação direta com outra
iniciativa. Ou seja, uma iniciativa com independência 5 pode ser desenvolvida e implementada em produção
totalmente independente de qualquer outra, seja tecnicamente ou a nível de geração de valor.
ID Iniciativas Impacto Importância Facilidade Independência ICE Score
F001 Onboarding para criação de comunidades 4 5 3 5 17
F002 Campanhas divulgando novo Slack Community 3 3 5 1 12
F003 Gestão de threads 4 5 3 4 16
F004 Gestão unificada de comunidades 3 4 3 4 14
F005 Dashboard de monitoramento simples 4 5 2 4 15
F006 Dashboard de monitoramento completo 5 5 1 2 13
F007 Dicas e plano de ação 5 5 1 1 12

Imagine que você só pode construir algo com, no máximo, 10 unidades de Esforço durante uma sprint…
Supondo que o time tenha optado por
estimar as demandas por Story Points no
padrão Fibonacci, então seria feito uma
correlação da escala do parâmetro
Facilidade, como no exemplo abaixo:
Escala Facilidade Story Points
1 baixíssimo 13
2 baixo 8
3 médio 5
4 alto 3
5 altíssimo 2
Iniciativas ordenadas por ICE Score Facilidade Story Points Sprint Release
Onboarding para criação de comunidade 3 5 Sprint 1 Release 1
Gestão de threads 3 5 Sprint 1 Release 1
Dashboard de monitoramento simples 2 8 Sprint 2 Release 2
Gestão unificada de comunidades 3 5 Sprint 2 e 3 Release 3
Dashboard de monitoramento completo 1 13 Sprint 3 e 4 Release 4
Campanhas divulgando novo Slack Community 5 2 Sprint 6 Release 6
Dicas e plano de ação 1 13 Sprint 4 e 5 Release 5
Como você priorizaria as funcionalidades
da primeira release que planejou?
Conhecendo o esforço em Story Points e imaginando que cada Sprint o
time de desenvolvimento consiga de fato trabalhar em 1o pontos por
Sprint, então haverão Sprints onde o time além de acabar o trabalho
iniciado, poderá adiantar demandas. Abaixo uma tabela mostrando
como se dariam as 6 Sprints de um trimestre e suas respectivas
Releases.

E se você pudesse construir 12 unidades de Esforço?
Iniciativas ordenadas por ICE Score Facilidade Story Points Sprint Release
Onboarding para criação de comunidades 3 5 Sprint 1 Release 1
Gestão de threads 3 5 Sprint 1 Release 1
Dashboard de monitoramento simples 2 8 Sprint 1 e 2 Release 2
Gestão unificada de comunidades 3 5 Sprint 2 Release 2
Dashboard de monitoramento completo 1 13 Sprint 2 e 3 Release 3
Campanhas divulgando novo Slack Community 5 2 Sprint 5 Release 4
Dicas e plano de ação 1 13 Sprint 4 e 5 Release 4
É possível entregar mais rapidamente quando há maior capacidade por Sprint disponível. Com 12 pontos por Sprint as
funcionalidades estariam, em tese, entregues em 5 das 6 Sprints programadas para o Trimestre, ou seja, acabaria uma
Sprint antes quando comparado a capacidade de 10 pontos. Porém, para a primeira Release não há diferença em
quantidade nem das funcionalidades a serem entregues para ambas capacidades.
Não é recomendável comprometer
uma Sprint em sua capacidade
máxima de esforço, pois normalmente
surgem questões não planejadas e
realmente necessárias a serem
trabalhadas durante uma Sprint, como
resolução de bugs, por exemplo. E é
altamente recomendável substituir
estimativas puramente subjetivas por
estimativas probabilísticas baseadas
em históricos de dados de entrega.
Importante!

1. User Stories
Escrevendo história de usuários

Escrita das User Stories Evolução de como as Stories foram escritas
Feature User Story
Epic
Título: Criar comunidade
Como usuário John Doubt, eu quero criar uma
comunidade através de um tutorial para que eu tenha
certeza que iniciarei uma comunidade de forma
adequada.
Título: Conhecer o que monitorar
Como usuário John Doubt eu quero conhecer o que
a plataforma oferece de monitoramento do sucesso
da comunidade para que eu possa acompanhar no
dia a dia e tomar as ações necessárias.
Título: Divulgar comunidade
Como usuário John Doubt eu quero a divulgação da
minha comunidade nas redes sociais logo após o
processo de criação para que o máximo de pessoas
fiquem sabendo e os interessados possam participar.
Onboarding para criação de comunidade
comunidade através de um tutorial para que eu tenha
certeza que iniciarei uma comunidade de forma
adequada.
Título: Iniciar o fluxo de criação
Como usuário John Doubt eu quero ter acesso bem
fácil ao botão de início de comunidade para que
rapidamente eu inicie o fluxo do tutorial de criação de
comunidade.
Título: Cadastrar info sobre comunidade
Como usuário John Doubt eu quero cadastrar
informações sobre a comunidade para que os
interessados possam avaliar se querem participar.
Título: Criar regras da comunidade
Como usuário John Doubt eu quero informar as
políticas e regras de interação dentro da comunidade
para que todos estejam cientes dos comportamentos
passíveis de punição por não serem tolerados.
Título: Organizar a agenda de eventos
Como usuário John Doubt eu quero criar uma
agenda da comunidade já com o link para sala virtual
do encontro para que todos participantes possam se
inscrever naqueles de seu interesse.
No início do Design de Solução No ﬁm do Design de Solução

Feature User Story
Epic
Onboarding para criação de comunidade Onboarding para criação de comunidade
No ﬁm do Design de Solução Durante o Reﬁnamento
comunidade.
comunidade.

Feature User Story
Epic
Título: Informar objetivo e tema
Como usuário John Doubt eu quero informar o
objetivo e tema que a comunidade irá abordar para
que os interessados avaliem se para eles faz sentido
participarem.
Título: Contar motivação
Como usuário John Doubt eu quero contar o que me
motivou a criar a comunidade para que os
interessados participem conectados ao propósito.
No fim do Refinamento
comunidade.
Não foram adicionados os
critérios de aceite para as
User Stories com intuito de
simplificar a apresentação.
E para fins de exercício, foi
definido como Epic uma
User Story que pode ser
quebrada em entregáveis
menores desde que não
comprometa o valor de
entrega, ou seja, não está
relacionado ao tempo de
entrega necessariamente..
Importante!

Feature User Story
Epic
Feature: F001
Feature: F001
F001: Onboarding para
criação de comunidade
Feature: F001
participarem.
Feature: F001
Feature: F001
Todos User Stories que fazem parte da primeira Release e foram selecionadas para a primeira Sprint.
Feature: F001
comunidade.
Feature: F001
F003: Gestão de threads
Título: Visualizar tempo de thread pendente
Feature: F003
Como usuário Zu Speaker, eu quero visualizar o
tempo que as threads estão pendentes de resposta
para que eu possa atender imediatamente os que
estão esperando há muito tempo.
Título: Listar todas threads pendentes
Feature: F003
Como usuário Zu Speaker, eu quero listar todas
threads pendentes de resposta indiferente a
comunidade para que eu possa ter uma ideia geral
do todo o quanto eu estou em falta.
Título: Alertar threads pendentes
Feature: F003
Como usuário Zu Speaker, eu quero ser alertado de
que há threads pendentes de resposta para que eu
saiba que há pessoas esperando algum atendimento.

2. Atribuições
Visualizando distribuição das demandas

Tasks de User Stories Evolução de como o trabalho foi sendo atribuído
Feature User Story
Epic
Design Solução
Backlog Reﬁnamento Desenvolvimento Homologação
F002: Gestão de threads
Produção
Ao puxar a feature F001 para Design de Solução o time
se reuniu para uma primeira sessão de Design e
entendeu inicialmente que a solução seria composta de
um ﬂuxo que contemplasse:
- Criar comunidade;
- Cadastrar info sobre comunidade;
- Divulgar comunidade
Com isso, surgiu a necessidade de criarem algumas
tasks para poder avançar nas User Stories.
Task
Rebeca Demoris
UX Designer
Aiko Chwae
Software Engineer
Maicon Silvestre
Software Engineer
Integrantes da Squad

Feature User Story
Epic
Design Solução
Feature: F001
comunidade através de um tutorial para que eu
tenha certeza que iniciarei uma comunidade de
forma adequada.
Feature: F001
Como usuário John Doubt, eu quero conhecer o que
Feature: F001
Como usuário John Doubtm eu quero a divulgação
da minha comunidade nas redes sociais logo após o
Entender quais seriam as etapas necessárias para
fluxo de Onboarding
Propor um layout nos padrões Slack para fluxo de
onboarding
Estudar melhor local para inserir botão de início da
comunidade
Validar com usuários melhor proposta de fluxo de
onboarding
Task
Os integrantes do time se atribuíram as tasks e após
executarem o trabalho previsto se entendeu necessário
quebrar a User Story“Criar comunidade” em outras
quatro, conforme mostrado neste slide.
Rebeca Demoris
UX Designer
Aiko Chwae
Software Engineer
Maicon Silvestre
Software Engineer

Feature User Story
Epic
Refinamento
Task
Rebeca Demoris
UX Designer
Aiko Chwae
Software Engineer
Maicon Silvestre
Software Engineer
Feature: F001
Feature: F001
Feature: F001
comunidade.
Criar infraestrutura de banco de dados para armazenar
dados de Onboarding
Criar micro-serviço de Onboarding
Criar operações CRUD para persistir informações da
etapa de objetivo e tema
Extender as classes de integração com API de agenda
já usada pelo Slack
Criar serviço de inscrição em evento
Criar classe de reenvio de invite
Inserir botão no menu lateral do Slack
Finalizar o desenho da tela da etapa de objetivo
Refazer telas de integração com agenda do Google
Feature: F001
Criar operações CRUD para persister informações da
etapa de motivações
Criar tela da etapa de motivações
Salvar o status do usuário no fluxo
Criar operações CRUD para persistir informações da
etapa de regras
Durante o refinamento o time criou novas
tasks a fim de preparar as Stories para o
desenvolvimento. Ao fazer isso, reparou que
fazia sentido quebrar uma das Stories para
facilitar o desenvolvimento e testes, conforme
mostrado neste e nesse outro slide.

Feature User Story
Epic
Desenvolvimento
Task
Rebeca Demoris
UX Designer
Aiko Chwae
Software Engineer
Maicon Silvestre
Software Engineer
Feature: F001
participarem.
Feature: F001
Feature: F001
comunidade.
Criar infraestrutura de banco de dados para
armazenar dados de Onboarding
Criar micro-serviço de Onboarding
Criar operações CRUD para salvar informações da
etapa de objetivo e tema
Inserir botão no menu lateral do Slack
Finalizar o desenho da tela da etapa de objetivo
Criar operações CRUD para persister informações
da etapa de motivações
Criar tela da etapa de motivações
Feature: F001
Criar operações CRUD para persistir informações
da etapa de regras
Finalizar desenho de pré-visualização das regras
pelo usuário interessado na comunidade
Implementar tela de pré visualização das regras
pelo usuário interessado na comunidade
Implementar tela da etapa de objetivo Implementar tela da etapa de objetivo

3. Engajamento
Incentivando o espírito missionário

“Ótimos produtos surgem de times empoderados e
multifuncionais”
John Cutler
Product Evangelist & Coach na Amplitude
Princípios norteadores
Pessoas de negócio e desenvolvedores devem
trabalhar diariamente em conjunto por todo o
projeto.
Construa projetos em torno de indivíduos
motivados. Dê a eles o ambiente e o suporte
necessário e conﬁe neles para fazer o trabalho.
As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis.
Três dos doze princípios do manifesto de
desenvolvimento ágil de software.

Missionários Transformando uma equipe em um time de missionários
Para transformar uma equipe em missionários é necessário transmitir com clareza a visão do produto e despertar
a paixão nas pessoas quanto ao problema que temos que resolver. Rotineiramente é preciso trabalhar a visão de
longo prazo e o desejo em conhecer cada vez os nossos usuários e como estamos impactando a vida deles.
As ações para que isso aconteça passam por trazer a squad para participação de parte do processo de
concepção do produto/features e não deixá-la apenas focada no delivery como um time tarefeiro. Para isso, uma
boa opção pode ser a participação do time em workshops de Lean Inception, sessões de brainstorm ou até mesmo
na fase de discovery, onde os desenvolvedores podem, por exemplo, acompanhar algumas entrevistas com
usuários. É necessário também ações a nível de alinhamento e contextualização sobre os objetivos de negócio a
cada nova feature priorizada, uso técnicas como a de press release podem ser muito úteis para esse ﬁm. Ainda
sobre manter o time com visão mais estratégica sobre o próprio trabalho que eles fazem, é importante
compartilhar constantemente as métricas do produto para analisarmos juntos os resultados que estamos
alcançando com as nossas entregas e oportunamente ouvir o que o time tem a dizer a respeito. Por ﬁm, mas não
menos importante, proporcionar um ambiente seguro e com bastante suporte ao time para que ele
gradativamente ganhe entrosamento e amadureça ganhando maior autonomia e desprendimento.

! Bonus point
E quando subestimamos as demandas?

No próximo slide e respondo explico num passo a passo
o que eu faria caso a seguinte situação ocorresse:
"Imagine que as funcionalidades que você selecionou
começaram a ser construídas, mas infelizmente ao
longo do caminho a equipe percebeu que a estimativa
estava errada, e os e na verdade o esforço é bem maior
(65%+) para construírem."
Case PM3 - Etapa 4
Case

Realimento de expectativas
Passo a passo após saber que os prazos estimados pela equipe não serão alcançados:
1. Tentarei entender com o time se precisamos revisar a estimativa de alguma outra funcionalidade planejada;
2. Me certiﬁcaria com a equipe se o trabalho a mais que foi mapeando é realmente necessário para o momento;
3. Se não houver como diminuir o escopo, eu rapidamente tentarei mapear o impacto no planejamento das releases;
4. Entraria em contato com stakeholders para comunicar o que descobrimos e re-alinhar as expectativas/prioridades;
5. Comunicaria os responsáveis por campanha de marketing caso houvesse alguma programada;
6. Me reuniria com outras squads que tem dependência de alguma entrega nossa e reorganizaria o planejamento.

Monetizando Comunidades no Slack

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Monetizando Comunidades no Slack

Semelhante a Monetizando Comunidades no Slack (13)

Monetizando Comunidades no Slack