Faz algum tempo que não escrevo. O motivo é que estou trabalhando com uma cliente em um modo mais hands-on, que chamo de CPO interino, para acelerar alguns temas de produto importantes para a organização como cultura de produto, visão e estratégia de produto, feature teams vs product teams. Esse tipo de trabalho é bastante intenso do ponto de vista de tempo, requer muitas conversas para que eu possa entender os diferentes aspectos da empresa, seu modo de operação e sobre o business para que eu possa fazer um diagnóstico e, a partir desse diagnóstico, desenhar a 4 mãos um plano de ação. Por isso não tenho conseguido escrever com a frequência que gostaria. Por outro lado, nesse trabalho surgiu um tema que acredito ser de interesse de várias empresas e vários times de desenvolvimento de produto, a necessidade de discovery, que será o tema desse artigo.

Já encontrei algumas vezes, pessoas do time de desenvolvimento de produto (gestoras de produto, designers e engenheiras) querendo fazer discovery para entender bem o problema antes de construir uma solução, enquanto pessoas de outras áreas, com bastante experiência no tema do produto, acreditando que existem coisas básicas que não precisam de discovery, só precisam ser implementadas. Desse debate vem a pergunta: pode haver situações em que o product discovery não é necessário?

Resposta curta: sim, pode haver situações em que o product discovery realmente não é necessário.

Antes de entender que situações são essas, devemos lembrar que discovery não é processo, mas sim uma caixa de ferramentas para mitigação de riscos. Que tipo de riscos? O principal risco é o risco de construir um produto, ou uma funcionalidade, que vai “flopar”, ou seja que vai ser um fracasso. Construir produto custa caro, normalmente o time de desenvolvimento de produto é um dos mais caros da empresa, e temos também os custos com infraestrutura e ferramentas de desenvolvimento de produto, que também não são baratas.

Por que um produto ou funcionalidade pode ser um fracasso?

• A cliente vai querer? (risco de valor para a cliente)
• Vai trazer retorno para a empresa? (risco de viabilidade de negócio)
• A gente consegue construir? (risco de desenvolvimento)
• A cliente vai saber usar? (risco de usabilidade)

Precisamos responder às perguntas acima da melhor forma possível para evitar construir um produto ou funcionalidade que será um fracasso, o que é um desperdício de tempo, dinheiro e trabalho.

Contudo, o discovery pode não ser necessário se tivermos alguma situação em que:

1. não temos nenhum dos riscos descritos acima, ou;
2. existe algum (ou alguns) dos riscos acima devidamente identificado, mas o custo (financeiro, tempo) para mitigar esse risco é maior do que o custo de fazer o produto ou funcionalidade.

Vou dar alguns exemplos para ajudar a tangibilizar essas situações.

Construção de funcionalidades bem conhecidas

Quando uma funcionalidade é bem conhecida, isso significa que alguém já fez o discovery, já encontrou uma boa solução, e o mercado já está acostumado com essa solução. Em um caso como esse o discovery pode não ser necessário. Imagine que você está trabalhando na construção de um eCommerce. Já existem muitos ecommerces no mercado. A maioria das pessoas já comprou em um ecommerce, e já teve experiências boas e ruins. Consequentemente, a maioria das pessoas sabe qual eCommerce funciona bem para servir de benchmark para o eCommerce que você construindo. É o famoso “não precisamos re-inventar a roda”.

Por outro lado, você pode estar criando um eCommerce para um novo nicho de mercado que não é atendido ou é mal atendido pelas soluções existentes. Em um caso como esse, o discovery será útil. Só que você não precisará fazer discovery de tudo, poderá fazer discovery em cima das soluções existentes. O que elas tem de bom? E o que não funciona ou poderia ser melhorado para ser mais adequado para esse nicho específico que vc está atendendo? E, para entregar rápido valor tanto para a cliente, quanto para a empresa dona do produto, minha recomendação é implementar a melhor solução existente e, a partir dessa solução, fazer discovery para melhor atender seu nicho.

Construção de funcionalidades requeridas por questão regulatórias

