O que queremos dizer com Discovery?
Interpretações sobre discovery em desenvolvimento de produtos digitais sob a perspectiva do design e da gestão de produto.
No dia a dia com os projetos percebo uma certa confusão com o conceito de “Discovery”. Para além do processo de buzzificação dos termos que, sabemos, de tanto serem repetidos, endeusados, gourmetizados, usados e desusados, esvaziam-se; tanto em sentido quanto em significado.
Para pessoas de produto, o que se espera do discovery pode ser algo totalmente diferente do que designers esperam. Isso tem gerado atritos em propostas comerciais, projetos e dificuldades de estabelecer entregáveis, especialmente no contexto de consultorias.
Já ouvi de designers, por exemplo:
“Cheguei achando que iria fazer todo aquele discovery, mas o que o cliente me pediu foi para fazer benchmarking e testes A/B.”
Depois fui entender, que o benchmarking serviu para orientar a priorização de funcionalidades para melhorias no produto e os testes A/B serviriam para informar melhor decisões de design de interfaces do produto.
Ou seja, se estas atividades não serviram para descobrir oportunidades para o produto — real valor dos processos de descobertas — o que então queremos dizer com discovery?
Percebi que o colega estava frustrado, pois sua expectativa de “discovery” envolvia aprofundadas pesquisas e análises.
Por que designers e gerentes de produto entendem o discovery de maneiras diferentes?
Parte desta confusão, entendo que vem da literatura dessas duas áreas.
De um lado, podemos entender o discovery como “Product Discovery” relacionado a literatura de Product Management — temos aí, grande influência do Marty Kagan do Livro Inspired, da Lean Startup, e autores como Tim Herbig.
Por outro lado, temos o discovery como “Discovery Phase” conectado a literatura de Design — como visto em artigos importantes de Maria Rosala (NN Group) e o próprio conceito de discovery do duplo diamante do Design Council.
Como “Product Discovery”:
“…é entendido como um processo cíclico e contínuo envolvendo todo o processo necessário para ‘descobrir e desenvolver o produto certo’.”
Ou seja, pode envolver pesquisa (e não se limitar a ela), ideação, testes, metrificação, etc. E, além disso, está bastante conectado ao processo de validação de hipóteses.
Já como “Discovery Phase”, podemos entender mais especificamente o estágio “Descobrir e Definir” do modelo de diamante duplo”:
“Uma descoberta é uma fase preliminar no processo de design de UX que envolve pesquisar o espaço do problema, enquadrar o(s) problema(s) a ser resolvido e reunir evidências suficientes e direção inicial sobre o que fazer a seguir.”
Ou seja, não envolveria o processo de validação de hipóteses.
O que as abordagens de discovery possuem em comum?
Tanto a primeira abordagem quanto a segunda possuem aspectos em comum.
A principal delas é que em ambos os casos, estamos falando de entender, explorar e dar maior atenção ao espaço do problema, em detrimento do espaço da solução.
Ou seja, com processos de “discovery” queremos entender se há de fato um problema a ser explorado mercadologicamente e porque ele é um problema? Quem se interessa em resolver este problema? São algumas perguntas fundamentais desses processos que valem a pena o investimento.
Como deveríamos colaborar em discovery?
Como se trata de descobertas e um processo ancorado em aprendizagem humana, não é de forma alguma um processo linear, com início, meio e fim. Pelo contrário, é iterativo, cíclico e dinâmico. Além disso, o esforço necessário para responder a estas perguntas de aprendizagem vai exigir uma abordagem multidisciplinar, diversa e ampla. Por isso não faz sentido que o discovery seja apenas responsabilidade de um ou outro papel em um time. É, ou deveria ser, uma missão compartilhada.
Por isso, eu particularmente, defendo que designers devem trabalhar de mão dadas com pessoas de produtos. As visões e focos são complementares, mesmo embora, eles compartilhem de processos, métodos e ferramentas em comum (personas, pesquisas, mapa de jornadas, blueprints, testes, etc).
Concluindo, quando entendemos estas duas concepções diversas sobre o discovery podemos entender melhor o que se espera de cada uma delas. E isso também reflete nos tipos de entregáveis.
Se entendemos discovery como product discovery, podemos entregar:
- Definição do problema baseado em evidências
- Mapas conceituais de serviço
- Mapas de jornada do usuário
- Declarações de necessidades do usuário
- Personas
- Conceitos ou wireframes de alto nível (para explorar com testes)
- Business Value Proposition
- “Backlog validado”
- MVP
⠀
Se entendemos discovery como discovery phase, podemos entregar:
- Resultados de pesquisa com usuários
- Desk research
- Curadoria de tendências
- Pesquisa de mercado
- Mapas conceituais de serviço
- Mapas de jornada do usuário
- Declarações de necessidades do usuário
- Personas e mapas de empatia
Ou seja, podemos sim falar a mesma língua, respeitando os diversos contextos e também nossas referências. Por estas e outras, acho importante termos essa clareza e alinharmos as nossas expectativas.
Existe uma abordagem mais certa que a outra? Claro que não.
A pergunta que devemos nos preocupar é outra:
- Qual a expectativa do cliente em um Discovery?
- Por que precisamos de um, em primeiro lugar?
Se a necessidade é compreender em profundidade as necessidades, ainda não conhecidas dos usuários, então um discovery com viés de design research seja o caminho. Já, se a necessidade é modelar e validar um novo modelo de negócios, um viés de processos e métodos mais orientado a produto, cairia muito bem.
