Armadilhas e o que não é um MVP

Em meu último artigo de empreendedorismo e agilidade eu tentei ao máximo desmitificar e esclarecer de maneira clara e didática o que é um MVP. No entanto, mesmo este mindset tão poderoso pode nos fazer cair em algumas armadilhas bem comuns quando estamos construindo nossos produtos.

Duas delas eu discuti no próprio artigo anterior:

Armadilha #1: MVP é aquilo que dá pra fazer no tempo que temos;

Armadilha #2: MVP é a primeira versão do produto que tem tudo que os clientes precisam;

Ambas armadilhas podem ser solucionadas se olharmos o diagrama abaixo que mostra quais características (e qual a proporção) que nossos MVPs devem possuir:

Estrutura de um MVP
Estrutura de um MVP

Um MVP que seja apenas factível (somente feasible, armadilha #1) provavelmente não será inovador o bastante para atrair os Early Adopters (sem o fator delightful, também chamado de “fator uau”).

Um MVP que tenha 100% de todas características não é um MVP é um produto completo.

Além de falar das demais armadilhas do conceito, quero reforçar algumas coisas que não são MVPs, mas que às vezes acabam sendo confundidas erroneamente. Agora, se você não faz muita ideia do que estou falando, sugiro ler o livro Lean Startup.

Armadilha #3: Roadmap de MVPs

Um roadmap de MVPs é algo parecido com o diagrama abaixo, onde temos a evolução de um produto para cortar grama.

Roadmap de MVPs
Roadmap de MVPs

Note que o raciocínio aqui está impecável: primeira versão temos uma tesoura, pra entender se de fato os Early Adopters cortariam suas próprias gramas, segunda versão temos um cortador mais prático para as costas, até chegar no MVP 8 onde poderíamos cortar a grama de um campo de futebol facilmente.

Qual a armadilha então?

Seguir esse roadmap à risca!

O Lean Startup não possui o Lean no nome ao acaso, ele veio dessa linha de pensamento japonesa de melhoria contínua, aprendizado e redução de desperdício, assim como os Métodos Ágeis de desenvolvimento de software. Estes últimos tem como base o Manifesto Ágil, em cujo quarto item nos diz que “responder a mudanças é mais importante que seguir um plano”.

E se a grama de nossos clientes cresce tão pouco que não faz sentido comprar um equipamento de corte? E se a quantidade de grama deles é tão pequena que eles jamais precisarão de um carrinho? E se a grama deles for sintética?

Você continuaria seguindo o roadmap nestes casos?

Lembre-se que o ciclo Construir-Medir-Aprender pode nos levar ao pivot e, com isso, nosso roadmap deve ser revisto. Ou seja, a armadilha aqui é focar em seguir o roadmap desenhado ao invés de aprender com as medições.

Armadilha #4: oferecer o seu MVP pra todo mundo

Vou começar sendo bem direto: o seu MVP não é um produto para lançar para todo mundo. Isso pode soar estranho para alguns, mas é exatamente isso. E não estou falando de segmentos de mercado, mas sim de segmentar os seus potenciais clientes do MVP dentro do seu segmento de mercado, ou seja, os seus Early Adopters.

Vamos pensar rapidamente em um MVP de ponte:

MVP de Ponte
MVP de Ponte

Há quem diga que isto não é um MVP de Ponte, uma vez que não atende aos critérios do diagrama inicial deste post (temos algum “fator uau” aí?), mas se considerarmos que estas pessoas tentavam pular este rio antes da ponte ou andavam kilômetros a mais para contornar o rio, ele pode ser considerado um bem para os ribeirinhos, certo?

Qual é o mercado de uma ponte? Todo mundo que precisa atravessar um rio? Mas especificamente de um MVP de ponte construído com tábuas, será que é o mesmo mercado? Quem são os Early Adopters deste MVP de ponte?

É muito importante oferecer o MVP e em alguns casos até restringir o acesso a somente os Early Adopters que você entender que de fato vão perceber as características de seu produto como valiosas e que a falta de algumas não os impeça de pagar pelo seu uso (ok, na ponte não há cobrança, mas você entendeu a analogia).

O que acontece se eu não restringir o acesso ao meu MVP a somente os Early Adopters? Várias coisas:

  • em uma análise quantitativa, o número de clientes que não gostaram do produto pode ofuscar o número de early adopters que de fato gostaram e que lhe dariam um feedback valioso (aprendizado); quem você quer agradar com a ponte de tábua, os ribeirinhos desesperados por uma solução rápida ou os turistas da cidade buscando uma experiência inesquecível?
  • pode queimar sua imagem no mercado com um “produto ruim” (nem todo cliente tem o mesmo mindset de um Early Adopter), uma vez que sua empresa já possua uma marca a zelar; imagine uma construtora inaugurando aquele MVP e ponte…
  • pode lhe trazer sérios problemas legais e de segurança caso clientes tenham experiências péssimas com um produto que pagaram para usar; imagine seu MVP de ponte sendo usado por um carro…

Armadilha #5: não definir seus Early Adopters

A quinta armadilha está bem interligada com a quarta, mas vou ser redundante mesmo assim: o seu MVP é para os seus Early Adopters. Se você não sabe quem são os seus Early Adopters, você nem deveria começar seu MVP.

O gráfico abaixo mostra a adoção de novas tecnologias pela população:

Adoção de novas tecnologias
Adoção de novas tecnologias

Dentro dos segmentos de mercado temos sempre aquelas pessoas que são mais propensas a adotar novas tecnologias e aquelas que só vão fazê-lo em último caso. Tipo meu sogro que ainda usava telefones de flip (estilo clamshell, de “abrir”) até pouco tempo e só trocou por um touch pois o dele estragou e não vendem mais o outro modelo.

Os Early Adopters são uma fatia do seu mercado, algo menor que 25%, que gostam de ser os primeiros a testar um novo produto, a usar uma nova funcionalidade, sentem-se valorizados quando as marcas pedem seu feedback e são críticos de maneira construtiva, colaborando com a evolução de produtos. Eles gostam de entrar em filas de espera de devices, de testar demos de jogos, se orgulham de usar softwares antes dos outros, mesmo que isso tudo incorra em estar sujeito a falhas ocasionais, falta de funcionalidades, etc.

Você sabia que o primeiro iPhone tinha a pior qualidade de ligação do mercado? E que ele não permitia copiar e colar texto entre apps? E que a Apple poderia ter lançado ele melhor do que lançou, mas que queria justamente testar o mercado? Isso não o impediu de ser um sucesso de vendas entre os early adopters da empresa.

Não definir antecipadamente quem são os seus Earl Adopters, e restringir o acesso ao seu MVP para eles pode gerar problemas enormes, principalmente se seu produto for um MVP de ponte…

MVP de Ponte - fail
MVP de Ponte – fail

O que não é um MVP?

Muitas vezes quando queremos que as pessoas entendam um conceito, precisamos mostrar a elas o que não é aquele conceito.

Um MVP não é um protótipo ou prova de conceito, não ao menos no sentido literal que estas palavras possuem dentro do ramo científico. Um MVP é um produto comercializável, enquanto que uma prova de conceito pode ser algo bem longe de ser comercializável. Cada um tem a sua utilidade, apenas não são a mesma coisa.

Um MVP não é o beta de um produto. Entende-se que um beta é um produto quase finalizado que abrimos para um grupo fechado de pessoas usarem e nos darem seu feedback, bem como descobrirmos erros ocultos que só os usuários conseguem detectar. Um MVP, principalmente nas iterações iniciais, é algo bem longe de um produto completo.

Um MVP não é a versão 1 de um produto. Ele está mais para uma v0.1. Se você chama suas v1.0 de MVP ou você está criando MVPs grandes demais, ou sua v1.0 é muito pequena. De qualquer maneira você está errado.

Um MVP não é um produto de mercado. Ele é um produto de nicho, para seus Early Adopters.

E finalmente, um MVP é um Minimum Viable Product e não um Maximum Viable Product.

Espero ter sido claro! 🙂

Quer ter ideias de como criar um MVP na prática? Dê uma olhada neste artigo aqui.

Querendo aprender a metodologia correta de desenvolvimento de software iterativo-incremental para não correr o risco de cair no modelo Waterfall de desenvolvimento de produtos? Conheça meu livro Scrum e Métodos Ágeis!

Você sabe o que é um MVP?

Em outro post mais antigo aqui do blog eu falei sobre como criar um MVP na prática, assumindo à época que o conceito de MVP era algo já “batido” e dominado por todos. No entanto, no final do ano passado finalmente entendi que embora todos saibam o que é a sigla, pouquíssimas pessoas realmente entendem a filosofia por trás deste conceito e o que de fato Eric Ries pretendia quando tornou-o famoso (embora ele não tenha criado o mesmo) em 2011.

A situação que me deparei foi a seguinte:

Queremos um MVP
Queremos um MVP

Ao que parecia, MVP era uma sigla que gestores que pouco entendem do assunto passaram a usar para convencer os times de desenvolvimento e a diretoria que sabiam o que estavam fazendo. Não havia nada de “mínimo” no escopo proposto, nada de “viável” no prazo estabelecido e nada de “produto” uma vez que era apenas um copycat. Resumindo, era uma sandice chamar este projeto de um MVP.

Chegou-se a usar inclusive a piada interna de que MVP significava “Maximum Viable Product” para aquele projeto.

Sendo assim, neste artigo (antes tarde do que nunca), eu tentarei dar uma luz à este tema, falar das origens, das armadilhas e muito mais.

A origem

O termo MVP passou a ficar famoso após a obra Lean Startup de Eric Ries, lançada em 2011, que já escrevi resenha aqui no blog. O conceito não foi ele quem inventou, ele é de 2009, e principalmente as ideias do Lean Startup também não eram 100% originais uma vez que Ries foi aluno de Steve Blank, autor do famoso livro The Four Steps to the Epiphany, onde descreve a metodologia Customer Development, além de ser investidor de muitas startups de sucesso e professor de empreendedorismo em universidades americanas.

Eric Ries e Steve Blank
Eric Ries e Steve Blank

Mas voltando à obra do Eric, neste fantástico livro ele nos traz conceitos como Contabilidade para Inovação (resumindo seu CAC deve ser menor que seu LTV), Métricas de Vaidades vs Métricas Acionáveis (ou sua métrica faz parte de um funil similar a um AARRR ou esqueça), Product Market-Fit (ajuste seu produto para atender uma necessidade de mercado), Pivotar (mude o produto conforme a necessidade, mas não a visão), Early Adopters (encontre primeiro quem pagaria para testar seu produto) e o famoso MVP (o mínimo para oferecer aos Early Adopters).

Claro que fui bem raso nas considerações sobre cada conceito e realmente lhe encorajo a ler este livro por completo.

Build-Measure-Learn

A metodologia foca muito forte em um ciclo chamado Build-Measure-Learn ou Construir-Medir-Aprender, conforme mostrado no diagrama abaixo. Esse ciclo foca em ajudar empreendedores a criar produtos inovadores, afinal, se você está apenas copiando um produto, não há porque ficar “experimentando”, apenas copie a receita do concorrente e pronto.

Build-Measure-Learn
Build-Measure-Learn

Você constrói uma parte do seu produto, mede o resultado alcançado e aprende com essas medições para que possa construir a próxima parte do seu produto. O ciclo ele é bem tranquilo quando estamos acertando, mas e quando estamos errando? Aí entra uma variação desse diagrama que é a minha favorita:

Build-Measure-Learn-v2
Build-Measure-Learn-v2

Nesta versão, que não é oficial do livro, quando o aprendizado nos traz que falhamos na ideia que construímos, é hora de pivotar (mudar de direção); ou seja, partimos para o campo das ideias e/ ao invés de ir para a próxima parte do produto, pode ser necessário trocar de funcionalidade (mais comum) ou até de produto (casos mais extremos).

Note também que esta versão enfatiza o uso de métricas acionáveis na medição para que de fato tenhamos aprendizado. Lembra quando falamos em Scrum sobre a Definição de Pronto? Não pode haver ambiguidade no que “DONE” significa e a analogia que faço aqui é que não pode haver ambiguidade sobre o que uma métrica significa para o sucesso do produto.

Você deve medir Métricas Acionáveis para poder aprender algo real com o que construiu. Métricas Acionáveis são aquelas que impactam diretamente no sucesso do seu produto, enquanto que as Métricas de Vaidade são aquelas que não contribuem tanto assim. Em minha antiga startup, uma métrica de vaidade era o número de visitantes no site. Uma métrica acionável era a receita gerada pelos anunciantes. Embora elas estivessem ligadas de alguma forma, a que realmente importava era a segunda.

Mas o que eu realmente queria mostrar nesta imagem era que a etapa Build do ciclo serve para construir um MVP. O ciclo Build-Measure-Learn e o MVP estão intimamente ligados uma vez que…anote isso…

Um MVP é criado para que possamos rodar uma vez o ciclo completo de Build-Measure-Learn. O seu tamanho deve ser pequeno o bastante para que seja barato falhar (considerando que estamos trabalhando com inovação, falhar faz parte do processo) e grande o bastante para que permita rodar o ciclo completo uma vez.

Ou seja, um MVP não serve para lançar um produto mais rapidamente no mercado, não na sua primeira iteração ao menos. Ele serve para validar uma hipótese, para se certificar que seus Early Adopters compram a ideia dele. Para lhe ajudar a entender se o que você está pensando tem futuro, se faz sentido.

Pra rodar uma vez o ciclo de Construir-Medir-Aprender, usando Métricas Acionáveis.

Apenas isso.

O Mindset MVP

O mindset MVP é como chamo o raciocínio de construir produtos usando a técnica de MVP do Lean Startup como guia. Provavelmente eu não inventei este termo, mas é assim que chamo.

Uma das imagens mais populares para o raciocínio de MVP é a abaixo:

Mindset MVP
Mindset MVP

Aqui temos a abordagem linear de construção de produtos no topo, e a abordagem usando MVPs.

A visão de ambos empreendedores é a mesma e pode ser definida como “fornecer uma solução de entrega”, onde o que eles adorariam ter seria um caminhão para fazer as entregas com o melhor custo-benefício entre velocidade de entrega, custo e capacidade de carga. No entanto, eles não possuem dinheiro para construir o caminhão em apenas uma iteração, deverão fazer aos poucos.

Enquanto que na abordagem linear, o “construir aos poucos” se resume a construir pedaços do caminhão, na abordagem MVP vamos iterando através de soluções de entrega alternativas e mais baratas ao caminhão, permitindo que desde a primeira iteração já tenhamos nosso produto gerando receita na rua. Ok, as primeiras versões (bicicleta e vespa) talvez não agradem o bastante nossos consumidores (a primeira é lenta e a segunda carrega pouca carga), mas a partir da terceira iteração já passamos a colher bons frutos.

Este diagrama possui muitas variações e serve para ilustrar um pouco o mindset MVP, mas não mostra todos os benefícios da técnica, principalmente considerando o cenário hipotético de que por exemplo, o mercado poderia estar precisando de entregas mais rápidas e menos poluidoras. Neste caso, qualdos dois empreendedores você acredita que poderia pivotar sua estratégia de entrega com o menor custo?

O mindset MVP é iterativo-incremental assim como os métodos ágeis, ao contrário do raciocínio waterfall das abordagens lineares de construção de produtos, onde um gerente de produto acredita ter todas as respostas sobre um mercado na sua cabeça. Repito: se não estiver trabalhando com inovação, mas apenas cópias, talvez dê certo sem uma abordagem MVP.

O Mindset MVP II

Quando entramos mais a fundo no estudo do mindset correto de criação de produtos inovadores entendemos que apenas uma abordagem simplista como a anterior não é o suficiente, embora seja um bom ponto de partida.

Uma falha comum na criação de MVPs é esquecer que ele deve ser um produto. E um produto deve ter algumas características mínimas que proporcionem ao Early Adopter uma experiência que o motive a pagar. O que quero dizer com isso é que um MVP não é “o que eu consigo construir do produto no tempo que eu tenho”, longe disso.

Para ilustrar melhor, considere esta abordagem linear de construção de um produto “bolo de casamento”:

Bolo linear
Bolo linear

Primeiro a massa de pão de ló, depois o recheio e depois a cobertura. Poderíamos chamar a massa de pão de ló de MVP de um bolo de casamento? Noivas comprariam uma massa de pão de ló para ter uma ideia de como seu produto final será? Estamos proporcionando a experiência correta com esta sequência de desenvolvimento do produto para que possamos gerar aprendizado a partir dele? Claro que não, este é o modo waterfall de desenvolver produtos.

Observe a abordagem abaixo para construção de um produto “bolo de casamento”:

Bolo com MVP
Bolo com MVP

Neste exemplo, nosso MVP (o produto mínimo viável pelo qual noivas pagariam para experimentar) é um cupcake. Um cupcake fornece toda a experiência de um produto “bolo de casamento” e pode ser feito com apenas uma fração do tempo e custo de preparo de um bolo inteiro.

Note que um cupcake não é apenas “o bolo mais rápido que conseguimos fazer”, pois o pão de ló é mais rápido de fazer do que um cupcake. Ele é sim “a experiência de bolo mais completa que conseguimos fazer de maneira rápida”. Jamais chame o “pão de ló” de MVP, ou uma “fatia de bolo” de MVP. Um MVP é um cupcake.

Mas como saber que temos um cupcake, digo, um MVP em mãos?

Quando nosso candidato a produto mínimo viável possui as seguinte proporção de características de um produto inovador:

Estrutura de um MVP
Estrutura de um MVP

Esse diagrama mostra as características desejáveis em um produto inovador, da base para o topo:

  • factível: conseguimos construir com os recursos que temos;
  • valioso: clientes pagariam por isso;
  • usável: clientes conseguiriam usar ele;
  • encantador: clientes se admiram e recomendam ele aos outros;

Os erros mais comuns de quem acha que sabe o que é um MVP são dois: achar que um MVP deve conter todas estas características na sua plenitude (lembra da imagem inicial deste post?) e o outro é achar que um MVP deve ser apenas “o que conseguimos fazer no tempo e dinheiro que temos”.

Para que seu MVP atraia os clientes certos (no caso de um MVP eles são os Early Adopters), ele deve proporcionar uma experiência de produto adequada. Se fizer algo de qualquer jeito, a sua ideia até pode ser boa, mas não vai vender e você vai ter um falso negativo sobre a sua hipótese de inovação. E se tentar fazer tudo perfeito, um produto completo, poderá demorar muito tempo e perder o time-to-market, ou até mesmo descobrir só mais tarde que construiu algo que ninguém quer.

Espero que eu tenha ajudado a esclarecer e desmitificar esta importante técnica!

E agora que você sabe o que é, leia este artigo para ter algumas ideias de como criar um na prática ou este aqui que fala das armadilhas do conceito.

Querendo aprender a metodologia correta de desenvolvimento de software iterativo-incremental para não correr o risco de cair no modelo Waterfall de desenvolvimento de produtos? Conheça meu livro Scrum e Métodos Ágeis!

Conselhos para quem quer empreender full-time

Palestrando no TDC 2016
Palestrando no TDC 2016

Esse post é focado em organizar em um só lugar algumas dicas de minha autoria para quem quer empreender full-time. Basicamente parte das minhas experiências pessoais com alguns toques do que eu faria de diferente hoje. Saí do meu emprego em 2012 para empreender e durante três anos toquei meu próprio negócio até que decidi voltar ao mercado de trabalho pois minha startup, apesar de ter faturamento, não decolou. Apesar disso, consegui viver bem durante este tempo, sem luxos ou firulas, mas bem, sem dívida alguma, sem precisar vender carro, etc.

Vou falar nesse post sobre:

  1. Planejamento
  2. Validação
  3. Migração
  4. Organização

Qualquer dúvida ou sugestão que tiver, deixe nos comentários no final do post!

Passo 1: Planejamento

Antes de sair xingando o chefe e dando tchau pra galera, pare e pense o motivo pelo qual está querendo empreender. Empreender é dureza e você nunca está 100% preparado psicologicamente para não ter seu salário caindo na conta todo dia 5. Você já sabe em qual área vai empreender? O quanto pretende faturar? Onde será seu escritório?

Um bom planejamento envolve:

  1. ter economias no banco que você possa queimar enquanto seu negócio não dá certo;
  2. encerrar suas atividades na empresa atual dignamente, pois você pode precisar voltar para lá ou ter referências deles algum dia;
  3. reduzir todos os custos supérfluos que podem existir no seu orçamento doméstico, pois a grana vai encurtar;
  4. conversar com sua família da sua ideia de empreender, pois você vai precisar de apoio moral e provavelmente financeiro;
  5. conseguir um mentor mais experiente ou um sócio para te ajudar no negócio, pois você vai ter muitas dúvidas e é sempre bom ter alguém pra conversar sobre elas ou até pra dividir a carga da responsabilidade de ter uma empresa;
  6. botar todas tudo no Excel pra manter o controle;

O que eu faria diferente? Na época minha esposa também estava empreendendo. Dois empreendedores em casa é algo um tanto problemático financeiramente. O ideal é que se você é casado e quer empreender, converse com sua esposa para que ela continue com um emprego fixo, só por precaução.

Além disso, eu deveria ter me planejado com mais antecedência. Lancei minha startup em julho e saí da empresa em setembro. Só que alguns meses antes de lançar minha startup eu troquei de carro, o que me gerou uma conta pesada que não era realmente necessária.

Passo 2: Validação

Não largue tudo para depois descobrir se a sua ideia tem potencial. Crie um MVP dela primeiro e só depois dele estar provado pense em largar seu emprego. Criar MVPs como side projects do seu emprego atual é uma ótima oportunidade de aprender mais e dependendo do quão avançado você conseguir, até gerar uma renda extra durante o processo, como um lifestyle business.

A regra é clara: só saia do seu emprego fixo se o seu empreendimento estiver gerando grana. Eu mesmo segui essa regra, embora se fosse fazer isso de novo hoje, sairia quando ele estivesse gerando grana suficiente para pagar todas minhas contas, o que não foi o caso na época.

Uma boa validação envolve (praticamente o ciclo do Lean Startup aqui):

  1. criar um MVP;
  2. tentar vender o seu MVP e conseguir 5 vendas;
  3. se não der certo, melhore seu MVP até conseguir as 5 vendas;
  4. continue tentando vender enquanto os primeiros compradores usam ele e lhe dão feedback de como melhorá-lo;
  5. implemente as melhorias sugeridas e continue trabalhando com as vendas até que você ganhe o suficiente para pagar as suas contas ou até que isso comece a trabalhar o seu emprego atual. Em ambos os casos, ou você terá de sair do emprego ou encerrar seu projeto de empreender.

O que eu faria diferente? Só sairia do meu emprego após o meu MVP estivesse faturando no mínimo o que eu precisar para pagar todas minhas contas fixas mensais. Além disso, escolheria melhor as minhas métricas de sucesso, uma vez que eu perdia muito tempo com métricas de vaidade.

Passo 3: Migração

Se você conseguiu fazer seu MVP lhe gerar tanta grana que pague todas as suas contas, ótimo, mas não foi assim comigo. Eu passei por um processo em que fui me desvencilhando aos poucos do “chapéu” de empregado e assumindo o de empreendedor. Basicamente mesmo após cortar todos os meus custos fixos e variáveis supérfluos, o que reduziu meu orçamento doméstico mensal de R$2.700 para R$1.800, eu não faturava R$1.800 com meu MVP e tinha de completar essa renda de alguma forma, a menos que eu me desfizesse do meu carro, que custava R$690 de prestação à época. Mas eu não queria. 🙂

Algumas coisas foram fáceis de cortar como Netflix, celular pós-pago para pré-pago, shopping todo final de semana. Outras foram mais difíceis com o curso e Inglês, que eu tive de fazer permuta com o dono da escola para pagar o curso com freelas de desenvolvimento pra ele. Além disso, fiz muitos apps mobile.

Eu fiz migração de empregado para empreendedor da seguinte forma:

  1. primeiro, saí do meu emprego atual que era de 8h/dia;
  2. peguei um contrato PJ (eu abri um CNPJ na época) de 4h/dia durante 6 meses em uma empresa de um amigo meu. Nas demais 4h eu trabalhava na minha empresa;
  3. depois dos 6 meses de contrato, passei a pegar freelas em que trabalhava 2h por dia neles e as demais 6h em minha empresa (como apps Android);
  4. depois de mais uns 6 meses consegui investimento para minha startup e passei a me dedicar 8h por dia à ela, podendo trazer inclusive meus sócios para vir trabalhar full-time comigo pois tinha grana em caixa pra isso;

Obviamente falar que eu trabalhei apenas 8h por dia em meu negócio é mentira, eu trabalhava no mínimo umas 12h por dia. Só nos finais de semana que eu costumava trabalhar menos, aí sim, provavelmente umas 8h.

O que eu faria diferente? Meus sócios só saíram de seus empregos depois que não havia mais risco. Isso não foi certo, pois eles estavam agindo como empregados. Exija tanto comprometimento de seus sócios quanto você está comprometido.

Outra coisa que eu faria diferente é trabalhar à noite em um serviço para queimar menos grana da empresa. Eu comecei a fazer isso depois de um ano empreendendo, trabalhando como professor em uma faculdade após o expediente na minha empresa. Com isso minha grana aumentou e diminuiu bastante minhas preocupações com as contas.

Passo 4: Organização

Trabalhar por conta própria é ser livre. E ser livre é muita responsabilidade, afinal, ninguém vai te dizer o que precisa ser feito e muito menos vai te pagar todo mês por apenas “estar trabalhando”. Ou você descobre o que precisa ser feito, o que é mais importante, ou seu negócio não gera grana e você vai quebrar logo, logo.

Se organizar é uma etapa fundamental do processo de ser um empreendedor. Você precisa ter muita disciplina e muitas vezes terá de fazer coisas que não gosta para que sua empresa dê certo, simplesmente porque elas são importantes para o crescimento do negócio. Se não definir prioridades bem claras e não executar todas as tarefas importantes, não tem milagre, você vai quebrar.

Uma maneira de organizar o seu dia-a-dia como empreendedor é:

  1. comece seu dia definindo as prioridades para o mesmo. Liste as coisas que devem ser feitas em uma planilha e coloque a prioridade de cada uma. Para definir a prioridade, pense a respeito de quanta receita aquela tarefa irá gerar ou economizar. Para ajustar a prioridade, pense no quão urgente é essa tarefa, se algo é urgente e vai gerar grana, deve ser mais prioritário de algo que apenas gera grana.
  2. pegue duas tarefas do topo da lista, que são mais prioritárias e urgentes que todas. Execute essas duas tarefas logo na manhã, isso garante que seu dia foi produtivo.
  3. no decorrer do dia, execute as demais tarefas da lista não necessariamente na ordem de prioridade, mas conforme o seu bom senso, apenas priorizando emergências que possam aparecer.

Pode soar um pouco estranho, mas é isso mesmo. Aprendi com um coach essa técnica muito simples há muito tempo atrás, e nesse meu post sobre produtividade tem mais algumas dicas adicionais.

O que eu faria diferente? Me organizaria dessa maneira desde o primeiro dia. Demorei um bom tempo até aprender que não dá pra fazer tudo que você precisa fazer em um dia só e que se você não botar regras e limites para o quanto é saudável trabalhar na empresa, você enlouquece. Eu perdi vários kgs no primeiro ano de empresa até organizar meu trabalho, pois não tinha tempo nem de me alimentar.

O que achou das dicas? Tem algo a acrescentar? Deixe aí nos comentários!