Gestão de produtos digitais: priorização

Buy a Feature - Introdução

Olá, pessoal, seja bem vindos ao curso de técnicas de priorização. Meu nome é Mario Melo, sou sócio fundador da Facta e facilitador na Emergee e eu vou dar uma passada rapidinha aqui sobre o conteúdo que nós vamos ver durante esse curso.

Na primeira aula, eu vou ensinar uma técnica bem legal, que chama "buy a feature", é uma técnica lúdica para fazer priorização e funciona muito bem quando nós tememos um grupo diverso de pessoas para priorizar. Depois vamos falar do modelo de Kano que é bem interessante onde tentamos categorizar as features em três categorias diferentes para facilitar a priorização.

E nós vamos fazer um modelo mais simples, que é risco e valor, uma matriz 2 por 2 com alguns detalhes que são bastante surpreendentes na hora de priorizar. E nós falamos de "user story map", que é uma técnica que eu adoro porque ela é bem visual, e destrincha bem o produto digital em diversas características e features bem pequenas.

E nós falamos de priorização para atributos, que se tornou bastante popular nos últimos tempos, porque o Paulo Caroli usa no "Lean Inception", e é um outro modelo bem legal que nos ajuda a equilibrar quando nós temos demandas diversas. E nós falamos fala de "cost of delay", é um modelo mais matemático e vai ter um pouquinho de conta nessa aula, mas é super legal também.

E, por último, o "trade off", que é um modelo bem visual e que ajuda grupos a chegarem a um consenso de priorização. Espero que vocês gostem e vamos começar.

Buy a Feature - Buy a Feature

O primeiro método de priorização, uma técnica bem interessante, que eu vou ensinar aqui vai ser o "Buy a Feature". Ele tem esse nome porque funciona mais ou menos como um mercado mesmo de funcionalidades.

Então, é um local onde você vai convidar o seu cliente — ou os seus clientes, quando tem mais de um cliente fica até mais interessante de utilizar essa técnica, e nós vamos ter as possíveis funcionalidades que vão ser implementadas no sistema expostas como se fosse mesmo uma vitrine de funcionalidades e cada uma com um preço e esse preço é uma estimativa do quão complexo e do quão custoso vai ser trazer essa feature para realidade.

Pode ser uma estimativa de tempo, uma estimativa de complexidade, mas nesse momento nós vamos trazer ela em forma de valor como se fosse mesmo um preço para aquela funcionalidade.

Para essa técnica funcionar de uma forma bem legal é bom limitarmos o número de funcionalidades. No máximo dez, se tiver oito ou sete... Fica excelente, porque se tiver coisa demais a reunião fica demorada e acabamos deixando passar alguma coisa, então, se tiver muita funcionalidade é mais legal rodar esse exercício mais de uma vez, porque se não fica muito maçante.

Os clientes vão ter esse mercado com várias funcionalidades e o nosso objetivo é limitar o tempo que eles vão levar para chegar a um consenso do que tem que ser priorizado, do que tem que ser feito primeiro, o que é mais importante para o produto naquele momento.

A ideia de limitar o tempo é tornar essa reunião bem objetiva e conseguirmos alcançar essa priorização de uma forma rápida e eficiente. Se demoramos tempo demais, dificilmente vai sair uma priorização muito melhor do que em um tempo limitado para oito funcionalidades, e o pessoal vai sair cansado.

Outra coisa que é legal porque como o objetivo, principalmente, quando temos muito cliente, é criar uma interação, um debate, colocamos esse preço que é a estimativa de custo maior do que o dinheiro que cada um deles vai ter para comprar a funcionalidade. Por quê?

Porque eles vão precisar interagir entre eles e fazer uma vaquinha, juntar nós dois aqui, nós achamos interessante comprar aquela funcionalidade e ela custa treze, mas eu tenho cinco e o meu amigo ele tem cinco... Vamos perguntar para outra amiga se ela anima de inteirar três. Se faz sentido pra ela, aquilo também é prioritário para ela.

Então, nós conseguimos juntar as necessidades de várias pessoas e fazer essas pessoas conversarem entre elas para chegar numa priorização que faz sentido para todo mundo. Então, se nós temos, vamos supor, um produto digital que tem vários perfis de clientes diferentes, de repente tem uma pessoa que usa muito, com muita frequência e outra que usa pouco, mas quando usa gasta muito dinheiro naquele produto, nós colocamos essas pessoas numa sala e juntando a necessidade de todas elas nós chegamos em uma priorização mais balanceada, por assim dizer.

