Suposições são coisas interessantes – todos nós as fazemos, o tempo todo, e raramente reconhecemos que estamos fazendo. Quando se trata de desenvolver uma estratégia de produto – ou mesmo tomar decisões sobre a melhor forma de criar um produto -, uma suposição pode nos levar ao fracasso. No entanto, podemos reduzir a chance de que isso aconteça.

Sobre estar errado

Qual é a sensação de estar errado? Assista cerca de 25 segundos desta palestra de Kathryn Schultz em uma edição do TED, a partir dos 04:09:

Volte mais tarde e assista à palestra na íntegra – realmente vale a pena. Mas fique comigo por enquanto. Tudo o que você precisa para este artigo está nesses 25 segundos, e a percepção de que você não sabe que está errado até que você saiba que está errado.

Escondido, mas à vista de todos

As suposições são como estar errado. Mas com um maior grau de dificuldade. Não apenas você não sabe que está errado – mas você não sabe que você está erroneamente afirmando algo e apostando que isso está certo.

Toda estratégia, cada ideia de produto, cada abordagem de design e cada aplicação prevista é construída em cima de uma pilha de suposições. Essas suposições estão lá, é só você olhar para elas. Mas você tem que procurar por elas, para poder vê-las. Elas estão bem ali à vista, mas estão escondidas.

A única dúvida é se elas vão causar algum problema. Você pode não estar errado, nas suposições que realmente importam.

Não seria bom saber quando você está errado? Antes que seja tarde demais? Antes que seja muito caro? Antes de sua janela de oportunidades se feche?

Identificando suposições arriscadas

Laura Klein falou, na Conferência Lean Startup, sobre a identificação de premissas de risco. Sua palestra foi publicada em dezembro de 2014 . Laura também está se tornando rapidamente um dos meus gurus favoritos. Eu só queria ter conhecido seu trabalho antes.

Laura identifica que cada produto tem pelo menos três classes diferentes de suposições:

1. Suposição do problema – vamos supor que há um problema de solução viável para o mercado.
2. Suposição da solução – presumimos que a nossa abordagem para resolver o problema é a correta.
3. Suposição de implementação – presumimos que podemos executar e tornar a nossa solução uma realidade, ela resolve o problema e nós temos sucesso.

Mantenha-se nesta linha de pensamento – eu preciso mudar um pouco e sacudir a poeira de uma ferramenta que eu encontrei há cinco anos e também de alguns trabalhos que eu realizei com meus clientes ao longo dos últimos anos. Nós vamos olhar para a forma de incorporar algumas dessas ideias com as que Laura compartilhou. E, eventualmente, a referência ao “Whack-a-mole” fará sentido.

Hipóteses e suposições

Eu realizei um workshop com um cliente, no ano passado, para provocar suposições sobre nosso projeto. Nós estávamos trabalhando para desenvolver o que Harry Max chama de a teoria do nosso produto. Basicamente, nós estávamos trabalhando para desenvolver a visão, as propostas de valor (para um problema de mercado de mão dupla), o modelo de negócio que permitiria uma estratégia de entrada confiável no mercado, dada situação atual da empresa, e a abordagem de uma solução viável. Essencialmente, estratégia de produto e reflexão sobre o produto.

Minha afirmação nesse workshop foi que as suposições e hipóteses, em termos práticos, são riscos.

Estratégia de produto e design de produto são um plano de ação formulado, construído sobre um conjunto de crenças – suposições e hipóteses. O risco é que essas crenças estejam erradas e nós não percebamos isso. Materialmente, a única diferença entre uma suposição e uma hipótese é que a suposição é algo que ninguém disse em voz alta. Ela representa um risco implícito. Uma vez que você reconheça a suposição, você pode tratá-lo de forma explícita – e explicitamente decidir fazer algo a respeito ou não.

No workshop eu solicitei aos participantes (executivos seniores, especialistas de domínio, patrocinadores do produto e membros da equipe) para identificar suas suposições e hipóteses. Comecei apresentando várias hipóteses e suposições que tinham sido parte de conversas anteriores.

