Criar com empatia do cliente

"A necessidade é a mãe da invenção." Este ditado captura a indelibilidade do espírito humano e o nosso impulso natural para inventar. Como explicado no Dicionário de Inglês de Oxford, "Quando a necessidade de algo se torna imperativa, você é forçado a encontrar formas de o conseguir ou alcançar." Poucos negariam estas verdades universais sobre a invenção. No entanto, como explica o artigo Inovação na economia digital, a inovação na cloud requer um equilíbrio entre a invenção e a adoção.

Se continuarmos com a analogia, a inovação vem de uma família mais alargada. A empatia dos clientes é o principal orgulhoso da inovação. Para criar uma solução de empatia do cliente, que impulsiona a inovação, é necessário um cliente legítimo que os faça voltar para resolver desafios críticos. Estas soluções baseiam-se no que os clientes precisam em vez de querer ou caprichos. Para encontrar as verdadeiras necessidades dos clientes, comece com empatia e uma compreensão profunda da experiência do cliente. A empatia é uma competência subdesenvolvida para muitos engenheiros, gestores de produtos e até líderes empresariais. Felizmente, as diversas interações e o ritmo rápido da função de arquiteto da cloud promovem esta competência.

Como cria empatia e porque é que a empatia dos clientes é tão importante? A empatia do cliente ajuda-o a compreender e a partilhar a experiência do cliente. Desde a primeira versão de um produto mínimo viável (MVP), até à disponibilidade geral de uma solução de nível de mercado, a empatia do cliente ajuda-o a criar melhores soluções. Mais importante ainda, a empatia posiciona melhor uma equipa para inventar soluções que incentivem a adoção. Numa economia digital, as equipas de produtos que possam facilmente simpatizar com as necessidades dos clientes podem construir um futuro mais brilhante com melhores ferramentas que redefinem e liderem o mercado.

Definir pressupostos para criar com empatia do cliente

Definir pressupostos é uma parte fundamental do planeamento. Quanto mais planeias, mais claramente podes ver as tuas suposições a entrar na base de uma grande ideia. As suposições são normalmente o produto da auto-empatia. Por outras palavras, o que quereria se estivesse nesta posição? Quando começa com a fase de compilação, minimiza o período em que os pressupostos podem invadir uma solução. Esta abordagem também acelera o ciclo de comentários com clientes reais, desencadeando oportunidades anteriores para aprender e afiar a empatia.

Atenção

Definir corretamente o que criar pode ser complicado e requer alguma prática. Se criar algo muito rapidamente, poderá não refletir as necessidades dos clientes. Se passar demasiado tempo a tentar compreender as necessidades iniciais dos clientes e os requisitos de solução, o mercado poderá cumpri-los antes de ter a oportunidade de criar algo. Em qualquer um dos cenários, a oportunidade de aprender pode ser significativamente atrasada ou reduzida. Por vezes, os dados podem até ser danificados.

As soluções mais inovadoras da história começaram com uma crença intuitiva. Esse sentimento intestinal vem tanto da experiência existente como da observação em primeira mão. Comece com a fase de compilação porque permite um teste rápido da sua intuição. A partir daí, pode cultivar uma compreensão mais profunda e graus mais claros de empatia. Em cada iteração ou versão de uma solução, o equilíbrio vem da criação de MVPs que demonstram empatia do cliente.

Para estabilizar este ato de equilíbrio, as duas secções seguintes descrevem os conceitos de como criar com empatia e definir um MVP.

Definir uma hipótese focada no cliente

Quando cria com empatia, significa que cria uma solução com base em hipóteses definidas que ilustram uma necessidade específica do cliente. Os passos seguintes formulam uma hipótese que incentiva a construção com empatia.

1. Quando cria com empatia, o cliente é sempre o foco. Esta intenção pode tomar muitas formas. Pode referenciar um arquétipo de cliente, uma persona específica ou até mesmo uma imagem de um cliente no meio do problema que pretende resolver. Tenha em atenção que os clientes podem ser internos (colaboradores ou parceiros) ou externos (consumidores ou clientes empresariais). Esta definição é a primeira hipótese para testar: podemos ajudar este cliente específico?
2. Compreenda a experiência do cliente. Criar com empatia significa que pode relacionar-se com a experiência do cliente e compreender os respetivos desafios. Esta mentalidade indica a próxima hipótese a ser testada: podemos ajudar este cliente específico com este desafio gerível?
3. Definir uma solução clara para um único desafio. Se depender de conhecimentos especializados entre pessoas, processos e especialistas em assuntos, isso pode levar a uma solução potencial. A hipótese completa a testar é: podemos ajudar este cliente específico com este desafio gerível através da solução proposta?
4. Chegar a uma instrução de valor. Que valor a longo prazo espera fornecer a estes clientes? A resposta a esta pergunta cria a sua hipótese completa: como é que a vida destes clientes será melhorada através da solução proposta para enfrentar este desafio gerível?

