En 2015 cofundé CompanyHouse, un intento LegalTech de digitalizar el registro de empresas y los trámites de modificaciones societarias en Irán. La premisa era sencilla y, sigo pensando, correcta. Registrar una empresa aquí exige un experto porque el proceso es deliberadamente opaco. La pericia es el producto, y también el cuello de botella.
Construimos lo que esa premisa implica. Modelamos el conocimiento tácito de los especialistas en registro en un flujo digital guiado, basado en preguntas, que generaba los trámites. Selección del tipo de empresa, introducción de datos, generación de documentos. Trabajamos con expertos legales para convertir reglas, puntos de decisión y excepciones en lógica de producto. Sobre el papel, era un diseño de producto limpio.
Funcionó durante un año y cerró. Fue mi primera experiencia seria de convertir en producto el conocimiento especializado, y la lección que me dejó es la que más he usado desde entonces: convertir en producto el conocimiento experto es un problema de extracción de conocimiento mucho antes de ser un problema de software.
Por qué la extracción es la parte difícil
Un experto puede describir el camino. Lo que no puede describir con facilidad es la excepción: el momento en que mira un trámite, algo no encaja y lo sortea sin registrar que ha tomado una decisión. Ahí es donde está el valor. Y es también la parte invisible para quien lo hace, porque para él no es una decisión; es simplemente un martes cualquiera.
Así que la prueba de si has convertido algo en producto no es si el camino descrito funciona. Es si funciona el que no se ha descrito. Hasta que no puedes modelar las preguntas que hace el especialista y las excepciones que conoce, no tienes un producto. Tienes un servicio con una pantalla de inicio de sesión, y el especialista sigue siendo el cuello de botella, ahora con una interfaz peor.
El mismo problema, cinco veces más
Una vez que le pones nombre a un patrón, empiezas a verlo en todas partes, y la mayor parte de mi trabajo desde entonces ha sido alguna versión de él.
En Bamana, cofundada en 2020, la brecha estaba entre el conocimiento experto y una decisión a las 11 de la noche de un martes. Los padres se ahogan en consejos sobre crianza y pasan hambre de orientación sobre crianza. La intervención no fue contenido, fue estructura: taxonomías, clasificaciones de necesidades y rutas de contenido que convierten el conocimiento especializado en algo sobre lo que un padre cansado puede actuar. El paso de extracción consistió en organizar lo que saben los especialistas en torno a lo que un padre tiene que decidir, y no en torno a cómo lo archivan los especialistas. Salió al mercado y se iteró durante cuatro años.
En Mehrabani y Soha, el conocimiento tácito pertenecía a los trabajadores sociales. La donación benéfica falla por los dos extremos: los donantes no pueden verificar la necesidad y los trabajadores sociales no pueden demostrar el resultado. La confianza se derrumba en el medio. El juicio de que una necesidad es real está en la cabeza de una persona, y no viaja. Así que construimos la Tarjeta Mehrabani —un único objeto que contiene la necesidad verificada, la historia del beneficiario, la donación y el resultado— con Soha debajo como capa de datos de necesidades verificadas. La parte de la que estoy más seguro es la menos glamurosa: diseñamos el flujo operativo que los trabajadores sociales realmente usan. Si la capa de extracción es una carga, nadie la rellena, y entonces no hay nada que convertir en producto.
En WritingChex, el experto era un examinador de IELTS. Un candidato fuera de una gran ciudad no tiene examinador, ni retroalimentación, ni forma de saber por qué su escritura obtiene la puntuación que obtiene. Construimos un motor de retroalimentación con IA que simula el examen, analiza la respuesta y devuelve retroalimentación específica, accionable y con forma de examinador, y luego diseñamos el ciclo de mejora a su alrededor. Llegó a un MVP validado con envíos reales y primeros clientes de pago: la primera prueba de que la gente pagaría por retroalimentación automática. Cerró en 2025. Fui honesto con el equipo sobre dónde no se podía confiar en el modelo, que es la lección de CompanyHouse aplicada antes: las excepciones son donde está el valor, y un sistema que se muestra seguro en las excepciones es peor que no tener sistema.
Ketabno invirtió el problema. El conocimiento que había que convertir en producto no era el de un experto: era lo que hace que la lectura enganche a un adolescente. Los adolescentes no dejan de leer porque los libros sean malos. Dejan de leer porque la lectura es solitaria, no tiene recompensa y es invisible para sus amigos. Así que el producto incorporó la capa social: recorridos narrativos, puntos, medallas, personajes narradores, cuestionarios. Se lanzó en unos tres meses.
Donde por fin funcionó de verdad
Shalize es el caso más claro, porque allí el conocimiento tácito era operativo y no profesional. Un negocio físico de oro y plata funcionaba con mensajes de WhatsApp, memoria y confianza, y el volumen crecía más rápido de lo que el proceso podía sostener. La memoria no se traspasa.
Reconstruimos el sistema operativo de principio a fin —consulta, pedido, facturación, verificación de pago, cumplimiento, seguimiento y recompra— y le pusimos un CRM debajo. El verdadero lanzamiento no fue el sitio web. Fue que ventas tuviera que dejar de trabajar de memoria; la adopción del CRM fue el lanzamiento. El volumen físico diario pasó de 0.5 a 10 kg/día, y el negocio reporta 4,000+ clientes compradores verificados y 1,000B+ tomanes en volumen bruto de transacciones. Esas cifras las reporta la empresa, proceden de la cartera de Tamin Tejarat Espahbod Khorshid, no están auditadas y no son ingresos ni margen neto. Prefiero decirlo antes que dejar que hagan un trabajo que no se han ganado.
Mokaab es la nota complementaria. Diseñé la arquitectura de una plataforma de inversión completa —recorridos de compra, venta, custodia, recompra, precios, facturación, entrega y cuenta— con la obligación de recompra integrada desde el primer día en lugar de añadida después. Nunca se lanzó: las prioridades del grupo matriz se desplazaron hacia las operaciones físicas antes de que la plataforma saliera. Pero la arquitectura y el modelo de mercado sobrevivieron y se integraron en el sistema operativo de Shalize. El conocimiento extraído sobrevive al producto para el que se extrajo. Ese es el argumento para hacer la extracción incluso cuando no estás seguro de que la cosa vaya a salir, y es la razón por la que enumero los fracasos: un portafolio sin ellos es uno con el que no te puedes calibrar.
En Emkan, el mismo movimiento se aplica a las políticas públicas. El desarrollo territorial se discute en un lenguaje sobre el que ningún equipo de producto, ningún inversor y ningún ciudadano puede actuar. Así que el trabajo consistió en traducirlo a estructuras que un equipo de producto pudiera construir de verdad: misiones de desarrollo, zonas económicas, sectores, biblioteca, galería. En Invest Iran, la plataforma de la agencia de promoción de inversiones, el conocimiento tácito era cómo se atiende realmente a un inversor serio, convertido en la arquitectura de un recorrido completo del inversor: desde el descubrimiento de oportunidades y la evaluación de ventajas competitivas, pasando por la manifestación de interés y la relación institucional, hasta la gestión de solicitudes y el acompañamiento posterior.
La prueba es simple y cruel. Si el experto se va de vacaciones, ¿la cosa sigue funcionando? Si la respuesta es no, todavía no has convertido nada en producto. Has documentado un cuello de botella.