Neste artigo, gostaria de discutir as principais causas do porque os produtos fracassam. Vejo a mesma maneira básica de trabalhar na maioria das empresas e não posso deixar de notar que isso não está perto de como as melhores empresas realmente trabalham.

Permita-me avisá-lo de que essa discussão pode ser um pouco deprimente, especialmente se chegar muito perto de como é a sua situação, portanto, se for esse o caso, recomendo que você (como meu avô me dizia): “firmar o corpo”

Vamos começar percorrendo o processo que a grande maioria das empresas ainda usa para criar produtos. Vou tentar não enumerar nada por enquanto; deixe-me primeiro descrever o processo:

Porque produtos fracassam: o processo é quebrado

Tudo começa com as idéias. Na maioria das empresas, elas vêm de executivos, principais stakeholders, proprietários de empresas, ou grandes clientes (ou potenciais clientes), mas, de qualquer forma, sempre há um monte de coisas que diferentes partes da empresa precisam que façamos. (Isso apesar de existir diversas fontes de idéias para seu produto)

Agora, a maioria das empresas deseja priorizar essas idéias em um roadmap e o faz por dois motivos principais.

  1. Primeiro, eles querem que trabalhemos nas coisas mais valiosas primeiro.
  2. Segundo, eles querem prever quando as coisas estarão prontas.

Para fazer isso, quase sempre existe uma forma de sessão de planejamento trimestral ou anual em que os líderes consideram as idéias e negociam um roadmap do produto. Mas, para priorizar, eles precisam primeiro de uma forma de caso de negócios para cada item.

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

  • quanto dinheiro ela ganhará?
  • quanto dinheiro ou tempo custará?

Essas informações são usadas para elaborar o roadmap, geralmente para o próximo trimestre, mas às vezes até um ano. Nesse ponto, a organização de produtos e tecnologia tem suas ordens, e elas normalmente trabalham os itens da mais alta prioridade para as de menor prioridade.

Depois que uma ideia chega ao topo da lista, a primeira coisa que é feita é que um gerente de produto converse com os stakeholders e crie um conjunto de “requisitos”. 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.

Depois que os requisitos são reunidos, a equipe de design da experiência do usuário (supondo que a empresa tenha uma equipe) é solicitada a fornecer o design de interação, o design visual e, nos casos de dispositivos físicos, o design industrial.

Finalmente, os requisitos e as especificações do projeto chegam aos engenheiros. Geralmente é aqui que o Agile finalmente entra em cena. De qualquer forma, os engenheiros normalmente dividem o trabalho em um conjunto de iterações – chamadas de “sprints” no processo Scrum. Então, talvez seja preciso de 1 a 3 sprints para desenvolver a idéia.

Espero que o teste de controle de qualidade faça parte desses sprints, mas, se não, a equipe de controle de qualidade seguirá com alguns testes para garantir que a nova ideia funcione conforme anunciada e também não apresente outros problemas (conhecidos como regressões)

Assim que obtemos a luz verde do controle de qualidade, a nova ideia é finalmente implantada nos clientes reais.


Na grande maioria das empresas que conheço, grandes e pequenas, é assim que elas funcionam há muitos anos. No entanto, essas mesmas empresas sempre reclamam da falta de inovação e do tempo que leva para passar da ideia às mãos do cliente.

Você pode reconhecer que, enquanto mencionei o Agile, e embora quase todo mundo hoje afirme ser ágil, o que acabei de descrever é basicamente um processo em cascata. Para ser justo com os engenheiros, eles normalmente estão fazendo o máximo de “Agil” possível, devido ao contexto mais amplo da modelo Cascata.

OK, então pode ser isso que a maioria das equipes faz, mas por que essa é necessariamente a razão de tantos problemas? O que eu quero fazer agora é conectar os pontos para que você mostre por que essa maneira muito comum de trabalhar é realmente responsável pela maioria dos esforços fracassados ​​do produto.

10 motivos do porque produtos fracassam

Agora eu poderia literalmente falar o dia todo sobre os problemas desse processo, mas o que vou fazer aqui é compartilhar o que eu acho que são os 10 principais problemas mais sérios com esse modo de trabalhar. Para ser claro, estou argumentando que todos esses dez problemas são muito sérios, qualquer um dos quais poderia atrapalhar uma equipe, mas muitas empresas realmente têm a maioria ou até todos esses problemas.

1. Fonte ruim de idéias

Esse modelo leva a promoções direcionadas a vendas e produtos direcionados a stakeholders. Há muito mais sobre este tópico, mas, por enquanto, deixe-me dizer que essa não é a fonte de 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. São o que chamamos de “Mercenários”

2. Plano de negocio mal feito

Em seguida, vamos falar sobre a falha fatal nesses planos de negócios. Agora, para ficar claro, sou realmente a favor de planos de negócios, pelo menos para idéias que precisam de um investimento maior.

Mas a maneira como a maioria das empresas as faz, nesse estágio, para elaborar um roadmap priorizado, é realmente ridícula. Aqui está o porquê. Lembre-se dessas duas necessidades principais para cada caso de negócios? Quanto você ganhará e quanto custará? Bem, a fria verdade é que, nesta fase, não temos idéia de nenhum deles e não podemos saber.

