Oi, pessoal! Hoje vou falar um pouquinho sobre como evoluímos de um mindset de desenvolvimento sob demanda para um time de produto aqui na mobLee. Quais foram as dificuldades e quais as características, positivas e negativas, que ainda carregamos por causa das nossas origens.
Nesse texto, você vai entender um pouco da história da mobLee e como chegamos onde estamos.
Primeiro de tudo, deixa eu me apresentar. Eu me chamo Luckas Frigo e apesar de ser formado em design gráfico, com mestrado em ergonomia, toda minha carreira profissional foi de desenvolvimento. Eu comecei a trabalhar na mobLee em 2013, assumindo o time de desenvolvimento web e há pouco mais de 6 meses assumi a frente do time de produto.
Minha primeira experiência com desenvolvimento de produto foi na Mobiliza, onde eu trabalhei como desenvolvedor web durante 6 anos, desenvolvendo cursos eLearning. Na época, quase tudo que nós fazíamos era em Flash (sim, o falecido). Lá eu liderei o desenvolvimento de uma ferramenta interna para a criação dos cursos, que nós resolvemos tornar pública e oferecer para nossos clientes. Infelizmente, enquanto eu estive na empresa, a ferramenta não chegou a ser comercializada e eventualmente ela foi descontinuada. Por que afinal ela rodava em Flash.
Só a título de curiosidade, hoje a Mobiliza comercializa uma ferramenta que é, digamos, filha daquela que eu comecei lá atrás. E isso me deixa pessoalmente orgulhoso! :)
Mas a seguir, você vai entender por que contextualizei a minha história de vida:
Por que eu estou falando de tudo isso?
Porque, talvez, há uns anos atrás eu não tivesse a noção tão clara de que o que eu precisava construir era um produto.
Para mim eu só estava desenvolvendo mais um software como outros tantos que eu já tinha feito.
Nesses últimos 5 anos de mobLee nós passamos por essa trajetória de mudar o pensamento de “uma empresa de desenvolvimento” para “uma empresa de produto”, e isso fez com que eu aprendesse muito. Aliás, continuo aprendendo cada dia mais sobre essa diferença de mindset.
Acho que essa minha “dupla personalidade” de desenvolvedor (dev, para os íntimos) e designer sempre me fez gostar de transitar nesse caminho de entender problema e implementar solução.
Para vocês terem um pouco mais de noção sobre como nosso produto (e nosso time) mudou nesses anos, vou contar um pouco da história da mobLee desde que eu me juntei ao time.
Um pouco da histórida da mobLee
Em 2013, quando entrei na mobLee, nós nos considerávamos uma empresa de desenvolvimento mobile. Na época nós tínhamos:
- Dois desenvolvedores Android;
- Dois desenvolvedores iOS;
- Um desenvolvedor web (eu!);
- Um designer;
- e um CEO.
Basicamente, alguns briefings chegavam pelo pelo André (nosso CEO), nós discutíamos viabilidade e preço e, se o orçamento fosse aprovado, nós desenvolvíamos.
Em uma dessas negociações, antes mesmo de eu entrar para a equipe, nós acabamos vendendo 5 aplicativos de evento para a filial brasileira da maior organizadora de eventos do mundo: a Reed Exhibitions Alcantara Machado.
Desde o primeiro contrato eles já sabiam os recursos que eles queriam que o app possuísse. Eles nos passaram o briefing e nós desenvolvemos. Basicamente o que eles queriam era uma guia digital, que substituísse a programação impressa do evento, mostrasse quem eram os expositores, que produtos eles estavam expondo e um mapa do evento.
Além disso, o usuário poderia favoritar essas informações antes do evento para programar melhor a visita dele. Esses 5 aplicativos viraram 9, e no ano seguinte viraram mais 22. E nesse início, o que nós fazíamos era basicamente copiar o código de um aplicativo para outro e adaptar algumas coisas da interface e eventualmente, funcionalidades.
Fonte: autor.
Isso não nos impediu de continuar desenvolvendo outros aplicativos com usos completamente diferentes. Alguns por conta própria, outros por contratos fechados. Nós desenvolvemos um aplicativo para o jogo Sueca (sim, aquele de beber), outro para uma galera que resolveu viajar de Kombi pela América Latina, um para o treinamento de uma grande montadora de carros, entre outros. Eu lembro de nós chegarmos a orçar um app de relacionamento para jogadores de tênis. Afinal, se estavam dispostos a pagar, por que não?
O que você precisa é de foco
Não existe nenhum problema em ser uma empresa de outsourcing de desenvolvimento. Inclusive, isto é um modelo que muitas empresas resolvem seguir. Porém, se você pretende ser uma empresa de produto é preciso ter foco. E naquele momento, apesar de não termos clareza do nosso produto, nós já sabíamos o que nós queríamos ser.
Lembram que nós tínhamos vendido um app de eventos para a maior organizadora de eventos do mundo? Nós começamos, de pouco em pouco, a estruturar um framework que permitia reaproveitar as principais funcionalidades do app (e copiar e colar menos código). Outros eventos começaram a nos procurar e, a cada novo evento, uma customização nova. Nós começamos a entender ali que tínhamos um produto.
É bem comum que cada evento tenha algumas características próprias. Por isso era comum que a cada contrato surgissem customizações. Customizar a interface de cada aplicativo era o mínimo que nós fazíamos, mas em geral, cada novo evento acabava demandando também novas funcionalidades, como por exemplo:
- Os visitantes precisam fazer check-in no facebook;
- Meu app tem que mostrar onde o visitante estacionou o carro;
- Eu quero que tenha uma raspadinha que sorteie brindes;
- Os participantes precisam conversar entre si;
- O usuário precisa fazer anotações dele dentro do app.
Algumas dessas funcionalidades, na verdade, fazem bastante sentido para vários eventos. Porém, nós tínhamos uma peculiaridade: quem utilizava o app não era quem contratava. O organizador do evento nos contratava, mas quem utilizava o app eram os participantes. Ou seja, nós não adicionávamos funcionalidades por que aquilo faria diferença para o usuário final, nós adicionávamos porque era o que o organizador tinha contratado. E isso gera uma miopia da solução final, que às vezes nos fez entregar soluções incompletas.
Foi o caso da funcionalidade de anotações, por exemplo. O usuário podia fazer suas anotações e consultá-las dentro do app, mas só dentro do aplicativo. Ele não tinha como exportá-las para outro lugar, a não ser que entrasse uma a uma e copiasse o conteúdo.
Claro que nós pensávamos no usuário final e sempre nos preocupamos em como ele utilizaria melhor qualquer uma das funcionalidades, mas quando seu objetivo é desenvolver uma funcionalidade X que o cliente contratou, com uma limitação de tempo e orçamento, é importante lembrar que quem aprova é o próprio cliente, muitas vezes você vai acabar pecando.
Por isso é importante que você conheça o seu público. Quem são os usuários que vão de fato utilizar? Quais os problemas que eles enfrentam e que eu não resolvo? Qual a melhor forma de adicionar valor para esse usuário? E se o usuário e o cliente não forem necessariamente a mesma pessoa, como no nosso caso, como que o valor que eu adiciono para esse usuário se reflete em valor para o meu cliente?
Como descobrimos isso?
E como eu descubro tudo isso? Conversando. Para ser bem sincero, esse ainda é um ponto de melhoria do nosso time de produto. Nós não conversamos com nossos clientes e com nossos usuários com a frequência ideal. Mas sempre que nós conversamos, algumas coisas ficam mais claras e isso nós dá mais segurança de para onde direcionar o produto. Por isso, conversem :)
Use isso para direcionar seu RoadMap e não tenha medo de acelerar algo por que alguém está disposto a pagar por isso agora. Só faça isso de forma consciente e sempre focando na entrega de valor.
Bom, voltando a história da mobLee. Mais ou menos ali entre 2013 e 2014 nós já estávamos fazendo apenas aplicativos para eventos. E esse já era um mercado bem grande.
Em 2013 o mercado de eventos movimentou centenas de bilhões no Brasil. Tudo certo, nós tínhamos um produto que atendia um mercado gigante. O que a gente demorou um pouco para perceber o mundo de eventos abrange muita coisa: casamento é evento, formatura é evento, show é evento, um jantar pode ser um evento a copa do mundo é um evento.
Conhecer o seu mercado e saber direcionar seu foco para o segmento certo é algo muito importante. Afinal, mesmo com características em comum, cada fatia do mercado vai ter suas características próprias e isso vai demandar processos diferentes no dia a dia e, por consequência, necessidades de soluções diferentes.
Nós acabamos direcionando nosso produto para o mercado de feiras de negócios e congressos (e mais para a frente também para eventos corporativos). O motivo? Bem, essa já era a fatia do mercado de eventos que considerávamos mais compatível e alinhado com o que tínhamos desenvolvido até então. Nós até chegamos fazer um ou outro aplicativo para shows ou outros tipos de evento, mas acabamos percebendo que focar no segmento correto ajudaria no direcionamento da empresa como um todo.
O crescimento da startup
Entre 2014 e 2015 o time começou a crescer um pouco e nós percebemos que algumas coisas ainda distraíam o time de produto, como atender o telefone e eventualmente ter que lidar com clientes.
Então, nós começamos a procurar alguém para fazer essa parte de “atendimento”. Mas infelizmente, falhamos miseravelmente com algumas tentativas.
Isso fez a gente dar mais valor quando encontramos a Angelina Hemckmeier, que hoje é nossa gestora de sucesso do cliente. Conheça aqui um pouco da história do time do CS na mobLee.
A grande diferença dela para todas nossas tentativas anteriores é que ela de fato se importava com o sucesso do cliente, e para isso ela se forçou a entender o produto que nós tínhamos o mais a fundo possível, mesmo sem domínio da área técnica. E esse mindset se propagou para toda a área de CS que nós temos hoje. Eu diria com certeza que hoje existem pessoas no time de Customer Success que dominam mais o funcionamento do produto do que alguns desenvolvedores, já que eles estão todo dia olhando para o todo.
Tenha um time de Suporte forte!
Isso mesmo! O que domina o produto não só ajuda o cliente a conseguir fazer as coisas do jeito certo, como também ajuda o cliente a adaptar o produto para situações inesperadas. Isso não só faz o time ganhar tempo para desenvolver, como nos faz entender melhor os problemas e necessidades dos clientes no dia a dia.
Muitas vezes, conversar com o time de CS é a melhor forma de entender o verdadeiro problema dos clientes.
Outra grande vantagem de termos um time de CS completamente próximo do time de produto, foi ganharmos mais tempo para a validação de novos processos e funcionalidades antes de implementarmos. Até 2016 todo aplicativo que precisava ser publicado era publicado por um desenvolvedor. Pegar as informações de cada aplicativo e gerar uma build demorava pelo menos 40 minutos. E isso não acontecia apenas para novos aplicativos… Qualquer correção de bug ou atualização precisava ser republicada.
Colocar esse processo nas mãos do time de CS permitiu que nós conseguíssemos liberar os desenvolvedores para incrementalmente automatizar o processo de configuração e publicação dos aplicativos, de forma que hoje basta clicar em um botão na nossa plataforma para que o aplicativo seja gerado.
Em geral, desenvolver algo é a maneira mais cara de validar, já que corrigir algo que já está desenvolvido costuma ser muito custoso. Por isso, sempre que puder, valide manualmente, transforme essa execução em um processo e com o tempo, automatize as atividades que mais te tiram tempo.
Mais produtos? E agora?
Bom, até início de 2017 nosso único produto era o aplicativo. Como nós sempre desenvolvemos nativo, tínhamos times separados por especialidade:
- Um time de design responsável por projetar a experiência do usuário em todas as plataformas;
- Um time iOS e um de Android focados no desenvolvimento do aplicativo;
- E um time de web responsável por desenvolver nosso CMS e a API que alimentava todas as plataformas.
Com o tempo cada um dos times foi mudando de tamanho e começamos a experimentar novas formações. Algumas demandas de web, como integrações, envolviam somente o time de web, enquanto algumas features dependiam das 3 plataformas. Por isso, começamos a experimentar dividir os times por entregas de funcionalidades ao invés de plataforma.
Como o suporte era executado pela equipe de produto, criamos uma função que chamamos de bombeiro e que era atribuída a um membro da equipe a cada semana, com a função de “apagar os incêndios das demandas que surgiam durante a semana“. Isso fez com que os outros membros pudessem se manter focados, o que nos garantiu mais eficiência na entrega.
Ao longo de todos esses anos constantemente revisitamos nossas decisões de processo, sempre focando em minimizar coisas que atrapalhavam nossa eficiência. Já mudamos os tamanhos das sprints, já abrimos mão de estimar tarefas e voltamos a estimar algumas vezes, já mudamos os horários e quais cerimônias fazemos como time.
Hoje em dia
Reavaliar constantemente seus processos é importante por que os times mudam, as demandas mudam e, mesmo que não mudem, de tempo em tempo um processo pode ficar burocrático demais ou a falta de um processo pode ficar bagunçada demais.
Hoje nosso time de produto é dividido em 4 times:
- Um time de projeto;
- Dois times de novas features;
- Um time de suporte técnico;
- E estamos caminhando para ter um time de QA.
O movimento para essa formação começou no meio de 2017, quando entendemos que nosso mercado estava demandando mais do que apenas aplicativos. Entendemos que precisávamos ter uma plataforma unificada, que trouxesse para o organizador todas as informações do público dele, desde a divulgação até o fim do evento.
Nós não sabíamos exatamente o que precisávamos desenvolver e quais as funcionalidades que cada novo produto teria. Mas nós tínhamos um norte claro, e isso permitiu que o próprio time se reorganizasse e definisse as prioridades de desenvolvimento.
Além disso, essa clareza de direcionamento trouxe mais autoridade para o time defender o por que estar desenvolvendo X ou Y para o resto da empresa.
Historicamente acostumamos nosso time de vendas a prometer coisas que ajudassem em um fechamento de contrato, mesmo que não estivesse completamente alinhado com o que o time acreditava ser o melhor para a evolução do produto. Ao mesmo tempo demoramos a aprender a dar visibilidade do direcionamento do produto para toda a empresa.
Nesse último ano, temos feito um trabalho melhor nesse sentido, possibilitando que não só o time de vendas, mas todos na mobLee tenham a oportunidade de contribuir para a evolução dos nossos produtos. Quinzenalmente apresentamos para toda a empresa os projetos que estão em andamento para que todos possam contribuir com feedbacks. Para cada lançamento fazemos um treinamento de utilização e capacidades do que está sendo lançado.
Temos também uma ferramenta de sugestões aberta, que é revisada semanalmente e permite que essas sugestões sejam incorporadas ao backlog. Resumindo, criamos ferramentas e processos para que todas as áreas, principalmente as que estão em contato direto com clientes ou potenciais clientes possam contribuir para a evolução do produto.
Para resumir um pouco de tudo que eu considero importante para um time de produto e que esses anos de experiência me ensinaram.
- É preciso ter foco e clareza do que seu produto é, qual o seu segmento de mercado e quem é o público do seu produto. Sem nunca esquecer quem paga a conta no fim do dia.
- Mantenha seu time de produto muito próximo de seu time de CS. Do tipo “vamos jantar juntos no Outback” próximo. Isso permite que o time de CS tenha mais domínio das capacidades do produto, o que te ajuda a ganhar tempo e validar novas funcionalidades antes de desenvolver 100%.
- Reavalie constantemente seus processos, não tenha medo de matar processos que estão atrapalhando e não tenha medo de testar novos processos que podem te ajudar. Além de oxigenar a equipe, isso melhora a eficiência do seu time, ajuda a minimizar erros e mantém seu dia a dia coerente com as demandas atuais. Sempre que possível automatize suas atividades.
- Dê visibilidade das decisões e direcionamentos do produto e permita que pessoas de fora do time possam contribuir. Isso mantém toda a empresa alinhada a uma mesma direção.
- Não foque nas features, mas nas entregas de valor e na qualidade dessas entregas.
Se quiser conhecer um pouco mais da história da mobLee do ponto de vista tecnológico,
