Princípios

Nesta parte do livro, falarei sobre a cultura de produto digital e apresentarei quatro princípios fundamentais que devem orientar o comportamento das equipes para aumentar as chances de sucesso na implementação de estratégias de transformação digital.

Conforme comentei no capítulo anterior, os princípios por trás do desenvolvimento de produtos digitais de sucesso que veremos nas próximas páginas são:

• Entregas rápidas e frequentes;
• Foco no problema;
• Entrega de resultado;
• Mentalidade de ecossistema.

Vamos nessa?

Entregas rápidas e frequentes

O primeiro princípio que vou abordar é o das entregas rápidas e frequentes, pois, sem ele, todos os outros são muito menos efetivos. De que adianta você estar focado em problemas e na entrega de resultados, com mentalidade de ecossistema, se você só coloca software em produção a cada 3 ou 6 meses?

Entregar rápido e com frequência é o que habilitará você a ter foco em resolver mais problemas, em gerar mais resultado mais rápido e em garantir que todo o seu ecossistema se beneficie do que você está fazendo.

Uma frase bastante conhecida no mundo dos produtos digitais é:

“Se você não tem vergonha da primeira versão do seu produto, você demorou demais para lançar.”

Reid Hoffman (2017), fundador do LinkedIn e venture capitalist.

Para ilustrar essa frase, vou mostrar algumas primeiras versões de alguns sites bem conhecidos, começando por esta:

Site do Google em 1998.

Certa vez, quando apresentei essa versão do site do Google, me avisaram que havia uma versão mais antiga. Pesquisei e encontrei essa aqui:

Site do Google em 1997

Você pode estar pensando que, em 1998, a internet inteira era composta por sites com design ruim. Vou então mostrar um site de 2006:

Site do Twitter em 2006.

Por outro lado, acredito que o Reid Hoffman provavelmente passou menos vergonha com a sua primeira versão:

Site do LinkedIn em 2005.

Outro bom exemplo dessa época é o Facebook que, em 2005, se chamava Thefacebook e tinha a foto do Mark Zuckerberg no canto superior esquerdo de todas as páginas:

Página de login do Facebook em 2005.

Página interna do Facebook em 2005.

Agora vamos ver alguns exemplos brasileiros:

Site da Locaweb em 1999.

Site da Conta Azul em 2011.

Site do Gympass em 2014.

Site da Lopes em 1998.

E agora, quem vai passar vergonha sou eu:

Site da Dialda em 1995

Por que é preciso passar vergonha?

Vou dar quatro razões que justificam essa necessidade de lançar seu produto ou funcionalidade o quanto antes e frequentemente.

Momento da verdade

Por mais pesquisas, entrevistas e protótipos que você faça, o momento da verdade, o momento em que você saberá se o seu produto é, de fato, a solução de um problema de um conjunto de pessoas é quando ele estiver nas mãos de seus clientes, no contexto onde eles precisam do produto.

Quanto mais tempo você demorar para colocar seu produto na rua, mais tempo demorará para aprender com pessoas reais se você está no caminho certo. E pior, quanto mais produto você construir sem validar com clientes, maiores as chances de você estar dando passos na direção errada, se distanciando do objetivo de construir um produto que ajuda você a atingir os objetivos estratégicos da empresa enquanto resolve problemas e necessidades de suas clientes.

É por isso que é tão importante apresentar algo do seu produto o mais rápido possível para potenciais clientes e usuários. Vai ajudar você a saber se está indo na direção certa. E se não estiver, o que você faz? Conserta, ajusta, muda! Quanto mais cedo você souber que o que você está desenvolvendo não está no caminho certo, melhor, pois menos tempo, energia e dinheiro você desperdiçará indo no caminho errado.

Excesso de funcionalidades

Existe um limite de funcionalidades que o usuário consegue entender. Quando colocamos funcionalidades demais, em vez de criarmos uma solução para o problema do cliente, acabamos criando um novo problema para ele.

