Falhas de Produtos

Marty Cagan - 05/06/2015 Traduzido por: Raphael Jubram

Observação: Esse artigo é uma versão escrita de uma palestra que dei para desenvolvedores na Craft Conference e para gestores de produto e designers na Mind The Product.


Neste artigo, gostaria de discutir as principais causas de tantas falhas de produtos.


Vejo a mesma forma básica de trabalhar na maioria das empresas, e não posso deixar de notar que isso não está nem próximo de como as melhores empresas realmente funcionam.


Deixe-me avisá-lo de que esta discussão pode ser um pouco deprimente, especialmente se ela chegar perto demais da sua casa. Portanto, se esse for o caso, peço que aguente firme.


Vamos começar percorrendo o processo que a grande maioria das empresas ainda utiliza para criar produtos. Tentarei não opinar ainda. Deixe-me primeiro descrever o processo:


Tudo começa com ideias.


Na maioria das empresas, elas provêm de executivos, de partes interessadas, proprietários de empresas ou de grandes clientes (ou potenciais clientes), mas, em qualquer caso, há sempre um monte de coisas que as diferentes partes do negócio precisam que façamos.


Agora, a maioria das empresas querem priorizar essas ideias em um roadmap e fazem isso por duas razões principais.


Primeiro, querem que trabalhemos, inicialmente, nas coisas mais valiosas, e segundo, querem ser capazes de prever quando é que as coisas estarão prontas.


Para tal, há quase sempre alguma forma de sessão de planejamento trimestral ou anual em que os líderes consideram as ideias e negociam um roadmap de produtos.


Mas, para estabelecerem prioridades, precisam, primeiro, de alguma forma, de um case de negócios para cada item.


Algumas empresas fazem cases de negócios formais, e outros são informais, mas, de qualquer forma, tudo se resume à necessidade de saber duas coisas sobre cada ideia:


1) Quanto dinheiro vai ganhar?

2) Quanto dinheiro ou tempo vai custar?


Essas informações, depois, são utilizadas para elaborar o roadmap, geralmente, para o próximo trimestre, mas, às vezes, para até um ano.


Nessa altura, os times de produto e tecnologia têm seus caminhos traçados e, normalmente, trabalham os itens da mais alta prioridade para baixo.


Quando uma ideia chega ao topo da lista, a primeira coisa a ser feita é um gestor de produto falar com os interessados para dar corpo à ideia e apresentar um conjunto de "requisitos".


Estes podem ser histórias de usuários ou podem ser mais como alguma forma de especificação funcional, mas o objetivo é comunicar com os designers e engenheiros o que precisa ser construído.


Uma vez reunidos os requisitos, a equipe de UX Design (supondo que a empresa tenha tal equipe) é solicitada a fornecer o design de interação, o design visual e, no caso de dispositivos físicos, o design industrial.


Finalmente, os requisitos e as especificações do design chegam aos engenheiros. É geralmente aqui que o Agile finalmente entra em cena.


De qualquer modo, os engenheiros dividem o trabalho, normalmente, em um conjunto de iterações - chamadas de "sprints" no processo Scrum.


Assim, talvez, sejam necessários de um a três sprints para construir a ideia.


Esperemos que os testes de QA façam parte desses sprints, mas, se não fizerem, a equipe de QA acompanhará este processo com alguns testes para garantir que a nova ideia funcione como anunciada e que não apresente outros problemas (conhecidos como regressões).


Assim que obtivermos a luz verde da QA, a nova ideia é, finalmente, implementada aos clientes reais.


Na grande maioria das empresas que conheço, grandes e pequenas, é essencialmente assim que elas trabalham e têm trabalhado durante muitos anos.


No entanto, essas mesmas empresas se queixam constantemente da falta de inovação e do tempo muito longo que leva para passar da ideia às mãos dos clientes.


Você deve reconhecer que, enquanto mencionei o Agile, e embora quase todos hoje afirmem ser ágeis, o que acabei de descrever é basicamente um processo de Waterfall.


Para ser justo com os engenheiros, eles, normalmente, estão fazendo o máximo de Agile possível devido ao contexto mais amplo do Waterfall.


OK, então pode ser o que a maioria das equipes faz, mas por que essa é, necessariamente, a razão de tantos problemas?


O que eu quero fazer agora é ligar os pontos para mostrar a você porque é que essa forma muito comum de trabalhar é, de fato, responsável pela maioria dos esforços fracassados de produto.


