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

Priorizando o aprendizado no desenvolvimento de produtos

Minha 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

MARCOS GARRIDO

@marcosgarrido

Criar produtos de sucesso é um enorme desafio.

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!

Mas e quando tudo parece bem?

Ter 2 milhões de usuários é sinal de sucesso? Poderíamos ter conseguido um resultado melhor?

Pensando no desenvolvimento de produtos...

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...)

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)

O que os 2 exemplos têm em comum:

Backlog = lista de requisitos

Mas se o produto a ser

desenvolvido é recheado de incertezas...

...como o Product Owner pode

saber se está tomando as melhores decisões de produto?

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.”

Requisitos x Hipóteses

Certezas

Dúvidas

HipóteseÉ uma tentativa de explicar como as coisas

funcionam, que precisa ser validada.

RequisitoConstruir 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

Customer Development

Testando as primeiras hipótesesAlto risco para o projeto

Baixo conhecimentosobre o assunto

Alto conhecimentosobre o assunto

Baixo risco para o projeto

1 2

3 4

by Joshua Seiden

Lembre-se:

O foco é no aprendizado!

‣ 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”

Minimum Viable Product

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

Feature Fake

Feature Fake

Para que tudo isso dê certo, o Product Owner precisa

conhecer intimamente todas as métricas do produto!

Métricas!

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

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.

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.

Construa um Dashboard!

Várias hipóteses testadas e 2 meses depois: Agora sim!!!!!

Dashboards precisam estar visíveis o tempo todo

A/B testing

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;

usabilityhub.com

optimizely.com

Mas eu não sou um Startup!

Posso trabalhar com hipóteses mesmo assim?

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?

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!

Exemplo / Case

Seus amigos no G1• O widget ao lado mostra as matérias mais l idas 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.

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

Hipótese 1: Resultado

46%nos clicks ao mostrar 5 matérias

Aumento de

Hipótese 2: O título faz diferença?‣ Nós acreditamos que

um título mais chamativo r e su l t a r i a em ma i s cliques.

X

Hipótese 2: Resultado

19%nos clicks com o título mais chamativo

Aumento de

Resultado Final após 2 hipóteses

74%no CTR da página.

Aumento de

Agora sim: O maior CTR do produto!

A hipótese falsa tambémgera aprendizado

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.