O documento discute gestão de produtos digitais e fornece definições e exemplos de estratégia, produto, validação de hipóteses, MVP e outras práticas relacionadas à gestão de produtos. O documento também inclui atividades para os participantes aplicarem os conceitos discutidos.

1. Vamos falar de
Gestão de Produtos Digitais?

2. Em primeiro lugar,
Muito prazer, eu sou a Eluza.
Eu gosto de contar histórias e resolvi
fazer isso de uma forma pouco
convencional: estudando Desenho
Industrial. Pesquisei UX muito tempo e
agora trabalho diretamente com
desenvolvimento de produtos digitais,
atualmente sou Product Owner na
Conta Azul.

3. Primeiro, uma atividadezinha:
Vocês já conhecem o FCO, né? Vocês
também já devem ter elencado por aí,
algumas melhorias de qualquer natureza
para ele também, correto?
Vamos fazer o seguinte exercício:
- Peguem 15 melhorias e as coloquem
em uma lista com cinco linhas e três
melhorias em cada uma das linhas.
1.
2.
3.
4.
5.
Ondas

4. Em primeiro lugar, o que é produto?
Produto é definido como um “algo produzido pelo
trabalho ou esforço” ou como o “resultado de um ato
ou processo”, e tem origem no verbo produzir, do
latim prōdūce(re) (levar para a frente, conduzir,
produzir, criar).
Um produto é qualquer coisa que possa ser oferecido
a um mercado para satisfazer uma demanda ou
necessidade.
Fonte: Wikipedia

5. Vamos falar então de gestão de produtos?
Gestão de Produtos é a função responsável por
todos os aspectos de um produto digital, desde
os objetivos estratégicos até os detalhes de
experiência do usuário.
É a função responsável por fazer a conexão
entre a estratégia da empresa e o cliente por
meio do produto digital.
É basicamente entender sobre estratégia e
como tangibilizar essa estratégia de modo que o
triunvirato funcione:
Pessoas
Negócios Produtos
Fonte: Gestão de produtos/ The Product Book

6. E o que é uma estratégia?
É o conjunto de
princípios-guia para que
o que é delineado
baseado nos objetivos da
empresa, seja executado
conforme a melhor
estratégia de entregas de
valores.
Fonte: https://hackernoon.com/wtf-is-a-strategy-bcaa3fda9a31

7. E a quem cabe fazer isso?
Aos Product Managers, claro.
Eles ajudam no
direcionamento da visão, da
estratégia, do planejamento e
processo e finalmente da
execução do produto.
É importante que a
humanidade se
torne uma espécie
interplanetária.
Elon Musk
VISÃO ESTRATÉGIA
PLANEJAMENTO EXECUÇÃO
Sua margem é
minha oportunidade.
Jeff Bezos
Você tem que
trabalhar duro para ter
seus pensamentos
claros no objetivo de
fazer tudo simples.
Steve Jobs
Tudo que nós
fazemos é muito
foda.
Stewart Butterfield

8. Definição clássica:
É o link crítico entre
negócios, tecnologia e UX.

9. Definição mais contemporânea:
É o link crítico entre
negócios, time e clientes
TEAM
UX + TECH
CUSTOMER

10. Como a gente tangibiliza uma estratégia?
Fonte: https://www.youtube.com/watch?v=ayaO26BmkPk

11. De volta ao exercício
Agora, ajustem as ondas de vocês para que elas sigam o objetivo da empresa
para esse quarter relacionado ao FCO, eficiência operacional.

12. Um jeito de pensar produto (como)
HIPÓTESE
Estratégia Execução
CONSTRUIR
MEDIR
APRENDER

13. Pensando produto
Faz parte do trabalho do PM entender quem faz uso dos seus produtos, suas necessidades e seus
problemas tendo certeza que o que vocês está construindo é certo, seja isso uma feature ou um novo
produto. No fim das contas, a maioria das empresas falham não por causa da sua tecnologia, mas
porque não entenderam as reais necessidades do consumidor e como isso interage com o mercado.

