Pasé el primer capítulo de mi vida laboral aprendiendo a recibir órdenes bien. Como freelance, desde 2007: diseño, ideación, maquetación, web, dirección de arte, contrato tras contrato. Allí aprendí una lección que nunca ha dejado de importar. Una idea potente no vale nada hasta que se convierte en un resultado real, entregable y defendible. Es una buena lección. Pero, tomada por sí sola, es también la lección de un proveedor. Alguien te entrega un brief. Tú devuelves una cosa. Ambas partes quedan satisfechas y ninguna ha pensado.
Luego, en Aghigh, lo industrialicé. Construí el modelo de trabajo: recepción del brief, definición del entregable, asignación, seguimiento, retroalimentación, revisión y entrega. Gestioné una cartera permanente de proyectos simultáneos de clientes y sus entregables. Funcionó. Pero, leído con honestidad, también era una máquina para convertir órdenes externas en entregables a escala. La organización solo dejó de ser eso cuando impulsamos la evolución hacia productos digitales propios: Bamana, Ketabno, HisTory, NoJahan, Mehrabani, Soha y Mastoura. El cambio no fue de servicios a software. Fue de recibir un problema a hacerlo propio.
El problema de quien da órdenes es un problema de conocimiento
En CompanyHouse fue donde choqué por primera vez con ese muro. Registrar una empresa en Irán exige un experto porque el proceso es deliberadamente opaco. La pericia es el producto, y también el cuello de botella. Así que modelamos el conocimiento tácito de los especialistas en un flujo guiado, basado en preguntas, que generaba los trámites, y trabajamos con expertos legales para convertir reglas, puntos de decisión y excepciones en lógica de producto. Funcionó durante un año. Cerró.
Lo que me enseñó: convertir en producto el conocimiento experto es un problema de extracción de conocimiento mucho antes de ser un problema de software. Y extraer conocimiento es muy difícil dentro de una relación en la que uno da órdenes y el otro las cumple. Si el especialista es un proveedor que responde tus preguntas, obtienes las reglas. Las excepciones son más difíciles, porque la gente no vive sus propias excepciones como excepciones: las vive como algo obvio. Salen a la luz cuando el experto está dentro del problema contigo, discutiendo un caso concreto, no cuando está rellenando tu plantilla. Hasta que no puedes modelar las preguntas que hace y las excepciones que conoce, no tienes un producto. Tienes un servicio con una pantalla de inicio de sesión. No creo que llegáramos lo bastante lejos dentro de esa sala.
Cómo se ve cuando funciona
Mehrabani y Soha son la versión más clara. 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. La Tarjeta Mehrabani era un único objeto que contenía la necesidad verificada, la historia del beneficiario, la donación y el resultado, con Soha debajo como capa de datos de necesidades verificadas. Pero la línea de ese historial que más me importa es más pequeña: diseñé el flujo operativo que los trabajadores sociales realmente usan. “Realmente usan” es una afirmación que solo te ganas tratando al trabajador social como una parte que piensa, no como el destinatario final de una especificación.
Shalize es lo mismo en un mercado comercial. Un negocio físico de oro y plata que funcionaba con mensajes de WhatsApp, memoria y confianza. El volumen crecía más rápido de lo que el proceso podía sostener. 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 volumen diario pasó de 0.5 a 10 kg/día, y el negocio alcanzó 4,000+ clientes compradores verificados. Esas cifras las reporta la empresa, no están auditadas, y prefiero decirlo ahora antes de que me las citen más adelante.
La frase que explica Shalize está en la página del marco de trabajo, no en las cifras: ventas tuvo que dejar de trabajar de memoria, y el verdadero lanzamiento fue la adopción del CRM, no el sitio web. Esa es la tercera de mis cinco preguntas: ¿quién tiene que cambiar su comportamiento para que esto funcione? Un cliente que solo da órdenes nunca tiene que responderla. Encarga el sistema, el comportamiento sigue igual y después se culpa al sistema.
En Emkan, todo el trabajo es esa traducción. Mi tarea es convertir el desarrollo territorial, la gobernanza económica, la economía marítima, las zonas francas y las nuevas ciudades en estructuras que un equipo de producto pueda construir de verdad. En Invest Iran, lo mismo: una agencia de promoción de inversiones sin presencia digital es un número de teléfono, así que diseñé la arquitectura del recorrido completo del inversor: descubrimiento de oportunidades, evaluación de ventajas competitivas, manifestación de interés, relación institucional, gestión de solicitudes y acompañamiento posterior. Nada de eso se le puede entregar a un cliente. Tiene que construirse con las personas que saben lo que realmente permite una zona franca, porque lo que el mercado permite cambia de un lugar a otro, y esa es siempre la quinta pregunta.
Lo que no funcionó
Mokaab. Lo cofundé y 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, no 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.
Quiero ser preciso sobre lo que esto demuestra, porque es fácil contarlo como la historia de un cliente que no escuchó. No lo es. Pasar a las operaciones físicas fue una decisión de negocio real, y yo estaba dentro del grupo como su Chief Product & Business Development Officer, no gritándole desde fuera. Lo que realmente ocurrió es que la arquitectura y el modelo de mercado sobrevivieron y se integraron en el sistema operativo de Shalize. Un artefacto entregado habría muerto con la decisión. Un entendimiento compartido, no. Es el argumento más sólido que tengo a favor de este principio, y viene del proyecto que fracasó.
WritingChex cuenta una versión más acotada. Dirigí el producto desde la definición del problema hasta el diseño, la construcción y la validación del MVP, di forma a la lógica de retroalimentación con IA y apoyé la captación de los primeros clientes de pago: la primera prueba de que alguien pagaría por retroalimentación generada por IA. Lo que más me enorgullece de ahí no es el producto. Es que fui honesto con el equipo sobre dónde no se podía confiar en el modelo. Aun así, cerró en 2025. Ser quien dice lo que no funciona no salva a todas las empresas. Solo hace que valga la pena tenerte en la sala.
La versión práctica
Por eso mi propuesta está formulada como está. Dime qué está roto. Si puedo ayudar, te diré cómo. Si no puedo, también te lo diré, y normalmente quién puede. Una relación en la que uno solo da órdenes no puede producir esa última frase. Un proveedor que dice “no puedo ayudar” ha terminado el encargo. Un socio que lo dice ha hecho el trabajo.
Lo más útil que aporto a una sala suele ser una pregunta mejor. Ketabno se lanzó en unos tres meses y se asoció con el Ministerio de Educación y con la plataforma nacional Shad, no porque alguien lo especificara así, sino porque primero se había planteado bien el problema: 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. Si esa frase sale mal, ninguna entrega fiel lo rescata. La mayoría de los productos fracasan en la pregunta del propósito, y nadie se da cuenta durante dieciocho meses.