Discovery é mais estado de espírito do que método
Reflexões sobre o conceito criado por Marty Cagan e incrementado por Teresa Torres, normalmente difícil de racionalizar e de pôr em prática, como percurso e não linha de chegada
Discovery, que significa “descoberta”, em português, é um desses termos que volta e meia recebem novos esforços para serem melhor definidos e aplicados. Não faltam tentativas, de gurus de produto, design ou tecnologia em geral a principiantes na área, tentando delimitar e sistematizar o conceito em suas próprias palavras.
Não há como fugir disso. O conceito é amplo, intangível, difícil de racionalizar e muito mais difícil de pôr e de observar — de ser registrado como uma sequência de passos, como um método, um framework; em resumo, uma técnica — na prática.
Uma dessas tentativas de delimitação mais sucintas e elegantes para discovery é de Tim Herbig, um consultor, coach, autor e palestrante em gestão de produtos:
“A descoberta do produto descreve o processo iterativo de redução da incerteza em torno de um problema ou ideia para garantir que o produto certo seja criado para o público certo.” — Tim Herbig, em “Product Discovery: A Practical Guide for Agile Teams”.
Mesmo assim, isso demanda um tratamento analítico rigoroso de outros conceitos, deixa muitas lacunas para interpretação e não nos fornece absolutamente nada para transpor discovery diretamente para a prática, para transformá-lo em técnica.
Este artigo é uma tentativa de juntar algumas dessas partes e fornecer, senão o quadro completo (impossível), mas um mosaico de reflexões sobre o conceito. É mais um convite a se abrir a percepções do que tentar reduzir o conceito a termos precisos, ao que ele pouco se presta.
Se você não tem familiaridade com o termo e procura uma introdução a ele, Eduardo Valim fez um ótimo guia no blog da Awari. Se o seu negócio é ter um entendimento para aplicar discovery nos estudos ou trabalho, Alex Ivonika, que é professor na Awari, tem um material bem didático na Product Oversee.
Vale lembrar, discovery, da forma como originado e conceituado em relação a produtos de software, é um conceito que diz respeito tanto à Product Management como a UX Design e, também, à Engenharia ou Desenvolvimento de Software. Não é algo mais da alçada de uns do que de outros nessa tríade. Por isso, a discussão pode ser interessante sob várias óticas.
Sobre descoberta
Etimologicamente, discovery, de forma ampla e não restrita a sua conceituação em produtos de software, é definida pelo Oxford Languages, o dicionário do Google, como:
substantivo feminino
1. ato ou efeito de descobrir (algo), de retirar a proteção, a cobertura, a capa, o invólucro etc.; descobrimento.
2. ação, processo ou efeito de patentear ou revelar (o que não se sabia ou se achava escondido). “fazer uma descoberta”.
Parece que tendemos, na grande maioria dos casos, a encarar descoberta como um processo de tirar a cobertura de algo que já está lá, o que é muito mais confortável, previsível e, principalmente, “planejável”, do que encontrar, quase esbarrar, com algo que não temos como saber se está lá — que podemos, inclusive, desconhecer em absoluto.
Tomemos de volta uma analogia do texto anterior: Cristóvão Colombo na descoberta, chegada ou invasão, dependendo do ponto de vista, à América, em 1492.
Partir da Espanha apenas para fincar marco em uma terra que já se imaginava que existia, apenas não se conhecia em detalhes (como ocorrera com a chegada de Pedro Álvares Cabral no Brasil), é uma nuance de descoberta: apenas tratar de retirar as últimas dúvidas que encobrem uma quase-certeza ou certeza.
Outra nuance bem diferente é partir da Espanha para uma viagem de circunavegação, almejando alcançar a outra face das Índias, e esbarrar em um continente totalmente novo no meio do caminho — que é o que a história oficial nos conta, tanto que Colombo teria morrido acreditando que chegara à costa indiana.
(Comentário paralelo inevitável: de uma visão de negócios e de “produto”, que belo produto é um continente inteiro para se esbarrar em uma descoberta em que se apostava em outras hipóteses, não? Que o diga a quantidade de ouro, prata, madeira e outros artigos que se levaria ou se furtaria, também dependendo do ponto de vista, dessa descoberta para a Europa).
Pulando alguns séculos, o conceito de discovery em produtos de software foi cunhado por Marty Cagan, product manager, consultor, palestrante, escritor e o grande precursor e “papa” da gestão de produtos como é praticada hoje (além de ter um poder de persuasão enorme em seus textos — leia-os e tente não concordar com tudo o que ele prega).
Certamente, como Cagan diz, o termo ou pelo menos a noção de discovery já existia em design e gestão de produtos muito antes. A experimentação dele com o conceito, porém, começou por volta de 2005 e foi tratada mais a fundo em um texto de 2007, enquanto escrevia a primeira edição de Inspired: How To Create Tech Products Customers Love (Inspirado: Como criar produtos de tecnologia que os clientes amam, na versão brasileira), uma “bíblia” da gestão de produtos, onde o conceito seria consagrado.
“[...] As organizações de produtos precisam aceitar o fato de que o processo de invenção de produtos é fundamentalmente um processo criativo. É mais arte do que ciência.
“Prefiro pensar nesta fase como "descoberta do produto" mais do que "requisitos e design". Acho que essa nomenclatura enfatiza dois pontos muito importantes:
“Primeiro, você precisa descobrir se existem usuários reais que desejam este produto. Em outras palavras, você precisa identificar seu mercado e validar a oportunidade com seus clientes.
“Em segundo lugar, você precisa descobrir uma solução de produto para este problema que seja utilizável, útil e viável. Em outras palavras, você precisa projetar seu produto e validá-lo com seus clientes e sua equipe de engenharia.”
— Mary Cagan, 2007.
Em 2020, com a chegada da pandemia, o trabalho remoto, as dúvidas de como fazer discovery de produto à distância (além de confusões que sempre persistiram sobre o conceito), Cagan escreveu uma série de novos artigos sobre o termo. Em um deles, relembrando a história, revelou:
“Encontrei o termo ‘descoberta’ na indústria farmacêutica para o processo que usaram para chegar a um medicamento viável. [...]
“Eu também gostei do termo ‘descoberta’ porque era agnóstico em relação à técnica.
“Também gostei que o termo ‘descoberta’ incentivou as equipes de produto a pensar sobre os riscos de valor, usabilidade, possibilidade e viabilidade.”
— Mary Cagan, 2007.
Para Cagan, há dois problemas essenciais em produtos de software: descobrir o produto certo e construir certo o produto.
Em sua visão, empresas, startups e a indústria de software em geral (muito por conta da mentalidade calcada em engenharia e em batalhões de devs), concentraram esforços demais em construir produtos, não em descobrir o que clientes gostaria de usar e até pagariam para fazê-lo.
Isso jogou no mercado uma infinidade de produtos nascidos puramente da cabeça de engenheiros, chatos e difíceis de usar, às vezes mais uma demonstração de talento em programação do que algo que o público geral usaria, desejaria e pagaria — afinal, depois do estouro da bolha das empresas pontocom, em 2000, a brincadeira acabara, era preciso sair do playground e gerar receita.
Toda a evangelização de Cagan nesses anos tem como mensagem central essa inversão, ou melhor, equilíbrio, entre discovery (descoberta) e delivery (entrega) de produtos de software, com uma repetição às vezes até cansativa sobre a importância da descoberta:
“Sempre me interessei pelos dois problemas [discovery e delivery], mas acho que o primeiro é mais difícil e é onde acontece a maior parte das inovações, então é aí que concentro a maior parte da minha atenção.” — Marty Cagan, 2007.
Visionário. Realista. Assertivo. Com experiência em produtos fracassados, equipes de desenvolvimento perdidas, “ideias geniais” vindas em ordens top-down para apenas serem especificadas por gestores de produto em longos documentos de especificação de requisitos ou PRDs (Cagan abomina “requisitos”), as quais desenvolvedores cegamente cumpririam, Cagan encontrou sua causa e influenciou todo o jeito de criar produtos de software que hoje praticamos.
Em 2016, com a gestão de produtos pregada por Cagan já em curso em startups mundo afora, discovery ganhou um refinamento prático e, consequentemente, mais ênfase das comunidades de design e produto.
Teresa Torres, uma coach de produtos, criadora do Product Talk, ministrou uma palestra de pouco mais meia hora na Productized Conference, em Portugal, na qual traduziu discovery em métodos mais tangíveis e na qual introduziu uma reconceituação do termo, o Continuous Discovery (descoberta contínua).
O que em Cagan era escrita e uma boa dose de “filosofia” (não sem uma certa pegação de pé que todos, sempre, estariam fazendo ou interpretando discovery errado), com Torres foi tratado em termos que muitos designers e products managers não só entendiam, como adoravam: empatia, pesquisa com usuários e apoio de artefatos visuais, como a Opportunity Solution Tree (Árvore de Oportunidades).
Opportunity Solution Tree diz, basicamente, o seguinte. A partir de resultados a serem atingidos (outcomes), o time de produtos, que envolve gestor de produto, designer(s) e desenvolvedores, com base em entrevistas com clientes/usuários, passam a descobrir oportunidades (opportunity), que podem ser a satisfação de um desejo ou o atendimento de uma necessidade das pessoas ouvidas.
Oportunidades são desdobradas em possíveis soluções, que passam a ser testadas, até se chegar àquela que é mais viável, desejável e possível de ser desenvolvida. A solução, obviamente, tem de estar conectada e atender ao resultado (outcome) que desencadeou todo o processo.
O framework auxilia não só no discovery em si como também no acompanhamento e na comunicação do processo. Ele também permite enxergar onde é possível encaixar práticas consolidadas do design, como pesquisas qualitativas e quantitativas, testes de usabilidade, o Design Thinking e outras técnicas, na exploração de oportunidades e soluções.
Mais do que métodos e técnicas, porém, a mensagem de Torres é clara, conforme diz na palestra:
“[...] não importa se essas ferramentas específicas são fantásticas [...], mas aqui está a mensagem mais importante: daqui a cinco anos [...] nosso mundo está mudando, agora estamos falando sobre design sprints e job-to-be-done. Daqui a cinco anos, estaremos falando sobre dois métodos completamente novos. [...] pode parecer opressor, mas aqui está o que devemos lembrar: nosso objetivo não é escrever boas user stories ou fazer um bom user-story-mapping. Nosso objetivo é gerar um resultado desejado para nossos clientes, que crie valor para o nosso negócio. [...]” — Teresa Torres, 2016.
Apesar de times de produto já estarem aplicando técnicas para tentar tornar o discovery tangível, em 2016, Torres meio que catalisou o “como fazer” discovery e como ele deveria ser um processo contínuo.
Na verdade, Marty Cagan já falava isso, mas sem o termo continuous. Para ele, discovery não é uma etapa separada do desenvolvimento de um produto. Se isso fosse feito, estaríamos repetindo o velho waterfall (método “cascata”), em que gestão de produtos especificava requisitos, para depois designers desenharem telas, para então desenvolvedores criarem o código, um esperando e culpando os outros por atrasos no cronograma e falhas na execução.
Divergindo na prática
Cagan e Torres praticamente resumem a teorização de discovery. Quase tudo o que outros discorrem a respeito acaba bebendo no que eles já anteciparam.
Acontece que até aí, na teoria, o mundo é bastante perfeito. Empresas e startups se parecem com big techs. Times de produto são altamente eficientes e não tem atritos. “Sucesso” é uma consequência natural de produtos que seguem a filosofia.
Na realidade, sabemos que é ao contrário. Tanto quem pensa discovery quanto quem o pratica (ou faz ambos) não raro deve ter se perguntado mentalmente: “ou (o time, os C-levels, a organização) não entendemos ‘certo’ ou discovery é, realmente, muito inspirador na teoria, mas muito difícil de conduzir na prática?” A resposta é: as duas coisas.
Primeiro, há a questão do entendimento do conceito. Não é fácil nem óbvio intuir e internalizar discovery. Talvez as próprias digressões de Cagan em torno do conceito, na tentativa de explicá-lo, acabaram por torná-lo ainda mais nebuloso. Torres jogou um pouco mais de ingredientes etéreos na discussão.
O roteiro é mais ou menos assim — é uma generalização da história, para fins ilustrativos, e não um estudo de caso.
A startup ou empresa geralmente não vai chegar do dia para a noite e colocar discovery como um mandamento, uma ordem top-down. O conceito brota em meio às equipes de produtos, no dia a dia, normalmente por cultivo de um gestor de produtos mais inspirado na teoria ou de designers que militam a favor de entender a fundo e co-criar com os usuários. Embora possa ocorrer, parece mais raro desenvolvedores abraçarem a tarefa.
Ocorre que há um choque do time de produtos com a realidade da organização. Não há algo como duas ou três semanas ou, o ideal, dois ou três meses, para se debruçar realmente sobre um problema, decompô-lo e analisá-lo de vários ângulos.
Não há recursos para executar um discovery como idealizado a partir da teoria, como entrevistar clientes/usuários todos os dias. Às vezes, o pouco que se consegue fazer não fornece nada muito útil. A expectativa de coletar algo revelador cai por terra diante de percepções que não passam de óbvias.
Há toda uma mentalidade, um backlog e método de trabalho voltados à entrega de features (funcionalidades de software), para piorar.
Por ordem clara ou velada ou mesmo por comportamento adquirido, há aquela necessidade de manter desenvolvedores, que normalmente são maioria, o tempo todo ocupados com tarefas, de preferência tarefas bem especificadas, senão irão reclamar.
C-levels, gestores em geral, pessoal do RH, de vendas, finanças vêm praticamente determinar e não sugerir que algo seja implementado no produto, porque acreditam que resolverá um problema importante de determinada área (desconsiderando todo o resto da empresa ou do produto).
Em pouco tempo, o time de produtos passa a entender que não têm como fazer discovery sem que haja mudanças na cultura da organização, para uma gestão com mais autonomia, descentralização e alinhamento. Em vários contextos, pode ser uma barreira complicadíssima ou impossível de ser transposta.
Então, ou os profissionais largam o osso em busca de um lugar onde possam executar o discovery (e outros conceitos) como imaginaram a partir da teoria — sendo que o lugar perfeito para isso dificilmente existirá —, ou lutam para tentar mudar a cultura interna (o que pode ser frustrante, além de emocional e fisiologicamente caro), ou sobrevivem fazendo um discovery mequetrefe dentro das restrições, às vezes mais por questões automotivacionais.
Cagan fala de tudo isso nos vários artigos que escreveu. Uma cultura de administração centrada em entregas (outputs) e em comando e controle acaba, segundo ele, transformando colaboradores em “mercenários”, quando, na verdade, em produtos de software, teria de haver um contexto propício para o surgimento de “missionários” — guiados por uma grande visão, baseados em estratégia e com outcomes (resultados) a serem atingidos, em vez de outputs (entregas).
Algo comum de ocorrer é uma certa apropriação do discovery por parte de designers e sua inevitável confusão com UX Research, a pesquisa relacionada à experiência do usuário. À primeira vista, há sobreposições e ambiguidades entre ambos os conceitos.
Design pode se apropriar de discovery para justificar mais tempo para a prática de entrevistas, pesquisas e testes e para reivindicar mais recursos a tais práticas, como se discovery fosse algo mandatório e que terá sucesso garantido ao negócio.
O tempo e espaço para a prática pode levar a um exercício rico de desenho de artefatos, uso de frameworks e todo tipo de modelos mentais (a quem gosta disso, no Product Discovery Methods há vários e o Airtable listou e detalhou 43 métodos de UX Research que podem se aplicar no discovery). O resultado, porém, pode acabar sendo apenas paredes cheias de post-its, sem relação nenhuma com objetivos de negócio.
Em outras palavras, pode-se cair naquela zona de conforto de se criar mil mapas de jornadas, mapas de histórias, tentar conectar um artefato a outro, como se fossem algum tipo de bruxaria ou ritual capaz de revelar oportunidades ou problemas com grande potencial de inovação ou disrupção. Enquanto isso, esquece-se do quadro maior que são os objetivos e restrições do negócio.
Podemos dizer que há, nesse caso, um excesso em prol do “desejável” (um girar em torno de métodos de design e visão pró-usuário em si) e pouca ou nenhuma conexão com o “viável” (negócio) e o “possível” (engenharia).
É claro que, atualmente, muitas startups e empresas já amadureceram para o conceito, o incentivam e trabalham em uma cultura mais voltada à exploração aberta e demorada, para um discovery mais próximo do que é pregado na teoria. Investimentos, escala e condições financeiras, basicamente, não só permitem como levam a isso.
Mesmo neste cenário, porém, a prática também pode parecer distante dos escritos inspiradores de Cagan. Às vezes, embarca-se com entusiamo em um processo para tentar descobrir oportunidades a um produto já existente, por exemplo.
Entretanto, o tempo passa, clientes são ouvidos, tenta-se entrevistas e testes de protótipos ou outras iniciativas com usuários e parece que não se chega a nada de relevante em termos de impactos na receita do negócio.
Errou-se o início do processo? As premissas e hipóteses não estavam bem delimitadas? Estudos foram mal desenhados e usuários foram mal selecionados? Discovery é mesmo tudo isso que se prega na teoria? Volta-se à questão: estamos fazendo “errado” ou é mesmo difícil?
Talvez até haja a um bom entendimento de um problema ou oportunidade, mitigue-se riscos e chegue-se a uma solução que, naquele momento, revela-se promissora. Desenvolve-se e implementa-se e, a partir daí, surgem reclamações de clientes/usuários, há débitos técnicos e a solução tem resultados pífios ao longo do tempo. Desperdiçou-se tempo e recursos? Discovery foi mal aplicado ou não serviu ao caso?
Pessoas de produto e design mais experientes reinterpretaram à teoria para acomodar melhor essas situações. Um dos aprendizados tem sido o de que discovery, como o próprio Cagan diz, não é “bala de prata” (vale sempre lembrar que elas só existem em histórias de lobisomens).
O principal objetivo do discovery é diminuir riscos de se construir soluções caras que ninguém usará. Se não há risco significativo ou os benefícios ultrapassam em muito os riscos, não há porque perder tempo com processos de descoberta. Desenvolve-se, implementa-se e monitora-se para ver no que dá, o que pode resultar em sucesso ou, se ele não ocorrer, em aprendizado.
Aqui, há mais um ponto que pode gerar confusão e dúvidas, em especial em relação ao movimento Lean Startup e, em menor medida, ao Agile (metodologia ágil de desenvolvimento de software).
Se o Lean prega que o objetivo é prototipar rápido, isto é, ter um Minimum Viable Product (MVP), colocá-los logo nas mãos de clientes reais, para poder captar dados e aprender com eles e ir refinando a solução, iterativamente, por que tanta ênfase no discovery? Não há uma certa contradição nisso?
O raciocínio é de que, para um produto em fase inicial, onde mal se enxerga um palmo de futuro à frente, isto é, onde a incerteza é gigantesca e é dificílimo o cálculo de risco, o caminho é começar pequeno, apostar, medir e melhorar a partir do aprendizado obtido com os usuários.
Já para um produto maduro, em que há emergências decorrente de sua própria complexidade, pode ser muito mais arriscado fazer o mesmo movimento para ver no que dá. Há risco de se perder clientes, de se ferir regulamentações (em um setor regulamentado como fintechs, por exemplo), entre outras possibilidades.
Quem vem de empresas e práticas mais tradicionais também pode se perguntar: mas não é o mesmo que voltar a fazermos Pesquisa e Desenvolvimento (P&D), como nas grandes corporações e indústrias?
Alguns vão vociferar, sem arredar pé, que não. Que discovery é exclusivo dos ambientes de inovação, que P&D é retrógrado etc. Mas, de forma ampla, sim, é como fazer P&D, mas sem alocar todo um setor dedicado, com recursos próprios e todo um método de trabalho.
Visa-se ter mais agilidade, experimentação e novidades implementadas “a quente”, com o carro andando, até porque não se sabe muito bem para onde ele está indo (inovação é sobre incerteza).
Não é tão objetivo como, usando um exemplo de Cagan, produzir um novo medicamento ou encontrar uma vacina à covid-19. Nesse caso, você dedica um setor de P&D inteiro a trabalhar sobre o vírus, para descobrir suas fraquezas, até ter métodos que o neutralizem.
No caso da covid, o que ocorreu foi um encurtamento drástico do período de testes, para saber se as vacinas eram viáveis e seguras. Após se ter um mínimo de viabilidade e segurança, partiu-se para a produção e distribuição em massa das vacinas.
Em negócios fundamentados em produtos de software, falta essa objetividade, essa linha de chegada (tipo: produzir vacina para a covid-19).
A linha de chegada é, muitas vezes, um punhado de convicções e crenças no longo prazo (visão), normalmente bastante ampla para acomodar todo tipo de mudança de estratégia de médio prazo e de táticas de curto prazo, o que permite continuar vasculhando um território amplo em várias direções, caso outras não se revelem promissoras.
Como muitos produtos de softwares ou suas apostas agem onde há baixa criticidade (ninguém vai morrer em decorrência direta da falha em um e-commerce, por exemplo, ao contrário das vacinas), tem-se uma margem muito maior para se fazer pesquisas rápidas, lançar algo, testar a quente e ver se gera retornos ou não.
É nesse cenário que o Continuous Discovery ganha ênfase. Em vez de se deslocar um time ou parte de times para, em um momento, se dedicarem à descoberta de uma oportunidade ou problema e em outro momento à construção de uma solução (chama-se isso de Dual Track Agile, o que, para críticos, cheira a waterfall disfarçado), o time está envolvido de cabeça tanto na descoberta, como prática diária, quanto na entrega de soluções, normalmente pequenas, incrementais e decorrentes das explorações.
Requer prática e experiência no conceito e contexto e cultura organizacionais propícios, mas, mesmo assim, não elimina outros riscos, como falhas, erros e ineficiência ao longo desse processo contínuo. De outro modo: pode-se ter a sensação de fazer discovery contínuo no micro, mas de fato haver pouca entrega de valor real no macro.
Todas essas nuanças dizem respeito à conversão da teoria em prática. Um segundo aspecto diz respeito à teoria em si, à sua compreensão e interpretação.
Quem olhar detida e analiticamente à toda a conceituação de Cagan, Torres ou de outros que bebem neles, por exemplo, notará, com alguma perspicácia, que por um momento parece que discovery é enfatizado como um desapego total do solution space (espaço da solução).
— Temos que amar o problema! — dirá um product manager ou designer mais fiel aos escritos.
— Mas estamos há seis meses nisso! — reagirá um desenvolvedor que só queria estar perdido em alguma lógica exata.
— É porque você não entende nada de discovery. Você deve se deter demoradamente, questionar o problema mais um pouco, para não ficar no óbvio e querer partir logo para a solução — retrucará o primeiro.
“Explore o espaço do problema indefinidamente [...] Nunca seremos capazes de fazer alguma pesquisa e, em seguida, concluí-la. Sempre há mais para aprender. Sempre há outra nuance ou outra exceção a descobrir. É por isso que adotar práticas de descoberta contínua é tão importante.” — Teresa Torres, 2018.
Em seguida, você consulta Marty Cagan, que diz que “os avanços acontecem, precisamente, quando quebramos a parede entre problem space e solution space.”
“[...] uma consequência [...] é a frequência com que encontro equipes de produtos que associam a descoberta de produtos apenas com ‘explorar o espaço do problema’.” — Marty Cagan, 2020.
Ou que o tempo está correndo, para ficarmos um pouco mais perdidos:
“Você precisa perceber que, assim que começa a trabalhar em um problema, no que diz respeito à sua gestão, o tempo começa a correr. E em breve, eles [a gestão] vão querer ver os resultados. Se você passar a maior parte do tempo se aprofundando no problema, isso pode deixá-lo com muito pouco tempo para a solução.” — Marty Cagan, 2020.
Ou então: que, no fim das contas, ainda assim precisamos de soluções, é tudo sobre soluções:
“Em última análise, nosso trabalho na descoberta de produtos não é apenas validar o problema, mas encontrar uma solução que os clientes adorem, mas que funcione para o nosso negócio. O que isso significa especificamente é chegar a uma solução que seja valiosa, utilizável, viável e viável.” — Marty Cagan, 2020.
— Tá, devemos focar no problema ou na solução? Devemos dar tempo à exploração ou devemos ter alguma agilidade para ir logo à solução? Se nos perdermos indefinidamente no problema, não corremos o risco de cair numa falta de escopo enorme, conversarmos com todos os clientes possíveis, fazermos semanas de design thinking e produzir toneladas de mapas mentais, enquanto o concorrente já colocou qualquer coisa na rua? — pode-se perguntar o gestor de produtos cético e pragmático.
— É assim: tem que fazer isso todo dia, a Teresa Torres diz para conversar todo dia com os clientes/usuários. Mas eu entendo que temos que entregar com frequência algo sobre as descobertas e irmos aprimorando com o tempo — sugere um designer, tentando interpretar a teoria.
— Não é mais ou menos o que já fazemos na prática? É só mudar o botão de lugar ou acrescentar o campo no formulário? Manda ver. Chega a sugestão, que já captaram lá no atendimento ao cliente, de refazermos todo o fluxo de cadastramento. Não paramos, analisamos, investigamos e pensamos? O que é discovery ou não é nisso? — reflete o gestor de produtos.
Por um momento, na teoria, discovery pode até parecer uma alquimia, um conhecimento obscuro que só iniciados podem obter e exercitar ou que só organizações “rockstar” conseguem ter. Não é acessível ao dia a dia da maioria que atua em produtos de software. Ou, como toda bruxaria, aos mais pragmáticos, pode ser um pouco “frescura”.
O pragmático radical poderia dizer que é só um conceito bem inteligente, inventado e alavancado por gente esperta, para vender livros e palestras recorrentemente, dado as interpretações que o termo possibilita e toda a “mística” criada em torno — e que isso não tem correlação com o trabalho interminável que nos aguarda no backlog todos os dias.
Tentando convergências
Isso nos permite entrar em uma tentativa de conciliação reflexiva sobre discovery e de enxergá-lo mais como mindset, como sugerem alguns, ou cultura, ou uma “filosofia” de trabalho ou, como dito no título, um “estado de espírito”.
Discovery é mais um conceito para ser ruminado e destilado, e um esse “estado de espírito” que decorre da prática e da experiência em relação a um produto e a um contexto e cultura organizacional específicos relacionado a ele, do que uma definição com significado inequívoco e preciso, capaz de ser autoexplicativo.
Se retirarmos o verniz ou aura que o termo ganhou como uma mentalidade necessária para “produtos de sucesso”, chegaremos a algo parecido com a mentalidade científica na condução de experimentos, que nos fala sobre ceticismo, desapego, abertura, curiosidade, honestidade intelectual e outras virtudes.
Como o próprio Cagan e Torres comentam em meio a seus escritos e falas, discovery não tem a ver com processo, linearidade e com linhas de chegada (certezas), mas com a exploração de oportunidades e problemas frente a incertezas e riscos.
No fundo, podemos brincar que é um cálculo atuarial sem cálculo nem parâmetros onde se agarrar. É uma busca que pode ser tanto no infinito como no vácuo ou no nada.
Os métodos que aliamos ao discovery, como entrevistas e pesquisas quali ou quant com usuários, são meios para se tentar captar fragmentos ou meteoritos desse espaço. Mas eles são sempre partes do todo e nunca o todo, sobre os quais acabamos, de uma forma ou de outra, criando alguma narrativa para tentar preencher as lacunas que sempre sobrarão.
Em outras palavras, discovery não é a + b + c + n fatores = x descoberta que, se convertida em y solução ≡ produto de sucesso. Talvez o desejo é que fosse assim, uma fórmula, o que nos frustra tanto e gera confusões e problemas. Mas se fosse uma fórmula que bastasse aplicar, inovações seriam banais e não levariam essa denominação.
Falando em mentalidade científica, chegaremos também ao que cientistas e a arte em geral já se depararam há séculos ou milênios: discovery é como que a captura de uma ideia, um insight, a eureka de Arquimedes, aquela extração ou conversão (as palavras não ajudam) de algo do universo misterioso e intangível, capaz de brotar no mundo das ideias e ser transposto (não sem perdas e reduções) à realidade, em forma de artefatos, produtos, construtos, como quisermos.
E, para nossa infelicidade, não é algo que conseguimos replicar em escala industrial, gerar em linhas de montagem, contra o relógio e atendendo a metas.
Não que isso não ajude: a repetição gera quantidade que, estatisticamente, pode levar a uma descoberta realmente inovadora e disruptiva, mas será uma em um milhão ou bilhão de vezes (na verdade, jamais saberemos quantas), que minguaram à média.
Discovery, assim, é mais como uma conduta despretensiosa e desapegada, não uma meta a ser atingida. É totalmente processo e trajeto e não linha de chegada. Agora, porém, avise isso para o negócio, os gestores e acionistas, que dependem de metas?
Em outra comparação: você aposta que tem ouro aqui, em algum lugar, ou alguém já encontrou algumas pepitas que indicam (entrevistou clientes, digamos), e está disposto a escavar o quanto for preciso (gerar hipóteses, fazer prototipação rápida, testar). Mas onde está o ouro, em que quantidade e em quanto tempo será encontrado — quem arriscaria cravar?
Relutamos contra essa palavrinha, querendo eliminá-la de negócios e quase que da vida atual (como se tudo fosse passível de previsões matemáticas), mas há que se considerar o papel da sorte na inovação. Quem abomina a palavra pode trocá-la por “probabilidades”. É que sorte tem outro sabor, mais mundano.
Há quem possa paramentar-se de equipamentos, munir-se de belos mapas do terreno, contar com detectores de metais e toda uma sistematização de abordagem e passar anos em campo atrás do ouro. Enquanto, em um belo dia, um caipira despreocupado (a nova startup disruptiva daqui a alguns anos), escavando uma área para enterrar trapos ou plantar couves, esbarra na mina de ouro completamente ao acaso.
Em suma, o estado do espírito do discovery é o da tentativa aberta e exploratória e não o foco em resultados, mesmo que eles existam para que a busca não se torne um fim em si mesma ou algo à toa. Querer condicionar o “tentar, tentar e tentar de novo” com “temos que acertar” levará a muitas frustrações com a teoria e a prática, como as relatadas.
Não é fácil internalizar essa noção em nós mesmos, quem dirá nos outros próximos e, muito mais, em uma organização inteira. Também é fácil se perder pelo caminho, fazendo discovery inútil ou não o fazendo tanto quanto necessário. Talvez esse se permitir viajar nas nuances de um conceito tão interessante seja algum começo para esse desafio.
Artigo escrito por Rogério Kreidlow, jornalista, que gosta de observar a tecnologia em relação a temas amplos, como política, economia, história e filosofia.
Referências
Product Discovery, SPVG, Marty Cagan, 2007
The Origin of Product Discovery, SVPG, Marty Cagan, 2020
Introduction to Modern Product Discovery, Teresa Torres, 2016
6 Guiding Principles for Effective Product Discovery - Product Talk, Teresa Torres, 2016
Product Discovery: A Practical Guide for Agile Teams, Tim Herbig, 2021.
Discovery vs. Documentation, SVPG, Marty Cagan, 2021
Requirements Are Not, SVPG, Maty Cagan, 2010
The Alternative to Roadmaps, SVPG, MArty Cagan, 2015
Discovery - Excuses, SVPG, Marty Cagan, 2021
Discovery - Delivery, SVPG, Marty Cagan, 2020
Discovery - Judgement, SVPG, Marty Cagan, 2020
Discovery - Problem vs. Solution, SPVG, MArty Cagan, 2020
Discovery - Learning vs. Insights, SVPG, Marty Cagan, 2020
Product Discovery: O Que É, Quando não fazer e Como Fazer, Alex Ivonika, 2021