Criar com empatia pelo cliente

"A necessidade é a mãe da invenção." Este ditado captura a indelébilidade do espírito humano e nossa vontade natural de inventar. Conforme explicado no dicionário Oxford em inglês, "quando a necessidade de algo se torna imperativa, você é forçado a encontrar maneiras de obtê-lo ou conquistá-lo". Poucos negariam essas verdades universais sobre a invenção. No entanto, como explica o artigo Inovação na economia digital, a inovação em nuvem requer um equilíbrio entre invenção e adoção.

Se continuarmos com a analogia, a inovação vem de uma família mais estendida. A empatia pelo cliente é o pai orgulhoso da inovação. Para criar uma solução de empatia do cliente, que impulsiona a inovação, requer uma necessidade legítima do cliente que os mantenha voltando para resolver desafios críticos. Essas soluções são baseadas no que os clientes precisam em vez de desejos ou caprichos. Para encontrar as verdadeiras necessidades dos clientes, comece com empatia e uma compreensão profunda da experiência do cliente. O empatia é uma habilidade subdesenvolvida para muitos engenheiros, gerentes de produtos e até mesmo líderes de negócios. Felizmente, as diversas interações e o ritmo rápido da função de arquiteto de nuvem promovem essa habilidade.

Como você cria empatia e por que a empatia do cliente é tão importante? A empatia do cliente ajuda você a entender e compartilhar a experiência do cliente. Desde a primeira versão de um MVP (produto mínimo viável) até a disponibilidade geral de uma solução de nível de mercado, a empatia do cliente ajuda você a criar soluções melhores. Mais importante, a empatia posiciona melhor uma equipe para inventar soluções que incentivam a adoção. Em uma economia digital, as equipes de produtos que podem mais facilmente empatia com as necessidades do cliente podem construir um futuro mais brilhante com melhores ferramentas que redefinem e lideram o mercado.

Definir suposições para criar com empatia do cliente

Definir suposições é uma parte fundamental do planejamento. Quanto mais você planeja, mais claramente você pode ver suas suposições rastejando para a base de uma grande idéia. Suposições normalmente são o produto de empatia. Em outras palavras, o que eu iria querer se eu estivesse nesta posição? Quando você começa com a fase de build, ela minimiza o período em que as suposições podem invadir uma solução. Essa abordagem também acelera o loop de comentários com clientes reais, disparando oportunidades anteriores para conhecer e evidenciar ainda mais a empatia.

Cuidado

Definir corretamente o que compilar pode ser complicado e requer alguma prática. Se você criar algo muito rapidamente, isso pode não refletir as necessidades do cliente. Se você gastar muito tempo tentando entender as necessidades iniciais dos clientes e os requisitos da solução, o mercado poderá atendê-los antes que você tenha a chance de criar qualquer coisa. Em qualquer cenário, a oportunidade de aprender pode ser significativamente adiada ou reduzida. Às vezes, os dados podem até mesmo ser corrompidos.

As soluções mais inovadoras no histórico começaram com uma crença intuitiva. Esse pressentimento vem tanto da experiência existente quanto da observação em primeira mão. Comece com a fase de build porque ela permite um teste rápido de sua intuição. A partir daí, você pode cultivar uma compreensão mais profunda e graus mais claros de empatia. A cada iteração ou lançamento de uma solução, o equilíbrio vem da criação de MVPs que demonstram empatia pelos clientes.

Para estabilizar esse ato de balanceamento, as duas seções a seguir descrevem os conceitos de como criar com empatia e definir um MVP.

Definir uma hipótese focada no cliente

Quando você cria com empatia, isso significa que você cria uma solução com base em hipóteses definidas que ilustram uma necessidade específica do cliente. As etapas a seguir formulam uma hipótese que incentiva a construção com empatia.

1. Quando você compila com o empatia, o cliente sempre é o foco. Essa intenção pode assumir muitas formas. Você pode fazer referência a um arquétipo de cliente, uma pessoa específica ou até mesmo uma imagem de um cliente no meio do problema que você deseja resolver. E tenha em mente que os clientes podem ser internos (funcionários ou parceiros) ou externos (consumidores ou clientes de negócios). Essa definição é a primeira hipótese para você testar: podemos ajudar esse cliente específico?
2. Entenda a experiência do cliente. A compilação com empatia significa que você pode se relacionar à experiência do cliente e entender seus desafios. Essa mentalidade indica a próxima hipótese a ser testada: podemos ajudar esse cliente específico com esse desafio gerenciável?
3. Defina uma solução clara para um único desafio. Se você contar com experiência em pessoas, processos e especialistas no assunto, isso pode levar a uma solução em potencial. A hipótese completa a ser testada é: podemos ajudar esse cliente específico com esse desafio gerenciável por meio da solução proposta?
4. Chegar a uma declaração de valor. Que valor de longo prazo você espera fornecer a esses clientes? A resposta a essa pergunta cria a hipótese completa: como as vidas dos clientes serão aprimoradas usando a solução proposta para resolver esse desafio gerenciável?