Este último passo é o culminar de uma hipótese orientada pela empatia do cliente. Define a audiência, o problema, a solução e a métrica através da qual deve ser feita a melhoria, todas centradas no cliente. Durante as fases de medição e aprendizagem, deve testar cada hipótese. Antecipar alterações no cliente, na instrução do problema ou na solução à medida que a equipa desenvolve uma maior empatia pela base de clientes endereçável.

Atenção

O objetivo é criar com empatia do cliente, não planear com ele. É muito fácil ficar preso em ciclos intermináveis de planeamento e ajustes para obter a declaração perfeita de empatia do cliente. Antes de tentar desenvolver essa instrução, reveja as secções seguintes sobre a definição e criação de um MVP.

Depois de provar as principais suposições, as iterações posteriores focam-se nos testes de crescimento, além dos testes de empatia. Depois de criar, testar e validar a empatia, começa a compreender o mercado endereçável em escala. Pode compreender melhor o seu mercado endereçável ao expandir a fórmula de hipótese padrão descrita anteriormente. Em seguida, com base nos dados disponíveis, calcule o tamanho do mercado total (o número de potenciais clientes).

A partir daí, estimize a percentagem do mercado total que experimenta um desafio semelhante e, por conseguinte, poderá estar interessado na solução. Em seguida, tem o seu mercado endereçável. A próxima hipótese a testar é: como é que x% da vida dos clientes será melhorada através da solução proposta para enfrentar este desafio gerível? Uma pequena amostragem de clientes revela indicadores principais que sugerem um efeito percentual no conjunto de clientes envolvidos.

Definir uma solução para testar a hipótese

Durante cada iteração de um ciclo de comentários build-measure-learn, a sua tentativa de criar com empatia é definida por um MVP.

Um MVP é a unidade de esforço mais pequena (invenção, engenharia, desenvolvimento de aplicações ou arquitetura de dados) necessária para criar uma solução suficiente para aprender com o cliente. O objetivo de cada MVP é testar algumas ou todas as hipóteses anteriores e receber feedback diretamente do cliente. A saída não é uma aplicação bonita com todas as funcionalidades necessárias para alterar a sua indústria. A saída pretendida de cada iteração é uma oportunidade de aprendizagem, uma oportunidade para testar mais profundamente uma hipótese.

O timeboxing é uma forma padrão de garantir que um produto permanece magro. Por exemplo, confirme que a sua equipa de desenvolvimento considera que a solução pode ser criada numa única iteração para permitir testes rápidos. Para compreender melhor como utilizar velocidade, iterações e lançamentos para definir o que significa mínimo, veja Planear caminhos de velocidade, iterações, lançamento e iteração.

Reduzir a complexidade e atrasar os picos técnicos

As disciplinas de invenção descritas na metodologia de Inovação exploram a funcionalidade que é muitas vezes necessária para proporcionar uma inovação madura ou uma solução MVP preparada para dimensionamento. Utilize estas disciplinas como um guia a longo prazo para a inclusão de funcionalidades. Da mesma forma, utilize-os como um guia de precaução durante os testes antecipados do valor do cliente e da empatia na sua solução.

A amplitude das características e as diferentes disciplinas de invenção não podem ser criadas numa única iteração. Pode ser necessário vários lançamentos para uma solução MVP incluir a complexidade de múltiplas disciplinas. Dependendo do investimento em desenvolvimento, podem existir várias equipas paralelas a trabalhar em diferentes disciplinas para testar múltiplas hipóteses. Embora seja inteligente manter o alinhamento arquitectónico entre essas equipas, é imprudente tentar criar soluções complexas e integradas até que possa validar as hipóteses de valor.

Deteta a melhor complexidade na frequência ou volume de picos técnicos. Os picos técnicos são esforços para criar soluções técnicas que não podem ser facilmente testadas com os clientes. Quando o valor do cliente e a empatia do cliente não são testados, os picos técnicos representam um risco para a inovação e devem ser minimizados. Para os tipos de soluções testadas maduras encontradas num esforço de migração, os picos técnicos podem ser comuns durante a adoção. Mas atrasam os testes de hipóteses nos esforços de inovação e deve adiá-las sempre que possível.

Uma abordagem de simplificação implacável ajuda qualquer definição de MVP. Esta abordagem significa que remove qualquer coisa que não ajude a sua capacidade de validar a hipótese. Para minimizar a complexidade, reduza o número de integrações e funcionalidades que não são necessárias para testar a hipótese.

Criar um MVP

Em cada iteração, uma solução MVP pode tomar muitas formas diferentes. O requisito comum é apenas que o resultado permite a medição e o teste da hipótese. Este requisito simples inicia o processo científico e permite que a equipa crie com empatia. Para dar este primeiro foco ao cliente, um MVP inicial pode depender apenas de uma das disciplinas de invenção.

Em alguns casos, o caminho mais rápido para a inovação significa evitar temporariamente estas disciplinas completamente, até que a equipa de adoção da cloud esteja confiante de que a hipótese é validada com precisão. A partir de uma empresa tecnológica como a Microsoft, esta documentação de orientação poderá parecer contra-intuitiva. No entanto, sublinha que as necessidades dos clientes, e não uma decisão tecnológica específica, são a prioridade mais alta numa solução MVP.