Outra coisa que é fundamental é o dinheiro total que nós vamos dividir para cada um dos participantes vai ser mais ou menos metade do curso de todas as funcionalidades que nós vamos apresentar, ou seja, eles não vão ter em hipótese alguma o dinheiro para comprar tudo, eles vão ter que abrir mão de algumas funcionalidades que estão sendo apresentadas ali e o intuito disso é realmente forçar um debate.

Se eles puderem comprar tudo, eles vão comprar tudo, e não vai ter muita conversa, só vai sair uma lista ordenada.

Se tem oito funcionalidades vai sair uma lista de um a oito, mas se limitamos o dinheiro e colocamos só a metade, por exemplo, eles vão ter um debate muito mais rico porque vão ter que começar a conversar sobre o que vai ficar de fora do produto.

Nós temos essa limitação e ao fazer isso saímos com um produto mais enxuto com um conjunto de funcionalidades ali que entrega o máximo de valor para aquele grupo de usuários, mas que conseguimos entregar de uma maneira mais rápida, conseguimos colocar isso no ar mais rapidamente.

Assim acho que dá para perceber que essa coisa que eu falei, o objetivo é o debate, é a parte mais importante. Esse exercício ele é feito para realmente forçar esse debate essa coisa do pessoal ter menos dinheiro vai incomodar e é legal ao facilitador, quem estiver rodando esse exercício, comentar com o pessoal que é proposital mesmo e que a ideia é essa para limitar, mas que essas features que não foram priorizadas, que de repente ninguém comprou, não é que elas nunca vão ser feitas.

Eventualmente nós podemos desenvolver, mas o exercício é de priorização. Nós precisamos entender o que é mais fácil e o que é melhor nós entregarmos nesse primeiro momento. Em um segundo momento nós podemos fazer as outras, sem problema nenhum.

E de repente, nós vamos ter novas funcionalidades, então, pegamos essas que não foram priorizadas agora e daí em uma segunda rodada de exercício juntamos com novas ideias que surgiram e prioriza novamente.

Uma coisa que costuma acontecer que é muito legal quando rodamos esse exercício é porque como temos essa limitação que só tem 50% de dinheiro distribuído entre todas as pessoas, ninguém, mesmo que eles se juntem, se unam, eles não vão conseguir comprar todas as funcionalidades.

Isso gera um certo incômodo. E eles podem começar a sugerir simplificações. Então, por exemplo: "Olha, Mário, essa feature aqui que custa treze da maneira que ela está descrita ela é bem complicada, mas e se fizéssemos uma versão mais simples será que não consegue quebrar ela e vender essa feature para mim por oito, temos oito de dinheiro aqui, o que que dá para fazer com esses oito?"

E esse tipo de debate é muito interessante, de repente, vamos supor, nós temos lá uma funcionalidade de login e o login tem autenticação em dois fatores. Tem lá por e-mail, manda uma SMS confirmando a senha, login por Facebook, por Twitter.

E alguém chega e fala olha: "esse aqui está treze, mas tem muita coisa. Será que de repente se fizéssemos um login simples, só o usuário e senha não dá para fazer por oito?" Rola essa pechincha.

E isso é interessantíssimo porque o nosso objetivo quando estamos criando um produto digital é exatamente tentar colocar ele no mercado o mais rápido possível, pra validarmos se tudo aquilo que a criamos faz sentido para o mercado, se as pessoas vão comprar aquilo e se elas não comprarem, pelo menos aprendemos isso investindo um mínimo de tempo e dinheiro nessa ideia.

Então, simplificar é sempre uma ideia que na pior das hipóteses gera um debate muito interessante, nós não precisamos sempre caminhar para uma versão mais simples, mas podemos exercitar essa ideia de tentar fazer uma versão mais simples.

Uma coisa que é interessante também, esqueci de mencionar, é que todo tipo de jogo, isso é considerado um jogo, uma dinâmica... Eles são meios para um fim, no final o objetivo é chegar na priorização, ótimo, mas no meio do caminho esse debate que acontece ele muda muito o resultado que que sai lá na frente dependendo do tipo de dinâmica que fazemos e das pessoas que estão envolvidas e como elas estão envolvidas.

