Skip to content
Tomer Naydnov
ENעב

§01/About

Technical product builder

About

I work where product decisions, systems and implementation stop being separate conversations.

I find the workaround everyone has accepted, trace it to the real problem, and build the fix.

Download CV ↓Get in touch →

§02/Experience

Hover, focus or tap a role to read the details.

Experience

  1. 2023 — now

    Current role

    Programming Instructor & EdTech Content Developer

    Nitzanim

    Teach programming and turn field needs into curricula, delivery plans and digital learning products.

    Role detailsClose details

    What I do

    • Work with clients and educational stakeholders to understand needs, clarify requirements, define deliverables and keep expectations aligned throughout development.
    • Plan and develop syllabuses, presentations, lesson plans, instructor guides and programming exercises, adapting the sequence and explanation to different starting points and audiences.
    • Build project timelines and Gantt plans, break initiatives into actionable tasks and support execution from initial planning through testing and delivery.
    • Co-develop Arc with another engineer, translating field needs into product requirements, prioritising improvements, testing workflows and coordinating rollout with instructors and relevant teams.

  2. 2020 — 2023

    Technical Support Roles · Tier 2

    IDF · Israel Electric Corporation · Isracard

    Diagnosed user and system problems across three large organisations, learning to separate reported symptoms from underlying causes.

    Role detailsClose details

    What I do

    • Provided Tier 2 support involving Active Directory, Citrix, remote access, hardware, software and connectivity.
    • Investigated user-reported symptoms and the system issues behind them, documented solutions and communicated next steps to users and technical teams.
    • That work formed the habit of treating the first report as evidence—not necessarily as the root cause.

§03/Education

Education

  1. 2026 — expected 2028

    Current studies

    M.Sc. Industrial Engineering & Management

    Shenkar College of Engineering, Design and Art

    Studying the formal tools for designing, measuring and improving the systems I had previously approached by instinct.

  2. 2021 — 2025

    B.Sc. Software Engineering

    Ben-Gurion University of the Negev

    The engineering foundation behind the systems and projects shown throughout this portfolio.

§04/The thesis

Software is the tool. Systems are the subject.

I completed a B.Sc. in Software Engineering and am now studying toward an M.Sc. in Industrial Engineering & Management. That is not a pivot away from engineering; it is a closer look at what engineering is for.

Industrial Engineering is the discipline of designing, measuring and improving systems and processes. It is the formal version of the thing I kept running into at work: the code was rarely the bottleneck. The bottleneck was an undefined requirement, a handoff nobody owned, or a workaround that had quietly become policy. I had been solving those problems by instinct. I went and learned to do it properly.

So the two degrees are one argument. Software is the tool. Systems are the subject. Being able to write the code is what stops the systems thinking from becoming a slide deck; understanding the system is what stops the code from being beautifully built and pointed at the wrong problem.

§05/What teaching taught me

CLASSROOM / LIVE FEEDBACK

A room of faces exposes a hidden assumption immediately.

I learned requirements in front of a room of sixteen-year-olds.

Teaching programming, alongside work on syllabuses, lesson plans, exercises and instructor guides, has been the most useful professional training I have had — and not for the reason people assume.

Teaching is requirements engineering with a thirty-second feedback loop. A room shows you immediately which part of an explanation was carrying a hidden assumption.

But a room never learns in one way. Every student arrives with a different starting point, pace and way of making sense of a problem. I learned to change the wording, sequence, medium or level of abstraction until the idea lands — without changing the goal.

That habit travels beyond the classroom. Students, instructors, coordinators, clients and engineers do not need the same explanation or interface. Understanding the audience is part of understanding the requirement.

A requirement is not finished until the people it is for can understand and use it.

§06/Where I do my best work

What I want next

A technical product role, on a small team, where the distance between noticing a problem and shipping something about it is short. I want to own outcomes rather than tickets, and I want to be close enough to the users that the feedback arrives directly rather than through a summary.

The team
A small, candid team where product, engineering and users are close enough to learn from one another quickly.
The work
Owning a problem from the first uncomfortable observation through framing, delivery and the iteration after real use.
The distance to users
Short. Direct conversations and observation produce better decisions than second-hand summaries.
What I bring
I can investigate the workflow, write the specification, understand the data model, build the critical path, teach the decision and revise it when reality disagrees.