Escalar produtos através da evolução do ecossistema

Oportunidade

A Esteira Digital da Kenlo foi construída para suportar um produto financeiro específico: o Kenlo Garante, uma solução de garantia locatícia. O fluxo original (proposta, garantia e formalização) era intencional: o corretor criava a proposta, vinculava a garantia da Kenlo e encaminhava para o Kenlo Locação, plataforma proprietária que monetiza por contrato administrado.

O cenário mudou quando soluções focadas exclusivamente no pré-atendimento começaram a ganhar espaço nas imobiliárias, cobrindo a captação de leads, gestão de visitas e acompanhamento do cliente antes da proposta. A Kenlo não tinha nada disso, e as imobiliárias pagavam por esses serviços separadamente.

A decisão estratégica foi expandir a Esteira para cobrir todo o funil, trazendo o pré-atendimento para dentro da plataforma. A lógica era direta: com o fluxo completo na Kenlo, haveria mais retenção, mais dados e espaço para monetizar com novas funcionalidades, o que de fato aconteceu.

Mas havia uma barreira crítica: apenas 3% da base usava a Esteira como plataforma principal. Sem resolver isso, a expansão do produto não teria tração.

Descoberta

O projeto chegou para mim como uma tarefa pequena de redesign visual. Enquanto explorava o produto, percebi que os problemas que via não tinham solução visual. Corretores abriam a tela e simplesmente não conseguiam trabalhar: um cliente com cinco imóveis de interesse virava cinco cards desconectados no kanban. Não havia histórico. Não havia contexto. Propor melhorias estéticas em cima disso seria trabalho desperdiçado. Precisei entender a profundidade do problema antes de propor qualquer direção.

Comecei realizando 20 entrevistas com corretores e gestores de imobiliárias de diferentes portes e regiões. O pesquisador da equipe me auxiliou nos agendamentos, na definição dos métodos, nas anotações durante as sessões e na análise dos dados, mas eu era responsável por conduzir as entrevistas, realizar os testes com usuários e sintetizar os insights para apresentar ao time de produto e direcionar o projeto.

Assisti também mais de 50 sessões gravadas buscando padrões de travamento, e analisei o histórico de tickets de suporte: 40% das reclamações eram sobre não conseguir recuperar o histórico de um cliente. Organizei workshops com PMs, tech leads e o outro designer para alinhar os achados e priorizar o escopo da solução.

O que encontrei

Três problemas centrais se confirmaram, e todos apontavam para a mesma raiz:

1. Contexto perdido: corretores não sabiam se já tinham atendido aquele cliente, quais imóveis ele havia visto, qual era a última interação
2. Kanban ingerenciável: imobiliárias com alto volume tinham centenas de cards duplicados, impossível trabalhar
3. Arquitetura bloqueada: funcionalidades que estavam no roadmap há anos eram tecnicamente inviáveis com a base de dados existente

Esse foi o ponto de virada. Apresentei o diagnóstico ao time: o projeto não cabia mais numa melhoria de interface. A arquitetura precisava ser refatorada do zero.

Resultados

Decisões de design

A mudança central foi reorganizar o sistema em torno do cliente, não do imóvel. Um cliente passou a ter um único card, com todas as interações, visitas e propostas vinculadas a ele. Histórico preservado, contexto sempre acessível.

Header global unificado: o divisor simbólico entre a versão antiga e o "Novo Imob", com navegação integrada entre todos os módulos.

Tela de detalhes repensada: resumo do cliente à esquerda para contexto rápido, conteúdo principal à direita segmentado em blocos, com destaque visual para pendências.

Cards simplificados: remoção de informações excessivas, padronização de status e foco em escaneabilidade rápida.

Fluxo de novo atendimento redesenhado: o CTA mudou de "Novo cliente" para "Novo atendimento", refletindo a mudança conceitual do sistema.

Handoff e colaboração técnica

Para um projeto com múltiplos fluxos e dezenas de cenários, estruturei uma documentação com especificações de comportamento detalhadas e um índice numerado para facilitar a navegação — uma evolução em relação ao padrão da empresa na época. Trabalhei próximo a três engenheiros navegando constraints de Vue e React, tomando decisões de tradeoff entre o ideal e o tecnicamente viável.

Deploy

A migração foi tratada como decisão de produto: não forçamos a transição. Criamos uma tela de transição que permitia cada imobiliária migrar no próprio ritmo, com suporte e treinamento durante o processo. 90% das imobiliárias que migraram fizeram isso por escolha própria.

Métricas

A nova arquitetura também desbloqueou o roadmap: funcionalidades que eram tecnicamente inviáveis passaram a ser desenvolvidas, e a estabilidade do sistema aumentou significativamente.

Aprendizados

Pesquisa abrangente define o escopo real do projeto

Esse foi o aprendizado central. O projeto chegou como um redesign cosmético, e se eu tivesse simplesmente executado, teria entregado uma interface mais bonita em cima de uma arquitetura quebrada. Foi a pesquisa com corretores, gestores, CS e suporte que revelou o problema real e me deu argumentos concretos para defender um escopo muito maior. Cada grupo enxergava uma dimensão diferente do sistema; só com todos os ângulos juntos foi possível ver o todo.

Arquitetura de informação precede design de interface

A decisão de reorganizar o sistema em torno do cliente, e não do imóvel, não foi visual: foi conceitual. Quando o problema é estrutural, mudar a aparência não resolve. Essa distinção passou a guiar como eu avalio e proponho projetos.

Migração gradual é estratégia de produto

Dar controle sobre o ritmo da transição foi o que garantiu que 90% das imobiliárias migrassem por escolha própria. Transições forçadas criam resistência; autonomia cria adesão.