Product Discovery ou Descoberta do Produto
Após eu ter participado do POs on Beer, realizado pela empresa Concrete Rio, um evento voltado a compartilhar conhecimento sobre produto, fiquei bem entusiasmada com as técnicas apresentadas sobre Product Discovery ou Descoberta do Produto pela Palestrante Andressa Chiara.
Dessa forma, eu resolvi escrever para transmitir um pouquinho do que eu ouvi por lá. Enfim, para aqueles que desejam trilhar o caminho profissional como PO, eu acredito que esse artigo vai ser bem bacana!!
Primeiramente, eu vou nivelar alguns conceitos para alcançar a diversidade de público que possa vir a ler esse artigo.
Definição de Product Owner:
De antemão, é um dos os três papéis que constituem uma Equipe Scrum clássica.
Para galera de Ágil, não é novidade que o papel do PO ou Product Owner (Dono do Produto), é saber os problemas e necessidades dos clientes, idealizar um MVP (Mínimo Produto viável) para então poder definir os itens que compõem o Product Backlog e os priorizar nas Sprint.
Mas como? Pera aí que eu já vou contar o que eu aprendi no evento.
Definição da Gestão Ágil:
Antes de mais nada, o ágil é uma abordagem leve e de mínima intervenção para o gerenciamento de projetos. Ou seja, o projeto é todo dividido em etapas menores, chamadas de iteração, que geralmente duram de 2 a 4 semanas.
Assim, ao final de cada etapa há uma reavaliação das prioridades do projeto. Enfim, é um possível replanejamento da etapa que virá em sequência.
Assim, o conceito de Gestão Ágil, surgiu em paralelo ao crescimento do setor de Tecnologia da Informação. Devido as crescentes pressões do mercado por inovação, produtividade e mais qualidade dos produtos (softwares), perceberam a necessidade de uma melhoria nas técnicas de desenvolvimento de software, onde o foco principal é a satisfação do cliente.
Enfim, para gerir de forma ágil projetos de Softwares, o framework mais usado e conhecido se chama Scrum.
Definição de MVP:
É um processo de validação de hipóteses, e não um produto final e estático.
- Minimum: o menor tamanho possível, que possa ser entregue no menor tempo possível.
- Viable: uma proposição de valor importante o suficiente para que seu principal cliente adote esse produto, se possível gerando receita.
- Product: funcionalidades encaixadas em uma entrega que se assemelhe a um produto coeso e útil.
Agora vamos aquela pergunta: Como o Product Owner identifica as necessidades do cliente e idealiza o MVP a fim de definir o Backlog do produto e posteriormente os Backlogs das Sprint?
Temos duas formas diferentes de processos para um Product Discovery:
Incremental e Iterativo
No primeiro já temos melhor definido o que queremos, ou achamos que queremos.
Já no segundo, temos apenas uma ideia genérica do que queremos, temos apenas uma vaga ideia (hipótese), e iremos descobrir mais detalhes do que queremos, ao longo do desenvolvimento. Em suma, o processo Interativo utiliza o framework Scrum.
Figura 1 – Incremental x Iterativo – Fonte da imagem: https://qualidadebr.wordpress.com/2010/11/22/processo-incremental-x-iterativo
Primeiramente, fomos apresentados as palavras do Jeff Gothelf: “toda solução de Design é uma hipótese”. Logo depois, vimos o Método Lean de Pesquisa, conforme imagem Figura 2 abaixo:
Figura 2 – Ciclo Build – Measure – Learn. – Fonte da imagem: https://www.slideshare.net/ConcreteS/pos-on-beer-rj-7973062
Método Lean de Pesquisa
Definitivamente, a idéia do método é utilizar o ciclo Build – Measure – Learn (Construir – Medir – Aprender) para desenvolvimento ágil de um MVP através da interação com os usuários para testar diferentes hipóteses de produto.
Desde já, o ciclo de descoberta é o processo de captura, pesquisa e priorização ativas das necessidades dos usuários. Além de coletar e validar idéias de solução para abordá-las.
Assim, com uma compreensão clara da necessidade do usuário, pode-se elaborar protótipos baratos e validar sua compreensão de soluções ótimas, para problemas urgentes.
De antemão, faça qualquer coisa que possa ajudá-lo a obter o feedback com a mais alta qualidade, e com o menor esforço possível. Por exemplo: protótipos de papel, esboços ou recursos propostos delineados em um documento.
Resumindo:
Em conclusão, junta-se os stakeholders e o time numa sala de guerra, e através das técnicas de consenso, se faz a validação de hipóteses com os clientes. Os feedbacks dos clientes servem para adquirir aprendizado e, então, decidir o que se deve construir e o que não deve construir.
Logo depois, utiliza-se as técnicas de priorização para definir o backlog do produto e das sprint.
Em suma, a idéia é que o product Discovery precisa ser colaborativa. É responsabilidade de todos (time de desenvolvimento, cliente e, se possível, usuários e patrocinadores) participar do processo.
Enfim, o nível de interação entre as pessoas é muito grande, e muitas relações são formadas ou fortalecidas, o que aumenta radicalmente as chances de sucesso do projeto.
Em síntese, a lição aprendida lá no evento, é que, no início do projeto para o Product Discovery leva-se de 2 a 3 dias para as técnicas de consenso e priorização.
A partir da execução do projeto, nas reuniões de Refining, leva-se 1 hora por semana para ideação e priorização, ou seja, identificar o que se deve mudar ou aprimorar.
Seguem Técnicas de consenso que foram apresentadas:
1. Painel CSD (Certezas Dúvidas e Suposições)
Figura 4 -É / Não é / Faz / Não faz – Fonte da imagem: https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623
Logo depois, a técnica É-NãoÉ-Faz-NãoFaz ajuda a definir um produto. Por vezes, é mais fácil descrever algo pelo que tal coisa não é ou deixa de fazer.
Em síntese, essa atividade busca clarificações desta forma. Indagando especificamente cada aspecto positivo e negativo sobre o produto ser ou fazer algo.
Tipicamente, após tal técnica, os participantes terão uma visão mais alinhada tanto sobre o que o produto faz. Assim como, o que o produto não faz.
Dessa forma, decisões estratégicas podem ser clarificadas, como tal coisa o produto nunca vai fazer, enquanto que aquela outra ainda não deve fazer.
3. OKR (Objectives and Key Results):
Figura 5 – OKR – Fonte da Imagem: https://pt.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery
Primeiramente, esse é um sistema de definição de metas. É uma abordagem simples para criar alinhamento e engajamento em torno de metas mensuráveis.
O conceito original da OKR veio da Intel e se espalhou para outras empresas do Vale do Silício. O Google aprovou o OKR em 1999, durante seu primeiro ano. Ele apoiou o crescimento do Google de 40 funcionários para mais de 60.000 hoje.
Além do Google, outras empresas usam OKR, incluindo Spotify, Twitter, Linkedin e Airbnb. Por outro lado, o OKR não é apenas para empresas digitais. Empresas como Walmart, Target, The Guardian, Dun e Bradstreet, e ING Bank também estão usando OKR.
Segue estrutura de um OKR: Eu vou (Objetivo) medido por (esse conjunto de Key Results).
- Objetivos são descrições qualitativas memoráveis do que deseja alcançar. Os objetivos devem ser curtos, inspiradores e envolventes. Um Objetivo deve motivar e desafiar a equipe.
- Key Results são um conjunto de métricas que medem o seu progresso em direção ao Objetivo. Para cada Objetivo, você deve ter um conjunto de 2 a 5 resultados principais. Mais do que isso e ninguém se lembrará deles.
Em síntese, todos os Key Results devem ser quantitativos e mensuráveis. Se não tem um número, não é um Key Result.
Enfim, os OKRs são frequentemente definidos, medidos e reavaliados. O OKR é um processo simples, de cadência rápida que envolve a perspectiva e a criatividade de cada time.
Dessa forma, não existe apenas uma maneira de usar o OKR, cada empresa ou time pode adaptá-lo e ajustá-lo, criando diferentes versões.
Mas existem alguns conceitos centrais:
- METAS ÁGEIS: Em vez de usar um planejamento anual estático, o OKR usa uma abordagem ágil. Usando ciclos de metas curtos, as empresas podem se adaptar e responder às mudanças.
- SIMPLICIDADE: abordagem OKR é simples, e os próprios OKRs são fáceis de entender. O modelo original da Intel definia objetivos mensalmente, o que exigiu um processo leve. As empresas que adotam o OKR reduzem o tempo gasto em definir metas de meses para dias. Como resultado, elas investem seus recursos no atingimento dos seus objetivos e não na sua definição.
- TRANSPARÊNCIA: O propósito principal do OKR é criar alinhamento na organização. Para isso, os OKRs são públicos para todos os níveis da empresa – todos têm acesso aos OKRs de todo mundo. Os OKRs do CEO normalmente estão disponíveis na intranet.
Erros comuns com OKR:
- Usar OKR como uma lista de tarefas, Use OKR para medir se você está adicionando valor, não se você está entregando tarefas. Portanto, você precisa entender a diferença entre os Key Results baseados em valor e baseados em atividades.
- Criar OKRs demais, este erro é uma conseqüência comum do primeiro. Em vez de ser uma lista de tudo o que você poderia fazer, OKR lista as suas principais prioridades.
- Não alinhar os OKRsOKR é uma ferramenta de alinhamento, então você nunca deve definir seus OKRs isoladamente. Você tem que conversar com as outras equipes.
- OKRs não são resoluções de Ano Novo. Sem acompanhamento regular, você nunca irá alcançá-los.
4. Proto-personas:
Figura 6 – Proto-personas – Fonte da Imagem: https://pt.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery
Primeiramente, personas são personagens fictícios, modelos descritivos criados para representar a definição do cliente típico.
Logo, personas são úteis para identificar características comuns entre os potenciais usuários, ajudando a selecionar e definir o perfil comportamental dos consumidores.
Portanto, podemos concluir que: o uso de personas é bastante útil e importante para uma melhor compreensão do comportamento do usuário como: o que pensam, o que desejam, quais serviços precisam, quais são suas aspirações, como preferem ser atendidos, que tipo de relação esperam, por quais valores estão dispostos a pagar, e como é o seu comportamento digital.
Estas são algumas definições que conseguimos identificar com o uso de personas: Modelamos personas para determinar os requisitos do produto, para comunicar a documentação com a equipe envolvida, e para validar as ideias medindo a efetividade do design.
Enfim, procure sempre listar características de cada tipo de persona, criando-as a partir de um nome e foto que represente este grupo de usuários, frase ou slogan que capture a sua personalidade, dados demográficos, dados tecnológicos, nível de educação, perfil profissional, histórico pessoal, estilo de vida, objetivos, valores e atitudes, necessidades, motivação, desejos, expectativas, conhecimento na área, contexto de utilização do produto, frequência de uso, entre outros.
5. User Story Mapping
Figura 8 – Relevância, urgência e tendência. Fonte da Imagem: https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623
Primeiramente, a matriz GUT é uma ferramenta usada para definir prioridades dadas as diversas alternativas de ação, respondendo racionalmente a duas questões básicas: o que se deve fazer primeiro? Por onde começar?
Dessa forma, essa matriz utiliza as variáveis Gravidade, Urgência e Tendência do fenômeno. Todos os problemas devem ser avaliados e classificados, e as notas em cada um dos quesitos devem ser um consenso entre o time.
- Gravidade: representa o impacto do problema analisado, caso ele venha a acontecer. É analisado sob aspectos como tarefas, pessoas, resultados, processos, organizações etc., considerando sempre seus efeitos a médio e longo prazo, caso o problema em questão não seja resolvido;
- Urgência: prazo, o tempo disponível ou necessário para resolver um determinado problema. Quanto maior a urgência, menor o tempo disponível para resolução.
- Tendência: representa o potencial de crescimento do problema, ou seja, a probabilidade de se tornar maior com o passar do tempo. É a avaliação da tendência de crescimento, redução ou desaparecimento do problema.
Logo, para cada problema levantado, o time atribui uma nota de 1 a 5 para cada variável. A pontuação final para cada problema será o produto entre as três variáveis. A tabela abaixo mostra a definição dos critérios para a nota em cada um dos quesitos.
Times Scrum são, por essência, auto organizáveis. Sendo assim, os times podem definir variáveis, valores ou critérios de priorização diferentes das apresentadas nesse texto.
Assim, o time tem autonomia para definir seus critérios de priorização, podendo este ser único, duplo ou múltiplo. Além de agregar mais objetividade na seleção de pontos de melhoria, são ferramentas que estimulam a comunicação e aumentam o alinhamento entre o time.
Ressalta-se que o resultado final da priorização dos problemas, deve ser consenso entre o time, tal qual a estimativa de pontos em estórias de usuário.
2. Indicadores Rut
Figura 9 – Indicadores Rut – Fonte da Imagem: https://pt.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery
A Andressa Chiara, é que Product Owner na Concrete Solutions, fez adaptações ao GUT, e criou a RUT que funciona em cenários em que outros métodos de priorização falham, porque ela força os stakeholders a avaliarem de forma objetiva cada aspecto do item de backlog e elencá-los usando definições específicas, o que minimiza a subjetividade do processo.
A utilização do resultado do modelo RUT de priorização ao longo do refinamento é para gerir o valor agregado por Sprint. Para maiores detalhes: https://imasters.com.br/desenvolvimento/agile/exotica-arte-de-medir-valor/?trace=1519021197&source=single
Definitivamente, eu espero ter contribuído de forma significativamente aos que tiveram curiosidade sobre quem é e o que faz um PO e também para aqueles que desejam trilhar o caminho profissional de ser um PO.
Por fim deixo o link da apresentação original do evento para quem tiver curiosidade: https://www.slideshare.net/ConcreteS/pos-on-beer-rj-79730623.
Fontes de Pesquisa:
http://artia.com/blog/voce-sabe-o-que-e-gestao-agil-e-quais-sao-suas-metodologias/
https://www.sebrae.com.br/sites/PortalSebrae/artigos/entenda-o-que-e-lean-startup,03ebb2a178c83410VgnVCM1000003b74010aRCRD
https://medium.com/olxbr-design/product-discovery-a8dc701f50b
https://qualidadebr.wordpress.com/2010/11/22/processo-incremental-x-iterativo/
https://blog.productboard.com/the-age-of-product-discovery-part-ii-aebc7f755223
http://felipecastro.com/pt-br/okr/o-que-e-okr/
https://www.slideshare.net/AndressaChiaraCSMCSP/tdc-floripa-workshop-product-discovery
http://www.devmedia.com.br/personas-e-user-story-mapping-identificando-o-seu-verdadeiro-publico-alvo/31699
http://www.caroli.org/o-produto-e-nao-e-faz-nao-faz/
https://www.concrete.com.br/2015/04/27/ferramentas-de-priorizacao-de-problemas/
https://imasters.com.br/desenvolvimento/gerencia-de-projetos/ferramentas-de-priorizacao-de-problemas-retrospectivas-mais-efetivas/?trace=1519021197&source=single
Informações sobre a autora:
Jacqueline Viana é Scrum Master na Concrete Solutions, e é apaixonada por agilidade.
Cofundadora Agile Pink
