Data science, machine learning e gestão de produtos

Nos últimos anos tem aparecido de forma recorrente e abundante os termos data science, machine learning e artificial inteligence. Esses termos são bastante importantes para os gestores de produtos. Não é à toa que dedico 5 capítulos do livro de Gestão de Produtos a assuntos relacionados a dados e métricas.

ds_ml

Como comentei nesse artigo, o gestor de produtos deve ser um data geek, ou seja, uma pessoa que está sempre pensando em como aprender mais com dados. Qual é o comportamento de uma pessoa nos meses e dias antes de cancelar a assinatura de seu produto? E o comportamento de uma pessoa que faz upgrade? Qual é o comportamento de um usuário que se diz satisfeito com seu produto? E do que se diz muito satisfeito? Se seu produto tem várias funcionalidades, qual é a mais popular? Qual gera maior satisfação? Qual é o padrão de uso típico de seu produto? Se aparecer um padrão de uso atípico, o que isso quer dizer? Esses são exemplos de algumas perguntas que o gestor de produtos pode fazer e que terão suas respostas nas métricas do produto. E a cada nova resposta obtida é muito provável que o gestor de produtos vai querer fazer mais perguntas.

Para achar as respostas às suas perguntas, é importante que o gestor de produtos conheça técnicas de data science e saiba como extrair ele mesmo as respostas para suas perguntas, quer seja por meio de ferramentas de extração e visualização de dados, quer seja rodando queries de SQL na base de dados do produto. Se o gestor de produtos não tiver essa independência, e precisar que outras pessoas extraiam os dados para ele, isso poderá atrapalhar a evolução do produto.

À medida que esse aprendizado a partir dos dados for acontecendo, é provável que o gestor de produtos comece a perceber oportunidades para inserir esses aprendizados dentro do produto. Por exemplo, um gestor de produtos de um software de CRM pode perceber, após fazer análises com dados de uso e engajamento do produto, que clientes acabam cancelando menos quando estão utilizando a funcionalidade de geração de propostas comerciais. Uma vez feita essa descoberta, ele pode promover uma mudança em seu produto para tornar mais fácil e imediato o uso dessa funcionalidade e, com isso, diminuir o churn de clientes por deixá-los mais engajados. Essa é uma forma de inserir data science em seu produto.

Machine learning, que nada mais é que uma forma de implementação de artificial inteligence, é quando programamos as máquinas para aprenderem com os dados e, quanto mais dados a máquina tiver em suas mãos, mais ela vai aprender. É uma maneira de inserir data science no produto para torná-lo melhor. Quanto mais você usa um determinado produto, mais dados estão à disposição do time que desenvolve o produto para conhecer seu usuário e como ele usa esse produto. Por exemplo, quanto mais compras você faz em uma loja virtual, mais ela aprende sobre seus hábitos de compra e mais fácil fica para o software da loja fazer recomendações que lhe interessem. O mesmo acontece com as sugestões do Netflix e do Spotify. Nesses casos é comum a loja comparar seu uso com o uso de pessoas que mostram comportamento similar para fazer sugestões do tipo “quem comprou esse item também comprou esses outros itens”.

É por isso que o gestor de produtos e todo o time que desenvolve o produto deve conhecer e saber usar data science, machine learning e artificial inteligence no seu dia a dia. São ferramentas poderosas para o ajudar a aumentar as chances de construir um produto de sucesso.

Saiu a edição atualizada do livro Gestão de Produtos

Essa semana ficou pronta a edição atualizada do meu livro Gestão de Produtos: como aumentar as chances de sucesso do seu software! \o/

gestao_produtos_linkedin_atualizada

Quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br. Quem ainda não comprou, é só visitar o site da editora Casa do Código e pedir já a sua cópia!

A primeira edição deste livro é razoavelmente recente, publicada em outubro de 2015. De lá para cá, são “só” 22 meses. Mesmo assim, senti a necessidade de atualizar o livro, pois continuei aprendendo muita coisa sobre gestão e desenvolvimento de produtos de softwares. Tenho publicado esses aprendizados aqui no blog Guia da Startup, mas senti a necessidade de incorporá-los ao livro para deixá-lo mais completo.

Nesse changelog, registrarei o que mudou desde a edição anterior. Assim, se você já leu o livro, pode ir direto para os novos textos!

  • Ao longo de todo o livro, inclui mais exemplos, tanto da Locaweb como da ContaAzul, para ajudar a ilustrar os conceitos abordados no livro.
     
  • Coloquei uma sessão nova no capítulo Gestor de produtos ou Product Owner?, explicando as diferenças entre BA (Business Analyst), PO (Product Owner) e PM (Product Manager). São papéis similares, mas com aumento de responsabilidades.
     
  • Adicionei um capítulo sobre como gerir gestores de produtos. Nem sempre um bom gestor de produtos se torna um bom gestor de gestores de produtos. Esse capítulo explica o que devem ser os objetivos de um gestor de gestores de produtos.
     
  • Na fase de Inovação, no capítulo Muitas oportunidades, inclui uma seção sobre uma pergunta que ouço com frequência: devo perseguir novas oportunidades, ou é melhor focar o time em implementar melhorias no produto existente?
     
  • Também na fase de Inovação, no capítulo Como obter retorno com seu produto de software, inclui mais uma opção de obter receita paga por alguém interessado em seu software: a venda de serviços de terceiros aos seus usuários.
     
  • Na fase de Crescimento, no capítulo O que é um roadmap?, inclui um seção intitulada OKRs, o futuro dos roadmaps, onde falo sobre OKRs (Objective and Key Results), framework usado por várias empresas (como LinkedIn, Google, Amazon, dentre outras) para ajudar na gestão das iniciativas da empresa como um todo e que são um ótimo complemento aos roadmaps.
     
  • Na fase de Crescimento, no capítulo Como priorizar o roadmap, inclui mais duas técnicas que aprendi recentemente: o Sequenciador de features, criado pelo Paulo Caroli, da ThoughtWorks; e o RICE, método de priorização adotado pelo time de desenvolvimento de produtos da ContaAzul.
     
  • Também na fase de Crescimento, inclui uma seção ao capítulo Crescimento: engajamento e churn intitulada Data science, machine learning e gestão de produtos. Nela explico os conceitos de data science e machine learning, e a sua importância para o sucesso do seu produto de software.
     
  • Inclui o capítulo O que é e como criar a visão e a estratégia do produto? no final da fase de Crescimento. Nele explico o que é e para que serve a visão e a estratégia do produto, ferramentas úteis para as tomadas de decisão sobre qual será o futuro do seu produto. Neste capítulo, apresento algumas técnicas e ferramentas para ajudar na criação da visão e na elaboração da estratégia de seu produto de software.
     
  • No capítulo Engenharia de produtos e gestão de produtos, incluí a seção Não dá mais, precisa reescrever tudo…, falando sobre reescrita de sistemas ou de parte de sistemas. Qualquer pessoa que trabalha com desenvolvimento de software vai se deparar com o momento em que surgirá a discussão da necessidade de reescrita. Qual o papel do gestor de produtos nessa discussão?
     
  • No capítulo Organizando para o foco e para a diversificação, inclui alguns parágrafos nos quais conto sobre as motivações que fizeram o time da Locaweb a não ter times separados de QA e de front-end, e sobre a razão de eu não ter mencionado BAs no capítulo sobre organização de times.
     
  • Inclui o capítulo Como quadruplicar a produtividade na Parte 4 do livro, no qual mostro como quadruplicamos a produtividade do time de desenvolvimento de produtos da Locaweb, sem aumentar a quantidade de pessoas no time e com impacto positivo na qualidade.
     
  • Inclui um capítulo na Parte 5 do livro, intitulado E se pararmos de tratar desenvolvimento de software como projeto?, em que proponho deixarmos de chamar desenvolvimento de software de projeto e passarmos a tratá-lo como produto.
     
  • Na conclusão, inclui uma seção intitulada O que é preciso para ser um bom gestor de produtos de software? para responder essa pergunta que me fizeram algumas vezes.

