Passei o primeiro capítulo da minha vida profissional recebendo ordens — e cumprindo-as bem. Como freelancer, a partir de 2007: design, ideação, diagramação, web, direção de arte — contrato após contrato. Ali aprendi uma lição que nunca deixou de importar. Uma ideia forte não vale nada até se tornar uma entrega real, concreta e defensável. É uma boa lição. Também é, sozinha, a lição de um fornecedor. Alguém lhe entrega um briefing. Você devolve uma coisa. Os dois lados ficam satisfeitos e nenhum deles pensou.
Depois, na Aghigh, eu industrializei isso. Construí o modelo de trabalho: recepção de briefing, definição da entrega, alocação, acompanhamento, feedback, revisão, entrega. Gerenciei um portfólio permanente de projetos simultâneos de clientes e suas entregas. Funcionou. Também é, lido com honestidade, uma máquina de converter ordens externas em entregas em escala. A organização só deixou de ser isso quando conduzimos a evolução para produtos digitais próprios — Bamana, Ketabno, HisTory, NoJahan, Mehrabani, Soha e Mastoura. A virada não foi de serviços para software. Foi de receber um problema para ser dono de um.
O problema de quem dá ordens é um problema de conhecimento
Foi na CompanyHouse que bati no muro pela primeira vez. Registrar uma empresa no Irã exige um especialista porque o processo é deliberadamente opaco. O conhecimento especializado é o produto — e o gargalo. Então modelamos o conhecimento tácito dos especialistas em um fluxo guiado, baseado em perguntas, que gerava os requerimentos, e trabalhamos com especialistas jurídicos para converter regras, pontos de decisão e exceções em lógica de produto. Funcionou por um ano. Fechou.
O que aprendi: transformar conhecimento especializado em produto é um problema de extração de conhecimento muito antes de ser um problema de software. E extrair conhecimento é muito difícil dentro de uma relação com alguém que só dá ordens. Se o especialista é um fornecedor respondendo às suas perguntas, você obtém as regras. As exceções são mais difíceis, porque as pessoas não vivem as próprias exceções como exceções — elas as vivem como óbvias. Elas aparecem quando o especialista está dentro do problema com você, discordando sobre um caso concreto, e não quando está preenchendo o seu formulário. Enquanto você não conseguir modelar as perguntas que ele faz e as exceções que ele conhece, você não tem um produto. Tem um serviço com uma tela de login. Não acho que tenhamos entrado o suficiente nessa sala.
Como fica quando funciona
Mehrabani e Soha são a versão mais clara. 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 Cartão Mehrabani era um único objeto que reunia 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. Mas a linha desse histórico que mais me importa é menor: desenhei o fluxo operacional que os assistentes sociais de fato usam. “De fato usam” é uma afirmação que só se conquista tratando o assistente social como uma parte que pensa, e não como um destinatário a jusante de uma especificação.
A Shalize é a mesma coisa num mercado comercial. Um negócio de ouro e prata físicos funcionando à base de mensagens de WhatsApp, memória e confiança. O volume crescia mais rápido do que o processo conseguia suportar. 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 volume diário passou de 0.5 para 10 kg/dia, e o negócio chegou a 4,000+ clientes compradores verificados. Esses números são informados pela empresa, não auditados, e prefiro dizer isso a vê-los citados contra mim mais tarde.
A frase que explica a Shalize está na página do framework, não nos números: as vendas tiveram de parar de trabalhar de memória, e a adoção do CRM foi o verdadeiro lançamento, não o site. Essa é a terceira das minhas cinco perguntas — quem precisa mudar de comportamento para que isso funcione? Um cliente que só dá ordens nunca precisa respondê-la. Ele encomenda o sistema, o comportamento continua como estava, e depois a culpa recai sobre o sistema.
Na Emkan, o trabalho inteiro é essa tradução. Meu trabalho é transformar desenvolvimento territorial, governança econômica, economia marítima, zonas francas e novas cidades em estruturas que uma equipe de produto consiga de fato construir. No Invest Iran, o mesmo: uma agência de promoção de investimentos sem presença digital é um número de telefone, então arquitetei toda a jornada do investidor — descoberta de oportunidades, avaliação de vantagem competitiva, manifestação de interesse, engajamento institucional, gestão de solicitações e acompanhamento pós-investimento. Nada disso pode ser entregue a um cliente. Precisa ser construído com as pessoas que sabem o que uma zona franca de fato permite, porque o que o mercado permite muda de lugar para lugar, e essa é sempre a quinta pergunta.
O que não funcionou
Mokaab. Fui cofundador e 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, e não 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.
Quero ser preciso sobre o que isso prova, porque é fácil contar como a história de um cliente que não ouviu. Não é. A mudança para as operações físicas foi uma decisão de negócio real, e eu estava dentro do grupo como seu Chief Product & Business Development Officer, não gritando de fora. O que de fato aconteceu é que a arquitetura e o modelo de mercado sobreviveram e foram incorporados ao sistema operacional da Shalize. Um artefato entregue teria morrido com a decisão. Um entendimento compartilhado, não. Esse é o argumento mais forte que tenho a favor deste princípio, e ele vem do empreendimento que fracassou.
A WritingChex conta uma versão mais estreita. Liderei o produto desde a definição do problema, passando pelo design do MVP, construção e validação, dei forma à lógica de feedback por IA e apoiei a conquista dos primeiros clientes pagantes — a primeira evidência de que alguém pagaria por feedback gerado por IA. Do que mais me orgulho ali não é o produto. É ter sido honesto com a equipe sobre onde o modelo não era confiável. Mesmo assim, ela foi encerrada em 2025. Ser a pessoa que diz o que não funciona não salva toda empresa. Só faz com que valha a pena ter você na sala.
A versão prática
É por isso que minha oferta é formulada do jeito que é. Diga-me o que está quebrado. Se eu puder ajudar, direi como. Se não puder, também direi — e, em geral, quem pode. Uma relação com alguém que só dá ordens não consegue produzir essa última frase. Um fornecedor que diz “não posso ajudar” encerrou o trabalho. Um parceiro que diz isso fez o trabalho.
A coisa mais útil que levo a uma sala costuma ser uma pergunta melhor. O Ketabno foi lançado em cerca de três meses e firmou parceria com o Ministério da Educação e com a plataforma nacional Shad — não porque alguém o especificou assim, mas porque o problema tinha sido formulado corretamente antes: 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. Erre essa frase e nenhuma entrega fiel resolve. A maioria dos produtos fracassa na pergunta do propósito, e ninguém percebe durante dezoito meses.