Isso ajudou a extrair ideias do grupo, mas não foi realmente o suficiente. O que fez as coisas andarem foram algumas sugestões de Harry, como a de completar a frase “Isso nunca vai funcionar porque ______________” ou “A única maneira de funcionar é se ____________”.

Nós fomos capazes de obter e, em seguida, organizar as entradas (mapeamento de afinidade) em uma coleção de hipóteses testáveis.

O que fazer com uma pilha de hipóteses?

Agora, de posse de uma lista de hipóteses, e tempo e recursos limitados para testar todos eles, fomos confrontados com o desafio de determinar qual risco abordar primeiro. Lembre-se – hipóteses e suposições são riscos. Riscos de estar errado (e não saber). Riscos de falha do produto.

Eu tenho usado, há muito tempo, “impacto potencial” e a “probabilidade de ocorrência” para gerenciar os riscos. Primeiro, aprendi a atribuir uma pontuação de 1 a 3 para a probabilidade do risco ocorrer, e uma pontuação de 1 a 3 de quão ruim seria se ele acontecesse. Multiplique os dois, e você terá uma pontuação de 1 a 9 (1,2,3,4,6,9). Aprendi isso com especialistas em PMO no final dos anos 1990. Talvez este pensamento tenha evoluído desde então. Há dois problemas com a criação de uma pontuação como esta.

1. Probabilidade de ocorrência e impacto potencial são tratados como fatores igualmente importantes. Um risco de impacto improvável, porém grande, seria “tão importante” quanto um risco provável com impacto mínimo. Cada abordagem específica para gestão de risco irá avaliá-los de forma diferente.
2. A combinação das duas informações em uma única parte é descartar informação útil. Se eu te disser que um risco é um “3” e o outro é um “4”, você não pode saber qual o risco é mais importante para você. O “4” é algo que tem uma chance razoável de ocorrer, e seria “ruim”. Isso seria mais importante do que entender um risco improvável, mas com impacto enorme na empresa? Seria mais importante do que um aborrecimento muito provável – um que pode causar morte por mil cortes para a sua empresa e de grande custo de suporte e absorver os lucros?

É por isso que eu tratei isso como um espaço bidimensional – utilizando um gráfico de probabilidade x impacto.

Laura propôs as etiquetas para este gráfico, renomeando meu eixo vertical. Estou descaradamente roubando isto dela. Me soa justo, pois ela fez a mesma coisa e deu crédito a Janice Frasier por parte de sua apresentação. Talvez uma das ideias que eu estou adicionando à mistura será roubada por uma próxima pessoa que vai acrescentar algo na nossa ideia.

Como uma equipe, você pode chegar a um consenso sobre o posicionamento relativo de todos os riscos. Em seguida, começar a rastrear o nosso top 10 riscos.

Como Laura diria – você começa com o “mais alto e mais à direita.” O que você faz é se perguntar – qual risco pode matar o seu produto, reduzir o preço das ações, demitir seu CEO, etc.

Há uma outra dimensão que torna o tratamento de riscos dessa maneira difícil – a incerteza. Você não sabe se este risco provavelmente vai acontecer. Você está supondo conforme você faz suposições sobre suas suposições.

A maneira mais fácil de pensar nisso é reconhecer que as medidas do seu impacto e da probabilidade não são medidas reais – são estimativas. Elas podem ser estimativas calibradas, como em “Como medir qualquer coisa”, de Hubbard, ou elas podem ser suposições com base em opiniões. Trate-os como estimativas, e depois delineie qual o seu ponto de vista “mais provável” ou de “pior caso” – que é uma chamada estilística, eu acho.

Removendo os Riscos

A razão de você testar uma hipótese é reduzir um risco. Eu acho que Laura usou a frase “tirar o risco” do risco.

