Spanish English French German Italian Portuguese
marketing social

concentrando

As startups são essencialmente máquinas que constroem MVPs (produtos mínimos viáveis) que ajudam a responder a perguntas e gradualmente reduzir o risco da proposta de valor da empresa.

A chave é que cada MVP que uma empresa cria precisa ser focado em responder a uma pergunta muito particular. Se você fizer algo mais do que isso, será perda de tempo e esforço. Na minha experiência, muitas startups se preocupam em escalar muito cedo, desperdiçando recursos em algo que pode nunca ser necessário.

Essa tendência é particularmente evidente em start-ups fundadas por pessoas provenientes de disciplinas de engenharia em empresas grandes e de grande porte. Mas as coisas que você precisa fazer para enviar código no Facebook, Netflix, Amazon ou Google não se aplicam da mesma forma a startups em estágio inicial.

As startups em estágio inicial podem ter algumas centenas ou milhares de clientes, e cada lista de clientes tem seu próprio conjunto de desafios.

Não entenda errado; É sempre melhor garantir que seu código seja relativamente seguro e escrito de uma forma que não prejudique a experiência do cliente. Mas os fundadores técnicos geralmente erram e gastam muito tempo fortalecendo o código (ou seja, tornando-o seguro), bem como escrevendo e implementando-o de forma que seja escalável.

Mas isso não funciona muito bem quando você está no modo de prova de conceito.

Os fundadores inexperientes geralmente ficam na defensiva sobre esse tipo de coisa, preocupando-se demais se o produto ou recurso que acabaram de criar oferecerá uma experiência de usuário perfeita ou se ele pode lidar com um milhão de usuários simultâneos. Sim, essas coisas são importantes, mas podem não estar certas neste exato momento.

A mentalidade nas startups em estágio inicial deve ser que você está criando MVPs para responder a perguntas. Lembre-se de que MVP ainda é um termo terrível; não é um produto nem viável. Também não é tão “mínimo” em muitos casos. Um MVP é a menor quantidade de trabalho que você pode fazer para confirmar ou rejeitar uma hipótese para sua startup.

Se a hipótese for: "Um milhão de clientes podem usar este aplicativo ao mesmo tempo?" Claro, esse é o momento certo para otimizá-lo dentro de uma polegada de sua vida útil. Mas, quando você está construindo um negócio nos primeiros dias, essa raramente é a questão e, a menos que você esteja em categorias específicas de aplicativos que precisam ser resilientes a quantidades notáveis ​​de tráfego, é improvável que os investidores se importem.

Em uma das startups em que ajudei, a empresa tinha um produto em que colocava dezenas de milhares de pessoas em uma sala de espera e, quando uma contagem regressiva expirava, todos podiam entrar no produto. Esse acabou sendo um desafio interessante: o que acontece quando 10,000 pessoas acessam exatamente a mesma parte de um aplicativo da web com um segundo de intervalo?

Como você pode imaginar, até mesmo pequenas ineficiências na plataforma causaram grandes gargalos e potencial degradação do serviço. A curto prazo, ele "resolveu" o problema ativando vários servidores adicionais e permitindo que as pessoas entrassem em minutos; ter 500 pessoas acessando o código ligeiramente ineficiente de uma vez era muito menos problemático do que ter 10,000 pessoas fazendo login ao mesmo tempo.

Elegante? Não funcionou? Sim, e fazia sentido porque, na época, a empresa não estava explicitamente preocupada se o serviço poderia atender 100.000 clientes ao mesmo tempo. Alerta: não poderia, e no momento necessário, aquela parte do código havia sido refatorada de forma a garantir que poderia.

Nos estágios iniciais, as perguntas tendem a ser: "O que estamos tentando fazer é possível?" ou "As pessoas vão pagar por isso?" ou "Podemos convencer um parceiro corporativo a integrar isso?" ou "Podemos adquirir clientes a um custo razoável?" ou "Podemos fazer isso a um preço que faça sentido?" ou “Como funciona a economia unitária deste produto à medida que escalamos?”

Para um negócio pré-semente, você não precisa de design e escalabilidade perfeitos; você precisa criar produto e tração suficientes para obter feedback do usuário. A partir daí, você pode iterar e criar valor para os clientes. Depois de começar a fornecer valor suficiente para que os clientes estejam dispostos a pagar, você pode começar a considerar investir mais em escalabilidade.

A engenharia excessiva de um produto muito cedo não é importante nem inteligente. É um contra-indicador: diz aos investidores que você não sabe o que é importante no estágio atual de sua startup.

Quando a atenção está focada, o teste decisivo é executado: sua atividade atual está contribuindo com garantias para ajudá-lo em sua próxima rodada de captação de recursos? Se não, provavelmente você está trabalhando em algo que parece super importante, mas não é apropriado para o cenário.

Isso é um problema - você sempre pode gastar mais tempo construindo algo mais sofisticado, mais rápido, mais bonito ou mais escalável - mas o mantra na inicialização deve ser "bom o suficiente é bom o suficiente". É incrível a rapidez com que você pode ir depois que a empresa o internaliza.

RELACIONADO

Deixe uma resposta

Por favor, digite seu comentário!
Por favor insira seu nome aqui

A moderação de comentários está ativada. Seu comentário pode demorar algum tempo para aparecer.

Este site usa o Akismet para reduzir o spam. Saiba como seus dados de comentário são processados.

INSCREVA-SE NO TRPLANE.COM

Publicar no TRPlane.com

Se você tiver alguma história interessante sobre transformação, TI, digital, etc. com um lugar no TRPlane.com, envie para nós e compartilharemos com toda a Comunidade.

MAIS PUBLICAÇÕES

Bem-vindo ao TRPlane.com

Instale
×
Ativar notificações OK Sem gracias