O documento discute a importância de validar hipóteses sobre o produto por meio de testes e métricas, em vez de depender apenas de requisitos, para garantir o aprendizado e o sucesso do produto. Ele enfatiza técnicas como o Minimum Viable Product, A/B testing e o uso de métricas para orientar o desenvolvimento iterativo do produto.

1. Priorizando o aprendizado no
desenvolvimento de produtos

2. MARCOS GARRIDO
Minha formação...
1994 - Tecnologia da Informação - PUC-RIO
2006 - MBA Management - IAG PUC-RIO
2009 - Mestrado em Administração - IAG PUC-RIO
Minha carreira...
1996 a 2007 - Trabalhando em TI (Dev)
2007 a 2009 - TecGraf - PUC-RIO
2010 - 2013 - Globo.com
2012 - Prof. Métodos Ágeis - MBA GP - PUC-RIO
2013 - Startup7
@marcosgarrido

3. Criar produtos de sucesso é
um enorme desafio.

4. Identificar o fracasso
pode ser fácil!
Um site com zero usuários é um desastre total!
Uma Page no Facebook vazia também é um desastre total!

5. Mas e quando tudo parece bem?
Ter 2 milhões de usuários é sinal de sucesso?
Poderíamos ter conseguido um resultado melhor?

6. Pensando no desenvolvimento de
produtos...

7. Usando o processo tradicional
‣ Gerente de projetos levanta requisitos com o cliente, avalia riscos e
estima a duração e custo do projeto;
‣ A equipe toca o projeto e o cliente recebe aquilo que contratou (se
tiver sorte...)

8. Usando o processo ágil
‣ Product Owner monta o backlog inicial com o cliente;
‣ O Time desenvolve o produto de forma iterativa e incremental;
‣ O Time faz releases frequentes e o Product Owner usa o feedback do
cliente como insumo para manter o backlog atualizado (grooming,
repriorização, etc)

9. O que os 2 exemplos
têm em comum:
Backlog = lista de requisitos

10. Mas se o produto a ser
desenvolvido é recheado de
incertezas...

11. ...como o Product Owner pode
saber se está tomando as
melhores decisões de produto?

12. Agindo como uma Startup
“O objetivo de uma startup é
descobrir a coisa certa a ser construída, sabendo o
que os clientes querem, o mais rápido possível.”

13. Dúvidas
Requisitos x Hipóteses
Certezas

14. Hipótese
É uma tentativa de explicar como as coisas
funcionam, que precisa ser validada.

15. Requisito
Construir um widget de matérias mais compartilhadas
Hipótese
Acreditamos que um widget de matérias mais compartilhadas
conseguirá mais cliques do que o widget atual

16. Customer Development

17. Testando as primeiras hipóteses
Alto risco para o projeto
1 2
Alto conhecimento Baixo conhecimento
sobre o assunto sobre o assunto
3 4
Baixo risco para o projeto by Joshua Seiden

18. Lembre-se:
O foco é no aprendizado!

19. Minimum Viable Product
‣ O conjunto mínimo de features necessários para aprender com
early adopters:
‣ Obter feedback o quanto antes;
‣ Evitar construir algo que ninguém irá usar;
‣ Conjunto mínimo de usuários (menor risco);
‣ “Maximizar o aprendizado por dólar gasto”

20. Existem várias formas de
descobrir rapidamente o que
os clientes querem, sem ter
que investir todas as fichas.

21. Feature Fake

22. Feature Fake

24. Para que tudo isso dê certo, o
Product Owner precisa
conhecer intimamente todas
as métricas do produto!

25. Métricas!
Pesquisa rápida: Quem aqui usa métricas para aprender
mais sobre o uso de cada feature desenvolvida?

26. Sem métricas, tudo é chute...
‣ Sair de 50k impressões no FB para 4m+ em um dia e voltar como se
nada tivesse acontecido;
‣ Até hoje, não sei o que aconteceu e nunca conseguimos repetir esse
resultado.

27. Construa um Dashboard!
Dashboard do aplicativo social “Seus amigos no G1” mostrando a distribuição
dos usuários pela quantidade de amigos. Dados do primeiro mês da app no ar.

28. Construa um Dashboard!
Várias hipóteses testadas e 2 meses depois: Agora sim!!!!!

29. Dashboards precisam estar visíveis o tempo todo

30. A/B testing

31. Facebook: testando novidades
‣ Toda nova feature no Facebook é disponibilizada primeiro
internamente, para todos os funcionários;
‣ Se passar no teste inicial, a feature está pronta para os primeiros
testes externos;
‣ Cada time no Facebook lança novas features em uma cidade
americana diferente;
‣ Assim é possível medir o impacto de uma mudança sem afetar
todos os usuários;

32. usabilityhub.com

33. optimizely.com

34. Mas eu não sou um Startup!
Posso trabalhar com hipóteses
mesmo assim?

35. Revisitando features entregues
‣ Fugindo da expressão “Missão dada é missão cumprida”;
‣ Existem tantas variáveis que determinam o real sucesso de um
produto:
‣ Entendimento do usuário sobre o funcionamento do produto;
‣ Design adequado / fluxos bem fechados;
‣ Comportamentos não previstos dos usuários;
‣ Como podemos tirar o máximo de cada entrega?

36. Revisitando features entregues
‣ Defina um objetivo (de preferência numérico) para o resultado de
uma feature;
‣ Defina hipóteses para alcançar o objetivo proposto;
‣ Crie histórias para cada hipótese levantada;
‣ Implemente, use métricas e aprenda!

37. Exemplo / Case

38. Seus amigos no G1
• O widget ao lado mostra as matérias
mais lidas pelos seus amigos do
Facebook;
• A expectativa é que esse widget tenha o
maior CTR da página;
• A primeira versão não chegou nem perto
disso.

39. Hipótese 1: Mostrando mais matérias
‣ Nós acreditamos que os usuários consumiriam
mais matérias se fossem mostradas 5 matérias
ao invés de 3.
X

40. Hipótese 1: Resultado
Aumento de
46%
nos clicks ao mostrar 5 matérias

41. Hipótese 2: O título faz diferença?
‣ Nós acreditamos que
um título mais chamativo
resultaria em mais
cliques.
X

42. Hipótese 2: Resultado
Aumento de
19%
nos clicks com o título mais chamativo

43. Resultado Final após 2 hipóteses
Aumento de
74%
no CTR da página.
Agora sim: O maior CTR do produto!

44. A hipótese falsa também
gera aprendizado

45. Para pensar...
Investimos muito tempo para que os times
sejam cada vez mais produtivos,
mas nada é mais improdutivo do que
construir algo que ninguém vai usar.