Kathy Sierra, consultora americana de experiência do usuário, criou um gráfico de funcionalidades que ilustra de forma clara e divertida como a satisfação do usuário diminui à medida que aumentamos a quantidade de funcionalidades de um produto.

Curva de funcionalidades. Adaptado de: Sierra, 2007.

Retorno do investimento

Quanto mais tempo seu produto demorar para ter usuários e, consequentemente, clientes que em algum momento pagarão pelo seu produto, mais você terá de investir do seu próprio bolso.

Veja a seguir um gráfico típico de retorno de investimento (ROI) de um produto. Enquanto você não o lançar e não tiver receita, tudo o que você terá é custo. Você estará na parte de investimento da curva. Isso só muda quando você começar a ter receita e esta for maior do que os custos mensais. Então você entra na área descrita a seguir como rentabilidade mensal. Só depois de alguns meses nessa área é que você terá o retorno do seu investimento. Veja como o caminho é longo:

Retorno do investimento.

Esse vale que vai do mês 1 ao mês 11 é a quantidade total de dinheiro que você terá que tirar do bolso para investir em seu produto. Agora veja, no gráfico adiante, como um atraso de 3 meses em obter receita pode atrasar em 6 meses a obtenção do retorno do investimento — e como se esses 6 meses de atraso não fossem razão suficiente, o vale dobra de tamanho. Esse aumento de 50% no tempo de entrega de seu produto custará mais que o dobro do que foi inicialmente planejado. Será que esses 3 meses de atraso em obter receita valem a pena? O que você vai fazer nesses 3 meses realmente compensa 6 meses de atraso no retorno do investimento e o dobro de investimento?

Retorno do investimento postergado.

Por outro lado, veja só o que você ganha se conseguir acelerar o desenvolvimento de seu produto e lançá-lo 3 meses antes do planejado: você ganha 6 meses de retorno do investimento! E a explicação para isso não é só porque você adiantou a entrada de receita, é porque você gastou bem menos para poder lançar o produto mais rápido. Veja no gráfico a seguir:

Retorno do investimento adiantado.

Cone da incerteza

O Cone da incerteza é um conceito bastante conhecido em gestão de projetos. Ele descreve como a quantidade de incertezas diminui ao longo do tempo à medida que avançamos e aprendemos mais sobre o que foi feito e o que ainda falta fazer. Em uma imagem, podemos representar dessa forma:

Cone da incerteza.

Essa imagem mostra que, quanto mais longe estamos do final de um projeto, maior a incerteza. No início de um projeto, a incerteza varia de 0,25x a 4x. Por exemplo, se estamos estimando o tempo de entrega de um projeto específico em 4 meses, no início do projeto essa estimativa varia de 1 mês a 16 meses. Isso é MUITA incerteza!

No entanto, essa é a teoria. Quando analisamos projetos na vida real, a maioria deles tem sua estimativa menor do que o que realmente acontece. É muito raro ver projetos sendo entregues antes de sua estimativa original. Assim, podemos representar melhor o Cone da incerteza da seguinte forma:

Cone da incerteza na vida real.

Essa imagem mostra que a probabilidade de uma estimativa ser 2x a 4x vezes o que foi originalmente estimado é maior do que a estimativa estar correta ou ser menor. Essa é a razão pela qual muitas pessoas, ao fornecer uma estimativa, tendem a aumentar essa estimativa para aumentar as chances de ela ser mais precisa. Colchão é o termo informal comumente utilizado para essa superestimação de estimativas.

Uma solução muito eficaz para reduzir incertezas é fazer entregas rápidas e com frequência. Fazendo isso, reduzimos a incerteza inicial por estarmos mais perto de cada entrega, e, consequentemente, a incerteza total é diminuída:

Cone da incerteza iterativo.

Acabamos de ver as quatro razões para fazermos entregas rápidas e frequentes:

• Produto na mão do usuário = momento da verdade;
• Evita o excesso de funcionalidades;
• Acelera o retorno do investimento;
• Diminui a incerteza.

Gympass Wellness

