Algumas notas sobre outcomes e outputs - Parte 2
De onde vem o output no desenvolvimento de produtos e serviços digitais?
Vamos considerar um caso hipotético de um serviço de streaming que possua uma quantidade de assinantes. Esta base é um percentual do total de usuários que o serviço poderia endereçar. Uma modelagem para este sistema pode ser exemplificada da seguinte forma:
A dinâmica deste sistema acontece da seguinte forma: Um pedaço da base de clientes endereçáveis é convertida em assinantes, integrando o total de assinantes. Por outro lado, alguns desses assinantes decidem parar de assinar o serviço, voltando para a base de clientes endereçáveis, passíveis de uma nova conversão no futuro.
Existem duas variáveis importantíssimas que estão em jogo aqui, são elas: a taxa de conversão de assinantes e taxa de churn de assinantes que determinam o percentual das respectivas bases que é convertido em novos assinantes ou em assinantes que cancelaram o serviço.
A partir deste modelo conceitual, podemos começar a discutir sobre a diferença entre outcome e outputs, e as causas de muitos dilemas dentro de uma corporação ao lidar com esse par de perspectivas.
Por exemplo, para aumentar a taxa de conversão de assinantes deste serviço podemos tentar mexer em diversas alavancas: talvez melhorar o sortimento de filmes e series oferecidos, ou talvez praticar um preço de assinatura mais atrativo para o público-alvo, ou, o que é comum muitas vezes, podemos tentar implementar funcionalidades que aumentem a aderência do produto e serviço as necessidades do usuários estimulando a maior conversão de assinantes.
Neste contexto, podemos usar um segundo modelo genérico para descrever um sistema onde novas ideias de funcionalidades são concebidas e incluídas no backlog do produto. A partir deste backlog, e de acordo com o throughput de entrega do time, temos finalmente um conjunto de features entregues naquele produto.
Dado este modelo conceitual podemos imaginar, novamente, como o esquema de incentivos abaixo pode acabar sendo implementado: estabelece-se um target/expectativa de vazão e capacidade de entrega (delivery throughput), a partir dele se avalia o diferencial entre a expectativa de vazão de entrega e o quanto está sendo de fato entregue (actual e o gap). A pressão entre eles gera um incentivo para executarmos ações que aumentem o delivery throughput e fecham este gap, eventualmente reduzindo a pressão.
O grande debate sobre outcome versus output acontece aqui, e ocorre da seguinte forma: uma perspectiva entende que as ideias colocadas no backlog, apesar de provavelmente bem intencionadas e legitimas, são apenas hipóteses a serem validadas, elas podem ou não atingir os objetivos de negócio e atender as necessidades dos usuários.
Por tanto, em vez de colocarmos o foco em entregá-las ( output ) devemos focar em validá-las/invalidá-las da maneira mais rápida e barata possível para reduzirmos os riscos e incertezas em relação a elas, para então focarmos em entregar os itens que temos mais certeza de que impactarão os indicadores e alcançarão os objetivos que estamos perseguindo ( outcome ).
Por outro lado um foco em aumentar o delivery throughput ( output ) assume que os itens que serão entregues gerarão os resultados de negócios esperados ( outcome ). Um foco em outcome assume que enquanto não tivermos essas evidências estamos otimizando uma máxima local (output) em detrimento de uma máxima global (outcome).
Conciliando os dois sistemas
Uma visão orientada a outcomes enxerga este sistema a partir dos objetivos de negócio a serem atingidos, por exemplo: dado o sistema abaixo no qual a taxa de conversão regula o fluxo de usuários não assinantes para assinantes, um dos objetivos poderia ser aumentar a taxa de conversão em 10%.
A partir daí as ações para tentar aumentar a taxa de conversão geram ideias que são inseridas no backlog do produto que, se e quando forem implementadas e agregadas ao conjunto de funcionalidades do produto, eventualmente gerarão um impacto positivo na taxa de conversão na direção de fechar o gap entre o target de taxa de conversão esperado e a taxa de conversão atual.
Uma visão integrada destes dois sistemas operando em conjunto poderia ser representada conforme o diagrama abaixo:
A partir dai, e assumindo que esse ciclo todo aconteça de acordo com o planejado ( ou seja, que as ideias sejam boas e de fato impactem a variável taxa de conversão da maneira esperada uma vez que sejam implementadas ), é bastante fácil ver como quanto maior a quantidade de itens no backlog a serem feitos maior a expectativa em cima do delivery throughput para entregá-lo, mudando a perspectiva para o foco em output e não apenas em outcome.
A divergência acontece, conforme já vimos, no fato de que as idéias a serem implementadas no backlog, na verdade são hipóteses, ( boas ou ruins ) sobre como a variável taxa de conversão vai ser impactada, logo em vez de partirmos para a execução completa das idéias em um ciclo mais longo de desenvolvimento, por que não tentamos validar/invalidar as hipóteses da maneira mais rápida e mais barata possível, e a partir daí definirmos os itens que serão de fato implementado no backlog, com alguma evidência de que esses sim impactarão a variável conforme esperado.
Algo que pode ser modelado conforme o sistema abaixo, onde antes do backlog temos um estoque de hipóteses que precisam ser validadas:
Ainda neste contexto de ideias e validações/invalidações de hipóteses, podemos ver como a mecânica de target, actual e gap na capacidade de validar/invalidar hipóteses pode ser um elemento importante.
E mesmo em um contexto onde o experiment throughput ( output ) seja uma variável importante a ser otimizada, podemos imaginar uma pressão para aumentar a quantidade de experimentos a serem executados com o objetivo de obter feedback mais rápido em relação as hipóteses sendo validadas/invalidadas, e com isso maximizar a velocidade do aprendizado, logo o mesmo esquema de incentivos é muitas vezes implantado aqui.
A mesma lógica começa a ser aplicada aqui, quanto maior a quantidade de hipóteses a serem validadas/invalidadas, maior é a pressão para se aumentar o experiment throughput, fazendo um ciclo similar ao que vimos em relação ao delivery throughput
Conciliando as duas perspectivas: outcomes e outputs.
A discussão outcome versus output, é essencialmente uma discussão sobre diferentes ênfases e perspectivas de um mesmo sistema integrado. Essa é uma realização importante para a prática de descoberta e desenvolvimento de produtos e serviços digitais, pois ela tira a fricção sobre o clássico antagonismo entre expectativas e visões diferentes de múltiplos stakeholders e faz com que possamos adaptar a discussão ao contexto sendo discutido.
No diagrama acima, a parte de cima, destacada em laranja é o que poderíamos chamar no nosso exemplo, da parte do sistema focado em indicadores de negócio e logo orientada a outcome. Inclusive ela está incrementada fazendo uma ligação entre o total de assinantes, o preço da assinatura do serviço de streaming, que gera a receita mensal. Esta receita quando subtraída dos custos e despesas mensais gera o lucro operacional mensal.
Por outro lado, a parte de baixo, destacada em azul é o que poderíamos chamar no nosso exemplo, da parte do sistema focada em indicadores e performance de entrega, e logo orientada a output. Inclusive ela esta incrementada com uma visão de headcount e custo de folha de salários associado a entregar os serviços e produtos digitais da nossa empresa hipotética.
Quando conseguimos ter uma visão mais completa do sistema dinâmico e complexo em que estamos envolvidos durante a descoberta e desenvolvimento de produtos e serviços digitais fica mais clara as alavancas e incentivos para certos tipos de discussões e a ênfase em um conjunto de indicadores e medições em detrimento de outros.