Você não precisa de um discovery!

Ok, vamos com calma. Apesar do clickbait, talvez você realmente não precise de um Discovery. Pode ser só uma questão de simplificar o processo. Independente da sua situação, nesse texto eu conto um pouco de como nosso time de design tem amadurecido esse tema e buscado realizar essa etapa tão importante de forma mais eficiente.

Como designers, somos confrontados o tempo todo com discussões sobre como fazer um Discovery ou até mesmo como provar o seu valor. De um lado, temos profissionais que lutam por espaço estratégico, do outro, empresas preocupadas com a eficiência dos seus times. Conquistar esse espaço vai muito além da abertura para realizar pesquisas, é preciso alinhamento com negócio e entrega de valor.

Como chegamos até aqui

Não tenho a intenção de abordar com detalhes o que é um Discovery em si, mas acredito que algumas informações são importantes para contextualizar melhor o momento que nos encontramos no mercado de tecnologia no geral.

No início do século XXI, o Manifesto Ágil[1][2] chegou como uma alternativa que revolucionou a forma como as empresas encaravam o fluxo de desenvolvimento de produtos, apresentando uma abordagem mais centrada no usuário formou o que chamamos hoje de Product Discovery. Essa metodologia busca trazer entendimento sobre o problema e uma visão mais clara da solução, garantindo alinhamento e validação da proposta. Essa mudança de abordagem foi muito importante, pois levou equipes a desenvolver de forma mais segura, garantindo que estavam resolvendo o problema certo com uma solução válida e bem sucedida.

Com a adesão de metodologias ágeis em alta e um mercado de startups com quase metade dos negócios falhando por falta de market-fit[3] (ajuste do produto ao mercado) o entendimento sobre a importância de criar soluções alinhadas com as necessidades do usuário foi se solidificando. Em meio a essa movimentação, as empresas passaram a buscar profissionais que pudessem atuar com mais clareza na definição de um problema, trazendo a experiência do usuário como pilar e, de certa forma, até influenciando na movimentação de profissionais de Produto e Design para áreas menos relacionadas à solução (User Interface — UI) e mais centradas no problema (User Experience — UX).

Com a disciplina de UX no seu auge, a aplicação do Discovery foi se integrando, cada vez mais, no processo de desenvolvimento dos produtos, chegando a ser considerada por alguns uma etapa indispensável na construção de qualquer solução. O que antes buscava trazer otimização na entrega, agora, por muitas vezes, tem gerado discussões sobre performance, falta de foco, e até mesmo se tornado o vilão para muitos stakeholders. Nos levando a pergunta: eu realmente preciso de um Discovery?

Antes que eu seja cancelado pelos mais fervorosos, quero deixar claro que o Discovery é sim uma das melhores formas de garantir o alinhamento e sucesso de um projeto. Assim como também precisamos reconhecer que o uso, por muitas vezes quase que religioso, desses processos não têm beneficiado nossa conquista pela tão sonhada posição estratégica.

Os fatores: cadência e adaptação

É comum encontrarmos profissionais muitas vezes até orgulhosos de toda metodologia aplicada em um Discovery ou do quanto as etapas dos processos foram respeitadas, segundo as diretrizes de frameworks como Design Sprint e Design Thinking, levando a uma cadência de entregas com prazos significativamente maiores, mas que seriam justificados pelo cumprimento de um cronograma e pela garantia de resultados melhores.

A polêmica discussão sobre cadência pode incomodar os mais metodológicos, ainda assim precisamos levar em conta a relevância e o impacto que o timing de uma entrega pode ter para o negócio, sendo listado em muitos estudos como um dos principais fatores de sucesso para uma empresa[4].

Entregar valor em tempo hábil é uma alavanca importante no crescimento de um negócio. Para isso, a flexibilidade como um todo de design/produto é essencial, com total adequação ao contexto do problema, tendo a qualidade de uma descoberta não baseada na aplicação de um grande volume de frameworks e metodologias hypadas, mas na capacidade dos profissionais de adequar cada etapa do processo para obter o aprendizado de forma otimizada.

Clareza e preparo

Logicamente, o discernimento depende de uma maior experiência e maturidade na aplicação dos processos. Com um nivelamento heterogêneo, garantir eficiência no amadurecimento, com esforços realmente orientados ao resultado, tem sido um dos meus principais desafios como gestor de design.

Para desassociar o sucesso de projetos do uso de determinadas metodologias, acelerando o ritmo de aprendizagem, criamos um plano de treinamento do time. Atrelamos um processo que pudesse permitir o acompanhamento de resultados, trazendo alinhamento sobre quando era necessário realizar determinadas etapas do processo de Discovery e, assim, garantir um padrão de qualidade nessa etapa.

Antes de definir um processo, entendemos o contexto do nosso time e os desafios existentes, considerando pontos como:

• Diferentes níveis de experiência e conhecimento do time;
• Alto custo para cenários de baixo impacto;
• Desalinhamento de expectativas entre líderes e stakeholders;
• Identificação de problemas durante a execução dos projetos.

A partir disso, estruturamos algumas perguntas/etapas para que cada designer ou gerente de produto tenha maior entendimento do seu cenário, buscando definir um racional padronizado que auxiliasse todo o time:

Quando fazer um discovery?

Oferecer critérios que auxiliem na definição de maturidade e risco de um projeto, para que assim seja determinado o que precisa ser descoberto.