Então, para pessoas que nunca participaram desse tipo de dinâmica tem um exercício muito legal que é distribuir como se fosse o dinheiro de Monopoly. Então, ao invés de você entregar para a pessoa e falar você tem R$ 100 para comprar features e você compra, distribui seu dinheiro da forma que você quiser, você pode entregar para essas pessoas por exemplo dinheiro distribuído em notas de Monopoly.

E dessa forma ela não vai conseguir dividir estão bem o dinheiro dela não vai poder chegar, por exemplo, e falar eu quero colocar metade em cada coisa ela vai ter que gastar ali uma nota de 100 e essa nota de 100 vai doer na hora de sair.

Mas quando ela colocar a nota de 100 em alguma feature fica bem claro que aquela é a maior dor que aquela pessoa tem naquele momento, que ali nós temos que tentar atacar, porque aquilo é o mais importante para ela. Então, nós conseguimos evidenciar algumas coisas, fica mais difícil, isso é muito útil quando estamos trabalhando com iniciante e também quando temos, por exemplo, só uma pessoa e não conseguimos reunir vários possíveis clientes.

Então, quando nós temos só uma pessoa esse tipo de coisa, essa distribuição meio Monopoly, ajuda a percebermos o que realmente importa para aquela pessoa.

Esse jogo também é interessante porque podemos executar ele de maneira assíncrona. Não é o ideal fazer de maneira assíncrona, mas às vezes tem um time distribuído ou pessoas que estão trabalhando com fuso horário muito diferente e nós conseguimos cada um distribuir ali o seu dinheiro de uma forma virtual e conseguimos chegar a um resultado mais ou menos semelhante.

Eu vi por exemplo numa feira no evento que teve no começo desse ano, o Global Scrum Gathering, que tinha uma empresa que tava fazendo isso com um flipchart grande e a medida que as pessoas passavam pelo estande elas entregavam dinheiro, o dinheirinho de papel, de Monopoly e pediam para a pessoa pregar no flipchart o que ela achava que era mais interessante aquela empresa desenvolver nos próximos meses e era uma forma totalmente assíncrona porque não tem como reunir todas as pessoas do evento no estande naquele momento.

E eles conseguiram um resultado legal era bem interessante passar pela estande deles e ver naquele flipchart a maneira como as pessoas iam priorizando. Eles não faziam distinção nesse caso então todas as pessoas recebiam a mesma quantidade de dinheiro para poder distribuir e eles aproveitaram aquele momento ali para interagir com o público.

O que faz sentido para eles é um público que, possivelmente, seria cliente deles, eles estavam em um evento de nicho e para tentar extrair dessas pessoas o que era mais prioritário para elas, então, dá sim para rodar de maneira assíncrona, embora não seja o mais recomendado.

Kano Model - Kano Model

O segundo método de priorização que eu vou explicar para vocês é o modelo Kano, "Kano Model". Esse modelo é muito interessante porque ele parte de uma premissa que eu acho muito inteligente, em que o cliente só consegue te dar um pedaço da fórmula do sucesso do seu produto.

A outra parte dessa fórmula nós precisamos descobrir juntos com o cliente. Então, ele tem ali essa noção, mas não é algo que ele naturalmente chega e conta. Tem um pedaço que nós temos que conversar um pouquinho para descobrir um pouco melhor.

E no modelo de kano ele traça um gráfico que é bem interessante que é de Satisfação por Necessidade. No eixo de satisfação eu tenho o quão satisfeito eu estou com aquela funcionalidade e no eixo da necessidade, que está aqui na horizontal, eu tenho o quanto que a minha necessidade foi suprida.

Então, eu dei o exemplo do login na aula anterior vamos seguir com ele para eu tentar explicar. Imagina que nós começamos nesse eixo da necessidade com um login só com usuário e senha. Eu tenho algum grau de satisfação quando eu tenho esse login só com usuário e senha.

A medida que esse login vai sendo mais incrementado começa a ter login com redes sociais, login com autenticação em dois fatores, login com link mágico igual do Slack nós vamos tendo a necessidade cada vez mais suprida. Minha necessidade de logar no sistema vai ficando... eu tenho cada vez mais opções.

Mas como é que fica o meu nível de satisfação a medida que essa necessidade ela vai sendo mais suprida? Então, o modelo de Kano ele trabalha com três curvas principais.

