Ataque esses 4 riscos antes de criar um produto ou startup de tecnologia
Se você está envolvido na criação de um produto digital ou startup de tecnologia, já deve ter visto (ou ainda vai ver) essa cena:
A cena que se repete
Depois de uma grande ideia, uma equipe gastou meses, dinheiro e dedicação na criação de um produto. O dia do lançamento se aproxima.
Durante essa jornada, foram feitos alguns testes do produto ainda inacabado. Os feedbacks dos possíveis usuários eram bons, pois apesar do produto ainda não estar pronto para uso, a equipe explicava ao usuário tudo o que o produto é ou ainda seria capaz de fazer. Todos estavam otimistas.
Conforme o lançamento se aproxima, surgem comentários de que essa ou aquela feature ainda não está boa suficiente. Mas tudo bem, alguém da equipe lembra da frase do co-fundador do LinkedIn, Reid Hoffman: “se você não se sentir envergonhado pelo produto que está lançando, então você o lançou tarde demais”. Outra pessoa aponta que somos uma startup e esse primeiro lançamento é um MVP (produto mínimo viável), não dá para exigir perfeição.
O lançamento é adiado algumas semanas para resolver algumas bugs (erros ou comportamentos imprevistos do software) e finalizar outras features consideradas centrais.
Finalmente, o lançamento acontece!
Na primeira semana de lançamento, vários usuários entram na plataforma. Desde amigos e familiares de toda a equipe até alguns desconhecidos, devido aos esforços de marketing focados para esse dia.
Na segunda e terceira semanas, o volume de usuários novos vai abaixando. Isso parece natural após um lançamento. A equipe de marketing vai se esforçando, e investindo em publicidade, para não deixar cair essa curva.
Até que ao final do mês o líder do projeto pede aos desenvolvedores de software algumas métricas do banco de dados, para analisar os resultados desse primeiro mês.
E aí vem a descoberta.
A maioria dos usuários sequer utilizou o produto. Quase nenhum fez login mais de uma vez depois do cadastro. Com novos relatórios do banco de dados, isso vai se tornando cada vez mais óbvio — e desesperador. A verdade é: o usuário não se importa com o produto que foi lançado.
O que vem depois disso é uma grande corrida para corrigir os erros que foram cometidos antes. Ou é colocada a culpa na equipe de marketing e vendas, que não está performando direito. Ou pior, ocorre o fim do projeto que tomou meses ou anos de dedicação para ser construído. Mas quais erros foram esses?
Os quatro riscos de um produto de tecnologia
O maior risco no desenvolvimento de um produto de tecnologia é lançar um produto que ninguém se importa.
O principal erro que podemos fazer é não atacar esse risco antes da criação do produto, mas apenas depois que ele já foi lançado.
Isso porque o custo para criar um produto é muito maior do que o custo para descobrir se os usuários se importarão com ele. Assim, antes de gastar meses (e muito dinheiro) na criação do produto, é sempre bom lembrar que não há nada que vai obrigar as pessoas a utilizá-lo.
Como podemos saber se as pessoas se importarão com o meu produto antes de lançá-lo?
Para isso, existem diversas teorias e ferramentas.
Aqui, vamos começar dividindo esse grande risco em quatro menores, sugeridos por Marty Cagan no excelente livro Inspired — How to Create Tech Products Customers Love:
- Risco de valor (“os usuários vão querer pagar pelo meu produto?”)
- Risco de usabilidade (“os usuários conseguirão usar meu produto?”)
- Risco de viabilidade técnica (“meus engenheiros de software conseguirão construir meu produto?”)
- Risco de viabilidade de negócio (“meu produto será possível do ponto de vista financeiro, marketing, vendas, jurídico, de modo geral, de negócios?”)
Agora vamos falar um pouco sobre cada um deles.
Risco de valor: comece pelo problema
Se você não está resolvendo um problema real do seu cliente, a chance de ele querer pagar por isso é muito pequena.
Ao mesmo tempo, se você tentar resolver um problema genérico de muitas pessoas, em vez de um público específico, será mais difícil agradar a todos e oferecer uma solução que resolva aquele problema de um modo que as pessoas estarão dispostas a pagar por isso.
Ou seja, o primeiro passo para resolver um problema real é entender profundamente os indivíduos de um nicho específico, o que e como fazem todo dia, como se sentem, quais são seus principais desafios e como os resolvem hoje.
Você deve se apaixonar por esses indivíduos e seus problemas únicos, de um nicho específico, e não pelas soluções tecnológicas que você tem em mente.
Se a sua solução é voltada “ao público em geral”, tente entender se existe um produto menor, voltado a um nicho específico, que pode ser construído antes, pois a probabilidade é que ele seja muito mais simples de construir e mais fácil de vender.
Risco de usabilidade: foco no cliente
Se o usuário não conseguir entender ou utilizar o seu produto, nada mais importa.
Primeiro porque se o usuário não entende o seu produto e como ele resolve o seu problema, ele nunca entenderá o valor do seu produto, primeiro risco do qual falamos.
Segundo, se o usuário depende de você para utilizar o seu produto, dificilmente ele irá utilizá-lo, já que você não estará sempre ao seu lado para ajudá-lo.
Aqui o segredo é, novamente, apaixonar-se pelo seu cliente, pois assim você entenderá como ele pensa e sente, suas habilidades, seu vocabulário e a experiência que deve ser oferecida a ele. E aqui uma grande vantagem é ter começado por um problema de um nicho específico, pois você conseguirá alinhar a experiência do seu produto e sua comunicação de um modo que essas pessoas entendam e consigam usar.
Também é essencial a ajuda de designers e especialistas de UX (user experience). Em situações em que você não tenha nenhum desses profissionais ao alcance (altamente perigoso), mantenha sempre o foco no seu cliente, na jornada que ele irá percorrer antes, durante e depois do seu produto, e tente manter tudo o mais simples possível, para evitar excesso de informações e distrações desnecessárias, que escondem o valor do seu produto. Sempre pense na jornada do seu cliente, do ponto de vista dele, construa user stories (“quadrinhos” do percurso do seu usuário). Não fique cego com as funcionalidades do seu produto.
Risco de viabilidade técnica: custo para desenvolver
Sempre que você perguntar a um desenvolvedor de software se algo é possível, 99% de chance que ele responderá que sim. Afinal, computadores são programados para seguir instruções e, no limite, podemos instruí-los a fazer qualquer coisa.
De toda forma, sempre há tecnologias e dispositivos novos por aí, e nem sempre a sua equipe de desenvolvedores tem familiaridade com eles. Muitas vezes essas ferramentas novas impõem limites que ainda são desconhecidos, ou que demandam um custo muito alto para superar.
Esteja sempre muito bem alinhado com seus engenheiros quais são os custos e a viabilidade para implementar a solução, e se ela performará como pretendido. Dê tempo a eles para pesquisar e testar caso não tenham certeza sobre alguma resposta. Esse tempo de pesquisa com certeza irá se pagar no futuro.
Risco de viabilidade de negócio: consulte todos stakeholders
Um produto não irá se sustentar sozinho sem que você pense em canais de aquisição de clientes, fontes de receita, fornecedores, equipe de vendas, equipe de suporte, alinhamento com os objetivos gerais da empresa etc. Ainda mais se o seu produto envolver parcerias ou terceiros dos quais você irá depender, e sem eles o negócio não funciona.
Tente avaliar com a maior antecedência possível os riscos de marketing, vendas, financeiro, jurídico, entre outros, se possível consultando todos os stakeholders do seu projeto. Stakeholders são todas as partes interessadas no seu projeto.
Por exemplo, não deixe para consultar o jurídico da empresa apenas no dia do lançamento do produto, para descobrir que uma das features que vocês implementaram, senão o produto todo, possui um risco jurídico que a empresa não está disposta a correr. O mesmo vale para todas as áreas da empresa. Uma dica aqui é expandir o olhar para além do produto, focando em ferramentas de negócios como o Business Model Canvas.
Em conclusão, antes de se dedicar meses ou anos para desenvolver um produto ou startup de tecnologia, sugiro fortemente que tente atacar os riscos do produto antes de criá-lo, e não depois.
Se lendo esse texto você lembrou de algum caso que já aconteceu com você ou conhecidos, ou tem algo a complementar, por favor compartilhe nos comentários!
E no próximo texto, trago uma dica prática de como atacar esses riscos de uma forma barata e rápida antes da criação do produto: comece criando um protótipo, e não um MVP (veja aqui).
