Business Operations & Program Manager

Turning operational friction intostructured, high-impact programs.

Business Operations & Program Manager with 5 years of experience leading complex technology programs across R&D, IT, Security, and Finance. I specialize in AI tool rollouts, multi-million-dollar infrastructure modernization, and automated executive reporting.

©2026

/AI governance · Technical program delivery · Enterprise infrastructure

(01) About

Hey!

I work at the intersection of software, AI adoption, product delivery, and cross-functional operations.

Portrait of Tavor Ben Shahar

With a hands-on technical foundation and experience at Applied Materials, IBM, and Keshet Media Group, I take fragmented processes and align R&D, IT, Security, and Finance to a single cadence.

Results from recent roles

  • 40+

    AI workflows moved under IT/R&D security compliance

    Keshet Media Group

  • 7

    Redundant tools cut through unified AI tool licensing

    Keshet Media Group

  • 900

    Project boards archived or consolidated in a platform cleanup

    Keshet Media Group

  • −30%

    Compute cost after moving servers to a colocation site

    Applied Materials

  • 1,200+

    Employee facility whose IT infrastructure was modernized

    Applied Materials

  • 0

    User disruption across system migrations

    IBM

I sit between the people who build technology and the people who fund and depend on it. I turn requirements into plans, constraints into decisions, and status into foresight leadership can plan with.

Discipline

What I actually do

Program management and business operations for technology teams.

(03)

  • Cross-functional alignment

    Get engineering, Finance, Security and leadership working to one plan.

  • Program delivery

    Run technology programs end to end: scope, schedule, risks and launch.

  • AI governance

    Turn ad-hoc AI use into secure, approved ways of working.

  • Budget and vendor management

    Plan budgets, run procurement and cut spend on tools nobody uses.

  • Leadership reporting

    Build live dashboards so leadership sees program health at a glance.

How I think

A few things I believe about product

(04)

  1. 01

    Early product work should expose the riskiest assumption, not prove the easiest one.

    Technical feasibility is almost never the assumption most likely to kill adoption. Whether the user who matters most actually has the problem you think they have usually is. I design the first weeks of any new product around stress-testing that assumption, not building the most demoable version.

  2. 02

    Value isn’t complete until users can perceive it.

    In complex categories like cybersecurity, AI and B2B platforms, a product can work perfectly and still feel like nothing is happening. The product job isn’t done until value is legible: visible enough to trust, specific enough to recommend, real enough to renew.

  3. 03

    Design is upstream, not downstream.

    The most important design decisions aren’t about color or polish. They’re structural: what appears first, what’s hidden, what’s the default, what the system implies about how users should behave. These choices shape behavior before anyone reads a single word, and they’re product strategy, not styling.

  4. 04

    I’d rather build something a smaller group loves than something everyone tolerates.

    In early products, love is a more reliable signal than completeness. It tells you whether you’ve found something worth scaling, or just something that technically works. Minimum lovable, not minimum viable.