Relembrando, quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br. Quem ainda não comprou, é só visitar o site da editora Casa do Código e pedir já a sua cópia!

Não dá mais, tem que reescrever tudo…

Já ouvi essa frase várias vezes ao longo da minha carreira. Quem trabalha com desenvolvimento de software sabe que invariavelmente chega um momento em que aparece essa discussão com frases como: Está cada vez mais difícil mexer no código. Se fosse fazer do zero, seria muito mais rápido. Se não reescrevermos, vai ficar cada vez mais lento e perigoso mexer no código.

Na Locaweb tínhamos o produto de Email Marketing, para envio e gerenciamento de campanhas de email marketing, que usava como base de dados o MongoDB, uma base de dados não relacional conhecida por sua capacidade armazenar grandes bases de dados. Contudo, provavelmente devido à nossa pouco experiência em desenvolvimento de software usando esse tipo de base de dados e em administrar bases de dados não relacionais, à medida que a base de dados crescia, o sistema ficava cada vez mais lento. Por isso foi necessário reescrever o produto para usar PostgreSQL. Desenhamos essa reescrita de forma a ser transparente para os clientes, ou seja, o cliente não ia ser migrado de uma base de dados para outra, evitando assim passar por um período de indisponibilidade ou eventual perda de dados. A reescrita foi um sucesso. O processo todo de reescrita, incluindo colocar todos os clientes existentes (mais de 15.000 clientes) na nova base de dados, permitindo desligar a base de dados MongoDB, levou seis meses, um prazo razoável para uma iniciativa desse tamanho. Contudo, durante esses seis meses o time não entregou nada novo para o cliente. Nenhuma nova funcionalidade. Para diminuir a frustração de nossos clientes, decidimos por contratar uma empresa terceirizada para construir aplicativos para iOS e Android em cima das APIs existentes do produto. Com isso conseguimos entregar novas funcionalidades para nossos clientes enquanto o time de produto ficava focado no reescrita. Se essa opção não existisse, teríamos que encontrar outras formas de entregar valor para o usuário que não dependessem do time de engenharia.

Se você trabalha com desenvolvimento de software, tenha certeza que, se ainda não passou por essa situação em sua carreira, certamente passará. O problema de reescrever software é que, ao reescrever software, o time deixa de fazer coisas novas para o usuário do software, como mostrei acima no exemplo do produto de Email Marketing da Locaweb. Ou seja, do ponto de vista de negócio o software não evolui, o cliente não vê evolução, e pode perder o interesse pelo seu produto passando a procurar opções melhores no mercado. Por isso eu gostaria de tecer algumas considerações sobre o tema:

  • Tecnologias novas e melhores irão aparecer sempre. Antigamente desenvolvia-se sistemas com tudo em um código só. Depois foi o conceito de MVC (_model_, _view_, _controller_) separando o código do software em camadas de acordo com sua função. Mais recentemente foi criado o conceito de microserviços, quebrando a aplicação em aplicações pequenas, conectadas com baixo acoplamento, feito preferencialmente via APIs, facilitando a manutenção. Se, a cada nova tecnologia que aparecer, formos reescrever o software, certamente não faremos outra coisa senão reescrever software.
     
  • Reescrever software tem que ter uma motivação clara de negócio, ou seja, deve de alguma forma atender os objetivos estratégicos da empresa que é dona do software e deve atender às necessidades ou resolver um problema dos clientes. Se não houver uma motivação clara de negócio, a recomendação é não reescrever.
     
  • Se reescrever for inevitável (tem certeza?), é importante pensar nessa iniciativa de reescrita do ponto de vista de negócios, ou seja, qual é o impacto dessa reescrita para os clientes e para o dono do software. Entender isso é responsabilidade do gestor de produtos. Algumas perguntas para te ajudar a refletir junto com o time sobre esse impacto:
    • Como será essa reescrita?
    • Enquanto a reescrita estiver acontecendo, vão ser entregues novas funcionalidades?
    • Como será a co-existência do sistema novo com o sistema velho?
    • Quando forem implementadas novas funcionalidades, serão implementadas no sistema novo e no sistema velho, ou só no sistema novo?
    • Quando novos clientes poderão ser instalados no sistema novo?
    • Quando os clientes existentes serão migrados para o sistema novo?
    • Se existir a proposta de fazer um sincronizador para que os dados dos clientes existam simultaneamente no sistema velho e no sistema novo, qual é o custo dessa proposta se comparado com a opção de não fazer esse sincronizador?
    • Se a diferença entre o sistema velho e o sistema novo puder ser percebida pelos clientes, como essa diferença será comunicado?

Pronto, aí estão algumas considerações sobre reescrita de software, um tema muito importante para qualquer gestor de produto.

