Como a Aarin faz produto.
Saiba como a Aarin, uma Techfin inovadora com foco no conceito de "invisible banking", está organizada e desenvolve os seus serviços.
Chamamos a Tici Amorim para nos contar como a Aarin uma das empresas mais inovadoras do nosso país e com reconhecimento internacional, constroem os seus serviços e estrutura os seus times.
A Aarin é uma Techfin inovadora com foco no conceito de "invisible banking". Em 2021, após apenas 18 meses de sua fundação, vivenciou um marco histórico: o Bradesco tornou-se seu maior acionista, por meio de uma fusão e aquisição. Contudo, a Aarin manteve sua autonomia operacional e de governança. O destaque desse processo foi a liderança de duas mulheres inspiradoras: Ticiana Amorim, fundadora e CEO, e Fernanda Rego, co-fundadora e CLO.
Em sua trajetória ascendente, a Aarin recebeu prêmios nacionais e internacionais, inclusive representando o Brasil em eventos na Arábia Saudita e Holanda. Em 2023, a empresa orgulhosamente anuncia, em primeira mão aqui no Product Guru's que será referenciada com três importantes premiações em Londres:
Best Contribution to TechFin in Open Banking/Finance Sollutions 2023
Most Innovative Digital Transformation/Tech Growth Facillitator 2023
Best CEO in the Financial Technology Industry 2023.
CEO essa que é uma produteira apaixonada e faz questão de manter a cultura de produto na Aarin sempre como prioridade. Atualmente com 116 pessoas, sendo dessas, 78 pessoas da área de Produto, Design e Tecnologia, a Aarin é reconhecida no mercado também pela quantidade de mulheres presentes no universo "ProdTech". Elas representam 35% frente à média nacional de 18% segundo o IBGE. Outro Highlight é o fato de que 50% da liderança da empresa é feminina, inclusive na diretoria da Aarin elas são maioria.
Adentrando no mundo de produto e como a Aarin faz produto temos alguns pontos que fogem do mercado. O primeiro é: não há uma diretoria de produto. A Aarin segue um modelo organizacional de uma empresa orbital e em rede. Ou seja, as funções orbitam em torno do cliente e estão interconectadas independente de departamentos, forçando a não formação de silos desconexos com os usuários.
Por isso, existe uma área de Customer Experience composta por pessoas de produto, marketing, vendas, atendimento, operações e compliance, por exemplo. Ao invés de áreas, as funções atuam em temas que no fim das contas geram um fluxo retroalimentável como mostro abaixo.
Para ilustrar essa abordagem, pense na estrutura como um guarda-chuva. O "front-office" identifica e soluciona os problemas dos clientes, enquanto o "back-office" apoia esse processo, similar à lona de um guarda-chuva protegendo contra a chuva e o cabo melhorando a experiência de se proteger da chuva.
O fluxo que está na lona pode ser visto com detalhes aqui:
Cada tema do fluxo tem bem definido o que compõe esse tema para que as pessoas responsáveis por essa etapa saibam exatamente o que é necessário cobrir:
E aqui é possível ver quais funções atuam em quais temas por meio de squads multidisciplinares que se montam e se desmontam de acordo com a fase:
Agora que temos um overview da área de CX e de como os profissionais de produto e desenvolvimento se encaixam em um macro fluxo com foco no cliente, vamos falar um pouco de como funcionam os squads que flutuam em problem space, solution space, pre release e px.
Para dar conta dessas fases a Aarin dividimos o nosso time em duas tribes: APIs e User Interfaces. Cada tribe é dividida em duas torres: ledger + payments e mobile + Web, respectivamente. Como somos uma techfin que entrega do core banking ao app end2end, faz sentido que os times tenham clientes internos garantindo que as implementações conversem entre si.
Então se eu preciso disponibilizar uma informação na interface web, essa feature é priorizada primeiro lá no time de ledger ou payments por exemplo, e quando disposta na API interna o time de interface consegue acessá-la para trabalhar em cima e entregar valor ao usuário analista financeiro de um cliente nosso, por exemplo.
O modelo spotify em que multiplos squads acessam e fazem mudança no código com foco em seu uso não funcionou bem aqui, principalmente por não termos um time de especialistas em desenvolvimento. Nosso time foi todo criado dentro de casa começando como juniors e tendo hoje os primeiros managers em tech. Então eu não aconselho startups em escala usarem modelos robustos de gestão de tecnologia porque é necessário uma certa maturidade para tal.
Outro grande desafio é como o time de prodtech dialoga efetivamente com a entrega de valor aos usuários, clientes e não sobe coisas que impactam o time financeiro, por exemplo, sem avisá-los?
Para isso criamos o time de PX. Ele existe para garantir que cada feature nova que sobe respeita nossas premissas de produto para escalabilidade, performance e interoperabilidade. Além disso, esse time é responsável por garantir o alinhamento entre como a feature deve ser usada (entendimento tem que ser claro nas knowlage bases internas para suporte e operação) e com quais outras áreas a feature conversa e gera impacto.
Após a bandeira verde do time de PX, temos uma etapa de pre-release liberada para haver o planejamento da comunicação à base e aos stakeholders internos de que vamos para produção e aquilo que foi alinhado deverá ser implementado.
Tudo através de rituais semanais que deixam o tracking transparente e a esteira constante. Hoje conseguimos ter quoruns todas as segundas em que pessoas de produto, vendas e operação priorizam juntas os próximos passos que fazem sentido ao negócio mesmo em uma empresa que precisa mudar e se adaptar muito a cada mês por estar em uma fase de escala exponencial. C
hamamos esse ritual de "Bandeiradas". Nele pegamos necessidades que apareceram através do time de vendas, time de implementação ou suporte e categorizamos com bandeiras para os squads de produto:
🟥Vermelha “pare o que tiver fazendo na sprint e priorize isso”.
🟨Amarela “tem que ser entregue em 30 dias”.
🟦Azul “tem que começar a fazer em até 30 dias”.
⬜Branca “coloque no seu backlog”.
A forma de passar essas demandas é automatizada via clickup e o card já vem com todas as especificações de dor do usuário, potencial de receita e casos de uso necessários para as pessoas de produto dos squads começarem a trabalhar em cima. Caindo automaticamente nos boards de cada time na coluna de backlog
Ou seja, formalizamos e processualizamos as famosas demandas paraquedas que toda empresa finge que não existe mas que são uma realidade no roadmap de empresas em crescimento que precisam garantir os clientes usando, principalmente b2b.
Porque eu vou trabalhar em uma feature que tenho uma hipótese que gera valor se o time de Px me trouxe uma que 3 clientes ativos da nossa base já tem interesse?
É aqui que os PMs precisam lembrar que eles não são donos da verdade e sim ajudam a empresa a entregar valor.
Saindo um pouco do dia a dia e alinhando as entregas de produto com a estratégia macro da empresa, a Aarin não utiliza OKRs. Criamos uma metodologia própria que mistura boas premissas de OKRs com excelentes premissas dos NCTs trazidos pela Reforge. Chamamos ela de We Are In. (leia: We Aarin :P)
Todos os chapters da empresa constroem narrativas, definem commitments (que podem ser do tipo realizar um discovery, construir algo ou lançar algo que foi construído e medir) e entregam um plano de tasks para alcançá-las.
As NCTs devem ser com foco em qual passo a mais será dado naquele semestre (temos dois ciclos semestrais com 1 mês de ajustes e planejamento em cada — janeiro e julho). E não relacionadas a entregas de processos ou rotinas que são base do time.
Por isso, cada chapter da empresa só pode construir até 2 NCTs. E a empresa atribui uma remuneração variável para o alcance dos NCTs com tanto que a área não deixe nenhum pratinho must have cair para poder alcançar esse NCT.
Para as tribes de produto temos o “roadmap independente” composto pelas tasks, agrupados em commitments (equivalentes aos épicos) e uma narrativa que justifique aquelas priorizações. Chamamos de roadmap independente aquilo que precisamos entregar independente das demandas paraquedas.
Essas definições acontecem em discussões que envolvem todo o time, não ficando restrita à alta liderança ou excluindo desenvolvedores, por exemplo. Os times têm 4 semanas para avaliar o que entregaram no último NCT e se organizar para o próximo considerando refatorações ou débitos técnicos que muitas vezes se cria quando existem metas ambiciosas.
Acho que vocês já perceberam que a cultura de produto aqui é bem realista. Claro que débito técnico deve ser evitado, mas não se cresce com velocidade sem aceitar que eles existirão. Então é mais justo contar com eles e analisar como atuar rapidamente sobre.
Por fim, falando de maneira macro, temos um método próprio de Desenvolvimento de produto que utilizamos o triple track agile como base, mas que montamos cada etapa misturando diversas metodologias e frameworks que vão desde modelos de Design Thinking à matrizes que nós mesmos inventamos, rs!
Como boa professora de produto, aqui não pode ser casa de ferreiro e espeto de pau! Então temos tudo muito bem documentado e novos PMs não tem nenhuma dificuldade de replicar nossos processos quando entram, pois cada PM já é vetor da nossa cultura de produto por acreditar que ela funciona e se beneficiar dos processos já estruturados.
O que geralmente acontece são improvements. Que eu amo! A metodologia base é minha, construída logo nos primeiros meses da Aarin, em 2020, e ela ainda é visível nas etapas e macro-processos, mas, de lá para cá, cada PM deixou sua marca em ajustes e refinamentos.
Esse é o primeiro texto da nossa série “Como as empresas brasileiras constroem Produtos”, fiquem ligados para saber como outras empresas, como a Rappi, Hiper Software entre outros.
Quer compartilhar como sua empresa constrói produtos, entre em contato conosco pelas nossas redes sociais ou mandando mensagem aqui no substack.
Muito feliz de ter fundado essa área de PX e ter metido mão pra criar todos esses processos, junto com Tici e esse time que é maravilhoso de trabalhar junto!
Obrigado Tici por toda essa generosidade. Esse artigo é uma preciosidade e deu para tirar MUITOS insights da forma como a Aarin (que é uma empresa que admiro) constroem produtos.