AI Engineering Product Manager

Run delivery for 15–25 backend, frontend, and AI engineers building construction- tech and CAD drawing-automation software — with structural engineers on one side of you and the codebase on the other. Must have Hands-on familiarity with AutoCAD, Revit or experience at a product company in the CAD / AutoCAD / BIM / PLM / EDA /simulation space

Role overview-

We are hiring one Technical Product Manager to own delivery across our engineering teams in Bengaluru. You will run 15–25 engineers across backend, frontend, and AI workstreams, and you will be the person who turns requirements originating with our structural and detailing engineers into scoped, sequenced, shipped software.

This is a technical role. You will not be handed a groomed backlog and asked to move cards across it. You will sit in the design discussion and have a view on how and when — you will push back on an approach that will not scale, ask why a trade-off was made, and know the

difference between a two-day change and a two-sprint one. You are not expected to write production code. You are expected to read it, understand the system, and never be the least- informed person in a technical conversation you are chairing

What you’ll own- Delivery ownership

• Own the end-to-end delivery plan for every active workstream — scope, sequence,dependencies, capacity, and dates that actually hold.
• Break large, ambiguous product intent into engineering-sized increments with explicit acceptance criteria, agreed with the people who will build them.
• Run the operating cadence: planning, standups, refinement, demos, and retrospectives that change something the following week.
• Maintain one honest view of status — on track, at risk, slipped, and why — visible to the founders and to the team at the same time.
• Manage cross-team dependencies between backend, frontend, AI, and drawing-automation workstreams so no team idles waiting on another.
• Surface risk early, quantify it, and arrive with options — never an escalation without a proposal.
• Protect the team from thrash: absorb changing priorities, re-plan properly, and say no or not now when a plan cannot take more.
• Drive releases to genuinely done — QA, UAT with domain experts, documentation, and post- release verification included.
• Own and improve the delivery metrics that matter: cycle time, predictability of committed scope, defect escape rate, and rework.
• Run the release calendar across two products so neither becomes the permanent second priority.

The floor & the team.

Our requirements do not come from a product spec written in a vacuum. They come from structural and detailing engineers sitting on the floor with decades of practice behind them. Converting that into software is the defining skill of this job.

• Partner with structural and detailing engineers to turn drawing standards, project practice, and domain expectation into unambiguous, implementable requirements
• Run requirement sessions whose output is a written spec — sample data, expected output,edge cases, and explicit non-goals — not a shared verbal understanding.
• Arbitrate the constant gap between “how it has always been done on site” and “what can be deterministically automated.”
• Set up validation loops so domain experts review generated output early and repeatedly, rather than at the end of a sprint.
• Maintain a decision log for domain rules so the same question is not re-litigated three sprints later by different people.
• Manage internal stakeholder expectations and, where relevant, commitments made to customers.
• Spot when a “small clarification” is actually a scope change, and handle it as one.
• Make sure engineers get access to the domain expert directly — your job is to structure that contact, not to become a relay in the middle of it.

Challenges you’ll solve.

We prefer to be candid. These are the problems that make this role genuinely difficult — and genuinely interesting.

Domain knowledge that arrives as tribal knowledge

Our structural and detailing engineers know what a correct drawing looks like, but much of that knowledge is tacit. Your job is to extract it into deterministic, testable rules before an engineer starts building. Getting this wrong is the single most expensive failure mode we have

— it produces work that looks finished and is not.

Three disciplines, one release

Backend (AWS serverless), frontend (Angular / React), and AI engineers ship into the same

product. They have different failure modes, different testing regimes, and different natural cadences. Sequencing them so nobody idles and nothing integrates late is the core scheduling problem here.

Correctness is not negotiable

This is construction software. A wrong drawing, a wrong quantity, a wrong permission, or a wrong payroll figure has consequences outside the screen. “Ship it and iterate” has limits here, and you will need judgement about exactly where those limits sit for each workstream.

AI workstreams do not estimate like CRUD

Drawing generation and extraction work is research-shaped: some weeks produce a breakthrough, some produce a negative result. You will plan around that uncertainty honestly— with timeboxes, decision points, and fallbacks — instead of pretending an unknown is a two-

week ticket.

Live customers, finite engineers

Companies run their operations on this platform daily. Production incidents, customer escalations, and enterprise integrations (Asite, Autodesk Construction Cloud) compete with roadmap work for exactly the same people. You will make that trade-off explicitly, every week,

and be able to defend it.

Two products, one organisation

The operations platform and the drawing-automation platform have different customers, different rhythms, and partly shared people. Keeping both moving — without either becoming the perpetual second priority — is a standing constraint on every plan you make.

Founder-adjacent, fast-changing priorities

Direction can change on new customer information, and sometimes it should. You are the shock absorber: re-plan quickly, communicate the change clearly and once, and make sure the team experiences it as a decision rather than as chaos.

Qualifications.

• 6–7 years minimum in software delivery, including at least 4 years directly managing engineering teams as a project, delivery, or engineering program manager.
• Proven experience running teams of 10+ engineers across more than one discipline —backend, frontend, mobile, data, or AI.
• Fluency in modern delivery practice — Agile / Scrum or Kanban applied with judgement rather than ceremony — plus genuine facility with Jira or Linear, Git workflows, CI/CD, and release management.

Strongly preferred

• Experience at a product company in the CAD / AutoCAD / BIM / PLM / EDA /simulation space — Autodesk, Bentley, Dassault, Siemens, PTC, Trimble, Hexagon, Ansys or similar.
• Exposure to AEC, construction tech, manufacturing, or industrial software where domain correctness matters more than interface polish.
• Experience managing teams that included AI / ML engineers alongside conventional product engineers.
• Hands-on familiarity with AutoCAD, Revit, Civil 3D, Tekla, or DXF / drawing-export workflows.

The bar, the process, the offer.

The manager we’re looking for

Technical enough to be trusted

Engineers respect the questions you ask, not just the dates you set.

Owns outcomes, not activity

Measures the job by what shipped and worked, not by how busy the board looked.

Direct and specific

Says the uncomfortable thing early, in plain language, to the person who needs to hear it.

Reduces chaos

Leaves every process, plan, and handoff simpler than they found it.

Holds opinions loosely

Strong views on how to run delivery, updated when the evidence changes.

Raises the standard around them

The team becomes more predictable and more capable because you are in it.