14. Pensando produto

15. O que é hipótese?
Uma hipótese basicamente é uma
predição testável. É o que esperar em
que vai acontecer em uma determinada
circunstância.

16. Atividade
Construir uma hipótese para nossa priorização de features do FCO.
Mas lembrem-se:
1- Vocês já tem um objetivo
2- Vocês já sabem, só de olhar, coisas que precisam ser melhoradas
3- Vocês já construíram personas para usar o produto, a hipótese de vocês
precisa contemplar elas

17. Como a gente sabe que uma hipótese deu certo?
Através de métricas.
Essas métricas podem incluir desde como os clientes terminam/se terminam as
tarefas, como algo pode afetar o produto, receita que está fazendo, se aumenta o
número de pessoas que usam.
Métricas são úteis porque elas aparecem junto com as hipóteses e mostram
como podemos prosseguir ou pivotar para fazer mudanças e atingir o sucesso
que esperamos relacionado ao produto.

18. Como a gente sabe que uma hipótese deu certo?
Elas são definidas pelos objetivos e pelas
estratégias. A maioria da empresas tem
métricas que medem seu sucesso em curto,
médio e longo prazo, definidas pelos valores
que são core para a empresa e para o
mercado. E sim, a gente pode ter métricas
para o produto, para a empresa, para os
times e para as features.

19. Como construir métricas
Através de OKRs

20. E porque usar OKRs?
Simples
Escalável
Ágil
Cultura orientada à resultados
Transparência
Foco

21. Atividade
Agora que vocês tem uma hipótese construída, um objetivo, montem dois
resultados chaves que vocês podem medir se estão alcançando o objetivo e
ajustem as ondas para que elas evidenciem essa escolha.

22. Analytics
Analytics nos ajudam nesse entendimento se estamos
capturando as métricas certas para o nosso produto.
Temos que entender em parte do ciclo de vida do produto
a gente está, quem a gente está medindo naquele
momento (nossos cohorts), qual o comportamento
influencia esses analytics ao longo do tempo.
Esse grupo de métricas (workflow) podem formar um funil
onde a gente entende como nossos usuários iniciam e
completam nossas análises.
Existem diversos frameworks que ajudam a montar
nossos workflows de métricas.

23. Pirate Métrics
Acquisition: Como o usuário chega no nosso
produto.
Activation: Como os usuários visitam nossos
produtos e tem sua primeira experiência feliz
Retention: O usuário gostou do nosso produto o
suficiente para voltar a usar.
Referral: O usuário gosta o suficiente para contar
para outra pessoa o quanto gosta dele (ou no
mínimo sobre o uso)
Revenue: O usuário acha que o produto vale a
pena a ponto de pagar por ele.

24. Transformando métricas em oportunidades
Como PMs, precisamos entender os produtos do ponto de
vista de quem usa o produto.
Gatilho (trigger) - o que acontece quando o usuário chega ao
produto?
Ação (action) - qual é a coisa mais simples que o usuário
precisa fazer no seu produto para ser recompensado?
Recompensa (reward) - como essa recompensa provê um
senso de complitude (fullfilment) e faça com que ele invista
mais tempo no seu produto.
Investimento (investment) - quais as próximas pequenas
ações que o usuário precisa fazer que vão levar ele a novos
gatilhos e retornar ao produto?
Fonte: The Hook Canvas - Nir Eyals

25. Validando hipóteses
Cada ideia que a gente tem, cada hipótese
testada tem o custo da oportunidade.
Quando a gente escolhe fazer A no lugar de
B, significa que acreditamos que A está
atendendo todas as necessidades imediatas
de negócio e dos clientes.
O jeito correto de validar uma hipótese
depende de cada situação em que ele está.

26. E como validamos?
Análise SWOT
Forças
Fraquezas
Oportunidades
Ameaças