Se você está construindo em um mercado regulamentado, você terá que implementar algumas funcionalidades para cumprir com essas regulamentações. Por exemplo, se você está construindo um produto no mercado financeiro, é importante chegar as regulamentações do BACEN, o Banco Central do Brasil. Se vc está trabalhando em um produto na área de medicina, certamente encontrará algumas regulamentações que deverão ser observados e que irão implicar e construir certas funcionalidades em seu produto.

Um dos produtos que desenvolvemos na Locaweb chamava-se PABX Virtual, um sistema de PABX que rodava na nuvem utilizando a tecnologia VoIP (Voice over IP), o que era uma novidade na época (2006). Acontece que o mercado de telefonia é um mercado bastante regulado. No Brasil temos a Anatel, a Agência Nacional de Telecomunicações, uma agência reguladora para fiscalizar as empresas que oferecem serviços de telecomunicações no país. O PABX Virtual da Locaweb está no mercado de telecomunicações e, consequentemente, deve seguir certas definições ditadas pela Anatel. Por exemplo, todos os meses tínhamos que enviar relatórios em um determinado formato para a Anatel, ou seja, nenhum discovery foi necessário. O que precisava ser feito já estava pré-determinado pela agência reguladora do mercado de telecomunicações.

Construção de funcionalidades urgentes

Por algum motivo você está em uma situação em que uma solução deve ser implementada de forma urgente. Por exemplo, uma crise como a da COVID-19, ou a infra-estrutura onde está o seu produto foi hackeada. São situações que requerem ação imediata.

Quando a pandemia veio, estávamos nos peprarando no Gympass para lançar o Gympass Wellness, marketplace de apps de atividade física, nutrição e meditação, em modo piloto para 5 empresas no Brasil e 5 empresas nos EUA, o que representava 0,5% de nossa base total de clientes na época. A ideia era testar se havia interesse nessa oferta, ou seja, fazer um discovery com um MVP para validar se havia interesse. Assim que a pandemia chegou e foi ordenado o lockdown pelas autoridades, decidimos incluir o Gympass Wellness na oferta principal do Gympass como uma forma de dar uma alternativa para nossos clientes que estavam com seus funcionários presos em casa. Acabou sendo uma ferramenta de retenção muito importante para o Gympass e, em função da pandemia, acabamos cancelando o modo discovery em que estávamos e passamos a oferecer o produto para toda a base de clientes. Simplesmente não havia tempo para discovery.

Discovery é ferramenta

Temos a tendência de achar que esse tema tem só duas respostas, devemos “fazer discovery” ou “não devemos fazer discovery”. Contudo, existem diferentes níveis de discovery a depender dos diferentes riscos e dos diferentes níveis de risco que temos. Em função disso, a resposta para pergunta “devemos fazer discovery?” não é simplesmente sim ou não. Você pode estar trabalhando em uma funcionalidade que tem muito pouco risco envolvido e você pode fazer discovery para resolver aquele risco específico, podendo ter um discovery que dure poucos dias ou mesmo poucas horas.

Importante, lembre-se que discovery é uma ferramenta, e como qualquer ferramenta, há situações em que pode não ser a ferramenta mais apropriada. Para poder entender qual é a ferramenta mais apropriada, precisamos antes entender os princípios, que são o guia de comportamentos que utilizamos nas situações do dia-a-dia. Tenho falado bastante ultimamente sobre os 4 princípios essenciais de uma cultura de produto:

1. Entregas rápidas e frequentes: não dá para querer inovar e fazer novos produtos fazendo entregas mensais ou trimestrais de código.
2. Foco no problema: entender bem o problema para só depois pensar em hipóteses de solução. Testar diferentes hipóteses para ver qual resolve melhor e mais rápido.
3. Entrega de resultados: o que um time de desenvolvimento de produtos tem que entregar são resultados. Produto, app, feature, algoritmo não são o objetivo, são meios para entrega de resultado.
4. Mentalidade de ecossistema: é o foco no cliente, só que turbinado. Toda empresa tem mais de um cliente, e é preciso entender esses diferentes tipos de clientes e suas relações.

