Produtos fracassados

Nota: Este artigo é a versão escrita de uma palestra que dei para desenvolvedores na Craft Conference e para gerentes de produto e designers no Mind The Product.

Neste artigo, quero falar sobre as causas pelas quais tantos produtos fracassam.

Por que produtos e lançamentos de produtos fracassam?

Na maioria das empresas, vejo a mesma forma básica de trabalhar, e isso não se compara nem de longe à forma de trabalhar de empresas realmente boas.

Deixa-me fazer um alerta, porque essa discussão pode ser desanimadora, especialmente se você for diretamente afetado por esse tema. Se esse for o caso, peço apenas um pouco de perseverança.

O processo de desenvolvimento de produto

Vamos primeiro dar uma olhada em qual processo a maioria das empresas ainda utiliza para desenvolver seus produtos. Vou tentar não fazer julgamentos por enquanto, apenas descrever o processo:

Tudo começa com ideias. Na maior parte das empresas, essas ideias vêm da diretoria, dos principais stakeholders, dos donos do negócio ou de grandes clientes (ou clientes em potencial). De qualquer forma, existe uma série de coisas que precisamos fazer para as diferentes áreas de uma empresa.

Em seguida, na maioria das empresas, as ideias são priorizadas em um Roadmap e isso acontece por dois motivos: primeiro, porque se quer trabalhar nas coisas mais valiosas primeiro, e segundo, porque se quer poder estimar quando essas coisas estarão prontas.

Para isso, quase sempre existe uma reunião de planejamento trimestral ou anual, na qual os líderes revisam as ideias e negociam um Product Roadmap. No entanto, para poder priorizar tudo, eles precisam primeiro de uma espécie de Business Case para cada item.

Algumas empresas elaboram Business Cases formais, outras mais informais, mas em ambos os casos o objetivo é descobrir as seguintes duas coisas:

1) Quanto dinheiro podemos ganhar com isso?

2) Quanto dinheiro ou tempo vai custar? A partir dessas informações, o roadmap é então criado, geralmente para o próximo trimestre, mas às vezes até para um ano inteiro.

Neste ponto, existe a ordem de marcha para o produto e a tecnologia, e normalmente os trabalhos são então realizados por ordem de prioridade.

Quando uma ideia chega ao topo da lista de prioridades, o gerente de produto primeiro conversa com os Stakeholders para elaborar a ideia e formular "requisitos".

Esses podem ser User Stories ou algum tipo de especificação funcional; o objetivo, no entanto, deve ser sempre a comunicação com os designers e desenvolvedores que vão construir o produto.

Uma vez que se tem todos os requisitos, a equipe de User Experience Design (desde que exista uma equipe assim na empresa) é solicitada a cuidar do Interaction Design, Visual Design e, no caso de hardware, do design do produto.

Por fim, os requisitos e especificações de design chegam aos desenvolvedores. Este é normalmente o ponto em que o Agile entra em cena.

O papel dos desenvolvedores no processo de desenvolvimento

Os desenvolvedores então dividem o trabalho em iterações, chamadas de "Sprints" no Scrum. Geralmente leva de 1 a 3 Sprints para implementar a ideia.

No melhor cenário, os testes de QA estão integrados ao Sprint. Caso contrário, a equipe de QA realizará alguns testes posteriormente para verificar se a ideia funciona como esperado e se não surgem outros problemas (também chamado de regressão).

Assim que você recebe luz verde da equipe de QA, a ideia finalmente é implantada e chega ao usuário.

Quase todas as empresas onde entro, sejam grandes ou pequenas, trabalham dessa forma há muitos anos. E ainda assim, todas essas empresas reclamam consistentemente da falta de inovação e do longo tempo que leva até uma ideia finalmente chegar às mãos dos clientes.

Ágil vs. Cascata

Você pode ter notado que, embora eu tenha mencionado Agile e hoje em dia quase todo mundo supostamente trabalha de forma ágil, o processo que acabei de descrever é basicamente um processo Waterfall. Para ser justo, devo dizer que os desenvolvedores frequentemente extraem o máximo possível do Agile dentro desse processo Waterfall.

Ok, talvez essa seja a abordagem da maioria das equipes, mas por que isso é necessariamente sempre a causa de tantos problemas?

Por que tantos produtos fracassam por causa disso?

