A importância da “definição do problema” 🔥

Precisamos falar sobre: definição do problema nos processos de #designdeserviços ou #produtos.

Antes de mais nada, quero esclarecer que este não é um conteúdo teórico ou crítico a nenhuma #metodologia, exploro aqui um aspecto prático que tenho observado no dia a dia das organizações por onde passo.

Para quem não conhece ou quer saber mais sobre a metodologia, comenta aqui que posso enviar alguns links de conteúdos muito bacanas e indicar perfis para vocês acompanharem.

Muitas pessoas utilizam em seu processo de design métodos que (em resumo) são baseados na seguinte ordem de ações:

descobrir – definir – desenvolver – entregar – medir

O “descobrir” é muito voltado a entender os problemas que temos com um cenário, que pode ser de produto, serviço ou ambos (solução), e o “definir” estão as práticas onde priorizamos, definimos o problema e estabelecemos as soluções.

A grande questão que exploro aqui, é que na prática, por uma série de motivos (que tem sua raiz em cultura e #performance), as empresas (muita, muitas mesmo) têm pulado do “descobrir o problema” para o “definir a solução” – e eu sei que todes colegas especialistas no assunto vão pular das suas cadeiras agora, but sorry designers, “produters” e afins, isso é real.

Eu acredito que isso acontece pelo velho paradigma do “rápido não é igual a ágil”. A adoção de mentalidades e sistemas de #agilidade nas empresas está acontecendo com duas lacunas importantes: a #cultura e #designorganizacional.

Então o que vemos são empresas que pagam consultorias e erguem squads e comunidades, para continuar “entregando na data”, mesmo que isso não gere valor (ou nenhum valor). Porque? A famosa #meta. Se eu não entregar não atingirei a “meta”. Agora é a vez das pessoas #agilistas pularem em suas cadeiras e arrancarem os cabelos.

Mas o fato é que o foco ainda é “entregar algo que alguém priorizou para cumprir uma meta”. E isso nos leva para muito longe dos princípios do design e da agilidade.

Na pratica, tenho visto “squads” de produto, partirem de problemas técnicos ou apontados internamente com pouca ou sem relação com o feedback do #cliente. E na sequência já iniciarem o desenvolvimento de soluções, pensadas pelo mesmo grupo e novamente sem envolvimento do cliente, porque afinal essas pessoas “sabem o que o cliente precisa”.

Na maioria das vezes que participei destes processos, ao invés de problemas o que via listados eram sintomas. E mesmo quando você realiza o #discovery com o cliente (como se deve ser), ainda esta sujeito a descobrir apenas sintomas. Se relacionados, estes sintomas podem indicar problemas, que precisam ser investigados e por fim: definidos.

O risco de pular a definição de problemas é você levar sentimentos e opiniões para a solução, que são importantes na descoberta, mas que precisam de fatos e dados para irem ao próximo nível. Sem isso, perde-se tempo, dinheiro e muitas vezes a motivação de times inteiros.

E você, tem visto isso acontecer? Conta aqui pra gente! 😊