Antes de falar sobre as diferenças entre o mindset de entrega e o mindset de resultado, e o impacto deles nos negócios, vou compartilhar uma história. Eu tinha um champanhe na geladeira da empresa pronto para estourar. O motivo? Estava convicto de que a minha entrega era perfeita. Em resumo, queria incluir na experiência dos usuários de um site de imóveis uma busca por mapas.
Na minha cabeça, as pessoas iriam amar. O pessoal na área de tecnologia adorava mapas, e eu também. De última hora, decidimos testar antes. Reservamos duas salas de experimentação e apresentamos diversos sites de busca de imóveis com mapas, e o nosso no meio. Foi uma surpresa, porque praticamente 15 das 15 pessoas entrevistadas não sabiam mexer no mapa. Elas queriam sair dali e ir para a lista convencional.
A gente iria criar um negócio que ninguém queria e ainda deixaria as pessoas confusas. A maioria do nosso público-alvo era renda baixa ou média, ou pessoas de idade avançada, sem o hábito de usar o mapa. Deixei o champanhe para outro momento. Em compensação, evitamos um impacto negativo para o negócio e não mandamos o usuário para o concorrente.
Achar que precisa entregar uma funcionalidade, algo novo, sem questionar é uma situação comum para o desenvolvedor de software e o gerente de produto. Alguns chefes dizem: “não me interessa o resultado, quero que você entregue funcionalidades novas”. Nessa hora muitas equipes de produtos ficam acuadas e trabalham dessa maneira, procurando somente entregar algo. E garanto que é menos eficiente.
Porém, existe outra cultura, mais saudável, que é a do mindset de resultado, ou seja, ser mais orientado pelo resultado — olha para os números, e como eles vão impactar o negócio. É como uma cultura de produto realmente deveria ser.
## Cultivando resultados
Para você conseguir[ entregar o resultado](https://www.revistahsm.com.br/post/de-olho-nos-resultados), muitas vezes, precisa entregar funcionalidades ou pequenas coisas. Elas provavelmente vão dar errado, mas servirão para você perceber o que pode dar errado e conseguir dar um passo para trás e seguir outro caminho.
Muitas empresas não têm essa cultura de médio prazo. Elas querem que você entregue o tempo inteiro, sem nem pensar se alguém vai usar. Isso é um desperdício de desenvolvimento muito grande.
A expressão “paradoxo de Abilene” cai bem aqui. É uma situação em que alguém fala em desenvolver uma funcionalidade, sem nenhum fator racional nisso, e todo mundo concorda em fazer — mesmo estando ciente de que ninguém vai usar. Mas a cultura da empresa é tão voltada a entregar qualquer coisa, sem pensar no resultado, que a equipe diz “beleza, vamos fazer”. Esse é o grande problema.
Você precisa entregar resultados, tanto para o usuário, quanto para o negócio. Não é entregar por entregar.
Gosto muito de pensar o “output driven” versus o “outcome driven”. O output é a entrega das coisas. O outcome é qual a sensação, o que alcancei, ou seja, o resultado. Claro que muitas empresas empregam o conceito de pensar coisas para o usuário, para o cliente. Se der para fazer algo voltado ao cliente, e que seja o melhor para o negócio, é o melhor dos mundos. Mas nem sempre é possível.
Imagine que você tem um cliente muito grande e vai fazer algo apenas para atender à demanda dele. Você vai alocar recursos da sua empresa para fazer uma coisa customizada. Se você pensar em escala, não faz diferença atender um cliente aqui, outro ali. É preciso atender a maioria dos clientes. Obviamente, é importante definir os objetivos e quais metas você quer atingir.
Vamos dizer que deu super certo o que você desenvolveu. Mas você vai conseguir dar suporte para isso? Ou vai virar um caos e os usuários vão ficar chateados, uma vez que o negócio não foi para frente?
## Usuários e novas funcionalidades
Em empresas maiores, você às vezes acaba sendo muito influenciado pelo seu contexto, como no meu exemplo do mapa. Estava tão imerso numa bolha que me esqueci de olhar para o lado, para o meu usuário e ver que ele não era eu; e sim, outra pessoa.
Você precisa se colocar no lugar do seu usuário, fazer um teste que seja rápido, bom e barato, e ver como ele usa para você aprender de fato.
A regrinha de bolso que uso, e sei que ajudaria muito as pessoas na hora de pensar e desenvolver uma nova funcionalidade: __(1)__ se isso está dentro da visão do produto e da empresa; __(2)__ se faz sentido hoje, e se fará sentido daqui cinco anos, ou é só para o curto prazo — e tudo bem se for o caso, desde que isso seja consciente; __(3)__ também pensar se isso beneficia a todos usuários, ou quase todos, pelos menos.
Por fim, para que tudo isso se encaixe na sua realidade, vai a minha dica. Se você tem 200 mil clientes, não faz sentido fazer uma coisa que apenas um cliente quer. É melhor priorizar algo que traga impacto para a maior quantidade de clientes, para trazer mais resultado para seu negócio.
Entretanto, existem contextos diferentes. Você trabalha num modelo de enterprise? Então, provavelmente ponderar o pedido do cliente pode fazer sentido já que perdê-lo pode custar milhões na sua empresa. Melhor ainda se conseguir criar algo que poderá ser reutilizado por outros clientes.
Conheço uma empresa no modelo enterprise que foi inteligente nesse sentido. Os clientes pediam muitas coisas e a empresa começou a cobrar R$ 100 mil para cada customização. Alguns pediam algo que já estava feito e eles cobravam o valor adicionalmente como se fossem fazer do zero enquanto, na verdade, iriam apenas habilitar a funcionalidade para o cliente. Eles conseguiram escalar produtos dessa maneira e, ainda por cima, aumentar a receita total da empresa.
O fio da meada é ter claro que tipo de produto e cliente a empresa tem. E a partir daí, desenvolver sua estratégia. Isso é ter mindset de entrega e mindset de resultado.
*Gosto do artigo do Marcell Almeida? Saiba mais sobre mindset de resultado assinando gratuitamente as [nossas newsletters](https://www.revistahsm.com.br/newsletter) e escutando [nossos podcasts](https://www.revistahsm.com.br/podcasts) na sua plataforma de streaming favorita.*
