I spent the first chapter of my working life taking orders well. Freelance, from 2007: design, ideation, layout, web, art direction — contract by contract. I learned one lesson there that never stopped mattering. A strong idea is worth nothing until it becomes a real, deliverable, defensible output. That is a good lesson. It is also, taken alone, the lesson of a supplier. Someone hands you a brief. You return a thing. Both sides are satisfied and neither has thought.
Then at Aghigh I industrialised it. I built the working model: brief intake, output definition, allocation, tracking, feedback, revision, delivery. I managed a standing portfolio of concurrent client projects and their deliverables. It worked. It is also, read honestly, a machine for converting external orders into outputs at scale. The organisation only stopped being that when we drove the evolution toward owned digital products — Bamana, Ketabno, HisTory, NoJahan, Mehrabani, Soha and Mastoura. The shift was not from services to software. It was from receiving a problem to owning one.
The order-giver problem is a knowledge problem
CompanyHouse is where I first hit the wall. Registering a company in Iran requires an expert because the process is deliberately opaque. The expertise is the product — and the bottleneck. So we modelled the specialists' tacit knowledge into a guided, question-based workflow that generated the filings, and worked with legal experts to convert rules, decision points and exceptions into product logic. It ran for a year. It closed.
What it taught me: productising expert knowledge is a knowledge-extraction problem long before it is a software problem. And knowledge extraction is very hard to do inside an order-giver relationship. If the specialist is a supplier answering your questions, you get the rules. The exceptions are harder, because people do not experience their own exceptions as exceptions — they experience them as obvious. They surface when the expert is inside the problem with you, disagreeing about a specific case, not when they are filling in your template. Until you can model the questions they ask and the exceptions they know, you do not have a product. You have a service with a login screen. I do not think we got far enough into that room.
What it looks like when it works
Mehrabani and Soha are the clearest version. Charitable giving fails on both ends: donors cannot verify need, and social workers cannot prove outcome. Trust collapses in the middle. The Mehrabani Card was one object carrying the verified need, the beneficiary's story, the donation and the outcome, with Soha underneath it as the verified-needs data layer. But the line in that record I care about is smaller: I designed the operational workflow social workers actually use. "Actually use" is a claim you can only earn by treating the social worker as a thinking party, not as a downstream recipient of a spec.
Shalize is the same thing in a commercial market. A physical gold and silver business running on WhatsApp messages, memory and trust. Volume was climbing faster than the process could hold it. We rebuilt the operating system end to end — enquiry, order, invoicing, payment verification, fulfilment, follow-up and buyback — and put a CRM under it. Daily volume moved from 0.5 to 10 kg/day, and the business reached 4,000+ verified purchasing customers. Those figures are company-reported, not audited, and I would rather say so than have them quoted back at me later.
The sentence that explains Shalize is on the framework page, not in the numbers: sales had to stop working from memory, and CRM adoption was the real launch, not the website. That is the third of my five questions — who has to change their behaviour for this to work? A client who is an order-giver never has to answer it. They commission the system, the behaviour stays as it was, and then the system gets blamed.
At Emkan the whole job is that translation. My work is to turn territorial development, economic governance, maritime economics, free zones and new cities into structures a product team could actually build. On Invest Iran, the same: an investment-promotion agency with no digital surface is a phone number, so I architected the full investor journey — opportunity discovery, competitive-advantage assessment, expression of interest, organisational engagement, request management and aftercare. None of that can be delivered to a client. It has to be built with the people who know what a free zone actually permits, because what the market permits is different in different places, and that is the fifth question every time.
What did not work
Mokaab. I co-founded it and architected a full investment platform — buy, sell, hold, buyback, pricing, invoicing, delivery and account journeys — with the buyback obligation designed in from day one, not bolted on. It never launched. The parent group's priorities moved to physical operations before the platform shipped.
I want to be precise about what this proves, because it is easy to tell it as a story about a client who did not listen. It is not. Moving to physical operations was a real business decision, and I was inside the group as its Chief Product & Business Development Officer, not shouting at it from outside. What actually happened is that the architecture and the market model survived and were folded into Shalize's operating system. A delivered artefact would have died with the decision. A shared understanding did not. That is the strongest argument I have for this principle, and it comes from the venture that failed.
WritingChex tells a narrower version. I led the product from problem definition through MVP design, build and validation, shaped the AI feedback logic, and supported the acquisition of the first paying customers — the first evidence anyone would pay for AI-generated feedback. The thing I am proudest of there is not the product. It is that I was honest with the team about where the model could not be trusted. It wound down in 2025 anyway. Being the person who says what does not work does not save every company. It just makes you worth having in the room.
The practical version
This is why my offer is phrased the way it is. Tell me what is broken. If I can help, I will say how. If I cannot, I will tell you that too — and usually who can. An order-giver relationship cannot produce that last sentence. A supplier who says "I cannot help" has ended the engagement. A partner who says it has done the work.
The most useful thing I bring to a room is usually a better question. Ketabno launched in roughly three months and partnered with the Ministry of Education and the national Shad platform — not because someone specified it that way, but because the problem had been framed correctly first: teenagers do not stop reading because books are bad, they stop because reading is solitary, unrewarded and invisible to their friends. Get that sentence wrong and no amount of faithful delivery rescues it. Most products fail on the purpose question, and nobody notices for eighteen months.