Construindo o que os clientes precisam: a receita definitiva

De acordo com Clayton Christensen, professor da Harvard Business School, quase 30.000 novos produtos são lançados a cada ano e 95% falham. Embora esse número esteja mais relacionado a produtos físicos, basta um pouco de esforço para perceber que isso é verdade para produtos digitais. E esse é um pensamento assustador e perturbador porque startups e empreendedores investem muito dinheiro para construir esses produtos. Isso nos leva a uma pergunta importante que todo gerente de produto e as equipes de tecnologia associadas se fazem toda vez que mergulham no rio da construção de produtos digitais. Por que os produtos falham e o que as equipes podem fazer para criar os produtos de que os clientes precisam?

Alguns dias atrás, eu estava conversando com um gerente de produto de uma das maiores empresas de software de nosso tempo. Ele lidera várias equipes há mais de dois anos. A parte mais emocionante de sua experiência é que ele conduziu mais de 50 experimentos nesses dois anos. E isso ajudou sua equipe a entender o que construir e, mais importante, o que não construir para os clientes. Conversando com ele, entendi que esses experimentos eram caros em termos de capital e tempo. Portanto, até mesmo decidir quais experimentos realizar era complicado, pois a equipe precisava justificar o capital necessário para realizar os experimentos.

Infelizmente, apenas algumas empresas têm tanta largura de banda e capital para experimentar. E, portanto, é extremamente importante entender o que os clientes precisam e construir os produtos de acordo. Mas antes de nos aprofundarmos em como construir os produtos que os clientes precisam, é essencial entender por que as empresas falham em fazê-lo.

Razões pelas quais as empresas falham em criar produtos que os clientes precisam

• Resolvendo o problema errado

Após investigação, descobriu-se que a automação era possível apenas ajustando os sistemas. E o problema não era usar “ML” para automatizar determinadas tarefas, mas sim automatizar determinadas tarefas principalmente porque eram demoradas. De fato, após uma pesquisa mais profunda, descobriu-se que essa automação não era necessária. Isso foi possível porque o gerente de produto investiu tempo para entender e definir o problema. E é por isso que é imperativo entender o problema em níveis mais profundos para que a equipe/empresa encontre o problema certo para resolver. Esta é a primeira e principal etapa, e a maioria dos produtos falha nesta etapa.

• Visando a solução perfeita

Algo semelhante aconteceu com o gerente de produto com quem conversei. Ele estava envolvido na construção de um produto que substituiria completamente o atual sistema de gerenciamento de conteúdo para cerca de 600 usuários internos. O prazo inicial para a construção desse sistema foi de 12 meses. Mas quando a equipe de engenharia começou a trabalhar na solução, eles se depararam com vários casos extremos. Isso aumentou o cronograma de 12 meses para 18 meses. Quando os usuários souberam disso, começaram a questionar todo o sistema de gerenciamento de conteúdo. O ponto deles era que, se levasse tanto tempo para construir todo o sistema, levaria períodos semelhantes e mais extensos para criar novos recursos no futuro. Então, eles continuaram pressionando para que mais recursos fossem adicionados ao escopo.

Tudo isso aconteceu porque as equipes de tecnologia estavam esperando para construir e lançar a melhor solução. O gerente de produto compartilhou que, em vez disso, eles deveriam ter dividido o sistema de gerenciamento de conteúdo em recursos secundários mais priorizados e lançá-los de forma iterativa, em vez de um lançamento de sistema big-bang. Felizmente, o risco de liberar dessa forma era menor já que o sistema era voltado para usuários internos, mas isso poderia ter sido um problema maior se os usuários fossem externos.

• Não Obtendo Feedback Antecipado

Em 30 de junho de 1970, a AT&T revelou seu serviço comercial Picturephone na cidade de Pittsburgh, Pensilvânia. Cegos por sua própria visão, os executivos da empresa ignoraram o feedback negativo que a empresa recebeu na fase de testes. Eles acreditavam que um milhão de unidades estariam em uso dez anos após o lançamento. Para sua surpresa, eles o retiraram do mercado em apenas três anos devido à falta de interesse do consumidor. Porque?

Durante a fase de teste, os usuários compartilharam seus comentários. Eles acharam o equipamento muito volumoso, a tela muito pequena e cara. Mas tudo isso foi ignorado, levando ao fracasso de todo o produto.

Obter feedback desde o início e trabalhar nele ajudará você a criar a solução certa para os problemas de seus clientes.

Produtos de construção que os clientes precisam

• Abordagem de trabalho para trás

• Cabeçalho — Idealmente, deve ser o nome do produto e basicamente dizer do que se trata o produto
• Subtítulo — O principal benefício do produto
• Resumo — Resuma o que o produto faz junto com seu principal benefício
• Problema — Problema específico que este produto resolve
• Solução — De que maneira o produto resolve o problema
• Citação de você - Crie um porta-voz fictício e peça uma frase explicando por que este produto é obrigatório.
• Como começar — Explique como usar o produto da maneira mais fácil possível.
• Fechamento e chamada à ação — Finalize o press release informando ao leitor como saber mais ou como começar a usar o produto.

• Design Sprint

Um dos exemplos que o gerente de produto compartilhou foi como um sprint de design ajudou sua equipe a decidir entre construir e comprar. Sua equipe foi incumbida de mudar o fluxo de produção de conteúdo que dava suporte a 400 usuários internos. A tarefa desses usuários era criar conteúdos (imagens, vídeos, gifs, etc.) diariamente que apareciam no site para 50 milhões de usuários ativos diariamente. Foi dito que o novo fluxo de produção de conteúdo economizou 2 milhões de euros por ano em 2020. O gerente de produto reuniu uma equipe de sprint composta por alguns usuários, seu líder, um gerente de engenharia e um líder de design. A corrida durou uma semana. No final do sprint, a equipe de tecnologia não apenas entendeu o problema em questão, mas também apresentou uma solução de baixo custo que eles converteram em um produto completo em um período de 2 meses.

• Feedback Quantitativo e Qualitativo

• O feedback quantitativo inclui experimentos como testes A/B, pesquisas com perguntas fechadas e análises de produtos. Isso requer aptidão analítica, pois os dados são grandes e expressos em gráficos e números.
• O feedback qualitativo inclui pesquisa usando questionários com perguntas abertas, entrevistas 1:1, observação direta, investigação contextual, grupos focais e coleta de dados personalizados. Em comparação com o feedback quantitativo, isso é expresso em palavras.

Como tal, existem várias maneiras de entender o que os clientes precisam e criar soluções de acordo, e depende exclusivamente da empresa e da equipe usar qualquer um dos métodos. Mas, o mais importante é não construir produtos que os clientes não precisam. A história diz que quanto mais cedo o feedback for obtido dos clientes, mais fácil será construir as soluções certas e economizar recursos.

Que método você usa em sua equipe/empresa para construir o produto/solução certo? Que problemas você enfrenta ao usar este método? Comente abaixo; Eu adoraria saber.