Concrete | (2+2) Nos Produtos Digitais, Menos é Mais….
No seu livro seminal, "Thinking, Fast and Slow", Daniel Kahneman trata das formas como nós humanos processamos informações, tomamos decisões, lidamos com a incerteza, e sobre como nossas tendências (bias) se diferenciam de um agente racional tomando decisões.
O livro não trata da opinião do autor, ou de um compilado de opiniões, se apóia em um conjunto grande de experimentos e mostra categoricamente, com grande amplitude, como tomamos decisões irracionais acreditando usar a melhor lógica do mundo.
Um dos erros de julgamento (bias) mais comuns é o que ele chama de "what you see is all there is – WYSIATI". Nós julgamos aquilo que está na nossa frente como tudo que existe, e isso distorce nossa capacidade de avaliação racional em diversas situações.
Em um dos experimentos citados, participantes precisam avaliar por quanto comprariam um conjunto de porcelana.
Alguns participantes viam um par de xícaras e pires em perfeitas condições, e outro grupo de participantes avaliava este mesmo par de xícaras com mais itens, como por exemplo mais um par de xícaras com rachaduras, ou mais duas xícaras sem os pires acompanhando.
Tipicamente, as pessoas levam em conta aquilo que está em sua frente apenas (WYSIATI) e o valor dado ao par de xícaras (em reais) em perfeito estado era maior que o conjunto com 4 xícaras.
Veja que o conjunto maior contém o conjunto menor, o par de xícaras em perfeito estado.
Racionalmente é claro que o conjunto maior devia valer mais, porém não é o que a prática sugere sobre nosso julgamento.
Além disso, queria chamar a atenção para outro fenômeno interessante que fica na diferença entre a memória que nós temos de uma experiência, e a percepção/expectativa desta experiência.
Pulando um monte de informações relevantes (leia o livro, é incrível), nós tomamos decisões nos baseando na memória que temos de uma experiência, e não na efetiva experiência.
Dentre outras coisas, a duração de uma experiência vivida é menos importante que o pico e o fim de uma experiência vivida (combinando a peak-end rule com duration neglect).
Usando uma analogia, um luta longa que termina com sua vitória vai gerar uma lembrança boa. Mesmo se você tiver apanhando bastante durante a luta, a sua vitória terá uma lembrança melhor do que uma luta em que você perde rápido.
Objetivamente, a luta longa e dolorida poderia ser avaliada como pior, porém, o final da luta é muito marcante.
Em outra esfera, o atendimento no call center pode ser lembrado como positivo se no final nosso problema é resolvido. E se não conseguimos resolver nosso problema, um atendimento rápido e indolor vai nos deixar com uma dor maior no final.
linguagem inapropriada para crianças – viewer discretion advised
Nós efetivamente usamos nossas lembranças das experiências para decidir o que fazer a seguir. Não é uma decisão completamente racional, e é fundamental entender isso para pensarmos em criar um produto.
Primeiro nós devemos entender como é a experiência do usuário (UX) e perceber como ela vai formar sua memória da experiência.
Como foi seu pico de dor e satisfação, qual foi o valor médio da experiência e como foi o final da experiência serão os maiores fatores determinantes para identificarmos o quanto fomos bem.
O foco do desenvolvimento deveria estar na criação de poucas funcionalidades que geram ótima experiência, com particular atenção ao final. Acrescentar uma funcionalidade com experiência dolorosa não apenas não constrói valor como destrói o valor de todo o resto.
De fato, muitas empresas vistas como inovadoras começaram com apenas algumas funcionalidades, porém funcionalidades matadoras, diferenciadas e que apenas funcionam (it just works).
Lembram de como Dropbox começou ?
Chegamos ao segundo ponto. Se o seu usuário vê menos coisas, mas que funcionam, sua avaliação será melhor do que quando comparado a outro produto com as mesmas funcionalidades que o seu, porém, acrescentando-se algumas outras não tão fantásticas (WYSIATI de novo).
Com isto tudo, minha conclusão traz duas reflexões para quem quer otimizar seu retorno de investimento ao criar um Produto Digital.
Primeiro, abandone a obsessão pela produtividade medida pelo número de funcionalidades que seu Produto Digital tem. Você provavelmente estará destruindo valor acrescentando mais itens.
Veja, apenas como um exemplo, esse artigo sobre o excesso de funcionalidades (Too much of a good thing). Uma vez que colocamos a funcionalidade no produto, é difícil voltar atrás.
Vocês se lembram quando a MS retirou o botão de Start no Windows 8 ?
Em vez de fazer sempre mais funcionalidades, utilize sua capacidade (flow) para fazer experimentos, para aprender, e então incorporar funcionalidades com parcimônia.
Funcionalidades originais e criativas são muito mais importantes que o número de funcionalidades.
Segundo, ao atribuir valor para cada item do seu Product Backlog, lembre-se que o valor que importa mesmo não é o do item, mas do produto como um todo.
Pergunte a si mesmo: quanto vale o produto sem isso? E quanto vale com isso?
Faça experimentos para validar a sua noção de valor!
Por exemplo, cortar o seu padrão de qualidade para acrescentar mais um item no seu release pode não apenas não realizar a geração do valor daquele item como pode matar o seu produto!