Novas oportunidades vs melhorias no produto existente

    Essa é uma dúvida bastante frequente. Devo perseguir novas oportunidades? E o que faço com as dores dos clientes atuais? Devo desenvolver um novo produto ou uma nova funcionalidade? Ou devo resolver dores dos clientes atuais desenvolvendo melhorias em meu produto? Como fazer para balancear entre perseguir novas oportunidades e implementar melhorias no produto existente?

    melhorias-ou-oportunidades

    Aqui a solução é simples, pelo menos em teoria. Produto atual é produto atual, novas oportunidades são novas oportunidades. Cada um tem que ser tratada de um jeito. O ideal é que sejam tratadas até mesmo por times diferentes. Só que nem sempre isso é possível. Nesses casos, se quisermos perseguir novas oportunidades, esse time tem que saber separar claramente o trabalho no produto existente vs o trabalho nas novas oportunidades. Por exemplo, 2 semanas para o produto existente, uma para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

    Atenção: não é time de bugs

    Esse é um ponto importante. A ideia não é separar os times para ter um time fazendo coisas novas e outro corrigindo bugs do produto existente. Isso não funciona, pois vai criar uma separação muito grande entre os dois times. Quem faz coisas novas vai eventualmente acreditar que pode fazer qualquer coisa sem se preocupar tanto com qualidade já que existe um time focado em correção de bugs. Do outro lado, o “time de bugs” vai achar que está fazendo trabalho de faxineiro, limpando as bagunças que outras pessoas fazem.

    Oportunidades vs melhorias

    Antes de investir em uma nova oportunidade é muito importante entender porque está se investindo nessa nova oportunidade. Uma ótima ferramenta para isso é a análise de oportunidades. Sem um claro entendimento e correto engajamento de todos os envolvidos pode-se colocar a oportunidade a perder sem nem mesmo começar a explorá-la.

    Um ponto importante que todos os envolvidos devem entender é que uma nova oportunidade é uma nova oportunidade, ou seja, ela deverá gerar resultados que se somam aos atuais. Esses resultados deveriam ser suficientes para justificar a criação de um novo time para perseguir essa nova oportunidade. No mínimo, dois engenheiros de software. Idealmente, além dos dois engenheiros, seria bom ter um gestor de produtos, um designer de UX e uma pessoa de marketing de produtos dedicadas a essa nova oportunidade. Essa nova oportunidade irá ser um novo produto ou uma nova funcionalidade. Quando esse novo produto ou nova funcionalidade estiver pronto e lançado, quem trabalhou no seu desenvolvimento irá cuidar de seus bugs e melhorias.

    Enquanto isso, o outro time cuida do produto atual, ou seja, de melhorar o produto atual para que ele continue atingindo seus objetivos. Melhorar o produto atual significa sim corrigir bug, mas significa também fazer coisas novas no produto existente. Melhorias para tornar o produto melhor, mais útil e mais usável.

    Caso não seja possível criar um novo time, pode-se fazer compartilhamento do tempo do mesmo time. Algo como uma ou duas semanas para bugs e melhorias do produto atual e uma semana para a nova oportunidade, até que se justifique a criação de um novo time para a nova oportunidade.

    Como saber se é uma melhoria ou uma nova oportunidade?

    É responsabilidade do gestor de produtos, junto com o time, entender se esse algo novo que surgiu para ser feito é uma oportunidade ou uma melhoria. Mas como discernir entre melhoria e oportunidade? Especialmente quando o algo novo a fazer for uma nova funcionalidade do produto existente, devemos encarar como nova oportunidade ou melhoria do produto existente?

    Depende do esforço e do retorno envolvidos. Uma nova oportunidade deve ter um retorno alto para fazer sentido persegui-la. Lembre-se que uma nova oportunidade vai eventualmente ter um time só para cuidar dela, então é preciso que o retorno seja suficiente para justificar esse novo time. Se o retorno for incerto, é melhor não tirar energia do produto existente para perseguir essa nova oportunidade. Por outro lado, se houver a perspectiva de um bom retorno, qual o esforço de criar algo para explorar essa oportunidade? E qual será o esforço para manter esse algo? Essas duas perguntas devem orientar a forma de encarar. Se o esforço for baixo, esse algo novo pode ser tratado como uma melhoria e ser desenvolvido pelo time atual. Se o esforço é alto, é recomendável tratá-lo como nova oportunidade e considerar ter um time separado para fazer o desenvolvimento.

Viagem no tempo

Acaba de ser lançada a edição atualizada do meu primeiro livro, o Guia da Startup. A primeira edição deste livro foi escrita em 2012, há mais de 4 anos. Muita coisa aconteceu na indústria de software e no cenário de startups do Brasil e do mundo. Por esse motivo, resolvi escrever uma segunda edição, trazendo algumas dicas novas, atualizando sobre o andamento do ContaCal e com um update das entrevistas publicadas na versão original, e mais algumas entrevistas novas.

Mudei as referências a “produto web” para “produto de software”. Fiz isso pois mobile é agora o novo veículo do software. No mobile, o software pode ser entregue via web ou via app. No futuro, o software será usado em relógios, em carros, em qualquer lugar. Por esse motivo, troquei onde falo “produto web” por “produto de software” ou simplesmente por “produto”. Aliás, isso me motivou até a mudar o subtítulo deste livro. Se você já o leu, talvez isso lhe motive a relê-lo, vendo produto sob este novo prisma.

Ao fazer essa atualização, um dos capítulos que mais mudou foi o capítulo “Produto web, móvel ou social?”. Atualizei o título do arquivo para “Produto web, móvel ou social? Produto para SmartWatches? SmartTVs? Bots?”. Aqui vai o capítulo completo, com direito a uma viagem no tempo!

Produto web, móvel ou social? Produto para SmartWatches? SmartTVs? Bots?

Acredito que, antes de falarmos sobre a situação e a recomendação sobre esses temas, vale mostrar o que escrevi em 2012, na primeira edição do *Guia da Startup*.

Viajando para o passado: web, móvel ou social em 2012?

Não é necessário ser nenhum mago das previsões para perceber duas tendências que estão acontecendo na internet. A primeira delas é que, cada vez mais, as pessoas estão acessando a internet e aplicações web por meio de aparelhos móveis, como iPhone, iPad, celulares e tablets com Android, ou mesmo aparelhos Blackberry ou com Windows Mobile. A segunda é que cada vez mais as pessoas gastam seu tempo online em redes sociais.

Em função disso, é natural surgir uma dúvida quando se pensa em fazer um produto web se, em vez de web, não deveríamos então estar pensando em fazer uma aplicação móvel, ou mesmo uma aplicação social, ou seja, para ser usada dentro das redes sociais.

Para ajudar a responder a essa dúvida, devemos olhar para duas questões: ter números do mercado para entender essas tendências, e conhecer seu usuário e onde ele quer seu problema resolvido.