Vou tentar mostrar a você a conexão de por que essa forma de trabalho tão difundida é, na verdade, responsável pelo fracasso da maioria dos produtos.

Eu poderia falar uma eternidade sobre os problemas desse processo, mas vou simplesmente listar os Top 10 dos problemas mais graves dessa forma de trabalho. Mesmo que cada um desses dez problemas seja realmente grave e possa derrubar uma equipe, a maioria das empresas enfrenta muitos ou até todos esses problemas ao mesmo tempo.

1) Vamos começar pelo topo – a fonte de ideias. Esse modelo leva a ofertas orientadas por vendas e produtos orientados por stakeholders. Há muito a dizer sobre esse tema, mas por enquanto quero apenas dizer que essas não são as melhores fontes para ideias de produtos. Outra consequência dessa abordagem é a falta de empoderamento da equipe, pois nessa abordagem ela é responsável apenas pela execução – mercenários.

2) Vamos falar sobre a fraqueza dos Business Cases. Para que você não me entenda mal, eu acho business cases fundamentalmente bons, pelo menos para ideias que representam um investimento maior. Mas a forma como a maioria das empresas os cria nesse momento, para obter um roadmap priorizado, é realmente ridícula. Lembra das duas coisas que fundamentam qualquer business case? Quanto você vai ganhar e quanto vai custar? Nesse momento, simplesmente não podemos saber isso, porque não temos ideia de nenhum desses dois fatores.

Simplesmente não podemos saber quanto vamos ganhar, pois isso depende principalmente de quão boas serão nossas soluções. Se a equipe fizer um trabalho excelente e for extremamente bem-sucedida, isso pode mudar todo o rumo da empresa. Por outro lado, a triste verdade é que a maioria das ideias de produtos não gera absolutamente nada. E isso não é exagero. Quero dizer realmente nada. De qualquer forma, uma das lições mais importantes no desenvolvimento de produtos é saber o que não podemos saber. E simplesmente não podemos saber nesse ponto quanto dinheiro vamos ganhar.

Da mesma forma, não temos ideia de quanto custará desenvolver o produto. Sem uma solução concreta, isso também é muito difícil de estimar. Muitos desenvolvedores experientes se recusam a dar uma estimativa tão cedo, embora alguns façam o bom e velho compromisso do "T-Shirt": pelo menos digam se é "Small, Medium, Large ou Extra Large"!

Empresas querem roadmaps priorizados e para isso precisam de um sistema para avaliar as ideias. Então as pessoas simplesmente jogam o jogo do Business Case.

3) A seguir vem um problema ainda maior. Empresas adoram Roadmaps. Já vi muitos roadmaps e a maioria deles é basicamente apenas uma lista de features priorizadas. O marketing precisa desse feature para uma campanha. Vendas precisa desse feature para um novo cliente. Alguém quer integrar o PayPal. Acho que você entendeu o que quero dizer.

No entanto, há um problema e talvez seja o maior de todos. Eu chamo de "as duas verdades inconvenientes sobre produtos".

A primeira verdade é que pelo menos metade das nossas ideias simplesmente não vai funcionar. Há tantas razões pelas quais uma ideia não funciona. O mais comum é que os clientes simplesmente não ficam tão entusiasmados com a ideia quanto nós. Então eles não usam o produto. Às vezes eles querem usar, mas é tão complicado que causa mais problemas do que benefícios. Então o resultado é o mesmo: os clientes não usam. Às vezes os clientes adorariam o produto, mas acontece que há muito mais esforço envolvido do que pensávamos e simplesmente não temos o dinheiro e o tempo para desenvolvê-lo.

Eu garanto que pelo menos metade das ideias no seu roadmap não vai entregar o que você esperava. E a propósito, as equipes realmente boas assumem que pelo menos três quartos das ideias não vão funcionar como pensávamos.

Como se isso não fosse ruim o suficiente, a segunda verdade é que mesmo com ideias que realmente têm potencial, normalmente são necessárias várias iterações até que sejam implementadas a ponto de realmente entregar o valor de negócio necessário. Chamamos isso de "Time To Money".

A coisa mais importante que aprendi em relação ao desenvolvimento de produtos é que simplesmente não há como escapar dessas duas verdades – não importa quão inteligente você seja. Tive a grande sorte de trabalhar com muitas equipes de produto realmente extraordinárias. A diferença está em como você lida com essas verdades.