Entendendo bem os princípios, podemos avaliar qual ferramenta mais pode nos nos ajudar a praticar esses princípios.

Por fim, se você não tem certeza se precisa ou não fazer discovery, minha recomendação é agir com cautela, elencar e priorizar os riscos e entender se é possível mitigar esses riscos de alguma forma rápida, tendo em mente que a nossa prioridade nº 1 é gerar resultado o mais rápido possível. Resultado para a empresa que é dona do produto, e para as clientes para quem o produto vai resolver um problema ou atender uma necessidade.

Resumindo

• Discovery é ferramenta de mitigação de risco. Por isso, pode haver situações em que o product discovery não é necessário. Se tivermos alguma situação em que (1) não temos nenhum risco, ou (2) existe algum (ou alguns) risco devidamente identificado, mas o custo (financeiro, tempo) para mitigar esse risco é maior do que o custo de fazer o produto ou funcionalidade.
• Alguns exemplos de situações que podem não precisar de discovery são (1) construção de funcionalidades bem conhecidas, (2) construção de funcionalidades requeridas por questões regulatórias e (3) construção de funcionalidades urgentes.

Programa In-company de Educação Continuada em Gestão de Produtos

Meu mais novo produto é o Programa In-Company de Educação Continuada em Gestão de Produtos, para ajudar você e sua equipe a aumentar seus conhecimentos sobre conceitos, princípios e ferramentas de gestão de produtos e, consequentemente, aumentar a taxa de sucesso de seus empreendimentos de produtos digitais.

Esse produto é composto de 3 elementos:

• Palestra de kick-off para toda a empresa, intitulada Lições Aprendidas de um Transformação Digital, onde apresento através de exemplos práticos como a cultura de produto pode potencializar a jornada de digitalização da uma empresa.
• Treinamento mensal sobre temas de gestão de produto e de transformação digital, para ajudar as pessoas da empresa a conhecerem conceitos, princípios e ferramentas que ajudam na criação de produtos digitais de sucesso. Existe uma sequência padrão, que pode ser revisada para se adequar às necessidades da empresa. Devem participar desse treinamento todas as pessoas de produto e de design, as lideranças de tecnologia e as lideranças das outras áreas da empresa. Para conhecer mais detalhes sobre o conteúdo, acesse esse documento.
• Mentoria, sessões individuais ou em grupo, onde trabalhamos temas vistos nos treinamentos ou outros temas que sejam relevantes.

As sessões podem ser presenciais ou remotas! Confira na página de testemunhos o que as pessoas dizem de meus serviços.

Faz sentido para a sua empresa? Vamos conversar! É só entrar em contato comigo por email ou WhatsApp, ou marcar um horário na minha agenda.

Treinamento e consultoria em gestão de produtos e transformação digital

Ajudo líderes de produto (CPOs, heads de produtos, CTOs, CEOs, tech founders, heads de transformação digital) a enfrentarem seus desafios e oportunidades de produtos digitais por meio de treinamentos e consultoria em gestão de produtos e transformação digital.

Newsletter

Escrevo reguIarmente sobre gestão de produtos, desenvolvimento de produtos, liderança de produtos digitais e transformação digital. Vc pode receber uma notificação por email sempre que eu publicar algo novo, sem depender dos algoritmos de notificação de redes sociais. Basta assinar minha newsletter.

Gestão de produtos digitais

Você trabalha com produtos digitais? Quer saber mais sobre como gerenciar um produto digital para aumentar suas chances de sucesso, resolver os problemas do usuário e atingir os objetivos da empresa? Confira meu pacote de gerenciamento de produto digital com meus 3 livros, onde compartilho o que aprendi durante meus mais de 30 anos de experiência na criação e gerenciamento de produtos digitais. Se preferir, pode comprar os livros individualmente:

• Liderança de produtos digitais: A ciência e a arte da gestão de times de produto.
• Gestão de produtos: Como aumentar as chances de sucesso do seu software.
• Guia da Startup: Como startups e empresas estabelecidas podem criar produtos de software rentáveis.