Não conseguimos saber quanto ganharemos, porque isso depende de quão boa a solução acaba sendo. Se a equipe fizer um trabalho excelente, ela pode ser muito bem-sucedido e literalmente mudar o curso da empresa. Por outro lado, a verdade é que muitas idéias de produtos acabam não produzindo absolutamente nada. E isso não é um exagero! De qualquer forma, uma das lições mais críticas em produtos é saber o que não sabemos e, neste estágio, não sabemos quanto dinheiro ganharemos.

Da mesma forma, não temos idéia do quanto custará desenvolver o produto. Sem conhecer a solução real, é extremamente difícil para a engenharia prever. A maioria dos engenheiros experientes se recusará a dar uma estimativa nesse estágio, mas alguns são pressionados a comprometer.

Mas a empresa realmente deseja esses roadmap priorizados e, para obtê-los, eles precisam de algum tipo de sistema para classificar as idéias, para que as pessoas consigam definir o plano de negocio.

3. Roadmap mal planejado

Um problema ainda maior vem a seguir. As empresas ficam muito empolgadas com seus roadmap. Eu já vi incontáveis ​​roadmaps e a grande maioria deles são essencialmente listas de features priorizadas. O marketing precisa dessas features para uma campanha. Vendas precisa dessa feature para um novo cliente. Alguém quer uma integração com o PayPal.

Mas aqui está o problema, e talvez seja o maior problema de todos. Eu chamo isso de “duas verdades inconvenientes sobre o produto”.

A primeira verdade é que pelo menos metade de nossas idéias simplesmente não vai funcionar. Existem muitas razões para uma ideia não dar certo. O mais comum é que os clientes não estão tão empolgados com essa ideia quanto nós. Então eles optam por não usá-lo. Às vezes, eles querem usá-lo, mas tentam e é tão complicado que é simplesmente mais problemas do que vale a pena, que acaba com o mesmo resultado – os usuários não escolhem usá-lo.

Às vezes, o problema é que os clientes adorariam, mas acabou sendo muito mais envolvido do que pensávamos, e decidimos que simplesmente não podemos arcar com o tempo e o dinheiro para realmente entregar.

Por isso, prometo que pelo menos metade das idéias do seu roamdap não oferecerá o que você espera. A propósito, as equipes realmente boas assumem que pelo menos três quartos das idéias não terão o desempenho esperado.

As boas equipes de produto assumem que pelo menos 3/4 das idéias não terão o desempenho esperado

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

Uma das coisas mais importantes sobre o produto que aprendi é que simplesmente não há como escapar dessas verdades, não importa o quão inteligente você seja. E tive a sorte de trabalhar com muitas equipes de produtos verdadeiramente excepcionais. A verdadeira diferença é como você lida com essas verdades.

4. Gestão de produto inexistente

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

Dica de leitura: diferença de produto e projeto.

5. Ausencia de um design UX

É uma história semelhante com o “papel do design”. Já é tarde demais para obter o valor real do design, e principalmente o que está sendo feito é o que chamamos de modelo “passar batom no porco”. O estrago já foi feito e agora estamos apenas tentando colocar uma camada de tinta na bagunça. Os designers de UX sabem que isso não é bom, mas tentam fazer com que pareça o mais agradável e consistente possível. (ao invés de trabalhar em conjunto com os engenheiros )

6. Time de engenharia sem voz

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 codificar, está recebendo apenas metade do valor deles. O pequeno segredo do produto é que os engenheiros geralmente são uma excelente fonte de inovação, mas eles nem são convidados para a parte nesse processo.

7. Metodologias Ageis não é aplicada no seu potencial total

A engenharia não só é trazida muito tarde, mas os princípios e os principais benefícios 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 entrega, mas o restante da organização e o contexto são tudo menos ágeis.

8. Foco no projeto e não no produto

Todo esse processo é muito centrado no projeto. A empresa normalmente financia projetos, projeta equipes e os impulsiona pela organização e, finalmente, lança projetos. Infelizmente, os projetos são produzidos e o produto tem tudo a ver com resultado.

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 criar produtos.

Dica de leitura: diferença de produto e projeto

9. Produto sem validação no mercado (pelos clientes)

A maior falha do antigo processo Cascata 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 “na moda”. O princípio principal é reduzir o desperdício, e uma das maiores formas de desperdício é projetar, construir, testar e implantar uma feature ou produto apenas para descobrir que não é o necessário.

A ironia é que muitas equipes acreditam que estão aplicando princípios “lean“, mas seguem o processo básico que acabei de descrever. E depois aponto para eles que eles estão realmente tentando idéias de uma das maneiras mais caras e lentas que conhecemos.

10. Tempo (e oportunidade) desperdiçadas

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

A maior perda de todas, acaba sendo a perda de oportunidade

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.)

Conclusão

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. O “Discovery” de produtos é como criamos soluções vencedoras para os problemas que estamos atacando. Ela é uma colaboração ativa e contínua entre produto, design de experiência do usuário e engenharia.

A etapa de “Discovery” e a entrega são contínuas e acontecem em paralelo. As features dos roadmaps (entrega) são substituídos pelos problemas de negócios a serem resolvidos (resultado). O objetivo é o “market fit”

Se sua empresa ainda estiver executando esse processo antigo e obsoleto, esperamos 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ê.