Estratégia de produto: Como fazer e quais os desafios

No decorrer dos últimos anos dei uma série de palestras enquanto estudava sobre vários assuntos de produto, como Visão de Produto, As verdades sobre ser Data-Driven, contei cases meus de Teste A/B, aprofundei no polêmico tema "Roadmap" e alguns outros tópicos. Mas um dos assuntos que mais gosto é estratégia de produto (ou Product Strategy para os mais chegados).

Como o alcance de qualquer palestra é limitado, resolvi fazer um artigo condensado alguns aspectos sobre Product Strategy. Porém, assim como a maioria dos artigos que tenho escrito ultimamente, este acabou ficando bem longo também. Então esteja bem acomodado ou vá lendo aos poucos.


Gerenciando um produto

Diferente do que muita gente pensa, gerenciar um produto não é tão simples quanto parece. Você precisa organizar os processos, motivar e influenciar as pessoas certas para fazer com que o produto seja um sucesso.

Mas como evitar que um produto vire um Frankestein com tanta demanda de diferentes áreas? Bom, pra começar você precisa ter duas coisas: i) Uma visão para o seu produto e; ii) Gerenciar ele baseado nessa visão.

OBS: Eu escrevi sobre isso em meados de 2016 e você pode ler aqui. É importante para o entendimento desse artigo e não acho que vale a pena estender o assunto aqui já que essa parte do conteúdo está disponível em outro local.


Não crie um software Frankenstein — todo remendado, lento e que não faz nada bem. Se for para remendar (e convenhamos, muitas vezes não temos opção) pelo menos crie um software Robocop que também é todo remendado (se vocês lembrarem do filme) mas é forte e robusto.

1. Lidere com o problema e não com a solução


Pirâmide do Product-Market Fit. Referência: The Lean Product Playbook escrito pelo Dan Olsen

Esse é o cerne de todos os problemas de estratégia de produto. Peguei o conceito da Pirâmide do Product-Market Fit do Dan Olsen para ilustrar melhor esse erro clássico.

O foco do time de produto deveria ser na proposta de valor e nas necessidades não atendidas, conforme a imagem abaixo — é justamente onde você encontra o Product-Market Fit e possíveis alavancas para melhorar seu produto. Por isso é tão importante executar bem a fase de Discovery (mais detalhes sobre discovery em artigos futuros).

1.0.1 Ilustrando com Jobs to be done

O problema é que naturalmente nós pensamos nas soluções antes de entender o problema e por isso muitos times de produto (normalmente os ruins) focam em UX e conjunto de features. Tenho certeza que você já leu isso em vários lugares diferentes então vou poupar explicações e ir direto para exemplos práticos.

Jobs to be Done é uma boa forma de ilustrar como focar em problemas e não em soluções. Veja o caso abaixo, o consumidor simplesmente quer conselhos que ele possa confirar, ter uma direção certa do que fazer, se sentir motivado e inspirado etc. A forma que você alcance esses objetivos pouco importam — e essa forma são geralmente as soluções.

 

1.1 Exemplo Zendesk

O Zendesk foi lançado em 2007 mas levou 6 anos de muitos experimentos e investimentos para que eles lançassem o Help Center, o qual é uma extensão natural do serviço de tickets deles. Posteriormente eles cresceram tanto que criaram o Zendesk Suite que é composto por uma série de produtos que resolvem problemas distintios.

Qual o aprendizado que podemos ter com o Zendesk aqui? Eles só expandiram o produto quando acharam que tinham resolvido o primeiro problema.

Referência: https://www.zendesk.com/company/press/zendesk-announces-60-million-financing/

1.2 Exemplo Easytaxi Empresas

Apesar de ser um produto que está prestes a acabar (Cabify adquiriu o Easy Taxi e o branding do Cabify deve ser mantido enquanto o do Easy desaparece) durante o período que trabalhei no Easy Taxi deu para ver um bom trabalho sendo executado. Quando lançamos o Easy Taxi Corporate ele era uma extensão natural do aplicativo de pedir corridas de Taxi porém focado para as empresas e com o objetivo de facilitar o reembolso e gastos por centro de custo. A versão para empresas só foi lançada depois de alguns anos e durante um bom período foi um dos produtos mais lucrativos da empresa.

