Mindset de entrega vs Mindset de
resultado
04/07/2019

Mini Currículo:
Graduado em Ciência da Computação e Product Manager com foco em
startups de rápido crescimento. Já fundou sua própria startup fintech e
agora lidera o Product Lab da Catho/Seek, um laboratório de inovação.
Life Achievements:
● Vendeu um site quando tinha 14 anos
● Gosta de fazer Kitesurfing
● Já perdeu um carro na bolsa de valores em 2013
@almeidamarcell

Ideia
Construir
Produto
Feedback do usuário???

Ideia
Construir
Produto
Feedback???
Como você vai saber
que está fazendo a
coisa certa?

Necessidades
do usuário
Objetivos de
negócio
Custo de
implementação

9 m
PARALISIA

DISCUSSÕES EM GRUPO

Paradoxo de Abilene
O paradoxo de Abilene
se refere a uma situação
em que um grupo toma
uma decisão coletiva
que é contrária aos
pensamentos e
sentimentos de cada um
individualmente.

AGENDA
2. Product
Discovery
1. Mais é
menos
3. Criando
hipóteses

Outcome ou
Output driven?

Empresas normalmente cometem um
erro de querer "se provar" com
funcionalidades.
ERRO COMUM:
QUERER SE PROVAR

É intuitivo pensar que criar um produto
que resolva uma série de problemas vai
aumentar o valor da startup e a chance
de vender o produto ou adquirir
usuários.
ERRO COMUM:
INTUIÇÃO LEVANDO AO ERRO

○ Fácil de explicar/vender
○ Fácil de manusear
○ Faz 1 coisa com excelência
○ Rápido de criar e testar

○
○
○
○
○
○
Tesoura vs. Canivete Suiço
○ Difícil de explicar/vender
○ Díficil adesão
○ Não faz nada bem
○ Demorado para criar e testar
○ Fácil de explicar/vender
○ Fácil de manusear
○ Faz 1 coisa de com
excelência
○ Rápido de criar e testar

Um sistema complexo que funciona é
invariavelmente a evolução de um sistema
simples que funciona.
Um sistema complexo projetado a partir do
zero nunca funciona e não pode ser
consertado. Você tem que começar partindo
de um sistema simples
Lei de Gall

O QUE PENSAR ANTES DE CRIAR
NOVAS FUNCIONALIDADES?
○ Está dentro da sua visão?
○ Vai fazer sentido em 5 anos?
○ Beneficia todos os usuários?
○ Qual o objetivo?
○ Se for um sucesso, nós vamos
conseguir dar suporte?
Regra de bolso

SER BOM NO QUE IMPORTA

Empresas não fracassam porque
elas não trabalharam 10% mais.
Elas falham porque elas
trabalharam nas coisas erradas.
- Paul Buchheit, Y Combinator

AGENDA
2. Product
Discovery
1. Mais é
menos
3. Criando
hipóteses

Product
Discovery
Product
Delivery
Decidir o que construir Construir
Annual Releases
Quarterly Releases
Monthly Releases
Weekly Releases
Daily Releases
Roadmap
Blablabla….
?

Quanto tempo
vocês acham que
precisa durar o
discovery?
6 meses? 3 meses? 1 mes? 2
semanas? Quanto?

A verdade:
A maioria das funcionalidades que nós construímos
na indústria do software é pouco ou nunca utilizada

A etapa de discovery é onde PM e UX devem passar a maior parte do seu
tempo
DISCOVERY
DELIVERY
OBJETIVOS PM UX TECH
80-90%
DO TEMPO
80-90%
DO TEMPO
10-20%
DO TEMPO
10-20%
DO TEMPO

PM e UX são pares
PM UX
Product designers e product managers devem ser BFF:
são uma dupla que trabalha a maior parte do tempo junta
durante o discovery, orientados aos usuários finais e ao valor
que o produto traz a esses usuários

Product Discovery
1.Quando fazer
2.O que fazer
3.Com quem fazer
4.Como fazer

Quando fazer

PERFORMANCE
Maturidade
Descontinuidade
Escala
Early stage
TEMPO

PERFORMANCE
TEMPO

PERFORMANCE
TEMPO
PRECISA DE
PRODUCT
DISCOVERY

Product Discovery: Quando fazer
VISÃO DE PRODUTO /
ESTRATÉGIA
DESIGN &
IMPLEMENTAÇÃO
DISCOVERY
ROADMAP

“Gerentes de produto precisam equilibrar duas
coisas:
1) encontrar continuamente melhorias que
beneficiem os clientes/usuários e;
2) garantir que tais melhorias identificadas não
fiquem perdidas em algum backlog ou post-it.

O que fazer