27. E como validamos?
Validação interna
A oportunidade está em linha com a visão que foi montada para o produto?
Ele ajuda nas funções core do produto?
Funciona bem com nossa capacidade? (Ou pelo menos é factível com nossa expansão ou para encontrar
outras oportunidades?
Ela contribui com nossa métricas chave?
Temos dados suficientes (seja de analytics, surveys, bug reports) para ajudar nessa oportunidade?
Ela requer termos uma iniciativa crítica de negócios?
Ela contribui para o sucesso dos usuários?
Está em nosso roadmap, ou objetivos, mesmo que indiretamente?
Ela vai importar em dois anos? (para entender a priorização)
Todo mundo ganha? É para um nicho que o custo valha a pena?
Se funcionar, a gente dá conta?

28. E como validamos?
Contexto
No fim das contas, o que interessa é o usuário usar o produto, que ele ganhe com
isso. Por isso devemos entender os usuários e para isso precisamos tomar boas
decisões de produto.
No fim das contas, o que interessa é o usuário usar o produto, que ele ganhe com
isso. Por isso devemos entender os usuários e para isso precisamos tomar boas
decisões de produto.

29. E como validamos?

30. E como validamos?
Surveys - tentar entender através do ponto de vista da satisfação do usuário em
diversos pontos da cadeia de uso, dentro da sua própria base.
Entrevistas com os usuários - testar novas features, entender o que se passa na
cabeça do usuário. É importante que elas não sejam a base das primeiras
hipóteses porque tudo pode ser muito vago e a gente acabe tendenciando para
uma necessidade específica, não para o market fit.
Construção de personas/patronos - conhecer o público-alvo, suas necessidades,
impedimentos e principalmente suas motivações.

31. E como validamos?
Validações externas
A ideia é evitar viéses.
Customer Development - construa seu produto junto com o seu público-alvo.
Tenha no seu time pessoas de CS para te ajudarem a entender o que você não vê.
Entrevistas - toda a iteração com os produtos precisa de entrevistas com
usuários. Saber dores e o que ele gosta. Mas saber de verdade. As entrevistas
deixam o PM pronto para os trade-offs

32. E como validamos?
Experimentos
É preciso ter espaço, dentro da estratégia de produto, para as experimentações.
Elas ajudam a definir estratégias, pivotamentos, decisões simples e completas da
cadeia de desenvolvimento de produto.
Protótipos - testar ideias com prototipos de baixa/média fidelidade,
principalmente para validar ideias.
Testes A/B - principalmente para testar qual ideia pode ser mais interessante
para um grupo de usuários.

33. E como validamos?
MVP
Minimal Viable Product (Mínimo produto viável) - É a menor solução que permita
testar suas hipóteses e que ainda assim entregue valor aos usuários.

34. Atividade
Baseados no que vocês viram, façam uma análise swot das entregas que vocês
planejaram até o momento nas ondas.

35. Entendendo produtos
MVP

36. Entendendo produtos
MVP

37. Entendendo produtos
MVP

38. Entendendo produtos
Tipos de MVP
Smoke tests - mostre que seu produto existe. Um mockup em uma plataforma digital que tenha uma
interação mínima.
Release 1.0 - início do código, set mínimo de features, lançamentos frequentes, fazer coisas
manualmente, automatizar depois.
Concierge MVP - sair do convencional e resolver os primeiros problemas.
Não é um MVP - entrevistas com usuários, protótipos ou páginas “em breve” porque eles não trazem
valor para o cliente.

39. Entendendo produtos
MLP - Construir uma versão de produto que traga algo que os usuários amem.
Fonte:
https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c

40. Entendendo produtos
Fonte:
https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c

41. Entendendo produtos
Fonte:
https://medium.com/the-happy-startup-school/beyond-mvp-10-steps-to-make-your-product-minimum-loveable-51800164ae0c

42. Atividade
Ajustem as ondas para a entrega de um MLP.

43. Entendendo produtos
Conhecer bugs e features
Toda interação de um usuário com nosso produto mostra nossos erros e acertos relacionados as
escolhas que fazemos relacionadas à priorização.
Essas interações mostram também como podemos escolher as novas funcionalidades que podemos
incluir no nosso backlog e que podem se tornar a base de novas hipóteses.
Os bugs são um problema porque bloqueiam o usuário de ter sucesso em alguma jornada proposta
dentro de um produto. Apesar de todo o trabalho que temos para priorizar, entender e todas as entregas
de negócios que temos para fazer, o bug é prioritário em termos de desenvolvimento.

44. Atividade
Temos 3 bugs, um de alta, um de média e um de baixa complexidade.
Sem aumentar o número de ondas (as cinco possíveis entregas que trabalhamos
até agora), coloque os 3 bugs na sua priorização.
Lembrem-se:
- Bugs são prioritários, não podem estar na última onda
- Vocês só podem ter uma onda com 4 entregáveis
- O bug de alta complexidade só comporta uma entrega junto com ele

45. Entendendo produtos
Ideias do time

46. Entendendo
produtos
Canvas BMP
Fonte: https://www.businessmodelsinc.com/about-bmi/tools/business-model-canvas/

47. Entendendo produtos
Value
Model
Canvas

48. Entendendo produtos
PMM
Conta Azul

49. Entendendo produtos
Kano model
Basic features. O que o consumidor espera
do produto.
Performance features (satisfers). São as
features que os usuários olham antes de
comprar. Um diferencial competitivo na
satisfação do básico.
Excitement features (delighters).Features
Wow.

50. Atividade
Coloque suas funcionalidades dentro de um Kano Model e veja o quanto você
está entregando para os seus usuários.

51. Do papel pro mercado
Trabalhar com novas ideias
O papel de PM inclui antecipar quaisquer riscos relacionados ao produto. Uma
das principais razões para os produtos sofrerem na sua escalada não é, no geral,
técnica.
Geralmente esses problemas vão estar relacionados aos clientes não precisarem
do produto, a estratégia não ajudar a atingir o product market fit.

52. Do papel pro mercado
Trabalhar com novas ideias

53. Do papel pro mercado
Trabalhar hoje para o futuro
Fazer um release do produto - Montar como seria um product press release da
sua entrega. Você precisa pontuar o que vai entregar, para quem e como vai
funcionar de uma maneira que venda o seu produto. Ou um review para uma loja
de apps.
Fazer a escolha correta do MVP - entender a partir do que você vai entregar
como vai ser o comportamento dela dentro do mercado. Entender,
principalmente, os riscos.

54. Do papel pro mercado
Problem space x solution space
Fonte: The Lean Product Playbook

55. Do papel pro mercado
Cenários de usuários - escrever possíveis cenários de uso do produto para
validação.
Requisitos/ Features In-Out - Faz parte da lista do seu MVP, fica mais fácil de
visualizar cada um dos requisitos em termos de cenários, personas, adoção, uso
e retenção.
Design - até um sketch de uma possível solução que possa validar ou até
invalidar suas premissas.
Perguntas e Q&A - estar preparado para o que o mercado (usuários e outros
competidores podem perguntar/entender/não entender do seu produto.

56. Atividade
Faça um press release da sua primeira onda.
Lembre-se:
- Oprah speech
- Se tiver conserto de bugs, você pode e deve evidenciar
- É um press release para o Twitter então, no máximo 240 caracteres.

57. Trabalho em conjunto com o design
UX
Em termos muito simples, em termos de Gestão de Produtos, UX é como nós
interagimos e engajamos consumidores com o produto.
Porque fazer produtos é fundamentalmente sobre fazer novas experiências ou
fazer uma experiência que já existe melhor.

58. Trabalho em conjunto com o design
PM/PO x Designers
Um PM tem muitas responsabilidades e quase nenhum poder. Ele vai ajudar a
estabelecer quais as políticas de desenvolvimento de produto, ajudar a escolher
as metas, entender e trazer para o sistema, todo o contexto de negócios. Já o UX
tem a responsabilidade de ajudar o PM com as recomendações para que ele
possa tomar as decisões e planejar as melhores metas e entregas.

59. E como ele ajuda?
O processo de design em um contexto de produto
1. User research
2. Information architecture
3. Interaction design
4. Prototyping
5. Visual design
6. Content strategy

60. Validando feedbacks de design
As pessoas na empresa, o time e os clientes (na sua escala, claro) esperam que o
PM dê bons feedbacks das ajudas que ele recebe. Como a gente ajuda o nosso
PM nisso?
A gente estrutura como ele pode dar os feedbacks. Uma sugestão: os princípios
do bom design do Dieter Rams

61. Validando feedbacks de design
Good design is innovative. Inovação tecnológica é criar oportunidades de fazer novos e inovativos
projetos.
Good design is aesthetic. Não é sobre beleza, apesar de ser bonito.
Good design makes a product understandable. Um bom design pode ajudar no
entendimento/uso/engajamento do usuário ao produto.
Good design is unobtrusive. Produtos ajudam um usuário a se sentir ótimo porque ele atinge um
objetivo. Design é neutro e mantém o foco.
Good design is honest. Um bom design não ilude o usuário.
Good design is long-lasting. O bom design é atemporal.
Good design is thorough down to the last detail. Só quando todos os detalhes são pensados, é
possível uma real boa interação.
Good design is as little design as possible. Depois que está tudo pronto, o que se pode eliminar sem
que a essência se perca?

62. Como trabalha um PM
Dual Track

63. Como trabalha um PM
Discovery - Google Design Sprints

64. Como trabalha um PM
Delivery: Inceptions

65. Trabalhando com a engenharia
Se a gente entende que design é mais que pixel, a gente entende também que
engenharia é mais que código. A construção de um produto é algo coletivo e a
engenharia faz muito parte dessa coletividade.
Um PM precisa ser técnico?
Um PM que não faz código é respeitado?
Uma PM consegue manter o time coeso e buscando o melhor para o
produto?

66. Trabalhando com a engenharia
Metodologias de
Desenvolvimento:: Waterfall

67. Trabalhando com a engenharia
Metodologias de desenvolvimento - Scrum

68. Trabalhando com a engenharia
Metodologias de desenvolvimento - Kanban

69. Trabalhando com a engenharia
Waterfall x Agil

70. Trabalhando com a engenharia
Metodologias de desenvolvimento - Lean

71. Atividade
Revisem as dependências das features de vocês e rearrangem as ondas,
pensando em uma entrega baseada em desenvolvimento ágil.

72. Produto e mercado
Planejamento de lançamento
Planejamento de pré-lançamento: metas para o lançamento, entendimento da maturidade do produto
para isso.
Objetivos de lançamento - propósitos de lançamento: upgrade de produto, nova feature, etc.
Timing de lançamento: Produto está pronto? Testado e entendido? O mercado está no timing correto?
(evitar o MAYA)
Teste - planejar junto aos reais usuários o lançamento para que se possa ter e entender as métricas.

73. Produto e mercado
Usando framework de marketing

74. Produto e mercado
O ciclo de vida do usuário

75. Entregando o produto para o mercado
Roadmap Um roadmap é um statement de intenção.
É a direção de construção de uma estratégia

76. Entregando o produto para o mercado
Os objetivos que se quer alcançar:
Ex.: Redução de bugs + Eficiência
Operacional
As métricas que vão provar que
seu objetivos for alcançado:
Ex.: Redução de 35% de bugs
Tema: Entender, a partir dos chamados recebidos e das
justificativas de notas do NPS como melhorar e nos anteciparmos
sobre futuros erros da plataforma.

77. Entregando o produto para o mercado
Backlog

78. Entregando o produto para o mercado
Backlog

79. Sugestão de leitura

80. Dúvidas? Sugestões?
Muito Obrigada!
https://www.linkedin.com/in/eluzapinheiro/