A mesma lição que tivemos com o Zendesk podemos ter com o Easy Taxi — apenas expandir o seu produto quando você resolver muito bem um problema.

2. O que fazer depois de encontrar market-fit? 

Só quando seu produto solucionar muito bem um problema você pode se preocupar em expandi-lo

Imagine uma tesourinha de cortar unha. É muito fácil de explicar o que ela faz e, por consequencia, é fácil de vender. Quer cortar unha? Compre uma tesourinha! Ela é fácil de manusear porque ela faz uma coisa com excelência — sem mencionar o fato de que ela é rápida para ser criada e testada.


Qual produto você usa para cortar suas unhas?

Agora coloque um canivete suiço do lado de uma tesourinha de cortar unha. O que o canivete suiço faz bem? Você já cortou a unha com algum? Aposto que não… No mundo real a gente não costuma utilizar ferramentas que fazem de tudo. Se o seu amigo precisa de ajuda para colocar alguns parafusos com certeza não vai ser com um canivete que você vai apertar os parafusos. É muito legal e bonito falar que você tem um (assim como as empresas costumam fazer com o seu produto cheio de funcionalidades). Mas no mundo real, é dificil explicar para que ele serve, até porque ele não faz nada bem — o que prejudica a adesão do produto.

Existe um grande pesquisador da teoria dos sistemas chamado John Gall que concluiu que um sistema complexo que funciona bem evoluiu de um sistema simples que funcionava bem. De acordo com a Lei de Gall, um sistema complexo não pode ser projetado a partir do zero, caso contrário ele não vai funcionar bem e não vai poder ser consertado. É necessário que ele surja a partir de sistemas simples. Gall disse isso em 1975 e até hoje é válido. Encaixa em todos os conceitos de lean startup, ágil etc.

Um sistema complexo que funciona é invariavelmente a evolução de um sistema simples que funciona.
Um sistema complexo projetado a partir do zero nunca funciona e não pode ser consertado. Você tem que começar partindo de um sistema simples
Lei de Gall

2.1 Regra de bolso: O que pensar antes de criar novas funcionalidades?

  • Está dentro da sua visão? Ela vai manter ou tirar você do caminho da visão?
  • Vai fazer sentido em 5 anos? Ela não vai se tornar obsoleta em 5 anos?
  • Ela beneficia todos os usuários? Se não todos, pelo menos a maioria? (Você precisa evitar fazer funcionalidades que beneficiem poucos clientes)
  • Qual o objetivo? Melhorar alguma coisa que não está bem feita? Aumenta o uso do produto?
  • E se a funcionalidade for um sucesso e todo mundo tiver usando, vai ser possível dar suporte para ela?

Confesso que na correria do dia a dia nem sempre consigo seguir essas regras de bolso mas me esforço ao máximo. Antes de pensar em avançar na criação de alguma funcionalidade me questiono com as perguntas acima. Isso tem me ajudado muito em todos os projetos que participo e dessa maneira quase nunca fugimos da visão/direcionamento estratégico.

2.2 O problema que ninguém vê em produtos com muitas funcionalidades

Existe uma diferença entre fazer um produto simples, e fazer o produto ser simples.

Uso do app de finanças pessoais (exemplo)

Se você fez um bom trabalho, você vai entregar o MVP do seu produto em algumas semanas. E como ele é bem enxuto você vai perceber que a maioria das pessoas está usando tudo. O que importa é que elas estão relamente fazendo o que você quer que elas façam.

No exemplo da imagem imagine que você criou um MVP de um app de finanças pessoais. Neste caso todas as funcionalidades estão sendo utilizadas quase que igualmente. Mas o seu produto vai evoluindo e evoluindo… Então em algumas semanas você simplesmente cria outras funcionalidades.


