About Liorry Herisnor
I help organizations turn complex business needs into practical technology solutions, streamlined processes, and measurable results. I am just as deliberate about where automation does not belong.
What I do
I run product and delivery for a set of connected systems: an email marketing platform, a purpose-built delivery engine, data discovery and enrichment pipelines, and the controls that let AI agents work against a live system safely.
My primary responsibilities are defining requirements, prioritizing work, coordinating implementation, managing testing and validating results. That includes deciding where AI genuinely helps and where fixed business rules are required instead — and then building the system so that decision holds without anyone having to remember it.
The clearest example is the sending path. It is full of places where AI would look impressive in a demo: predicting when a mailbox provider will start throttling, choosing retry timing, classifying failures. None of them use AI, because a confidently wrong answer there costs weeks of sender reputation, and a simple running average turned out to be both cheaper and more accurate. Making that call, and explaining it to someone who wanted an AI feature, is the job.
How I decide where automation belongs
I use AI to improve analysis, recommendations and productivity, while keeping approvals, permissions and critical business rules inside reliable software workflows. High-impact actions require a person to approve them.
Where exactly that line falls is a decision made per project, and each case study states the boundary it actually uses.
How I think about it
Four things I hold to
Write the rules down, with the reason behind them
A rule with no evidence behind it turns into folklore, and nobody can tell whether it still applies. A rule that points to why it exists brings a new contractor — or an AI assistant — up to speed on day one. It is the cheapest document I maintain and it has prevented the most expensive mistakes.
A rule that needs judgment fails when judgment is scarce
“Approval required for risky changes” asks someone to assess risk under time pressure, which is exactly when that assessment is least reliable. “Approval required for every production change” leaves nothing to argue about.
No errors does not mean everything is working
Most of the ways these systems fail are quiet: a number that stops moving, a background job that exits, a backlog that stops clearing. Monitoring has to watch for progress, not just for errors.
The best AI decision is often not to use AI
A lot of what people hand to AI is a factual question that a database query answers exactly, faster and for free. Recognizing that is worth more than any prompt technique.
How I work
Discover → Define → Design → Build → Validate → Operate
Discover
I work through the operation with the people running it, map the current process step by step, and find where time, money and accuracy are being lost.
Define
I write the requirements: goals, what is explicitly out of scope, user stories, acceptance criteria and the measure that decides success.
Design
I design the workflow and the system around it, and decide where AI is genuinely useful and where fixed business rules are required instead.
Build
I coordinate implementation and build parts of it myself, using AI development tools under defined scope, cost and review rules.
Validate
I plan and run the testing — unit, integration, user acceptance and post-release checks — then track defects through to closure.
Operate
I monitor the system in production, diagnose incidents, tune performance and feed what I learn into the next round of work.
What I am looking for
Product, program, technical program and product operations roles where the work is turning a real business problem into a system that runs — and where someone is expected to own the decisions about what should and should not be automated.