A primeira nós chamamos de Musts que é essa ali de baixo. A do meio as Wants e a de cima os Exciters. O que é um Musts? É uma coisa que ela precisa ter. Se não tiver, eu não estou feliz. E o que a curva representa é bem isso. Enquanto essa necessidade não é suprida o meu grau de satisfação com o produto é muito baixo. Quando ela é suprida meu grau é Ok. É obrigatório ter isso se não tiver eu não to feliz.

Esses Musts são algo que os clientes esquecem de mencionar muitas vezes porque é óbvio para eles que eu não preciso nem te contar que você deveria incluir isso no sistema.

Então, na minha empresa eu já tive um problema uma vez no produto que o cliente esqueceu de me falar que ele tinha que funcionar offline e como era uma aplicação para minerador o técnico utiliza esse aplicativo no lugar onde não tem sinal de nada para eles eram muito óbvio que eles trabalham nesse ambiente todo dia. Eles esqueceram de mencionar que tinha que funcionar offline. Nós fomos descobrir um pouco tarde no projeto, deu para corrigir, mas poderia ter sido descoberto antes.

Então, o que é um Must? Por exemplo, temperatura da comida no restaurante. Nós não temos que contar que queremos a comida quente, nós esperamos que ela venha quenta, se ela vier fria nós achamos ruim. Se vier quente, não fizeram mais do que a obrigação.

Em um produto digital nos dias de hoje seria, por exemplo, visualização em dispositivos móveis. Nós, às vezes, não contamos que queremos isso, mas já contamos como certo que vai ter que todo mundo vai acessar pelo celular, pelo tablet. Ao passo que as coisas que queremos que são as funcionalidades lineares, esses Wants, elas são funcionalidades que, quanto mais, melhor.

Vamos supor, nós temos itens no cardápio, eu vou no restaurante e quanto mais coisas tiver no cardápio, mais satisfeito eu estou. Tem mais opções. Então, a medida que vai aumentando nós vamos ficando mais satisfeito. Por isso que chama funcionalidade linear, então, poderia ser, por exemplo, vamos supor, em um aplicativo de pedido de comida. O tempo com que a comida chega na sua casa. Quanto mais rápido, melhor. Se chegou em 5 minutos está ótimo, mas se chegar em quatro, melhor ainda. Nós vamos ficando mais felizes a medida que essa necessidade vai sendo suprida.

[04:36]Nós temos os Exciters, que são aqueles bônus, é um fator "uau" no produto. É aquela coisa que às vezes nós nem contávamos que ela fosse existir, mas já que ela existe ficamos feliz para caramba que tem. Então, vamos supor, no exemplo digital seria um aplicativo desses que você vai pedir a comida e descobre que você pode pagar com Bitcoin, por exemplo, para quem usa Bitcoin, nós não contamos com isso, mas se está lá faz uma diferença.

Esse tipo de funcionalidade geralmente ela é esse fator uau. É aquela coisa que o cliente acaba lembrando quando ela é muito bem executada. Então, se pegamos, vamos supor, um exemplo de banco. "Ah, o banco tem o pagamento por QR Code". Algum tempo atrás não estávamos contando com isso de fazer a transferência ali rapidinho com QR Code, pagamento com QR Code. Então, ainda é um Exciter uma coisa que é um bônus, nem todo mundo oferece, então, é legal para caramba.

Da mesma forma o restaurante que aceita esse pagamento com QR Code também cai nessa faixa. Uma coisa interessante das funcionalidades bônus nesses Exciters é que o tempo tende a tornar eles Musts, funcionalidades obrigatórias.

Se pensarmos aí em uns quinze anos pra trás... quinze para vinte anos atrás em celulares com câmera. A câmera era um grande diferencial e era aquela qualidade terrível da foto, mas poxa o telefone tinha câmera. Você conseguia ter câmera no bolso e era um grande diferencial, celulares que tinham câmera eram até mais caros do que os outros e hoje em dia ninguém nem pensa em fazer um celular sem câmera, se alguém fizer cai naquela curva da necessidade do Must. Se não tem, eu estou infeliz e se tem eu estou ok, não está fazendo mais do que a obrigação.

