O Valor Percebido é um importante conceito quando falamos de um Produto. Ele está relacionado à compreensão e ao desejo do cliente em usar/comprar o Produto. É um fator guiado pela percepção, pelos sentidos, pelas emoções e pela informação social que o cliente recebe sobre o Produto.
O Valor Percebido é um equilíbrio entre o esforço que o cliente percebe que está relacionado a usar o produto e a vantagem que o cliente percebe em continuar usando-o. Uma fórmula possível seria:
Valor Percebido = Beneficio Esperado Pelo Cliente – Esforço Percebido pelo cliente
Existem muitos fatores que influenciam o valor percebido, muitos deles psicológicos como o posicionamento da marca a que o produto pertence, alguns sociais, como o status que o produto implica e alguns decorrentes das propriedades do produto em si. O preço do produto é um fator. O cliente percebe o valor e lhe atribui uma facha de preço aceitável. Se o produto estiver a baixo ou acima da faixa a percepção do cliente será modificada. Por exemplo, um relógio não será percebido como uma item a adquirir se apenas custar 10 reais. Mas se custar mil, o relógio passa a ser um item de desejo desde que o produto acompanhe e justifique o preço. Um relógio de mil reais, de plástico provavelmente será percebido como um engano, enquanto que um cravejado de diamante pode parecer um bom negócio. Há um equilíbrio instável entre a percepção e o preço. E não só com o preço. Com todas as propriedades do produto.
Porque é um valor percebido e não um valor objetivo pode ser manipulado e frequentemente é. Cínicos poderiam dizer que todo o objetivo de um bom marketing é dobrar a percepção do cliente.
Contudo, hoje gostaria de me concentrar nos fatores decorrentes das propriedades do produto em si. Estes são fatores mais objetivos e mais diretos de avaliar e comparar.
Aplicando este conceito ao software, podemos dizer que o cliente sempre espera que o software lhe entregue o máximo benefício pelo menor esforço. Contudo, este benefício tem que ser realmente percebido. Por exemplo, se dizemos um endereço para a Alexa e ela nos manda para o lugar errado, o esforço foi quase nulo, mas o benefício também. Para que haja benefício o software tem que prover serviços que o cliente entende como benéficos. Nem sempre esse benefício é material ou verificável. Por exemplo, os jogadores de games – que são softwares – podem perceber o uso do software como divertido, competitivo ou desafiador. Nada disto é materializável, mas é percebido como um benefício pelo jogador que se sente bem com essas recompensas. Mas se o jogo é demasiado difícil, longo ou injusto, o jogador pode começar a perceber o jogo como entediante e, portanto, não benéfico.
A percepção é individual, e que o que um cliente percebe sobre um produto não é o mesmo que outro cliente percebe. Contudo é importante entendermos quais são as percepções dominantes. Aquelas que são mais frequentes e que mais gente compartilha. É para eles que o produto é construído primeiro.
O esforço percebido pelo cliente em um software tem que ver com a forma como realiza as entradas (inputs) e obtêm as saídas (outputs). Ou seja, como ele introduz informação no sistema e como ele obtém informação de volta. Por exemplo, um software de navegação já vem com os mapas. Isto é uma informação complexa que o cliente não tem que dar ao software, ele já a contém. Quanto mais informação o software contém, ou é capaz de inferir, através de outras entradas do cliente, menor será o esforço percebido relacionado à introdução de dados. O mesmo acontece na saída. Se sabemos que introduzimos as informação no software, mas não encontramos onde está aquele relatório que a mostra, o esforço percebido aumenta e o cliente se frustra por não acha a informação, e acaba considerando que foi um desperdício todos os dados que ele introduziu no software e, pior, todo o tempo gasto nesse exercício.
Ha dois fatores importantes : quantidade e facilidade. Quanto menos e mais fáceis forem as entradas melhor. Quanto mais e mais fáceis as saídas, melhor.
Claro, como disse, ha outros fatores, mas estamos considerando apenas aqueles que derivam do software em si.
A análise de valor percebido pode ser então dividida em algumas áreas: forma, utilidade, rapidez, acesso e posse. Vejamos cada um.
Se o valor percebido passa pela entrada e saída de dados, então claramente o grafismo da interação (UI) e facilidade de uso dessa interação(UX) são vitais. O par UI/UX são o pilar que dá forma ao produto de software. É esta UI e UX que moldam a forma como o cliente vê e lembra do produto. É a forma que estabelece o conceito de “marca” e “identidade” do produto. Certas cores, formas, interações, são lembradas pelo cliente. Quanto mais únicas forem, mais o cliente se lembra e associa aquela ação ao produto.
Tem que haver uma ergonomia no design. Imagine um copo com borda de vidro afiado. Talvez não a melhor escolha para um copo. Ou uma garrafa em que a sua mão não consegue segurá-la. Não a melhor escolha. Tem que haver uma adequação da funcionalidade ao cliente, ao humano; não só uma estética envolvida, mas uma praticidade.
Software existe no mundo abstrato das ideias e dos comportamentos. A forma é apenas uma possível imagem do software. Se essa imagem não corresponde com o verdadeiro software, se cria uma barreira cognitiva. Por isto, as maioria dos softwares de sucesso são baseados em uma metáfora do mundo real. Isto ajuda o usuário a transpor o seu conhecimento e experiência do mundo real para o uso da forma do software.
O exemplo clássico é o e-mail. A metáfora é a de um correio corporativo onde existem caixas de entrada e caixas de saída. Repare que nada na metáfora indica como realmente funciona, mas os conceitos de endereço e caixas de entrada/saída são facilmente correspondentes com o mundo real das metáforas escolhidas: endereço = correios, caixas = troca de mensagens entre departamentos.
O cliente sempre irá preferir os softwares esteticamente agradáveis em que ele entende a metáfora subjacente. A forma e a metáfora andam juntas.
O que é agradável hoje pode ser enfadonho amanhã. A forma precisa evoluir. O prazo varia entre 3 a 5 anos. O cliente irá perceber quanto a forma não muda ou se ela muda muito drasticamente. Como sempre, se for uma mudança leve demais ou forte de mais isso vais desbalancear a percepção do cliente fazê-lo repensar se quer continuar usando o software.
Um software irá propor auxiliar o usuário em uma série de tarefas ou atividades. Estas tarefas são como arcos de história. Têm que ter início, meio e fim. Quando mais facilmente o cliente cumprir a tarefa, maior será o valor percebido. Realizar a tarefa usando o software tem que ser mais eficaz que sem o software: o famoso momento”aha!” em que o cliente pensa “mas só tenho que fazer isso !?” Realizar a tarefa deve poupar tempo, dinheiro, esforço. Pontos de bônus se puder fazer tudo isso simultaneamente.
Mas, fazer não é suficiente. O cliente tem que ter a percepção do que foi feito. Quanto mais complexa o cliente achar que a tarefa é, mais valor irá perceber, mesmo que de fato a tarefa não seja tão complexa assim.
A utilidade também se relacionada com aspectos como a consistência, a conformidade (com compliance, leis e normas) e o rigor técnico. Um software não será aceite se produz resultados contrários à matemática, à geografia, à contabilidade ou qualquer disciplina que possa ser verificada no mundo real. Mesmo os jogos investem muitos recursos em que as interações sigam as regras da física o melhor possível. Dados não podem ser inconsistentes nem percebidos como inconsistentes. Enfim, a utilidade tem que ser correta.
Quanto mais as tarefas são relativas a campos específicos do conhecimento, mais importante é que sejam corretas. Quanto mais o cliente confiar no que o software lhe informa, maior será a percepção de valor e a lealdade.
O software provê serviços para auxiliar na execução de tarefas e atividades.
Serviços podem ser divididos em três categorias : essências, adicionais e opcionais. Serviços essenciais são aqueles que o cliente não dispensa. São os primeiros que o cliente procura. Imagine um serviço de streaming sem tocar o video, sem pausa ou sem voltar atrás. Alguns serviços são adicionais, são aqueles que o cliente procurar como diferencial em relação aos outros produtos da categoria.No streaming, seria, por exemplo, o controlo parental. Não é essencial, mas uma larga fatia de clientes irá querer ter, e se o produto não tiver – mesmo que o cliente não use – o produto será rejeitado. E alguns serviços são totalmente opcionais e nem todos irão usar: como pontos de acesso extra, melhor qualidade de imagem, etc.
O cliente sempre irá preferir os softwares que realizam mais serviços essenciais especialmente se for de forma unificada e correta. Mais serviços adicionais afetam o valor percebido e podem ser a diferença entre comprar e não comprar o produto, mesmo quando o usuário não os usa. Ter serviços opcionais não irá afetar o valor percebido tanto quanto os outros e se destinha mais a obter clientes limítrofes fora dos grupos centrais de percepção.
Um software se propõe – enfim – a utilizar o poder computacional de máquinas para acelerar a realização de tarefas, que de outra forma, seriam muito demoradas, complexas ou susceptíveis de erro. O software pode ter uma boa UI e realizar uma tarefa benéfica, mas se não o fizer em tempo hábil, o cliente não vai perceber o valor.
O conceito de rapidez não tem que ver apenas com o tempo de relógio que o software demora a realizar a tarefas, mas também o tempo que demora a instruir o software e a obter o resultado. O famoso “one click buy” da Amazon exemplifica isto. O processo de compra em si, demora o mesmo que antes, mas porque apenas um comando é necessário em vez de vários, o cliente percebe maior valor.
O conceito de tempo hábil varia com a tarefa. O cliente tende a ser mais impaciente na leitura e mais leniente na escrita por achar – empiricamente – que o processamento complexo acontece na escrita e não na leitura. Se o formulário de 20 campos demora 2 segundos para salvar, o cliente tende a achar que é porque ha uma vantagem de persistência e cálculos e não se importa tanto com o tempo. Mas se um relatório demora 2 segundos para obter os mesmos 20 campos, isso será entendido como lento. O tempo hábil é, portanto, um tempo aceitável psicologicamente e não necessariamente um tempo de relógio. O cliente sempre irá procurar por softwares que ele percebe com menor tempo hábil, ou seja, mais rápidos.
Para funcionalidades perigosas como apagar dados, o software pode perguntar se o usuário tem a certeza da operação. Isto são dois cliques: um para ativar a funcionalidade de apagar e um para confirmar. O ideal seria que o software permitisse apagar com um clique apenas e permitir voltar com os dados mais tarde caso tenha havido engano. Porque o erro é mais improvável, então se poupa um clique, na grande maioria das vezes.
O mesmo conceito pode ser utilizado ao contrário. Para funcionalidades muito importantes, como segurança, um maior número de passos pode ser percebido como vantajoso dada a importância, ou risco da ação. Como sempre o segredo está no equilíbrio e na percepção.
O cliente sempre irá preferir os softwares que ativam a funcionalidade da tarefa em menos passos- idealmente, nenhum, sendo automático; e que mostram os resultados, também, em menos passos. Quanto menos passo melhor. Quando mais curtos, em termos de tempo de relógios, os passos forem, melhor. Um software com 1 passo de 2 segundos ainda é melhor que um software com 2 passos de 1 segundo cada.
O acesso diz respeito a como o usuário tem acesso ao software ou, mais especificamente, aos seus serviços. O acesso está relacionado com o quão conveniente é usar o software. Para produtos não de software isto tem que ver com a localização, onde comprar o produto, a que horas usar o serviço. Bancos, por exemplo, são bastante inconvenientes, têm horário reduzido de funcionamento, sempre muito cheios, tendo que passar por vistorias de segurança, etc.
No caso do software isto se traduz pelo tipo de hardware necessário, onde colocá-lo, como acessá-lo e que dispositivos são necessários para o acessar. Tem também que ver com questões de acessibilidade como insuficiência visual, auditiva, ou outra para as quais o software deve estar preparado.
Softwares corporativos, historicamente estavam limitados a serem acessados dentro das quatro paredes da empresa ou talvez por uma VPN. Os servidores estavam fisicamente dentro da empresa e qualquer problema tinha que ser resolvido in loco. Hoje, temos alternativas; a famosa nuvem. O software é acessível de qualquer lugar no mundo via internet, tanto para o cliente, como para quem o mantém.
O navegador se transformou no ponto de acesso por excelência, logo seguido do smartphone. Hoje em dia o mesmo software pode estar disponível em uma variedade de dispositivos e não apenas no clássico computador de mesa. Temos celulares, tablets, TV’s e até relógios.
Contudo, demasiada facilidade de acesso pode ser prejudicial dependendo do tipo de software e serviços que ele provê. Questões com segurança podem estar em jogo. Então o acesso tem que ser adequado ao tipo de software.
O cliente sempre irá preferir aquele que percebe como o mais adequado. Acesso fácil a coisas importantes, sensíveis ou ariscadas pode não ser bem visto. Da mesma forma, acesso complicado, a funcionalidades simples, não será bem visto.
Por fim ha a questão da posse. A posse está relacionada ao quão fácil é adquirir,e descartar, o produto. O quão fácil é se manter “dono” do produto. O status causado pela posse, também é um fator aqui.
Antigamente, para adquirir um software, tínhamos que ir em uma loja física, adquirir um mídia física como disquetes, CDs ,DVDs ou Blu-ray, inserir essas mídias no computador e seguir os passos de instalação. Hoje, usamos lojas de aplicativos online ou simplesmente abrimos uma conta em um site online sem sequer ter que baixar nada.
Vale a nota que nunca estamos adquirindo software realmente. Estamos sempre adquirindo o direito de usar o software. Todo o software é um serviço, e não ha como ser dono do serviço, apenas pagamos pelo uso do serviço. Em modelos de assinatura, estamos adquirindo o direito de continuar usando o software. Contudo este direito nos trás outras regalias. Por exemplo, que os dados entrados continuem disponíveis, não pagamos apenas pelo direito de interagir mas por questões como persistência; o software se “lembrar” dos nosso dados e nossas preferencias e configurações.
Para aumentar o valor percebido o cliente tem que rapidamente entender qual é a relação entre o preço do software (seja uma assinatura continua ou apenas uma compra única) e serviços que ele provê. Em um primeiro nível o preço será comparado apenas com a funcionalidade e o acesso provido. O cliente irá comparar com concorrentes com base nisso. A rapidez é assumida. Sempre o cliente vai assumir que o software irá responder em tempo hábil. A forma não é relevante num primeiro momento, mas pode ajudar a desempatar.
Assim que o cliente decide adquirir, a adquisição deve ser instantânea. Quando mais coisas o cliente tiver que fazer para adquirir o produto de software, pior. Adquirir o software é um serviço em si mesmo, então segues as mesmas regras: tem que ser rápido.Ter que falar com a alguém ao telefone destroi qualquer opção de adquisição fácil e simples. O quando mais fácil for adquirir, melhor. O quanto mais fácil for abandonar também. O software não é um bem físico, é um serviço. Então o cliente quer ligar e desligar o serviço o mais depressa possível conforme as suas necessidades. É como poder fechar o registro de segurança da casa, ou desligar o quadro elétrico. Tem que ser simples, reversível, e possível a qualquer momento.
Depois que o cliente começa a usar o software a forma e a rapidez começam a pesar. Porque o cliente assumiu coisas antes, ele será surpreendido agora. A forma e a rapidez têm que garantir que o cliente não se frustra e devem surpreender o cliente positivamente.
Outra questão é o custo total de posse; em inglês Total Cost of Ownership (TCO). Não basta entender quando custa adquirir o software, mas mantê-lo adquirido. Antes tínhamos coisas como risco de não realizar um update, custo de manter os dados seguros e preservados (backup), custos com máquinas para acessar, periféricos como impressoras e consumíveis como papel, tinta, e energia. Hoje, temos que nos preocupar com roubos e sequestro de dados e contas de acesso.
Com o advento da nuvem e softwares SaaS (Software as a Service) o TOC diminui bastante e está reduzido ao valor da assinatura. Tudo é condensado na assinatura. Contudo, o valor da assinatura considerando um ano de exercício tem que ser percebido pelo cliente como justo. Isto só vai acontecer se ele perceber os outros fatores. Ao pagar uma assinatura o cliente está pagando muitos serviços simultaneamente. O cliente precisa se aperceber disto ou ele achará a assinatura muito cara.
Qualquer falha na percepção dos outros fatores causará que o cliente ache injusto o valor. Uma UI ruim, a necessidade de ter que entrar todos os dados manualmente, a dificuldade em achar os dados ou os relatórios, a lentidão, muitos cliques desnecessários, falta de uma metáfora compreensível, poucos serviços ou serviços com problemas e até a capacidade de suspender o serviço a qualquer momento. Enfim, o cliente vai equilibrar o preço da assinatura com todas as vantagens que recebe.
A posse é um fator tão relevante quanto os outros para educar o valor percebido.
É claro que temos que ter a melhor forma, o melhor acesso, os melhores serviços da forma maís rápida e com o preço mais justo. Mas como?
Devemos fazer tudo o que pudermos para melhorar a ergonomia, facilitar a interação, reduzir passos, aumentar o entendimento; em suma: reduzir o atrito. O uso tem que ser fluido. Sem dúvidas. Sem soluços e sem preocupações.
Uma grande ferramenta é estabelecer a metáfora, e segui-la em todos os momentos. Homogeneizar a UI de formar que informações da mesma espécie estão sempre no mesmo local relativo da tela. Homogeneizar mensagens e diálogos. Homogeneizar o tom dos textos e as palavras usadas. Homogeneizar as interações. A mesma informação deve ser sempre obtida da mesma forma. Informações semelhantes devem ser sempre obtida de forma semelhante.
O software deve garantir que as operações podem ser revertidas. Avisar claramente quando não podem. A comunicação tem que ser clara e homogenia. Cada palavra deve significar apenas uma coisa. Um conceito, uma palavra. Uma palavra, um conceito.
É importante também que a forma seja ajustada ao público e às funções do sistema. Talvez não é uma boa ideia que um sistema de segurança tenha aspecto de jogo de crianças, e vice versa. A forma não deve despertar sentimentos como violência, descriminação, ódio e outros. Deve levar em consideração a saúde do usuário cuidando da escolha das cores para que não gerem stress, ansiedade ou depressão, nem, por outro lado sobre-exaltação. O uso do software deve ser agradável, mas se isso não for possível, então que seja neutro. O software deve elicitar as mesmas emoções que um animal de estimação, como confiança, aconchego, lealdade e proteção.
A forma pode, e deve, mudar conforme os outros fatores. Se o sistema é lento a UI deve compensar entretendo o usuário. Se o acesso muda, a forma muda para se acomodar. Se o software é percebido como caro, a UI tem que ser percebida como elegante e esteticamente agradável. Não nada errado em um software barato e esteticamente agradável, mas o inverso é um grande problema: ninguém quer pagar pelo desagradável.
Porque a forma precisa se manter atualizada e vai mudar entre 3 a 5 anos, o software precisa ser construído com isso em mente. A UI deve ser construída de forma a ser fácil, rápido e barato modificar o seu aspecto e disposição. Separação de Responsabilidades, Componentização, adotar um Design System e ter a sua própria biblioteca de componentes visuais permitirão que a Forma acompanhe os sinais dos tempos com baixo custo de desenvolvimento.
Nem todas as utilidades têm impacto no mundo real. Às vezes possibilitar uma configuração ou memorizar um filtro pode ser tão ou mais útil quanto consultar mapas ou fazer cálculos complexos.
Portanto prover melhores serviços não implica apenas que o usuário irá realizar as tarefas mais facilmente, mas que os serviços essenciais estão presentes antes de partirmos para os outros. Identificar e listar quais são os serviços essências, adicionais e opcionais melhora o valor percebido.
Mostrar esses serviços ao usuário em listas para permitir comparar com a concorrência é importante.Por exemplo, explicitar que o acesso é online e 24h por dia, é meio óbvio se você entende como funciona a internet, mas pode não se óbvio para o cliente. Dizer que a quantidade de dados preservados é ilimitada, é óbvio se você entende o que é um ERP, mas pode não ser óbvio para o cliente.
Outra questão é o quanto o cliente ainda tem que usar outros softwares para realizar o que ele precisa. Se ele precisa usar outros softwares então é porque as tarefas essenciais e adicionais não estão cobertas. O cliente não irá usar outros softwares por motivos de tarefas opcionais, afinal, são opcionais. Investir nos serviços opcionais não traz o mesmo retorno do que investir nos essenciais e adicionais.
Para aumentar o valor percebido, devemos incluir os serviços realizadas por outros softwares. Remover a necessidade de copiar ou transferir os dados para outros softwares. Se o seu software obriga o usuário a fazer cálculos, inclua uma calculadora. Melhor ainda, faça os cálculos pelo usuário e apresente os resultado. Desta forma o usuário não tem que recorrer ao aplicativo de calculadora ou ao Excel nem ficar com vários programas abertos, indo e voltando entre eles. O usuário pode fazer isso, mas não o obrigue a fazer isso. Inclua as funcionalidades no software. Se possível torne as necessidades desnecessárias. Não apenas contas, mas qualquer coisa que evite o usuário de sair do seu software e ir usar outro. Não sabe um endereço ? – pergunte o CEP e faça o software escrever o endereço. Não sabe os dados da empresa ? – digite o CNPJ e faça o software escrever os dados, etc. Quando menos o usuário tiver que tirar a sua atenção da tela do seu software, melhor.
Mas mais funcionalidades não implica apenas quantidade. Melhores funcionalidades são mais relevantes. O cliente busca soluções, não ferramentas. Ele busca inteligência, facilidade e rigor.
O cliente não busca apenas um repositório de informação. Ele busca um serviço de organização e inteligência que trabalhe por ele, automaticamente.
O ponto não é que seja rápido, é que seja percebido como rápido. É claro que se for de fato rápido tanto melhor.
Tenha atenção à rede e não apenas a quanto custa rodar o algoritmo. Tire vantagem de que o usuário irá se sentir melhor se a escrita demorar e a leitura for instantânea do que o inverso. Tire partido que a resposta não precisa ser síncrona. Entretenha o usuário enquanto ele espera ou permita que ele vá fazer outra coisa.
Em suma: não atrapalhe o tempo do usuário. Não force o usuário a esperar. Torne as confirmações desnecessárias.
Ha muitas coisas que você pode dimensionar melhor, como processamento, memória, rede, volume de dados, distribuição localidade dos dados, etc. Contudo o que interessa é a percepção, não os fatos. Use isso a seu favor.
É claro que um sistema cujas operações consomem mais tempo de relógio que outro, está em desvantagem, mas o que realmente importa ao cliente é a percepção. Se o sistema faz em meio segundo, o cliente ainda pode perceber isso como “muito tempo”. É claro que consumir menos tempo sempre ajuda, mas a forma e a metáfora também pode ajudar: por exemplo, tornar o processo assíncrono não cria ansiedade porque o cliente sabe que a resposta virá mais tarde e ele não precisa esperar.
Prepare o seu sistema para funcionar assincronamente nas tarefas mais demoradas. Assuma o pior caso, tenha em mente as falácias da computação distribuída.
Não se trata de disponibilizar o software no máximo de plataformas, mas naquelas que são mais adequadas conforme a percepção do cliente. Ha uma razão porque as pessoas não acessam suas contas bancárias nas suas consolas de jogo. A forma percebida de uma consola é associada a diversão e liberdade, não a segurança.
Disponibilize o software em várias línguas. Tenha atenção à accessibilidade e necessidades especificas. Um alarme sonoro é inútil para um surdo. Uma mensagem que aparece quando se passa o mouse, é inútil se estivermos usando um celular ou uma TV. A forma tem que se adaptar ao acesso.
O acesso também pode influenciar as funcionalidades. Um software de navegação por GPS em um mainframe é inútil. O acesso ao GPS, pode aumentar as funcionalidades ou pode melhorar uma funcionalidade existente.
Adaptabilidade da forma e dos serviços disponíveis ao acesso é vital nos dias de hoje. Não assuma que os serviços são fixos ou que funcionam da mesma forma em todos os acessos.
Hoje em dia cobrir vários tipos de acesso é complexo e requer dominar várias tecnologias diferentes. Tente reduzir o número de tecnologia ao mínimo. Lembre-se que as tecnologias de acesso mudam muito rapidamente e estão ligadas ao clico de 3 a 5 anos da Forma. Então, tenha um arquitetura resiliente e centralizada, preparada para mudar de forma e se adequar a vários acessos. Isto vai lhe poupar muito dinheiro e dor de cabeça depois. Isto, é claro, se você quiser que ser produto dure mais que 5 anos.
Entender como a percepção do cliente é volátil, sensível a vários fatores, influenciável e manipulável, é essencial para entender como um produto de software deve ser construído. Não basta que o software realize algo, ele precisa aderir aos padrões de percepção dos clientes alvo. Nem sempre o alvo é um grande grupo de usuários, às vezes é um nicho, mas sempre tem que ser adequado.
A tecnologia, os padrões, a modelagem e a arquitetura servem para que você possa construir um software que, não apenas é adequado à percepção do cliente, mas que continua se adequando ao cliente conforme o tempo passa. Um produto de software, como dito, é abstrato e é como o Navio de Teseu, sua forma muda constantemente mas ainda é o mesmo produto. No caso, não é um paradoxo, é a própria realidade do que é um software.
Suas técnicas, tecnologias, modelagem e arquitetura apenas têm que levar em conta que a única verdade constante na vida do seu produto de software é que ele irá mudar. Se as suas técnicas, tecnologias, modelagem e arquitetura não estivem preparadas para essa mudança constante, vai nascer uma desfasagem na percepção do cliente, e ele abandonará o seu produto.
Nem toda a percepção de valor vem das propriedades do software, mas elas são uma fatia importante pois são as mais objetivas e controláveis. Mas também porque são as mais objetivas, são as que irão causar mudanças mas drásticas na percepção de valor. Cuide bem delas, e terá sucesso.