4) O papel do produto nesse modelo: na verdade, eu nem falaria do produto como um papel. Basicamente, é mais uma forma de gerenciamento de projetos. Nesse modelo, trata-se mais de coletar requisitos e documentá-los para os desenvolvedores. Acredite em mim, isso não tem nada a ver com gestão de produtos moderna.

5) É semelhante com o papel do design. Nesse ponto, já é tarde demais para criar valor real através do design. Então recorre-se ao chamado modelo "Lipstick on the pig". O estrago já está feito e estamos apenas tentando disfarçar. Os UX Designers sabem que isso não é bom, mas tentam fazer tudo parecer o melhor e mais uniforme possível.

6) O que mais faz perder oportunidades nesse modelo é provavelmente o fato de que o desenvolvimento só é envolvido tão tarde no processo. Dizem que se você usa seus desenvolvedores apenas para escrever código, você perde metade do valor que eles poderiam oferecer. Desenvolvedores são normalmente a melhor fonte de inovação e, no entanto, nem sequer são envolvidos no processo.

7) Não apenas os desenvolvedores, mas também os princípios e principais benefícios do Agile entram em cena tarde demais aqui. Equipes que usam Agile dessa forma obtêm apenas cerca de 20% do valor e potencial dos métodos ágeis. Aqui, Agile se refere apenas à entrega, mas o resto da organização e do contexto continua sendo tudo menos ágil.

8) Todo o processo é muito orientado a projetos. Uma empresa financia projetos, contrata pessoal para os projetos, impulsiona os projetos e os implementa. Infelizmente, projetos são apenas Output, mas o desenvolvimento de produtos é sobre Outcome. Esse processo inevitavelmente leva a projetos órfãos. Ok, algo foi lançado no final, mas não cumpre o propósito real. Então qual é o sentido? Esse é um grande problema e está muito próximo de como construímos nossos produtos.

9) A maior fraqueza do antigo processo em cascata é e sempre foi o fato de que todo o risco aparece no final. A validação pelo cliente simplesmente acontece tarde demais.

Espero que você já tenha ouvido falar dos métodos Lean Startup, que representam praticamente o oposto disso. O princípio principal é minimizar o desperdício, e o maior desperdício é projetar, construir, testar e fazer deploy de um feature ou produto, apenas para descobrir que não é necessário. Ironicamente, muitas equipes acreditam que estão aplicando os princípios do Lean, mas na verdade estão apenas seguindo o processo descrito acima. E então eu explico a elas que estão testando suas ideias da forma mais cara e lenta que conhecemos.

10) E por último, mas não menos importante, enquanto estamos ocupados com o processo e desperdiçando nosso tempo e dinheiro, os custos de oportunidade das coisas que uma organização poderia e deveria ter feito representam a maior perda. Esse tempo e todo esse dinheiro nunca mais recuperaremos.

Não estou muito surpreso que tantas empresas invistam tanto dinheiro e tempo e recebam tão pouco em troca. Eu avisei que isso poderia ser deprimente.

A boa notícia é que posso garantir que as melhores equipes não trabalham nem de longe da forma que descrevi.

Resumo

Já escrevi muitos artigos sobre os diferentes aspectos das melhores equipes. Product Discovery trata de como encontramos soluções bem-sucedidas para nossos problemas. É uma forma ativa e contínua de colaboração entre as áreas de Produto, User Experience Design e Desenvolvimento. [Continuous Discovery e Continuous Delivery](/pt/product-owner/discovery-vs-delivery/ "Discovery vs. Delivery) acontecem em paralelo. Features em roadmaps (Output) são substituídas por problemas de negócio que precisam ser resolvidos (Outcome). O objetivo é que o produto se encaixe da melhor forma possível na demanda do mercado (Product/Market Fit).

Se a sua empresa ainda está presa nesse processo antigo e ultrapassado, esperamos que agora você consiga esclarecer as coisas e começar com um novo olhar para o futuro. E espero que você consiga isso antes de ser ultrapassado por uma startup ou concorrente que seja muito mais rápido e eficaz do que a sua empresa.

Este texto é do blog de Marty Cagan e foi traduzido por nós para o alemão.

Tabela modelo para o Product Backlog

=> Assim você pode representar User Stories no Product Backlog como uma tabela.

O Product Goal Canvas

=> Defina seu objetivo de produto com o Product Goal Canvas.