Aplicações para aparelhos móveis

Antes de mais nada, é preciso confirmar as tendências. A primeira é sobre o uso de aparelhos móveis para acessar a internet. O site StatCounter Global Stats (http://gs.statcounter.com) oferece bons dados sobre acesso web agregados de um conjunto de 15 bilhões de pageviews mensais.

Esses dados oferecem uma visão sobre como as pessoas estão acessando a web. É clara a tendência de aumento de acesso a web por meio de aparelhos móveis, mas ainda está na faixa de 10%:

Evolução global de acesso móvel à web

Evolução global de acesso móvel à web

No Brasil, temos um pouco menos de adoção ao acesso móvel à web:

Evolução de acesso móvel à web no Brasil

Evolução de acesso móvel à web no Brasil

Nos Estados Unidos, a situação também é parecida com a estatística global:

Evolução de acesso móvel à web no Estados Unidos

Evolução de acesso móvel à web no Estados Unidos

Somente por curiosidade, um país onde a adoção de acesso móvel quase se iguala e está próximo de passar o acesso via desktop é a Índia:

Evolução de acesso móvel à web na Índia

Evolução de acesso móvel à web na Índia

Para confirmar esses dados, aqui vão os dados de acesso ao site da Locaweb. Aproximadamente 97,5% dos acessos são feitos a partir de desktop ou notebooks:

[Dados de acesso ao site da Locaweb em Abril/2012

[Dados de acesso ao site da Locaweb em Abril/2012

E no ContaCal, aproximadamente 93% dos acesso são feitos a partir de desktop ou notebook:

Dados de acesso ao site da ContaCal em Abril/2012

Dados de acesso ao site da ContaCal em Abril/2012

Esses gráficos mostram que é importante, sim, pensar em ter um produto web que possa ser acessado de forma móvel. Contudo, o mercado brasileiro, o americano e o mundial ainda não são majoritariamente móveis, nem estão próximos de se tornar majoritariamente móveis nos próximos 3 anos. Se olharmos a evolução da Índia, que está próxima de ter a quantidade de acesso móvel igual ao acesso desktop, essa situação chegou após 3 anos da situação que é vista no resto do mundo.

É difícil saber se o acesso móvel vai substituir ou minimizar o acesso desktop. Pode até acontecer de aparecerem outras formas de interação que ainda não existem hoje. O acesso por meio de aparelhos móveis é uma tendência clara, que deve não só ser observada de perto como também já deve motivar você a agir, ou seja, a pensar em desenvolver versões móveis de seu site ou aplicação web caso você ainda não o tenha feito. Para ajudar nessa tarefa, aqui vão algumas dicas.

De volta para o futuro

Isso tudo foi em 2012. Vindo para o agora, se você acessar o StatCounter Global Stats (http://gs.statcounter.com), verá que os dados evoluíram consideravelmente nos últimos anos. A quantidade de acesso móvel acaba de passar a quantidade de acesso via web:

Evolução global de acesso móvel à web

Evolução global de acesso móvel à web

No Brasil, a tendência é a mesma, apesar de estarmos um pouco atrasados:

Evolução de acesso móvel à web no Brasil

Evolução de acesso móvel à web no Brasil

Nos Estados Unidos, temos já 40% de acesso móvel:

Evolução de acesso móvel à web no Estados Unidos

Evolução de acesso móvel à web no Estados Unidos

E na Índia, o acesso móvel chegou a 80%:

Evolução de acesso móvel à web na Índia

Evolução de acesso móvel à web na Índia

Em julho de 2015, a PewResearch informava que 76% das pessoas que acessavam a internet usavam algum site social, sendo que 72% usavam Facebook. E os gráficos seguintes mostram que, enquanto a quantidade de PCs vendidos cai, a quantidade de aparelhos móveis cresce vertiginosamente.

Vendas de PCs por ano

Vendas de PCs por ano

Vendas de PCs e equipamentos mobile por ano

Vendas de PCs e equipamentos mobile por ano

Além disso, outras possíveis interfaces surgiram, como os SmartWatches, as SmartTVs e os bots. Algumas inclusive surgiram e já morreram, como é o caso do Google Glass.

O que fazer? Devo desenvolver produtos web? Mobile? Social? SmartWatch? SmartTV? Bot? E a Internet das Coisas? As opções aumentaram bastante desde 2012. E posso afirmar com toda a certeza de que elas vão continuar aumentando.

Por isso, você deve mudar o seu foco. Em vez de pensar no meio por onde seu produto vai ser entregue, foque-se no seu usuário.

Entenda seu usuário

Antes de pensar em qual plataforma você vai entregar seu software, você deve dar um passo atrás e relembrar qual o problema ou necessidade que você busca resolver e para quem. As pessoas para quem você resolve um problema ou necessidade com seu produto de software, como eles preferem interagir com seu software? Usando um SmartPhone? Um SmartWatch? Bot? Web?

Você precisa entender aonde faz sentido entregar seu produto de software para que ele possa resolver o problema ou necessidade de seu usuário da melhor forma possível.

Entenda o contexto

Quando um usuário acessa um site ou uma aplicação web de um desktop ou notebook, ele está normalmente sentado, com o computador em uma mesa ou no colo. A tela é grande, com bastante espaço para dispor informações. A interação é feita com mouse ou trackpad e teclado.
Já com um SmartPhone, a pessoa pode estar parada ou em movimento. A tela é pequena, com pouco espaço para disponibilizar informações, e a interação é feita com o dedo em equipamentos touch, ou com um apontador e um teclado pequeno.

Já com um tablet, a pessoa normalmente acessa sentada, com ele no colo ou sendo segurado em uma mão; ou em pé, com ele sendo segurado em uma mão; ou deitado, com ele apoiado nas pernas ou sendo segurado por uma das mãos. A tela é maior, chegando próxima do tamanho de tela dos notebooks menores, tendo assim um espaço razoável para dispor informações. A interação é normalmente feita com os dedos e, em alguns casos mais raros, com um teclado adaptado para tablets.

É importante conhecer esses contextos nos quais cada aparelho é usado para desenvolver uma versão de seu produto de software que seja útil para seu usuário. Por exemplo, se você estiver fazendo um site de um restaurante, no que será acessado por desktop faz sentido colocar o cardápio, matérias de jornal que falam sobre o restaurante e fotos. Já na versão para ser acessada por SmartPhones, você deve pensar no contexto e oferecer as funções mais úteis nessa situação.

Por exemplo, o site no SmartPhone pode ter dois botões grandes: um que ao ser tocado possibilita ligar para o restaurante; e outro que abre o Google Maps mostrando o endereço do restaurante.

Mobile não é “menos” que desktop

É importante também entender que SmartPhones não são menos poderosos que desktops. É comum pensar que, por terem menos capacidade de processamento e de armazenamento, equipamentos móveis são mais “fracos” do que computadores desktop ou notebooks. Sim, isso é verdade na maioria das vezes. Por outro lado, equipamentos móveis são providos de outras funcionalidades que não estão presentes nos equipamentos maiores, como GPS, sensor de movimento, duas câmeras, telefonia celular, conexão com internet em qualquer lugar que tenha rede de telefonia móvel. Isso é muito mais do que um notebook pode entregar.

É importante entender as diferenças e as possibilidades de cada interface para poder tirar o melhor dela na resolução do problema de seus clientes com seu produto de software.

Resumindo

Como vimos aqui, é importante sim estar antenado a essas tendências, mas devemos também entender muito bem nossos usuários, seus problemas e necessidades para oferecer a eles a melhor solução da maneira que for mais conveniente para eles, quer seja pela web, por meio de uma aplicação móvel, aplicação dentro de redes sociais, aplicação para SmartWatch, ou até um bot. Uma estratégia mista acessível por qualquer uma dessas plataformas pode ser a solução mais adequada para seu produto de software resolver o problema de seus usuários.

2ª edição do livro Guia da Startup

Desde de fevereiro está disponível a 2ª edição do livro Guia da Startup. Para conhecer todas as novidades dessa segunda edição, veja o changelog.

Guia da Startup – edição atualizada

Essa semana ficou pronta a edição atualizada do Guia da Startup! \o/

Quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br.

A primeira edição deste livro foi escrita em 2012, há mais de 4 anos. Muita coisa aconteceu na indústria de software e no cenário de startups do Brasil e do mundo. Por esse motivo, resolvi escrever uma segunda edição, trazendo algumas dicas novas, atualizando sobre o andamento do ContaCal e com um update das entrevistas publicadas na versão original, e mais algumas novas.

guia-da-startup-edicao-atualizada-capa

Veja aqui o changelog completo:

  • De produto web para produto de software — Mudei as referências a “produto web” para “produto de software”. Fiz isso pois mobile é agora o novo veículo do software. No mobile, o software pode ser entregue via web ou via app. No futuro, o software será usado em relógios, em carros, em qualquer lugar. Por esse motivo, troquei onde falo “produto web” por “produto de software” ou simplesmente por “produto”. Aliás, isso me motivou até a mudar o subtítulo deste livro. Se você já o leu, talvez isso lhe motive a relê-lo, vendo produto sob este novo prisma. 
     
  • Adição ao capítulo Recebendo feedback — Adicionei a este capítulo uma seção explicando a importância do porquê antes do como. 
     
  • Adição ao capítulo Cuidado ao lançar um produto mínimo — Adicionei a este capítulo um exemplo de experimento de fake feature que fiz no ContaCal e que me poupou muitas horas de desenvolvimento que se mostrariam desnecessárias. 
     
  • Capítulo novo: Dicas básicas (e não tão básicas) de SEO — Para ajudar a atrair tráfego para o site de sua startup, é importante entender de SEO (Search Engine Optimization). Neste capítulo, compartilho um pouco do que aprendi sobre o tema. 
     
  • Capítulo novo: Vá vender! — Essa é a melhor maneira de entender se seu produto resolve o problema dos clientes. Em uma startup, todos têm de vender. Então, o que você está esperando? Vá vender! 
     
  • Capítulo novo: Churn — Um capítulo inteiro dedicado ao churn, quantidade de usuários e clientes que deixaram de ser usuário ou cliente. Neste capítulo, explico também sobre o tão falado churn negativo. Como é possível ter churn negativo? 
     
  • Capítulo novo: Mudança de rumo (pivot) — Aqui conto o caso da Eventials, uma plataforma para transmissão de palestras online, que precisou mudar para sobreviver. Qual era o problema, o que eles fizeram e as 10 formas possíveis de mudança de rumo são os temas deste capítulo. 
     
  • Adição ao capítulo Quanto tempo demora até ter retorno? — Adicionei a este capítulo informações sobre o primeiro mês positivo do ContaCal. 
     
  • Capítulo novo: Cinco anos depois, como está o ContaCal? — Aqui conto como está o ContaCal, se ele está dando retorno financeiro e se atingiu seus objetivos. 
     
  • Entrevistas — Todas as entrevistas foram atualizadas com a situação mais recente das empresas e de seus produtos. Inclui também algumas novas entrevistas:
    • Sonia Tuyama, da empresa Aurum, com mais de 20 anos de mercado, que tem um software não web e que, em um determinado ponto de sua vida, percebeu que precisava fazer uma versão web de seu software.
    • Thiago Lima, fundador da Eventials, que citei em dois capítulos novos.
    • Vinicius Roveda, um dos fundadores da ContaAzul, empresa que escolhi para voltar a viver esse clima tão gostoso de Startup.

Gostou das novidades? Como disse acima, se vc comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço contato@casadocodigo.com.br.

Agora, se vc ainda não comprou sua cópia do Guia da Startup, o que está esperando, adquira sua cópia hoje mesmo!!!

Mais sobre priorização de roadmaps

Como comentei em meu artigo anterior, priorização é uma das principais tarefas de um PO e de um PM, e é o diferencia um PO de um BA. Escrevi um artigo sobre as várias formas de priorização e sobre como dizer não aos inúmeros pedidos que recebemos tanto dos clientes quanto das pessoas de dentro da empresa.

priorizacao

Como o passar do tempo aprendi mais maneiras de se priorizar um roadmap e queria compartilhá-las aqui.

Sequenciador de Funcionalidades

O Sequenciador de Funcionalidades foi criado por Paulo Caroli, da ThoughtWorks, para auxiliar no planejamento de um produto a partir de suas funcionalidades. As regras desse método, como o limite de 3 cards por linha, auxilia na conversa sobre priorização.

O Sequenciador de Funcionalidades ajuda a organizar e visualizar as funcionalidades e sua relação com os entregáveis. O sequenciador organiza as releases do produto além do primeiro entregável. Tipicamente, times utilizando o sequenciador de funcionalidades irão vislumbrar a evolução do produto por meio de um entendimento claro das funcionalidades de cada entregável bem como a ordem dos releases.

secuenciador-2

De acordo com Paulo Caroli, em seu livro Direto ao Ponto, Criando produtos de forma enxuta, o Sequenciador de Funcionalidades funciona da seguinte forma:

Feature é a descrição de uma ação ou interação de um usuário com o produto. Por exemplo: imprimir nota fiscal, consultar extrato detalhado, e convidar amigos do facebook. A descrição de uma feature deve ser o mais simples possível. O usuário está tentando fazer uma coisa. O produto deve ter uma feature para isso. Que feature é essa?

Cada cartão de feature possui uma cor representado o nível de incerteza, e marcações para o nível de esforço e o valor de negócio. Por exemplo, a figura acima mostra features em index cards, nas quais foram adicionadas marcações de $, $$ ou $$$, respectivamente, para valor de negócio alto, muito alto e altíssimo, bem como E, EE, ou EEE, respectivamente, para nível de esforço baixo, médio e alto. O nível de incerteza é representado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente.

O nível de incerteza da Feature refere-se ao grau em que a Feature é incerta, a partir do ponto de vista do entendimento de negócio e do entendimento técnico. Isso é indicado pela cor do cartão de índice, os quais são verde, amarelo ou rosa, indicando níveis baixo, médio ou alto de incerteza, respectivamente. O entendimento da Feature de acordo com os desafios técnicos, e os requisitos de infraestrutura. Você já fez isso antes? Você sabe como fazê-lo? Um sim bem firme indica elevado nível de entendimento técnico. A clareza do objetivo da Feature, o benefício para o negócio e o que deve ser feito. O que fazer? Uma resposta direta e clara indica um alto nível de concordância.

Esforço da Feature

O nível do trabalho que precisa ser feito para a Feature. O entendimento da equipe de acordo com a dificuldade e o trabalho que vai ser necessário para completar a Feature.

Valor do Negócio da Feature

O valor de negócio, o ROI (Return On Investment) associado a Feature, uma medida do negócio sobre o valor previsto para tal feature. Qual é o retorno no investimento ou a economia que a Feature vai trazer?

As regras do sequenciador de features

Features serão adicionadas a cada onda. A seguir, as seis regras para adicionar features às ondas. Tais regras foram definidas depois de aplicar esta forma de planejamento e priorização inúmeras vezes.

  • Regra 1: Uma onda pode conter no máximo 3 features.
     
  • Regra 2: Uma onda não pode conter mais de uma feature em cartão vermelho.
     
  • Regra 3: Uma onda não pode conter três features, somente em cartões amarelos e vermelho.
     
  • Regra 4: A soma de esforço das features não pode ultrapassar 5 Es.
     
  • Regra 5: A soma de valor das features não pode ser menos de 4 $s.
     
  • Regra 6: Uma onda tem de conter no mínimo 2 features.

A regra 1 limita o número de features que estão sendo trabalhados ao mesmo tempo. Isso evita o acúmulo de features parcialmente completas, aumentando o foco para as poucas features priorizadas por onda. As regras 2 , 3 e 4 evitam um período de trabalho desequilibrado com muita incerteza, ou muito esforço. As regras 5 e 6 garantem o foco constante na entrega de alto valor para o negócio.

Os MVPs no sequenciador de features

Além dos cartões de features (sequenciados), o sequenciador de features mostra claramente o agrupamento de features para cada MVP. Isto é representado por post-its no canto direito sobre a linha que delimita uma onda.

As ondas não terão necessariamente uma relação de um para um com os MVPs. O intuito é de organizar features em ondas para entregar valor o mais rápido possível, entretanto respeitando as dependências entre as features

RICE

Quando cheguei na ContaAzul me deparei com outro método de priorização adotado pelo time de produtos, o RICE.

RICE é a sigla em inglês para Reach (Alcance), Impact (Impacto), Confidence (Confiança) e Effort (Esforço). Os três primeiros itens da matriz são pontuados e, ao final, divididos pelo último.

Alcance se refere a quantas pessoas aquela tarefa irá alcançar num determinado período de tempo, que deve ser igual para todas as features que estão sendo comparadas. Impacto estima a quantidade de pessoas que serão impactadas (use o valor 3 para um impacto massivo, 2 para um grande impacto, 1 para médio, 0.5 para pequeno e 0.25 para um impacto mínimo). Confiança aborda o quão confiante você está sobre suas estimativas (escolha entre 100%, para uma alta confiança, 80% para média e 50% para baixa). Em Esforço, coloque quantas pessoas-mês a tarefa levará para ser concluída sendo o mínimo o valor 0,5, ou seja, uma pessoa por meio mês.

O cálculo matemático é bem simples:

RICE = (Alcance x Impacto x Confiança) / Esforço

A melhor ferramenta de priorização

Tanto o índice RICE quanto o sequenciador de funcionalidades são excelentes ferramentas para o gestor de produtos poder ter mais confiança em sua priorização. Contudo, como eu disse no meu primeiro artigo sobre o tema:

…existem várias maneiras de se priorizar um roadmap, todas elas bastante úteis. Ou seja, o que dá para concluir é que, se há tantas maneiras de se priorizar um roadmap e se todas as maneiras de se priorizar podem ser úteis, isso significa que priorização de roadmap não é uma ciência exata.

Temos um anseio de querer achar um método de priorização para justificar nossas escolhas, mas sempre que esse método falhar em um determinado item que temos certeza que seria melhor fazer antes ou depois do que o método diz, acabamos tentados a seguir essa nossa certeza, pondo abaixo o método.

Por isso, por mais que existam várias técnicas e métodos de priorização de roadmap, o melhor método é o bom senso, ou seja, a capacidade do gestor de produtos de analisar as opções disponíveis e, usando-se de sua empatia, priorizar essas opções levando em conta os objetivos da empresa e as necessidades dos usuários.

E por que é preciso incluir o bom senso como mais uma ferramenta de priorização? Porque para priorizar é preciso entender os objetivos dos usuários de seu produto de software e do dono do software. Esse objetivos podem ser conflitantes e, provavelmente, existem mais variáveis do que alcance, impacto, confiança, esforço, retorno, valor, custo, satisfação e necessidade para ajudar a quantificar esses objetivos. Como se não bastasse a grande quantidade de variáveis e os objetivos conflitantes dos usuários do produto de software e do dono de software, há ainda a variável tempo, ou seja, esses objetivos podem mudar ao longo do tempo.

Toda priorização é uma decisão e todo processo decisório é composto de incertezas. As ferramentas acima ajudam a remover um pouco das incertezas. Contudo, com essa grande quantidade de variáveis, é muito difícil, diria até que impossível, remover 100% das incertezas. Por esse motivo, para fazer uma boa priorização, pode ser útil usar uma ou mais dessas ferramentas descritas, mas é importante usar também o instinto, a experiência e o bom senso.

BA, PO e PM

Escrevi em julho de 2014 sobre as diferenças entre gestor de produtos ou product owner, onde comento que gestor de produtos e product owner são dois lados da mesma moeda. Enquanto o papel de gestão de produtos é focada no resultado, ou seja, no software que está sendo feito e nos objetivos desse software, tanto para o dono do software quanto para seu usuário, o papel de product owner é focado no processo pois todas a metodologias ágeis tem seu foco no processo de desenvolvimento de software.

Em um outro artigo, de março de 2016, comento que “BA e PO são papéis muito similares no desenvolvimento de software. Ambos têm o mesmo objetivo: ajudar o time a fazer um software que atenda ao objetivos do dono do software enquanto resolve problemas e necessidades de seus usuários”.

Algum tempo depois…

Esse dois artigos foram escritos baseados em minha experiência na Locaweb, onde tínhamos somente o papel de gestor de produtos, que chamávamos indiscriminadamente de PO ou de PM e em conversas que tive com pessoas de outras empresas onde elas me contavam sobre suas estruturas e divisões de papéis e responsabilidades.

Em agosto de 2016 assumi a gestão da gestão de produtos na ContaAzul e quando aqui cheguei me deparei com business analysts (BAs) e product managers (PMs), um cenário novo para mim. Passei algum tempo conversando com as pessoas para entender papéis e responsabilidades de cada função e as motivações de essa estrutura ter sido criada. Após essas conversas, ficou mais claro para mim a diferença de papéis e responsabilidades de cada uma das funções, diferença essa que tento traduzir na imagem abaixo.

ba-po-pm

Essa imagem mostra alguns pontos importantes:

  • POs fazem o que BAs fazem (especificação) mais a priorização do que precisa ser feito. E os PMs, além de priorização e especificação, são responsáveis pelo desenvolvimento, comunicação e execução da visão e estratégia do produto. Ou seja, existe um aumento de escopo e responsabilidade à medida que se move na carreira de BA para PO e depois para PM.
     
  • Apesar de o PM ter por sua responsabilidade o desenvolvimento, comunicação e execução da visão e estratégia do produto, ele também é responsável pela priorização e pela especificação.
     
  • Pode fazer sentido em algumas empresas ter BAs e PMs, ou POs e PMs, ou mesmo BAs, POs e PMs. Contudo, não pode haver empresas sem alguém fazendo o papel de PM, ou seja, desenvolvendo, comunicando e executando a visão e estratégia do produto.
     
  • Caso haja em uma empresa, além dos PMs, pessoas exercendo função de BA e/ou PO, é possível colocar os PMs como gestores dos BAs e/ou POs. Contudo, isso cria uma carga extra para o PM que, além de gerir o produto, terá que se preocupar com gestão de pessoas.
     
  • Minha preferência é por não ter essa separação de papéis e ter apenas PMs, ou seja, se houver BAs e ou POs numa determinada organização, minha recomendação é por tratar esse papéis como passos intermediários de carreira que vão evoluir para atingir o nível de PM, com aumento de escopo e de responsabilidade. A justificativa para essa minha preferência é que, ao deixar os papéis separados, pode acontecer de o PM fazer pouca ou nenhuma especificação e/ou priorização, delegando essas responsabilidades para BAs e/ou POs. Ao fazer isso, o PM perderá insumo importante para o desenvolvimento da visão e estratégia do seu produto.

Acredito que com essa imagem consegui deixar mais claro as diferenças e similaridades das funções de BAs, POs e PMs.

Retrospectiva 2016

Mantendo a tradição das retrospectivas, como fiz no final de 2015, farei agora uma retrospectiva de 2016.

2016-930x527

Gestão de Produtos

Ao longo desse ano acabei escrevendo alguns artigos que complementam meu livro Gestão de Produtos: Como Aumentar as Chances de Sucesso do seu Software:

Guia da Startup

Também escrevi algumas atualizações para o meu primeiro livro, Guia da Startup, Como startups e empresas estabelecidas podem criar produtos web rentáveis:

Dentre meus planos para 2017 está lançar as segundas edições desses dois livros. Também estou pensando seriamente em transformar esse material em dois cursos online.

Cultura Organizacional

Além da atualização desses dois livros, escrevi bastante em 2017 sobre valores e cultura empresarial:

Alguns dos artigos acima estão em inglês pois o Paulo Caroli está trabalhando na tradução para o inglês do meu livro sobre gestão de produtos. Nosso objetivo com essa tradução é aumentar a literatura disponível sobre o tema Gestão de Produtos. Há poucos livros sobre o tema, mesmo em inglês, e acreditamos que essa tradução pode ser útil para pessoas da indústria de software não só no Brasil, como em todo o mundo.

Artigos mais lidos

Aqui vai a lista dos 5 artigos escritos em 2016 mais lidos ao longo do ano:

E essa aqui é a lista do 5 artigos mais lidos em 2016, não importando quando foram escritos:

Pronto, está aí minha retrospectiva 2016. Estou bastante animado com 2017. Como disse acima, tenho planos de lançar as segundas edições de meus dois livros. Se tudo correr bem, também terei o livro sobre Gestão de Produtos em inglês. Além disso, estou estudando a possibilidade de lançar dois cursos online, um sobre Startup e outro sobre Gestão de Produtos. E tenho certeza que vou aprender muita coisa nova bacana que irei compartilhar por aqui!

Um excelente 2017!!!

Entrevista: ContaAzul

Trabalhei na Locaweb por mais de 11 anos. Quando eu entrei lá, eram pouco mais de 100 funcionários, ou seja, era ainda uma startup. Após esses 11 a empresa cresceu muito e hoje tem mais de 1000 funcionários. Nesse tempo que passei lá conheci várias pessoas e, dentre elas, vários fundadores de startups. Um deles foi o Vinicius Roveda, que conheci em 2012, quando a ContaAzul ainda estava dando os seus primeiros passos. A ideia era Locaweb e ContaAzul terem algum tipo de parceria para oferecer a solução de ERP da ContaAzul para os clientes da Locaweb. Na época a parceria não vingou mas Vini e eu conversamos algumas vezes sobre gestão e desenvolvimento de produtos de software e desde essa época já havia afinidade sobre esses temas.

Ao longo de 2016 voltamos a conversar e começamos a explorar a possibilidade de eu me juntar ao time da ContaAzul. A empresa agora tem 5 anos e está escalando a uma velocidade incrível. Por esse motivo o Vini estava buscando pessoas que tivessem já passado por isso em outras empresas e pudessem ajudar o time da ContaAzul a escalar de forma sustentável mantendo a alta velocidade de crescimento. Resolvi aceitar a proposta e voltar a viver novamente esse clima de startup.

Claro que eu aproveitei a oportunidade para fazer mais um entrevista para o Guia da Startup!

logo_contaazul

vini

Guia da Startup: Você poderia nos contar como surgiu a ideia da ContaAzul?

Vinicius Roveda: A ContaAzul surgiu com o objetivo de proporcionar uma nova experiência para micro e pequenos empreendedores em termos de sistemas de gestão. Sabemos que a principal causa a mortalidade das micro e pequenas empresas é a falta de planejamento e gestão. Por isso criamos algo que permite o pequeno empreendedor, com o mínimo de esforço, ter um alto nível de controle do seu negócio e, por consequência, obter melhores resultados. Nossa ideia era baseada em fazer um sistema online de gestão que pudesse ser acessado de qualquer lugar, sem a necessidade de treinamentos e implantação.

Outra preocupação que tínhamos era a capacidade de investimento do pequeno empreendedor e pensando nisso, criamos uma solução altamente escalável que nos permite oferecer um preço super acessível sem a necessidade de investimentos em infra estrutura própria, basta um computador com acesso a internet para começar a usar.

GS: Como você validou que sua ideia poderia virar uma empresa?

VR: Visualizamos a oportunidade de fazer um sistema de gestão online focado para MPEs em 2007. Desde então, estudamos muito esse mercado. O começo foi muito difícil. Criamos uma primeira versão do produto em 2008, mas acabamos não saindo dos beta users. Foi muito difícil encontrar o modelo de negócio ideal para escalar. Eu acabei gastando todas as minhas economias e diante dessas dificuldades nós acabamos abrindo outra empresa de desenvolvimento de software sob demanda junto com alguns amigos. Em paralelo a essa empresa, continuávamos com a ideia de fazer um negócio baseado em produto de software e com alta escala. Foi aí que relançamos o projeto com o nome ÁgilERP, isso foi entre 2010 e 2011. Nessa fase, fizemos uma tentativa de utilizar revendedores, mas esse modelo voltou a fracassar, pois os revendedores preferiam vender softwares mais caros e não o nosso que era barato e baseado em mensalidade. Em 2011, tivemos a oportunidade de conhecer a 500 Startups. Fomos a primeira empresa brasileira a ser escolhida para o processo de aceleração. Tivemos a oportunidade de viver quatro meses na Califórnia, período em que aprendemos muito sobre como acertar o modelo de negócio que utilizamos hoje.

GS: Você teve sócios desde o início? Como você encontrou seus sócios?

VR: Sim, desde o começo o José Carlos Sardagna, o João Zaratine e eu estamos juntos nessa jornada. Logo trouxemos também o Anderson Borges. Fiz faculdade com o Sardagna, fizemos o primeiro estágio juntos e depois de passar por outras empresas conhecemos e trabalhamos com o João e com o Anderson. Antes da ContaAzul montamos uma empresa de desenvolvimento de software sob demanda, a Informant onde trabalhamos juntos por alguns anos até criarmos o ContaAzul. Estou contando esses passos que demos juntos para mostrar a importância de conhecer bem e ter afinidade com os sócios com quem você vai trilhar esse caminho.

Anderson Borges, José Carlos Sardagna, João Zaratine e Vinicius Roveda

Anderson Borges, José Carlos Sardagna, João Zaratine e Vinicius Roveda

GS: O que motivou vocês a buscarem investimento?

VR: Para que a gente pudesse ajudar o maior número de pequenos empreendedores o mais rápido possível, precisávamos de ajuda. Essa ajuda era não só o dinheiro, que nos permitiu contratar os melhores profissionais para compor o nosso time, mas também a possibilidade de aprender com quem já fez empresas de sucesso e passou por desafios similares aos nossos. Temos a possibilidade de conversar com pessoas muito experientes do Brasil e de todo o mundo para trocar experiências. Isso nos ajuda muito. Os investidores nos apoiaram a estruturar o negócio e nos tornar líderes no segmento de sistema de gestão online com apenas 3 anos de existência.

Além de dois fundos americanos (500 Startups e Ribbit Capital) e dois brasileiros (Napkn Ventures e Monasshees), em 2013 recebemos um aporte da Valar Ventures, fundo do Peter Tiehl, que foi um dos criadores do Pay Pal e um dos primeiros investidores do Facebook. Recentemente recebemos mais um aporte que teve a participação da Tiger Global.

GS: Hoje podemos dizer que a ContaAzul atingiu a fase de “Escala”, ou seja, não é mais uma startup. Quais são, na sua opinião, os principais fatores que ajudaram vocês a chegar nessa fase?

VR: Foi uma combinação de fatores mas eu acho que o mais importante são as pessoas. É essencial ter as pessoas certas. Não basta só ter as melhores pessoas em cada função da empresa. Elas precisam estar alinhadas com o mesmo propósito, no nosso, o propósito de ajudar o pequeno empreendedor a ter sucesso, e com os mesmos valores, ou seja, com a mesma entendimento sobre a maneira correta de endereçar as situações.

Tendo as pessoas certas conseguimos construir um produto simples e fácil de usar mas que, apesar de simples, resolvia problemas reais dos pequenos empreendedores.

Com o time certo criamos um atendimento ao cliente UAU, ou seja, quando o cliente é atendido por nós ele é surpreendido positivamente. Ele fala “UAU”.

GS: Que conselhos você daria para quem está com uma ideia de montar uma startup?

VR: É um caminho difícil, mas vale a pena. Hoje podemos ver que ajudamos milhares de pequenos empreendedores de todo o Brasil a terem sucesso. Recebemos testemunhos todos os dias que nos enchem de alegria e nos dão a certeza de que estamos no caminho certo.

Ter um ótimo time é fundamental. E quando falo em time, não é só funcionários. A primeira escolha são os sócios, escolha pessoas com quem você tenha afinidade para trabalhar junto e para encarar momentos difíceis. Escolha bons investidores, que aportem mais que dinheiro, que te ajude a atingir os objetivos.

É isso! É um caminho difícil, mas vale muito a pena pela satisfação de poder ajudar pessoas a realizarem seus sonhos.