O que fazer no discovery?

Tornar claro que tipo de pergunta deve ser respondida em cada variação de cenário, evitando que perguntas desnecessárias sejam respondidas e a performance seja prejudicada.

Como fazer um discovery?

Explicar como cada framework ou metodologia funciona e que tipo de respostas elas trazem, criando uma ligação clara entre as perguntas que seriam feitas e as possíveis formas de conseguir as respostas.

O que entregar no discovery?

Garantir o alinhamento das expectativas, principalmente com líderes e stakeholders, sobre os possíveis entregáveis de cada etapa.

Encontrando padrões

Após essa primeira fase definida, com o time entendendo se determinada iniciativa necessitava de Discovery, seguimos para a segunda parte. Definimos uma estrutura para as descobertas, de forma que o time mantivesse a padronização necessária para mensurar os resultados.

Definimos 3 formas de Discovery que poderiam ser realizadas. Elas se diferenciam na profundidade de entendimento necessário, que foi clarificado e alinhado na etapa anterior:

Planejamento da squad (Definindo cenários e estratégia):

Processo de descoberta no contexto macro da squad, realizado no início do semestre. Define-se os questionamentos e dores que precisam ser priorizados.

• O quê, quem e qual ( Exemplo: O que é o produto? Quem é o usuário?…)
• Impacto/Esforço
• Priorização

Discovery padrão (Aplicado a um cenário já definido):

No caso de um contexto com pouca informação, é necessário investigar o cenário, bem como entender e priorizar o problema.

• Entendimento
• Viabilidade
• Risco

Define (Maior entendimento sobre o cenário)

Quando já temos mais segurança sobre o cenário ou menor risco e precisamos alinhar o problema e já começar a convergir em uma solução.

• O quê
• Por quê
• Como

Definido o que vamos responder em cada etapa, conseguimos alinhar melhor os pontos de quebra no processo para garantir o pragmatismo necessário, assim, quando já temos as respostas podemos simplificar a definição e focar em solucionar o problema, utilizando o modelo de discovery mais robusto para cenários incertos ou de grande impacto, e uma definição mais objetiva para cenários de grande certeza ou pequeno impacto.

Adequando a rotina e documentação

Por fim, para garantir a execução e visualização/alinhamento, integramos a proposta com o processo de documentação no Jira (software que utilizamos para gestão de tarefas). Assim, organizamos modelos que, se preenchidos corretamente, oferecem para a liderança um acompanhamento simplificado da performance.

Cada uma das etapas pode conter tarefas de acordo com o contexto. Com esse modelo, conseguimos acompanhar informações sobre a performance do time em cada uma das fases e como uma variação de cenários afeta a execução do processo, auxiliando, dessa forma, a identificação de pessoas que necessitam de auxílio ou projetos que precisam de algum tipo de alinhamento estratégico.

Padrões vs Flexibilidade

Nesse processo, decidimos trabalhar com uma base em comum e, com ela, simplificar o aprendizado, a gestão e a metrificação. Esses padrões macros não mitigam as individualidades de cada profissional nem anulam a flexibilidade na execução. Pelo contrário, elas focam na clareza, alinhamento e categorização, permitindo assim que cada profissional tenha autonomia na tomada de decisão durante o processo.

Assim como outras padronizações do nosso time, como o Design System, nossos processos estão em constante evolução,adaptando-se à realidade de cada time.

E aí?

O processo de discovery veio como uma forma de aproximar a voz do usuário ao processo de desenvolvimento de produtos, trazendo um maior alinhamento das necessidades do público-alvo com a abordagem do negócio. Executá-lo de forma estratégica requer pragmatismo, aplicando metodologias com uma abordagem que foca em responder as principais perguntas de forma direta.

Com a implementação do nosso processo, otimizamos o alinhamento de expectativas da liderança, facilitamos a dinâmica com profissionais de produto nas etapas de descoberta e trouxemos mais clareza para os designers sobre a realização das etapas. Clareza essa que, alinhada com as iniciativas de desenvolvimento, colabora com o aumento da confiança do time.

Acreditamos que a abordagem de design deve ser sempre flexível, aberta aos erros, voltada para os aprendizados e focada nas soluções. Aliando o apoio ao negócio na tomada de decisão com um ambiente altamente eficiente.

A missão do time de design na Quero:

“Apoiar o negócio na tomada de decisão através da visão do cliente e da tangibilização da estratégia. Projetando experiências universais de alto valor para nossos clientes, em um ambiente altamente eficiente e humano.”

Se quiser fazer parte deste time, estamos com vagas abertas.

Leia também:

• Casa de ferreiro, espeto de ferro: sobre resultados exponenciais no investimento da sua ferramenta interna
• Design ágil na prática: adaptando UX ao seu meio e cultura
• Onboarding de design em tempos de pandemia: Simulando uma experiência real, o(a) novo(a) designer finaliza sua integração de forma remota gerando um entregável e conhecendo muito melhor seu usuário

Esse texto se baseia em materiais de terceiros para construir alguns argumentos, você pode saber mais sobre eles nos links abaixo:

[1] O que é o Manifesto Ágil, seus 4 valores e 12 princípios.

[2] Manifesto Ágil — Wikipédia, a enciclopédia livre

[3] Why Startups Fail: Top 20 Reasons l CB Insights

[4] A principal diferença entre as empresas de sucesso e as que fracassam