Normalmente, uma solução MVP consiste numa aplicação ou solução de dados com funcionalidades mínimas e polimento limitado. Para organizações com experiência em desenvolvimento profissional, este caminho é, muitas vezes, o mais rápido de aprender e iterar. A lista seguinte inclui várias outras abordagens que uma equipa pode adotar para criar um MVP:

• Um algoritmo preditivo que está errado 99% das vezes, mas que demonstra resultados pretendidos específicos.
• Um dispositivo IoT que não comunica de forma segura à escala de produção, mas que demonstra o valor de dados quase em tempo real num processo.
• Uma aplicação criada por um programador cidadão para testar uma hipótese ou satisfazer necessidades de menor escala.
• Um processo manual que recria as vantagens da aplicação a seguir.
• Um wireframe ou vídeo suficientemente detalhado para permitir que o cliente interaja.

Desenvolver um MVP não deve exigir grandes quantidades de investimento em desenvolvimento. De preferência, limita o investimento tanto quanto possível para minimizar o número de hipóteses que estão a ser testadas de uma só vez. Em seguida, em cada iteração e em cada versão, melhora intencionalmente a solução para a sua solução preparada para dimensionamento que representa múltiplas disciplinas de invenção.

Acelerar o desenvolvimento do MVP

O tempo de comercialização é crucial para o sucesso de qualquer inovação. As versões mais rápidas levam a uma aprendizagem mais rápida. A aprendizagem mais rápida leva a produtos que podem ser dimensionados mais rapidamente. Por vezes, os ciclos tradicionais de desenvolvimento de aplicações podem atrasar este processo. Mais frequentemente, a inovação é limitada por limites de conhecimentos disponíveis. Os orçamentos, a contagem de cabeças e a disponibilidade do pessoal podem criar limites para o número de novas inovações que uma equipa pode lidar.

As restrições de pessoal e o desejo de construir com empatia geraram uma tendência em rápido crescimento para os programadores cidadãos. Estes programadores reduzem os riscos e fornecem dimensionamento na comunidade de desenvolvimento profissional de uma organização. Os programadores cidadãos são especialistas em assuntos na experiência do cliente, mas não são preparados como engenheiros. Estes indivíduos utilizam ferramentas de prototipagem ou ferramentas de desenvolvimento mais leves que podem ser mal vistas por programadores profissionais. Estes programadores alinhados com a empresa criam soluções MVP e testam teorias. Quando alinhado bem, este processo cria soluções de produção que fornecem valor, mas não transmitem uma hipótese de dimensionamento suficientemente eficaz. O Teams também pode utilizar as soluções para validar um protótipo antes do início dos esforços de dimensionamento.

Em qualquer plano de inovação, as equipas de adoção da cloud devem diversificar os seus portfólios para incluir os esforços dos programadores cidadãos. Ao dimensionar os esforços de desenvolvimento, pode formar e testar mais hipóteses num investimento reduzido. Quando valida uma hipótese e identifica um mercado endereçável, os programadores profissionais podem, em seguida, proteger e dimensionar a solução com ferramentas de desenvolvimento modernas.

Portão de compilação final: Dor do cliente

Quando a empatia do cliente é forte, um problema claramente existente deve ser fácil de identificar. A dor do cliente deve ser óbvia. Durante a compilação, a equipa de adoção da cloud está a trabalhar numa solução para testar uma hipótese com base num ponto de dor do cliente. Se a hipótese estiver bem definida, mas o ponto de dor não estiver, a solução não se baseia verdadeiramente na empatia do cliente. Neste cenário, a compilação não é o ponto de partida certo. Em vez disso, invista primeiro na criação de empatia e aprendizagem com clientes reais. A melhor abordagem para criar empatia e validar a dor é simples: ouvir os seus clientes. Invista tempo na reunião e observe-os até que possa identificar um ponto de dor que ocorra com frequência. Depois de compreender bem o ponto de dor do cliente, está pronto para testar uma solução hipótese para lidar com essa dor.

Quando não aplicar esta abordagem

Existem muitos requisitos legais, de conformidade e de indústria que podem exigir uma abordagem alternativa. Esta abordagem poderá não ser adequada se as versões públicas de uma solução em desenvolvimento:

• Criar risco para o temporização de patentes, proteção de propriedade intelectual ou fugas de dados do cliente
• Violar requisitos de conformidade estabelecidos

Quando estes riscos percebidos existirem, consulte o advogado antes de adotar qualquer abordagem orientada para a gestão de lançamentos.

Referências

Alguns dos conceitos neste artigo baseiam-se em ideias abordadas por The Lean Startup Eric Ries.

Passos seguintes

Depois de criar uma solução MVP, pode medir o valor de empatia e o valor de dimensionamento. Saiba como medir o impacto do cliente.

Avaliar o impacto do cliente