App de finanças pessoais com novas funcionalidades adicionadas — cenário que você imagina (exemplo)

Você lança mais funcionalidades achando que todas elas vão continuar sendo usadas bastante. Mas mesmo que você erre, vocês devem estar imaginando que o pior cenário é o ao lado "Ah, se der ruim as pessoas não vão utilizar as funcionalidades novas mas as antigas vão continuar com uso alto"


App de finanças pessoais com novas funcionalidades adicionadas — cenário que geralmente acontece(exemplo)

Quando na verdade o pior que pode acontecer é cair o uso de quase todas as suas funcionalidaes — impactando o produto de maneira geral. Afinal ele ficou mais complexo.

Agora imagine um cenário mais ou menos como o da imagem ao lado. Isso significa que você tem um produto incrivelmente bom nessas duas áreas. Mas que você adicionou um bocado de porcaria junto. Imagine se chega algum competidor e pensa “Opa. A melhor parte na verdade é só essa. Então vou criar um produto que só é bom nisso e acabar e ganhar o mercado”. Nessa hora que um novo player domina o mercado.

Evite criar funcionalidades que não são necessárias. E se por acaso você errar (quem nunca desenvolveu algo que não devia?) tenha coragem para matar a funcionalidade e lide com os stakeholders e aqueles poucos usuários chateados. 

2.2.1 Você precisa ser bom no que importa

Exemplo 1: Google+ e Hangouts

O Google também seguiu a mesma linha com Hangouts. Ele surgiu dentro do Google+ e rapidamente o Google viu que o Hangout gerava muito mais engajamento que o Google+ e desmembrou eles (sábia decisão).

Exemplo 2: Facebook e Messenger

Também temos o Facebook como grande exemplo disso. Lembram quando era tudo junto? O aplicativo de mensagens junto com a rede social? Eles primeiro separaram o aplicativo e em seguida separaram no site também. Agora você pode acessar exclusivamente o Messenger do Facebook — mesmo sem ter um perfil no Facebook.

2.2.2 Não adianta ser bom no que importa se você pode ser facilmente copiado

Sou extremamente cético em relação ao futuro do Dropbox e muito curioso em ver pessoas inteligentes apostando nele como uma empresa que vai ser duradoura. O Dropbox é um ótimo serviço de sincronização de arquivos e já fizeram uma baita grana inovando no segmento — mas tenho a impressão muita gente ficou cega pela emoção do Dropbox ser um utilitário bem elaborado e esqueceram de olhar por outra perspectiva. Na prática o Dropbox é facilmente copiável e rapidamente se tornou praxe sistemas operacionais terem um sistema de cloud nativo — prejudicando o market share do Dropbox.

Apesar de muita gente ainda acreditar neles já dá pra ver uma resposta do mercado onde eles não enxergam um futuro próspero para o Dropbox — a não ser que algumas medidas drásticas sejam feitas. Veja o valor da ação abaixo:

Em 2018, as receitas do Dropbox aumentaram 26% em relação ao ano anterior, chegando a US$ 1.4 bilhão. Apesar de ser um bom crescimento, está abaixo de 31% e 40% que foram as taxas de crescimento de 2017 e 2016, respectivamente. Provavelmente isso está relacionado ao fato de estar muito mais fácil ter Cloud Storage — hoje temos o Google syncando tudo (Google Photos, Drive, etc), a Apple fortíssima como iCloud e até a Microsoft com o One Drive.

Querendo ou não quem está numa posição competitiva vantajosa são as empresas que são donas de sistemas operacionais: Apple, Microsoft ou Google. Cada uma dessas empresas tem uma solução similar ao Dropbox que já integra ao sistema e, sem esforço algum, o usuário tem seus arquivos salvos na nuvem.

