Em 2015 fui cofundador da CompanyHouse, uma tentativa de LegalTech para digitalizar o registro de empresas e os requerimentos de alterações societárias no Irã. A premissa era simples e, ainda acho, correta. Registrar uma empresa aqui exige um especialista porque o processo é deliberadamente opaco. O conhecimento especializado é o produto — e o gargalo.
Construímos o que essa premissa implica. Modelamos o conhecimento tácito dos especialistas em registro num fluxo digital guiado, baseado em perguntas, que gerava os requerimentos. Escolha do tipo de empresa, entrada de dados, geração de documentos. Trabalhamos com especialistas jurídicos para converter regras, pontos de decisão e exceções em lógica de produto. No papel, era um trabalho limpo de design de produto.
Funcionou por um ano e fechou. Foi minha primeira experiência séria de transformar conhecimento especializado em produto, e a lição que ela me deixou é a que mais usei desde então: transformar conhecimento especializado em produto é um problema de extração de conhecimento muito antes de ser um problema de software.
Por que a extração é a parte difícil
Um especialista consegue descrever o caminho. O que ele não consegue descrever com facilidade é a exceção — o momento em que olha para um requerimento, algo está errado, e ele contorna o problema sem perceber que tomou uma decisão. É ali que está o valor. É também a parte invisível para quem a executa, porque, para ele, aquilo não é uma decisão; é só mais uma terça-feira.
Então o teste para saber se você transformou algo em produto não é se o caminho descrito funciona. É se o não descrito funciona. Enquanto você não conseguir modelar as perguntas que o especialista faz e as exceções que ele conhece, você não tem um produto. Tem um serviço com uma tela de login, e o especialista continua sendo o gargalo — agora com uma interface pior.
O mesmo problema, mais cinco vezes
Depois que você dá nome a um padrão, passa a vê-lo em todo lugar, e a maior parte do meu trabalho desde então foi alguma versão dele.
Na Bamana, cofundada em 2020, a lacuna estava entre o conhecimento especializado e uma decisão às 11 da noite de uma terça-feira. Os pais se afogam em conselhos sobre criação de filhos e passam fome de orientação. A intervenção não foi conteúdo — foi estrutura: taxonomias, classificações de necessidades e trilhas de conteúdo que transformam conhecimento especializado em algo sobre o qual um pai ou uma mãe cansados conseguem agir. A etapa de extração foi organizar o que os especialistas sabem em torno do que os pais precisam decidir, e não em torno de como os especialistas arquivam esse saber. Foi lançada e evoluiu ao longo de quatro anos.
Na Mehrabani e na Soha, o conhecimento tácito pertencia aos assistentes sociais. A doação beneficente falha nas duas pontas: os doadores não conseguem verificar a necessidade, e os assistentes sociais não conseguem comprovar o resultado. A confiança desmorona no meio. O julgamento de que uma necessidade é real fica na cabeça de uma pessoa, e não viaja. Então construímos o Cartão Mehrabani — um único objeto que reúne a necessidade verificada, a história do beneficiário, a doação e o resultado — com a Soha por baixo como a camada de dados de necessidades verificadas. A parte da qual tenho mais certeza é a menos glamorosa: desenhamos o fluxo operacional que os assistentes sociais de fato usam. Se a camada de extração é um fardo, ela não é preenchida, e aí não sobra nada para transformar em produto.
Na WritingChex, o especialista era um examinador do IELTS. Um candidato fora de uma grande cidade não tem examinador, não tem feedback e não tem como saber por que sua redação recebe a nota que recebe. Construímos um motor de feedback por IA que simula o exame, analisa a resposta e devolve um feedback específico, acionável e no formato de um examinador, e depois desenhamos o ciclo de melhoria em torno dele. Chegou a um MVP validado com submissões reais e os primeiros clientes pagantes — a primeira prova de que as pessoas pagariam por feedback de máquina. Foi encerrada em 2025. Fui honesto com a equipe sobre onde o modelo não era confiável, que é a lição da CompanyHouse aplicada mais cedo: as exceções são onde está o valor, e um sistema confiante nas exceções é pior do que nenhum sistema.
O Ketabno inverteu o problema. O conhecimento a transformar em produto não era de um especialista — era o que faz a leitura pegar num adolescente. Adolescentes não param de ler porque os livros são ruins. Param porque a leitura é solitária, não recompensada e invisível para os amigos. Então o produto trouxe a camada social: jornadas de histórias, pontos, medalhas, personagens narradores, quizzes. Foi lançado em cerca de três meses.
Onde finalmente funcionou de verdade
A Shalize é o caso mais claro, porque ali o conhecimento tácito era operacional, e não profissional. Um negócio de ouro e prata físicos funcionava à base de mensagens de WhatsApp, memória e confiança, e o volume crescia mais rápido do que o processo conseguia suportar. Memória não se passa adiante.
Reconstruímos o sistema operacional de ponta a ponta — consulta, pedido, faturamento, verificação de pagamento, atendimento do pedido, acompanhamento e recompra — e colocamos um CRM por baixo. O verdadeiro lançamento não foi o site. Foram as vendas terem de parar de trabalhar de memória; a adoção do CRM foi o lançamento. O volume físico diário passou de 0.5 para 10 kg/dia, e o negócio informa 4,000+ clientes compradores verificados e 1,000B+ tomans em volume bruto de transações. Esses números são informados pela empresa, do portfólio da Tamin Tejarat Espahbod Khorshid, não auditados, não são receita nem margem líquida. Prefiro dizer isso a deixá-los fazer um trabalho que não conquistaram.
O Mokaab é a nota complementar. Arquitetei uma plataforma de investimento completa — jornadas de compra, venda, custódia, recompra, precificação, faturamento, entrega e conta — com a obrigação de recompra desenhada desde o primeiro dia, em vez de acoplada depois. Nunca foi lançada: as prioridades do grupo controlador migraram para as operações físicas antes que a plataforma fosse lançada. Mas a arquitetura e o modelo de mercado sobreviveram e foram incorporados ao sistema operacional da Shalize. O conhecimento extraído sobrevive ao produto para o qual foi extraído. Esse é o argumento para fazer a extração mesmo quando você não tem certeza de que a coisa vai ser lançada, e é por isso que listo os fracassos — um portfólio sem eles é um portfólio que você não consegue calibrar.
Na Emkan, o mesmo movimento se aplica às políticas públicas. O desenvolvimento territorial é discutido numa linguagem sobre a qual nenhuma equipe de produto, nenhum investidor e nenhum cidadão conseguem agir. Então o trabalho foi traduzi-lo em estruturas que uma equipe de produto consiga de fato construir: missões de desenvolvimento, zonas econômicas, setores, biblioteca, galeria. No Invest Iran, a plataforma da agência de promoção de investimentos, o conhecimento tácito era como um investidor sério é de fato atendido — arquitetado numa jornada completa do investidor, da descoberta de oportunidades e avaliação de vantagem competitiva, passando pela manifestação de interesse e pelo engajamento institucional, até a gestão de solicitações e o acompanhamento pós-investimento.
O teste é simples e cruel. Se o especialista sair de férias, a coisa continua funcionando? Se a resposta for não, você ainda não transformou nada em produto. Você documentou um gargalo.