Agora, eu poderia literalmente falar o dia todo sobre os problemas com esse processo, mas o que vou fazer aqui é compartilhar o que penso serem os "top 10" problemas mais sérios com essa forma de trabalhar.


Para ser claro, estou argumentando que todos esses 10 são problemas muito sérios, qualquer um dos quais poderia atrapalhar uma equipe, mas muitas empresas têm, de fato, a maioria ou mesmo todos eles.


1. Vamos começar pelo topo - a fonte das ideias. Esse modelo conduz a promoções especiais orientadas para as vendas e a produtos direcionados para as partes interessadas. Há muito mais sobre esse tema-chave, mas, por ora, deixe-me apenas dizer que essa não é a fonte das nossas melhores ideias de produtos. Outra consequência dessa abordagem é a falta de empoderamento das equipes - nesse modelo, elas estão lá apenas para implementar. Mercenários.


2. Em seguida, vamos falar sobre a falha fatal nesses cases de negócios. Agora, para ser claro, sou realmente a favor dos cases de negócios, pelo menos para ideias que precisam de um investimento maior. Mas a maneira como a maioria das empresas as faz, neste estágio, para elaborar um roadmap prioritário, é verdadeiramente ridícula. Eis a razão. Lembra-se dessas duas entradas principais para todos os cases de negócios? Quanto você ganhará e quanto custará? Bem, a verdade fria é que, nesta fase, não temos qualquer pista sobre nenhum deles e não podemos saber.


Não podemos saber quanto dinheiro vamos ganhar porque isso depende muito de quão boa é a solução.


Se a equipe fizer um excelente trabalho, isso poderá ter um enorme sucesso e mudar, literalmente, o rumo da empresa.


Por outro lado, a verdade é que muitas ideias de produtos acabam por não fazer absolutamente nada. E isso não é um exagero. Literalmente, nada.


Em todo o caso, uma das lições mais críticas do produto é saber o que não podemos saber e, simplesmente, não podemos saber nesta fase quanto dinheiro vamos ganhar.


Da mesma forma, não temos ideia do que custará construir.


Sem conhecer a solução real, isso é extremamente difícil de a engenharia prever.


A maioria dos engenheiros experientes se recusará a dar uma estimativa nesta fase, mas alguns são pressionados para o velho compromisso de "tamanho da camiseta" - basta dizer se é "Pequeno, Médio, Grande e Extra Grande".


Mas as empresas querem realmente esses roadmaps priorizados e, para obter um, precisam de algum tipo de sistema para classificar as ideias.


Por isso, as pessoas jogam o jogo do case de negócios.


3. Uma questão ainda maior vem a seguir. As empresas ficam muito entusiasmadas com os seus roadmaps. Já vi inúmeros deles e a grande maioria são, essencialmente, listas priorizadas de características. O marketing precisa dessa funcionalidade para uma campanha. As vendas precisam dessa funcionalidade para um novo cliente. Alguém quer uma integração com o PayPal. Você entendeu a ideia.


Mas aqui está o problema, e talvez seja o maior de todos. Chamo isso de "duas verdades inconvenientes sobre o produto".


A primeira verdade é que, pelo menos, metade das nossas ideias não vai funcionar.


Há muitas razões para que uma ideia não funcione.


A mais comum é que os clientes simplesmente não estão tão entusiasmados com ela quanto nós estamos.


Por isso, optam por não a utilizar.


Às vezes querem usá-la, mas a experiência é tão complicada que há mais problemas do que vale a pena, o que acaba por ser o mesmo resultado - os usuários não escolhem usá-la.


Por vezes, a questão é que os clientes adorariam, mas acaba que precisaríamos nos envolver muito mais na construção do que pensávamos, e decidimos que, simplesmente, não podemos nos dar ao luxo de arcar com tempo e dinheiro para realmente entregar.


Portanto, prometo que, pelo menos, metade das ideias do seu roadmap não vai concretizar o que você espera.


A propósito, as equipes realmente boas assumem que, pelo menos, três quartos das ideias não terão o desempenho esperado.


Se isso não for ruim o suficiente, a segunda verdade inconveniente é que, mesmo com as ideias que provam ter potencial, normalmente são necessárias várias iterações para levar a implementação dessa ideia até ao ponto em que ela realmente proporciona o valor comercial necessário. Chamamos isso de "tempo para dinheiro".