Esta última etapa é o culminar de uma hipótese orientada para a empatia pelo cliente. Ela define o público, o problema, a solução e a métrica pela qual a melhoria deve ser feita, tudo centrado no cliente. Durante as fases de medida e aprendizado, você deve testar cada hipótese. Prevejo alterações no cliente, na instrução de problema ou na solução à medida que a equipe desenvolve maior empatia pela base de clientes endereçável.

Cuidado

O objetivo é compilar com empatia pelo cliente, não planejar com ela. É muito fácil ficar preso em ciclos intermináveis de planejamento e ajuste para ter acesso à instrução perfeita de empatia pelo cliente. Antes de tentar desenvolver essa declaração, examine as seções a seguir sobre como definir e criar um MVP.

Depois de provar as principais suposições, as iterações posteriores se concentram em testes de crescimento, além de testes de empatia. Depois de criar, testar e validar a empatia, você começa a entender o mercado endereçável em escala. Você pode entender mais profundamente seu mercado endereçável expandindo a fórmula de hipótese padrão descrita anteriormente. Em seguida, com base nos dados disponíveis, estime o tamanho do mercado total (o número de clientes potenciais).

A partir daí, estime o percentual do mercado total que enfrenta um desafio semelhante e, portanto, pode estar interessado na solução. Em seguida, você tem seu mercado endereçável. A próxima hipótese a ser testada é: como x% da vida dos clientes será melhorada usando a solução proposta para enfrentar esse desafio gerenciável? Uma pequena amostragem de clientes revela os principais indicadores que sugerem um efeito percentual no pool de clientes envolvidos.

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

Durante cada iteração de um loop de comentários de compilação-medida-aprendizado, sua tentativa de criar com empatia é definida por um MVP.

Um MVP é a menor unidade de esforço (invenção, engenharia, desenvolvimento de aplicativos ou arquitetura de dados) necessária para criar uma solução suficiente para aprender com o cliente. O objetivo de todo MVP é testar algumas ou todas as hipóteses anteriores e receber feedback diretamente do cliente. A saída não é um aplicativo bonito com todos os recursos necessários para alterar seu setor. A saída desejada de cada iteração é uma oportunidade de aprendizado, uma chance de testar mais profundamente uma hipótese.

Timeboxing é uma maneira padrão de garantir que um produto permaneça enxuto. Por exemplo, confirme se sua equipe de desenvolvimento acha que a solução pode ser criada em uma única iteração para permitir testes rápidos. Para entender melhor como usar velocidade, iterações e versões para definir o mínimo de meios, confira Planejamento de velocidade, iterações, lançamento e caminhos de iteração.

Reduza a complexidade e adie os spikes técnicos

As disciplinas de invenção descritas na metodologia inovar exploram a funcionalidade que muitas vezes é necessária para fornecer uma inovação madura ou uma solução de MVP pronta para escala. Use essas disciplinas como um guia de longo prazo para a inclusão de recursos. Da mesma forma, use-as como um guia de prevenção durante o teste inicial do valor do cliente e da empatia em sua solução.

A amplitude de recursos e as diferentes disciplinas de invenção não podem ser criadas em uma única iteração. Pode levar várias versões para uma solução MVP incluir a complexidade de várias disciplinas. Dependendo do investimento em desenvolvimento, pode haver várias equipes paralelas trabalhando em diferentes disciplinas para testar várias hipóteses. Embora seja inteligente manter o alinhamento arquitetônico entre essas equipes, é imprudente tentar criar soluções complexas e integradas até que você possa validar as hipóteses de valor.

Você detecta a complexidade a melhor na frequência ou no volume de picos técnicos. Os spikes 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 e maduras encontradas em um esforço de migração, os spikes técnicos podem ser comuns em toda a adoção. Mas eles atrasam o teste de hipóteses nos esforços de inovação e você deve adiá-las sempre que possível.

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

Compilação de um MVP

Em cada iteração, uma solução MVP pode usar várias formas diferentes. O requisito comum é apenas que a saída permita medição e teste da hipótese. Esse requisito simples inicia o processo científico e permite que a equipe construa com empatia. Para fornecer esse foco no cliente, um MVP inicial pode contar apenas com uma das disciplinas de invenção.

Em alguns casos, o caminho mais rápido para a inovação significa evitar temporariamente essas disciplinas inteiramente, até que a equipe de adoção da nuvem esteja confiante de que a hipótese é validada com precisão. De uma empresa de tecnologia como a Microsoft, essa orientação pode soar contraintuitiva. Mas enfatiza que as necessidades do cliente, não uma decisão de tecnologia específica, são a prioridade mais alta em uma solução mvp.

