Gestão Ágil de Produtos com Lean Startup para times Scrum

1,510 views

Published on

Aprenda a usar os conceitos de Lean Startup para incrementar o desenvolvimento de produtos a partir do uso de hipóteses e métricas.

Published in: Business
  • Be the first to comment

Gestão Ágil de Produtos com Lean Startup para times Scrum

  1. 1. Priorizando o aprendizado nodesenvolvimento de produtos
  2. 2. MARCOS GARRIDOMinha formação...1994 - Tecnologia da Informação - PUC-RIO2006 - MBA Management - IAG PUC-RIO2009 - Mestrado em Administração - IAG PUC-RIOMinha carreira...1996 a 2007 - Trabalhando em TI (Dev)2007 a 2009 - TecGraf - PUC-RIO2010 - 2013 - Globo.com2012 - Prof. Métodos Ágeis - MBA GP - PUC-RIO2013 - Startup7 @marcosgarrido
  3. 3. Criar produtos de sucesso é um enorme desafio.
  4. 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. 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. 6. Pensando no desenvolvimento de produtos...
  7. 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. 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. 9. O que os 2 exemplos têm em comum:Backlog = lista de requisitos
  10. 10. Mas se o produto a serdesenvolvido é recheado de incertezas...
  11. 11. ...como o Product Owner pode saber se está tomando asmelhores decisões de produto?
  12. 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. 13. DúvidasRequisitos x HipótesesCertezas
  14. 14. HipóteseÉ uma tentativa de explicar como as coisas funcionam, que precisa ser validada.
  15. 15. Requisito Construir um widget de matérias mais compartilhadas HipóteseAcreditamos que um widget de matérias mais compartilhadas conseguirá mais cliques do que o widget atual
  16. 16. Customer Development
  17. 17. Testando as primeiras hipóteses Alto risco para o projeto 1 2Alto conhecimento Baixo conhecimento sobre o assunto sobre o assunto 3 4 Baixo risco para o projeto by Joshua Seiden
  18. 18. Lembre-se:O foco é no aprendizado!
  19. 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. 20. Existem várias formas dedescobrir rapidamente o que os clientes querem, sem ter que investir todas as fichas.
  21. 21. Feature Fake
  22. 22. Feature Fake
  23. 23. Para que tudo isso dê certo, o Product Owner precisa conhecer intimamente todas as métricas do produto!
  24. 24. Métricas!Pesquisa rápida: Quem aqui usa métricas para aprender mais sobre o uso de cada feature desenvolvida?
  25. 25. 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.
  26. 26. Construa um Dashboard!Dashboard do aplicativo social “Seus amigos no G1” mostrando a distribuiçãodos usuários pela quantidade de amigos. Dados do primeiro mês da app no ar.
  27. 27. Construa um Dashboard! Várias hipóteses testadas e 2 meses depois: Agora sim!!!!!
  28. 28. Dashboards precisam estar visíveis o tempo todo
  29. 29. A/B testing
  30. 30. 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;
  31. 31. usabilityhub.com
  32. 32. optimizely.com
  33. 33. Mas eu não sou um Startup!Posso trabalhar com hipóteses mesmo assim?
  34. 34. 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?
  35. 35. 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!
  36. 36. Exemplo / Case
  37. 37. Seus amigos no G1• O widget ao lado mostra as matériasmais lidas pelos seus amigos doFacebook;• A expectativa é que esse widget tenha omaior CTR da página;• A primeira versão não chegou nem pertodisso.
  38. 38. 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
  39. 39. Hipótese 1: Resultado Aumento de 46% nos clicks ao mostrar 5 matérias
  40. 40. Hipótese 2: O título faz diferença?‣ Nós acreditamos que um título mais chamativo resultaria em mais cliques. X
  41. 41. Hipótese 2: Resultado Aumento de 19% nos clicks com o título mais chamativo
  42. 42. Resultado Final após 2 hipóteses Aumento de 74% no CTR da página. Agora sim: O maior CTR do produto!
  43. 43. A hipótese falsa também gera aprendizado
  44. 44. 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.

×