No Gympass em 2018, conversávamos constantemente sobre oportunidades para expandir nosso marketplace além de academias e estúdios. Personal trainers, e-commerce de artigos esportivos e aplicativos de bem-estar eram algumas oportunidades de expansão de oferta que estávamos considerando. No entanto, como tínhamos muito a melhorar na nossa oferta principal, decidimos adiar a exploração dessas oportunidades.

Em outubro de 2019, chegamos a um ponto em que nossa equipe de desenvolvimento de produto estava bem estruturada e trabalhando adequadamente para enfrentar nossos desafios em nosso produto principal, então decidimos nos concentrar na expansão de nosso marketplace. Decidimos trabalhar em uma ideia chamada “hub de parcerias do usuário final Gympass”. O plano era fazer parceria com aplicativos de bem-estar e fornecê-los aos nossos usuários. Essa nova ideia tinha duas hipóteses principais que precisávamos testar:

• Disposição para parceria de fornecedores de aplicativos: os provedores de aplicativos, assim como as academias, estão acostumados com o modelo de receita mensal recorrente. Eles aceitariam ser pagos por dia de uso?
• Disposição de pagar de nossa base de usuários: nossa base de usuários está interessada em pagar uma mensalidade para ter acesso aos aplicativos?

Para testar nossa primeira hipótese, construímos um deck com a proposta de valor que planejávamos entregar aos parceiros e conversamos com alguns parceiros em potencial. Apresentamos a oportunidade de parceria a 8 potenciais parceiros, dos quais 6 mostraram interesse e 4 decidiram se juntar à nossa prova de conceito: NEOU, um app de treino de atividade física; 8fit, um app de treino de atividade física e de nutrição; Tecnonutri, um app de nutrição; e ZenApp, um app de meditação.

Ok, nossa primeira hipótese foi validada, precisávamos validar a segunda hipótese, a disposição a pagar. Nosso usuário está disposto a pagar para ter acesso a esses aplicativos através do Gympass? Para testar nossa segunda hipótese, construímos um formulário simples, no qual descrevemos o produto e perguntamos nome, e-mail e empresa. Após o usuário fornecer essas informações, ele seria direcionado para uma página de assinatura do Paypal, onde ele precisa fornecer os dados do cartão de crédito para assinar o serviço. O usuário receberia um e-mail com o link de ativação de cada aplicativo. Não havia um produto real, apenas um formulário para testar o interesse e um e-mail com os links para os aplicativos. 100 aplicativos parceiros em menos de 2 meses porque precisávamos de uma boa variedade de aplicativos em vários idiomas, e fomos de zero a centenas de milhares de usuários em poucos meses. Costumo descrever esse momento como o de maior blitzscaling na minha carreira.

Inicialmente, demos a esse serviço o nome Gympass W, o W significando Wellness (bem-estar). Adicionamos um beta para que todos pudessem entender que não era um produto acabado. Mais tarde, renomeamos para Gympass Wellness para deixar sua proposta de valor mais clara.

Nosso plano era testar essa prova de conceito com 5 clientes corporativos nos EUA e 5 no Brasil, o que nos forneceria uma base de potenciais usuários de 15 mil funcionários. Nossa expectativa era ter cerca de 200 assinantes. Lançamos internamente – eat your own dog food (coma sua própria ração para cachorro) – em 9 de março de 2020 e conquistamos 66 inscritos. Em seguida, veio a COVID-19.

Fomos capazes de adaptar nosso piloto do Gympass Wellness em tempo recorde para ser oferecido a toda a nossa base de usuários, de forma que eles possam não apenas permanecer ativos, mas cuidar de sua alimentação e de suas mentes durante esses tempos tão desafiadores. Com o Gympass Wellness, fomos capazes de atender aos problemas e necessidades dos usuários e de nossos clientes corporativos durante a crise. Crescemos de 4 para quase 100 aplicativos parceiros em menos de 2 meses porque precisávamos de uma boa variedade de aplicativos em vários idiomas, e fomos de zero a centenas de milhares de usuários em poucos meses. Costumo descrever esse momento como o de maior blitzscaling na minha carreira.

Transformação digital e cultura de produto