Product Discovery =
Identificação do problema e
experimentação com
possíveis soluções

Entendemos a
necessidade do negócio?
Entendemos a
necessidade do usuário?
Entendemos o que tem
que ser feito?
Sabemos como fazer?
Sabemos o que fazer
primeiro?
Quantas suposições
estamos fazendo?

Entendemos a
necessidade do negócio?
Entendemos a
necessidade do usuário?
Entendemos o que tem
que ser feito?
Sabemos como fazer?
Sabemos o que fazer
primeiro?
Quantas suposições
estamos fazendo?
MENTE QUESTIONADORA

Ferramentas de Delivery e Discovery
Ferramentas de discovery
Ferramentas de delivery

Ferramentas de Delivery e Discovery
Ferramentas de discovery
Ferramentas de delivery

Ferramentas de Delivery e Discovery
Ferramentas de discovery
Ferramentas de delivery
Nem todo discovery é power point
e delivery nem sempre é código.
Você também pode fazer
discovery com código

Mapa VivaReal (apenas interno)

Com quem fazer

Tomadores
de decisão
Usuários/Clientes Stakeholders
Product Discovery: Com quem fazer

● Workshop de engajamento
● Fluxo de engajamento
● Experimentos de engajamento
O que rolou?
- Insumos de Pesquisa
Como nós podemos ( baseado nas dores)
- Diagrama de estratégia
- Matriz DEP (desafio, entrega e premissa)
- Ideação (Crazy 8's)
- Prototipação
- Criar experimentos para o próximo ciclo
Dinâmicas com clientes/usuários - Exemplo Catho Lab

Como fazer

Dinâmicas com clientes/usuários - Mapa VivaReal

Dinâmicas com clientes/usuários - Mapa VivaReal

“
Foque na validação do problema e não
na construção da solução

Reunir as pessoas certas para concordar
com o problema certo para resolver
1
Um resumo Certifique-se de que está validado por
clientes e dados
2
3 Constantemente reforce o problema
conforme você avança para o design e
implementação. Mantendo todos da sua
equipe sempre alinhados

AGENDA
2. Product
Discovery
1. Mais é
menos
3. Criando
hipóteses

Resultado
esperado
Oportunidade Oportunidade OportunidadeTemas /
Hipóteses
Objetivo
Experiment
SoluçãoSoluçãoFuncionalidades
Experimento Experimento
Como ser outcome driven

Manter a
tripulação
saudável
Návio limpo
Alimentação
saudável
Exercício
regulares
Temas /
Hipóteses
Objetivo
ArrozFrutasFuncionalidades
Maçãs Laranjas
Como ser outcome driven

Hipóteses
Necessidades
ou problemas
Soluções
Manter a tripulação
saudável
Fazendo com que
eles comam de
maneira saudável
Ter frutas, em
especial laranja,
disponíveis no návio
Como ser outcome driven

"Se [variável], então [resultado], porque [racional]."
Formule uma hipótese

● O elemento que vai ser
modificado
● Isole uma variável para o
A/B test
● Pense no Call to action,
visual ou formulário
"Se [variável], então [resultado], porque [racional]."
Formule uma hipótese

● Preveja o resultado
● Use dados para determinar
o efeito dele
● Mais e-mails? Mais
signups? Mais CTA? Mais
conversão?
"Se [variável], então [resultado], porque [racional]."
Formule uma hipótese

● Demonstre o quanto você
conhece os seus usuários
● O que vai estar provado
ser incorreto caso o
experimento seja igual ou
inferior ao atual?
"Se [variável], então [resultado], porque [racional]."
Formule uma hipótese

"Se as imagens chamarem mais atenção, então a
taxa de clique vai aumentar, porque sabemos que
as imagens são um dos fatores mais importantes
para quem busca um imóvel."
Formule uma hipótese

Hipótese forte
Se o funil de compra tiver menos
páginas, vamos aumentar a
conversão de compra da loja
Se a navegação for removida das
páginas de checkout, a taxa de
conversão em cada passo vai
aumentar porque o analytics do site
mostra que uma porção desses
usuários está deixando a página
antes de clicar no link dessas
páginas
Hipótese fraca
Hipóteses não devem ser genéricas

Validar solução
O suficiente para
entender se a solução
proposta resolve o
problema.
Você deveria querer
validar uma solução
antes de gastar tempo e
dinheiro na
implementação.

Priorização das hipóteses

ANTES
UM RECADO
DE TERMINAR

● Curso online com PMs de
várias empresas
● Site: cursospm3.com.br
● Cupom: Pstarter (Link)

Marcell Almeida{ Redes sociais: @almeidamarcell
Slides + planilha:
almeidamarcell+pstarter@gmail.com
Obrigado!