Normalmente, uma solução de MVP consiste em um aplicativo ou solução de dados com recursos mínimos e polimento limitado. Para organizações com experiência em desenvolvimento profissional, esse caminho geralmente é o mais rápido para o aprendizado e a iteração. A lista a seguir inclui várias outras abordagens que uma equipe pode levar para criar um MVP:

• Um algoritmo preditivo que está errado 99% das vezes, mas que demonstra os resultados desejados específicos.
• Um dispositivo IoT que não se comunica com segurança em escala de produção, mas demonstra o valor de dados quase em tempo real em um processo.
• Um aplicativo criado por um desenvolvedor cidadão para testar uma hipótese ou atender às necessidades de menor escala.
• Um processo manual que recria os benefícios do aplicativo a seguir.
• Um wireframe ou vídeo detalhado o suficiente para permitir que o cliente interaja.

Desenvolver um MVP não deve exigir grandes quantidades de investimento em desenvolvimento. Preferencialmente, você restringe o investimento o máximo possível para minimizar o número de hipóteses que estão sendo testadas ao mesmo tempo. Em seguida, em cada iteração e a cada versão, você aprimora intencionalmente a solução para sua solução pronta para escala que representa várias disciplinas de invenção.

Acelere o desenvolvimento do MVP

O tempo de colocação no mercado é crucial para o sucesso de qualquer inovação. Versões mais rápidas resultam em aprendizado mais rápido. O aprendizado mais rápido leva a produtos que podem ser dimensionados mais rapidamente. Às vezes, os ciclos de desenvolvimento de aplicativos tradicionais podem retardar esse processo. Com mais frequência, a inovação é restrita por limites de experiência disponível. Orçamentos, contagem de funcionários e disponibilidade de funcionários podem criar limites para o número de novas inovações que uma equipe pode lidar.

As restrições de pessoal e o desejo de construir com empatia geraram uma tendência crescente em relação aos desenvolvedores cidadãos. Esses desenvolvedores reduzem o risco e fornecem escala na comunidade de desenvolvimento profissional de uma organização. Os desenvolvedores cidadãos são especialistas no assunto na experiência do cliente, mas não são treinados como engenheiros. Esses indivíduos usam ferramentas de protótipo ou ferramentas de desenvolvimento mais leves que podem ser rejeitadas desenvolvedores profissionais. Esses desenvolvedores alinhados aos negócios criam soluções de MVPs e testam o teorias. Quando bem alinhado, esse processo cria soluções de produção que fornecem valor, mas não passam uma hipótese de escala suficientemente eficaz. As equipes também podem usar as soluções para validar um protótipo antes do início dos esforços de escala.

Em qualquer plano de inovação, as equipes de adoção de nuvem devem diversificar seus portfólios para incluir esforços de desenvolvedor cidadão. Ao dimensionar os esforços de desenvolvimento, você pode formar e testar mais hipóteses em um investimento reduzido. Quando você valida uma hipótese e identifica um mercado endereçável, os desenvolvedores profissionais podem então proteger e dimensionar a solução usando ferramentas de desenvolvimento modernas.

Porta de compilação final: problema com o cliente

Quando a empatia pelo cliente é forte, um problema evidentemente existente deve ser fácil de identificar. O problema do cliente deve ser óbvio. Durante a compilação, a equipe de adoção da nuvem está trabalhando em uma solução para testar uma hipótese com base em um ponto de dor do cliente. Se a hipótese for bem definida, mas o ponto de dor não for, a solução não será realmente baseada na empatia do cliente. Nesse cenário, o build não é o ponto de partida certo. Em vez disso, invista primeiro na criação de empatia e aprendizado de clientes reais. A melhor abordagem para criar empatia e validar a dor é simples: ouvir seus clientes. Invista tempo em reunião e observá-los até que você possa identificar um ponto problemático que ocorre com frequência. Depois de entender bem o ponto de dor do cliente, você está pronto para testar uma solução hipotética para lidar com essa dor.

Quando não aplicar essa abordagem

Há muitos requisitos legais, de conformidade e do setor que podem exigir uma abordagem alternativa. Essa abordagem pode não ser adequada se versões públicas de uma solução em desenvolvimento:

• Criar risco para o tempo de patente, proteção de propriedade intelectual ou vazamentos de dados do cliente
• Violar os requisitos de conformidade estabelecidos

Quando esses riscos percebidos existirem, consulte o consultor jurídico antes de adotar qualquer abordagem guiada para o gerenciamento de lançamentos.

Referências

Alguns dos conceitos deste artigo se baseiam em ideias discutidas por The Lean Startup Eric Ries.

Próximas etapas

Depois de criar uma solução MVP, você pode medir o valor da empatia e da escala. Saiba como Medir o impacto sobre o cliente.

Avaliar o impacto sobre o cliente