O Dropbox obviamente está trabalhando para deixar de ser apenas uma "funcionalidade" e se posicionar diferente perante outras alternativas. Por isso não adianta você ser incrível em alguma coisa se pode ser facilmente copiável. Em 2009, Steve Jobs queria pagar mais de US$ 100 milhões pelo Dropbox, mas o CEO Drew Houston recusou a oferta e logo em seguida (talvez num ato de raiva) Jobs disse que o Dropbox era uma funcionalidade e não um produto. Ao meu ver ele estava certo. 10 anos depois dá pra ver que as empresas que possuem sistemas operacionais tem uma grande vantagem e não precisam do Dropbox.

Na verdade, até hoje, o Dropbox frequentemente tem problemas em sincronizar alguns arquivos. Vou usar como exemplo o Office, se você esquecer de fechar ou salvar o arquivo do Word no seu computador, ele não estará sincronizado no seu Dropbox. Isso não é culpa do Dropbox — é o Office que bloqueia esse tipo de ação. Mas isso destaca o que estou falando: o Dropbox só tem controle sobre uma pequena parte dos sistemas operacionais.

Tentando se diferenciar

O Dropbox já adquiriu pelo menos 10 empresas e a mais recente foi a HelloSign. Essa aquisição elimina a necessidade de integrar com outros serviços de assinatura (Docusign, Adobe Sign etc) e faz com que os usuários continuem dentro do ecossistema do Dropbox. Ter uma assinatura eletrônica nativa pode tornar a plataforma mais atraente para as empresas e ao meu ver esse movimento tem como objetivo principal entrar mais forte no mercado enterprise já que o B2C está saturado com o Google, Apple e Microsoft — isso inclusive faz com que a empresa ataque mais fortemente o seu outro concorrente Box.

2.3 Celebre o uso e não a entrega

Manifesto agil fala da entrega. Só que mais importante que isso é o uso. Inclusive é algo que o manifesto agil deveria evoluir e na minha visão está desatualizado. 

Outra opção seria criar um manifesto de produto, afinal na época da criação do Manifesto Ágil o mundo pensava muito em entregar valor para os clientes e não entender o problema em si. De qualquer maneira isso é um bom assunto para outro artigo. 

Mas ressalto estes 3 pontos:

  • Entregar algo não é nada.
  • Taxa de uso é TUDO.
  • Faça mais pessoas usarem uma funcionalidade ou faça elas usarem mais do que o normal.

Recapitulando antes de irmos pra última parte do artigo: 

Pra gerenciar bem o escopo de um produto, é necessário sempre medir as funcionalidades que estão sendo usadas. Entender que mais funcionalidades não vão necessariamente te dar mais usuários. E o ideal é primeiro resolver um ou dois problemas muito bem antes de pensar em evoluir o produto, afinal, você minimiza suas chances de erro começando por sistema simples ao invés de começar desenvolvendo um sistema complexo. E, por últitmo, considere sempre deixar os seus produtos desacoplados caso você detecte que eles possam ter propósitos diferentes porém com uma integração de sistemas útil para a maioria dos usuários.

3. Erros comuns de estratégia de produto

3.1 Querer se provar

Empresas, principalmente startups, cometem um erro de querer “se provar” com mais funcionalidades — como se isso fosse um diferencial hoje em dia. Você prefere o Excel ou o Google Sheets? É óbvio que o Excel tem mais funcionalidades, em especial as avançadas, mas o Sheets engoliu uma bela fatia do mercado com a simplicidade e focando em necessidades mais abrangentes como, por exemplo, edição de múltiplas pessoas em tempo real — algo que a Microsoft teve que copiar anos depois, com o Office 365.

3.2 Intuição levando ao erro

Muitas vezes a gente se pega pensando “Agora com essa nova funcionalidade os downloads vão aumentar!” ou algo como “Agora com essa funcionalidade vamos ter 1000 clientes novos pagando”. Embora isso possa acontecer, as chances de você estar enganado são enormes. Não se iluda! Nessa hora é importante lembrar da visão e seguir com ela independente das funcionalidades.

3.3 Falha na hora de gerenciar o portfólio de produtos (apenas para times maiores)