Para tirar o risco do risco, a primeira coisa que você precisa fazer é eliminar a incerteza que você tem sobre quão ruim as coisas realmente poderiam ser. Você precisa executar um teste. No exemplo acima, você testaria primeiro a hipótese número 7 – é o mais alto e mais à direita. Você não estaria muito errado se você testasse as de número 4 ou 8 primeiro (supondo que uma delas seja mais fácil, mais rápida, ou mais barata para testar). Se você pretendesse testar algo além de 4, 8 ou 7 primeiro, você realmente deveria ter uma boa razão.

Depois de executar seu teste e determinar que o risco não é um risco, volte e enfrente o próximo risco mais importante. Esta é a dinâmica do jogo whack-a-mole*, o jogo de bater o martelo. Você nunca vai ficar sem riscos para testar. Você só vai finalmente chegar a um ponto onde o valor econômico de atrasar o seu produto para manter o teste não faz mais sentido.

Note que um teste poderia resultar em múltiplos resultados e próximos passos. Aqui estão alguns:

• Este risco não é tão impactante como pensamos, não vamos abordá-lo com as mudanças de produtos, nós vamos absorver esses custos no nosso modelo de rentabilidade e rever os preços para garantir o business case ainda se mantém.
• Este risco é tão provável quanto temíamos. Vamos determinar um problema de correção (ou abordagem de design de solução), onde este risco já não tem o impacto ou a probabilidade que antes. Por exemplo – o risco de os usuários não adotarem um produto com uma experiência deselegante pode justificar repensar a abordagem e investir para melhorar a experiência do usuário.

Tentar encontrar todas as maneiras por meio das quais você pode responder aos riscos (e riscos removidos) tornaria este artigo excessivamente longo, ridiculamente longo.

Board de validação

Em, 2012 eu encontrei um quadro de hipóteses do leanstartupmachine.com. Na época, ele era livre para uso por consultores. Eu não acredito que tenha ganho uma adoção generalizada. Pelo menos as pessoas olham com cara de “não entendi” quando eu o menciono. Talvez, agora, mais pessoas conheçam sobre ele.

Eu, pessoalmente, nunca usei porque pouco útil para mim, para os problemas que eu estava ajudando meus clientes a resolver. Eu nunca conseguia descobrir o porquê, no entanto. A placa tem muitos componentes importantes. Fazendo uma retrospectiva, este é um indicador de que o quadro de validação é propenso a resolver um problema que eu não tenho (em vez de ser uma solução ruim para um problema que eu tenho).

O board de validação é estruturado mais pelo início de trabalho de descoberta do cliente – com três categorias de hipóteses para rastrear: cliente, problema e solução

• Quão grande é o mercado potencial?
• Quão valioso é o problema que precisamos resolver?
• Somos capazes de resolver o problema dessas pessoas?

A ferramenta foi criada com o objetivo de ajudá-lo em a descobrir se você tem os clientes errados, ou os problemas, ou as soluções.

O que eu preciso é saber qual hipótese testar em seguida. Eu acho que pode ser feito melhor com um gráfico simples como os que Laura e eu utilizamos. Mas use os rótulos dela.

Bata com o martelo, jogue o whack-a-mole

 Ao invés de debater sobre detalhes de implementação, considere avaliar os riscos do seu produto. Determine se esses riscos justificam fazer um investimento para reduzi-los. Formule uma hipótese mensurável e valide.

Então vá atrás do próximo risco. Até que os riscos restantes já não sejam grandes o suficiente para você perseguir.

 

*Nota de tradução: whack-a-mole é um jogo de arcade que consiste em bater com um martelo em um objeto que sai de um buraco. O autor do texto utilizou o jogo como metáfora para o tipo de “brincadeira” que acontece quando lidamos com riscos em projetos. No Brasil, ele é comumente chamado de “jogo de bater com o martelo”. Aqui, você pode jogar uma das milhares de versões existentes.

***

Scott Sehlhorst faz parte do time de colunistas internacionais do iMasters. A tradução do artigo é feita pela Redação iMasters, com autorização do autor, e você pode acompanhar o artigo em inglês no link: http://tynerblain.com/blog/2017/01/08/whack-a-mole/