Mas o grande segredo do Kano Model é uma pesquisa que nós tentamos fazer com os usuários para identificar pra cada funcionalidade que pretendemos criar para o produto, qual que se encaixa em cada uma dessas curvas e tem mais duas curvinhass que eu não desenhei para não confundir, porque elas não são tão relevantes assim, que são as funcionalidades indiferentes e as invertidas.

Então, a indiferente é aquela que honestamente não muda muito para o cliente a percepção dele de valor do produto.

Vamos supor, você vai no restaurante, já que usamos muito aqui o exemplo do restaurante. E você tem um cardápio com a capa emborrachada, uma capa bonitona. É indiferente. É uma coisa que é legal ter, mas não vai te atrair mais clientes por conta disso, você não vai voltar no restaurante só para pegar aquele cardápio na mão.

No caso de entrega de comida pensando um produto digital seria um relatório com o tempo médio das suas últimas entregas. Legal é, mas não é isso que vai fazer você usar aquele software mais ou menos.

E tem o tipo invertido que é aquele que quanto mais funcionalidade tem, quanto mais aquela funcionalidade está elaborada dentro do produto mais insatisfeito nós ficamos. Então, são geralmente burocracias. Vamos voltar no exemplo do restaurante, seria o couvert artístico cobrado na hora que vamos no restaurante, principalmente quando ele é surpresa. Se te cobram R$ 2,00 você fica um pouco chateado, mas se te cobram R$ 50 sem te avisar você fica bastante chateado.

Quanto mais tem, mais chateado ficamos. Um exemplo de produto digital seria, por exemplo, o excesso de notificações. Às vezes não queremos spam no e-mail, não queremos esse tipo de coisa, quanto mais mandam, mais chateado ficamos. Então, o nosso grau de satisfação ele desce a medida que essa funcionalidade é mais executada.

Vamos voltar para pesquisa, como é que descobrimos onde uma funcionalidade se encaixa, em qual curva que ela está? O modelo de Kano define uma pesquisa muito interessante que se baseia em duas perguntas que é: como você se sente caso essa funcionalidade exista no sistema, em nosso produto, e como você se sente caso ela não exista no produto.

Nós temos uma escala com cinco respostas. São as mesmas cinco respostas para as duas perguntas que são: Eu gosto que tenha/eu gosto que não tenha. Eu espero que tenha/Eu espero que não tenha. Eu não ligo se tem ou se não tem, tanto faz. Eu sobrevivo, então, assim eu consigo viver sem/eu consigo viver com isso me incomodando no produto. E a última que é eu não gosto que não tenha/eu não gosto que tenha.

E aí quando as pessoas respondem a essas duas perguntas conseguimos fazer uma tabelinha, fazer um mapa de onde aquela funcionalidade se encaixa. O mais óbvio aqui são os dois extremos que é o eu gosto, eu não gosto. Então, se alguém fala que gosta que a funcionalidade exista e não gosta que a funcionalidade exista, nós não conseguimos concluir nada. Ficam duas respostas opostas e não concluímos.

Agora quando a pessoa fala que gosta que a funcionalidade exista ou que ela não gosta que não exista já é uma funcionalidade linear. É uma coisa que está bem fácil de perceber o quão importante é para a pessoa. E da mesma forma que está na tabelinha aqui em cima, dá para ver que casando essas duas respostas nós conseguimos mapear, mais ou menos, nas nossas três curvas ali o que aquela funcionalidade representa para o cliente. Com só duas perguntas para cada funcionalidade, claro.

Então, de novo, assim como para o modelo do Buy a Feature, é interessante limitarmos o número de funcionalidades para não ficar um formulário muito maçante também.

Sabendo onde cada cada funcionalidade se encaixa fica mais fácil de começarmos a priorizar. Então, não adianta tentarmos fazer um produto que só tenha Exciter, só coisa bônus, se nós ainda não fizemos os Musts, as coisas que são obrigatórias, que vamos apresentar algo para o cliente e, por mais legal que sejam os Exciters, ele vai acabar ficando insatisfeito.

Sobre o curso Gestão de produtos digitais: priorização

O curso Gestão de produtos digitais: priorização possui 82 minutos de vídeos, em um total de 28 atividades. Gostou? Conheça nossos outros cursos de Gestão de Produtos em Inovação & Gestão, ou leia nossos artigos de Inovação & Gestão.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Buy a Feature
• Kano Model
• Risco versus Valor
• User Story Map
• Priorização por Atributos
• Cost of Delay
• Trade-Offs