Uma das coisas mais difícieis em gerenciar um portfólio de vários produtos é fazer uma boa priorização de iniciativas. As empresas disfuncionais tendem a considerar todas as iniciativas como alta prioridade e isso, obviamente, torna tudo muito complicado.

Pela minha experiência os 4 maiores erros na gestão de um portfólio são os abaixo (em ordem):

  1. Projetos demais para a capacidade da empresa. Geralmente é um problema de alocação de pessoas. Empresas disfuncionais tendem a priorizar mais do que são capazes de entregar
  2. Decisões que vão e voltam e são tomadas em cima da hora, tornando tudo ineficiente
  3. Não ser capaz de inovar rápido o suficiente e perder o time to market. Normalmente a empresa possui uma série de disfunções, ou time incapacitado, e a inovação/velocidade não acontece. Uma solução que algumas empresas adotaram é criar uma unidade de negócio separada para dar velocidade e autonomia para algumas equipes.
  4. Sem forma consistente ou transparente de medir o sucesso dos produtos — a não ser por receita, o que coloca a empresa e a equipe de produtos numa situação ruim, na qual o foco é dinheiro e não resolver problemas com bons produtos (algo que leva tempo mas o resultado é muito superior)

Esses erros acima geram grandes disfunções nas empresas. i) Perda e tempo e/ou dinheiro; ii) Oportunidades de aumento de receita são perdidas; iii) A empresa começa a perder a sua vantagem competitiva; iv) Demorar muito para matar produtos e deixar um legado enorme de 'produtos zombie' que dão uma certa renda extra mas no fundo tiram o foco de uma série de profissionais que poderiam estar atacando produtos com um potencial maior; 

3.3.1 O que se perguntar para endereçar esses problemas

  • Utilizar o que já tem: Que tecnologias e ativos (assets) temos atualmente que podemos utilizar para alavancar o nosso negócio atual ao invés de investir em criar algo do zero?
  • Tentar detectar a necessidade de novas habilidades e recursos: temos as pessoas certas e com as habilidades certas? E os nossos ativos atuais dão apoio aos novos investimentos para inovação?
  • Condições do mercado em constante mudança e novos concorrentes: Como podemos garantir que podemos agir com rapidez e ter uma vantagem competitiva?
  • As equipes de produto e engenharia agora precisam focar em muitas variáveis como tecnologias, serviços, localização, apps, mensagens e outros itens essenciais — geralmente ao mesmo tempo. Como podemos garantir que estamos conectando todas as equipes e mapeando as dependências para garantir que cada lançamento seja bem-sucedido?

Além de se fazer as perguntas acima e tentar responder elas de uma maneira completa e sem correria, o ideal é fazer os 4 passos abaixo também: 

  1. Tomar decisões mais baseadas em dados do portfolio (e não necessariamente apenas números financeiros)
  2. Consistentemente seguir o processo de portfólio (obviamente para ter um processo você precisa criar um primeiro);
  3. Realocar pessoas e dinheiro para inovações de maior oportunidade — não necessariamente o que tem o maior valor no presente;
  4. Aumentar o foco (investimento de tempo) no gerenciamento de porftólio ao invés de reuniões demoradas e análises puramente financeiras.

Espero que esses insights possam ajudar qualquer profissional (seja agora, em 2019, seja no futuro) a resolver os problemas de estratégia de produto na sua empresa. Não acho que exista uma resposta correta para isso e sim vários métodos diferentes. Meu objetivo aqui era apenas compartilhar o que aprendi até hoje com as experiências que tive. 

Se você que chegou até o fim do artigo tiver outros insights de como melhorar a estratégia de produto dentro das empresas, por favor, deixe um comentário e vamos discutir para crescer juntos. Só assim vamos ser capazes de inovar mais e aumentar a receita ao mesmo tempo. 

Torne-se um Product Manager completo

Aprenda com os melhores profissionais do mercado neste curso totalmente online com mais de 40 horas de conteúdo. 24/7, aonde e quando quiser!

QUERO
Close

50% Complete

Baixe a ementa