Uma das coisas mais importantes sobre produto que aprendi é que simplesmente não há como escapar dessas verdades, por mais inteligente que você seja.


E tive a boa sorte de trabalhar com muitas equipes de produtos realmente excepcionais. A verdadeira diferença é a forma como se lida com essas verdades.


4. A seguir, vamos falar sobre o papel do produto nesse modelo. Na verdade, nem sequer chamaríamos esse produto de produto, de fato. É realmente uma forma de gerenciamento de projetos. Neste modelo, trata-se mais de reunir requisitos e documentá-los para os engenheiros. Neste ponto, deixe-me apenas dizer que isso está a 180 graus da gestão moderna de produtos.


5. É uma história semelhante com o papel do design. É muito tarde no jogo para obter o verdadeiro valor do design e, principalmente, o que está sendo feito é o que chamamos de modelo "batom no porco". O dano já foi feito e agora estamos apenas tentando colocar uma camada de tinta na confusão. Os designers UX sabem que isso não é bom, mas tentam fazer com que pareça o mais agradável e consistente possível.


6. Talvez a maior oportunidade perdida nesse modelo seja o fato de a engenharia ser trazida muito tarde. Dizemos que, se você está apenas usando seus engenheiros para codar, está recebendo apenas metade do valor deles. O pequeno segredo do produto é que os engenheiros são tipicamente a melhor fonte única de inovação, mas nem mesmo são convidados para participar nesse processo.


7. A engenharia não só é trazida muito tarde, como os princípios e os benefícios-chave do Agile entram em cena tarde demais. As equipes que usam o Agile dessa maneira estão obtendo, talvez, 20% do valor real e do potencial dos métodos Agile. O que você realmente vê é o Agile para a entrega, mas o restante da organização e o contexto são tudo, menos ágeis.


8. Todo esse processo é muito centrado no projeto. A empresa, normalmente, financia projetos, projetos de equipes e os impulsiona pela organização e, finalmente, lança projetos. Infelizmente, os projetos são produzidos (output) e o produto tem tudo a ver com resultado (outcome). Previsivelmente, esse processo leva a projetos órfãos. Sim, finalmente algo foi lançado, mas não atende aos seus objetivos. Qual era realmente o objetivo? De qualquer forma, é um problema sério e não está perto de como precisamos construir produtos.


9. A maior falha do antigo processo Waterfall sempre foi, e continua sendo, que todo o risco está no fim. Isso significa que a validação do cliente acontece muito tarde.


Você, provavelmente, já ouviu falar dos métodos Lean Startup, que estão no centro da alternativa. O princípio fundamental é reduzir o desperdício, e uma das maiores formas de desperdício é projetar, construir, testar e implementar um recurso ou produto apenas para descobrir que não é o necessário. A ironia é que muitas equipes acreditam estar aplicando princípios lean, mas seguem o processo básico que acabei de descrever. E depois mostro a eles que eles estão realmente experimentando ideias de uma das maneiras mais caras e lentas que conhecemos.


10. Finalmente, enquanto estamos ocupados fazendo esse processo e desperdiçando nosso tempo e dinheiro, a maior perda de todas costuma ser o custo de oportunidade do que a organização poderia ter e deveria estar fazendo. Não podemos recuperar esse tempo ou dinheiro.


Para mim, não é surpresa que tantas empresas gastem tanto tempo e dinheiro e recebam tão pouco em troca. Eu avisei que isso poderia ser deprimente.


A boa notícia é que prometo que as melhores equipes não operam nada como o que acabei de descrever.


Escrevi muitos artigos sobre os vários aspectos de como as melhores equipes funcionam.


Product Discovery é a forma que criamos soluções vencedoras para os problemas que estamos atacando. Discovery é uma colaboração ativa e contínua entre produto, UX Design e engenharia. Continuous Discovery e Continuous Delivery acontecem em paralelo. Os recursos dos roadmaps (output) são substituídos pelos problemas de negócios a serem resolvidos (outcome). O objetivo é o ajuste do produto/mercado.


Se sua empresa ainda estiver executando esse processo antigo e obsoleto, espero que você possa esclarecer isso e iniciar a transição para o futuro. E espero que você faça isso antes de se sentir perturbado por uma startup ou concorrente capaz de se mover muito mais rápido e com mais eficiência do que você pode.

Artigo Original: https://bit.ly/2R7zEgl