Siga o ciclo de vida da inovação

5 minutos

A Tailwind Traders tem dúvidas sobre inovação que também afetam muitas outras organizações:

Como aumentamos a taxa de alteração sem afetar os negócios em andamento?
Como decidimos onde inovar e quais alterações implementar a fim de maximizar o retorno dessas inovações para os negócios?

A resposta das duas perguntas é: a Tailwind Traders precisa adotar a mudança como parte da cultura organizacional. Um motivo pelo qual organizações avessas a mudanças geralmente têm interrupções relacionadas a mudanças é que essas mudanças são muito grandes e impactantes. As mudanças são difíceis de testar em ambientes controlados e realistas.

Se forem estabelecidos processos para introduzir as alterações com frequência, essas alterações serão menores em tamanho e risco. No entanto, esse processo não envolve apenas a adoção de determinadas ferramentas ou tecnologias. Ele requer uma cultura que estimula mudanças e aceita falhas.

O conceito de aceitar falhas pode parecer contraintuitivo, mas é vital para o ciclo de inovação. Se as pessoas têm medo de fracassar porque podem ser culpadas por eventuais erros, é provável que não busquem novas abordagens para solução de problemas devido a esse medo. Em seguida, toda a organização fica prisioneira das práticas estabelecidas.

É possível estabelecer uma cultura de "falhar rapidamente", em que as pessoas são incentivadas a experimentar novos métodos. Elas são capacitadas a mudar rapidamente de direção quando não chegam ao resultado esperado, ajudando a criar uma cultura de inovação mais rica.

Inovação baseada em hipóteses

A inovação pode ser descrita como um ciclo iterativo, baseado em hipótese. Quando você identifica a existência de um problema, uma ou mais hipóteses podem ser formuladas para possivelmente explicar a causa raiz e levar à solução. A definição do problema em si pode ser um desafio, pois ele precisa ser mensurável.

Por exemplo, a definição de problema "Os clientes não estão satisfeitos com as opções da plataforma de pagamento" não é mensurável e, portanto, é difícil de ser resolvido. Se o problema for definido como "23% dos clientes saem da sessão de compra na etapa de escolha da plataforma de pagamento", ficará mais fácil medir o sucesso de uma possível solução.

Depois de definir um problema de maneira mensurável, você pode formular hipóteses para explicar e resolver o problema. Por exemplo, uma hipótese para a Tailwind Traders pode ser descrita como: "A adição do ContosoPay às nossas plataformas de pagamento compatíveis diminuirá a rotatividade de clientes na página de pagamento de 23% para 10%". Agora foi apresentada uma ideia e é preciso testá-la para verificar a validade dela.

As hipóteses devem ter como foco agregar valor aos clientes e aprimorar a experiência deles nas interações com sua organização. Essa ideia é conhecida como empatia com o cliente: colocar o cliente no centro da sua inovação e se concentrar em agregar valor para ele e para você.

Há muitas maneiras de validar uma hipótese sem tocar no código do aplicativo. Pesquisas com clientes e pesquisas de mercado são dois exemplos de fontes de informações valiosas que podem ajudar a decidir a validade de uma hipótese. A verificação dessas fontes permite qualificar suas hipóteses e desenvolver aquelas com a maior probabilidade de precisão e valor comercial agregado.

Build

Quando uma hipótese tem potencial de valor suficiente para ser incorporada ao seu aplicativo, o processo de criação começa. Aqui, novamente, a velocidade é crucial.

Seus sprints de desenvolvimento devem ser tão curtos quanto possível. Manter sprints curtos permite uma verificação ou rejeição da hipótese mais rápida. Também permite que você ajuste o modo como a funcionalidade necessária é integrada ao aplicativo. O resultado são ciclos de inovação mais rápidos.

Medida

Você deseja verificar a precisão da hipótese assim que possível. Um MVP (produto viável mínimo) é uma versão preliminar da nova funcionalidade que reúne comentários e ajuda a confirmar se você está se movendo na direção certa.

A meta do MVP é verificar não apenas sua hipótese, mas também qualquer suposição que você possa ter feito. Por exemplo, se 23% dos clientes da Tailwind Traders abandonam o processo de compra na página de pagamento, a hipótese é de que isso ocorre porque a empresa não está oferecendo plataformas de pagamento suficientes. No entanto, o motivo pode ser outro. O MVP deve ser projetado de maneira a confirmar ou rejeitar essas suposições e a hipótese.

Learn

A fase de aprendizado é semelhante ao início do processo. Depois de aprender mais sobre as suposições e a hipótese, você pode descobrir que elas estavam certas, parcialmente certas ou erradas. Com uma mentalidade de crescimento e humildade suficiente para admitir falhas, você pode:

Mudar rapidamente de direção caso precise continuar trabalhando no MVP.
Orientar seus esforços para outras áreas e formular uma hipótese alternativa.

É importante observar que, mesmo que a hipótese e as suposições estivessem erradas, o processo permitiu que você aprendesse algo novo sobre os clientes e sua empresa. Não considere esse tempo perdido. A chave é obter esse conhecimento o quanto antes e aplicá-lo a uma hipótese futura. Essa ideia é o cerne da cultura de fail-fast.

O que procurar em seguida