VP Engineer - ASP.NET

Strong Technical Project Manager Profile with hands-on delivery ownership and technical depth

2

Mandatory (Experience 1): Must have 8+ years of experience, including 4+ years leading cross-functional software product delivery across multiple medium-sized companies

3

Mandatory (Experience 2): Must have proven experience delivering software projects from concept through production in a service-delivery environment within a mid-sized organisation.

4

Mandatory (Experience 3): Must have strong experience with Agile/Scrum, estimation techniques, release planning, and end-to-end project execution — including release readiness, production rollouts, rollback planning, hypercare, and customer acceptance.

5

Mandatory (Experience 4): Must have experience managing multiple workstreams, cross-team dependencies, and stakeholders in fast-paced environments, and building/managing project teams from initiation to delivery.

6

Mandatory (Experience 5): Must have experience with integrations (REST APIs, IdP, payment gateways, CRM, ERP, POS) and familiarity with CI/CD, cloud (AWS/Azure/GCP), and the deployment lifecycle

7

Mandatory (Experience 6): Must have experience working with global customers (US/EU) in a customer-facing delivery role, with international exposure.

8

Mandatory (Tech skill 1): Must have a high-level understanding of backend systems, REST APIs, and microservices architecture (Node.js exposure preferred), plus system design principles (scalability, reliability, fault tolerance, performance).

9

Mandatory (Tech skill 2): Must be able to participate in architecture discussions, review technical proposals, evaluate trade-offs, and constructively challenge engineering decisions.

10

Mandatory (AI): Must have experience using AI tools (e.g. Claude, GitHub Copilot) to improve delivery productivity.

11

Mandatory (Communication): Must have excellent written and verbal communication with engineering teams, business stakeholders, customers, and leadership.

12

Mandatory (Company): Must come from a mid-level service company.

13

Mandatory (Certification): Must have PMP and/or CSM certification.

14

Mandatory (Education): Must have a BE/MS in Computer Science or a related field

15

Preferred (Background): Development background earlier in career (QA / mobile / web developer who moved into TPM); ability to create SRS/RFP; business-analysis capability.

We are seeking a Senior Technical Product Manager with 6+ years of experience to own product strategy and delivery end-to-end. You'll define the roadmap, translate business needs into clear requirements, and drive execution with engineering and design, using technical depth to partner on APIs, integrations, and platform decisions.

Key Responsibilities

• Own and communicate the product roadmap and priorities

• Gather requirements from stakeholders and users; write clear specs

• Partner with engineering and design through agile delivery

• Make data-driven decisions using product analytics

• Balance business goals, user needs, and technical constraints

• Track outcomes and iterate on the product

Mandatory Skills

• 6+ years in product management for technical products

• Roadmap ownership and prioritization

• Strong requirements gathering and user research

• Agile delivery with engineering teams

• Data-driven decision making (analytics)

• Excellent stakeholder communication

Nice to Have: technical background (APIs/architecture); SaaS/platform product experience

Technical Project 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.

FULL-TIME

MANAGER · 7+ YRS

Engineering — Delivery & Program Management

TEAM YOU’LL RUN

15–25 engineers · Backend · Frontend · AI

LOCATION

India

EXPERIENCE

6–7 yrs min · 4+ yrs managing engineers

WORK MODE 

Hybrid

DOMAIN

ENGAGEMENT

AEC · CAD / BIM automation · Multi-tenant SaaS

About BuildTwin

BuildTwin is a multi-tenant SaaS platform that runs the day-to-day operations of construction

and infrastructure companies — their workforce, projects, commercials, and documents — on a

single system. Alongside it we build an AI drawing-automation platform that turns structured

element data into production-ready technical drawings and exports them to PDF and DXF.

Both products are built by a small, senior engineering group in India: backend engineers on an

AWS serverless platform, frontend engineers on Angular and React, and AI engineers working

on drawing generation and data extraction. Sitting next to them — not in another building, not

in another timezone — are the structural and detailing engineers who define what a correct

drawing actually is.

That adjacency is our biggest advantage and our hardest coordination problem. This role exists

to make it work.

 Role overview

We are hiring one Technical Project 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.

The centre of gravity of this job is the floor, not the calendar. Most of your day is

spent with the people building and the people specifying — closing the gap between what a

domain expert means and what an engineer can implement deterministically. Status

reporting is a by-product of doing that well, not the job itself.

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.

Technical partnership

Participate substantively in technical discussions on design, sequencing, and trade-offs —

and hold your own with senior engineers.

Understand the architecture well enough to reason about blast radius: what a schema

change touches, why a migration is risky, why an API contract must be agreed before two

teams start.

Challenge estimates that look wrong in either direction, and recognise when an estimate is

uncertain because the problem is still unclear.

Translate technical constraints into decisions leadership can act on, and business constraints

into direction engineers can act on.

Keep testing, observability, and debt-reduction work on the plan instead of losing to features

every single quarter.

Insist that decisions get written down — architecture choices, drawing rules, API contracts,

and the reasoning behind each.

Stay close to the artefacts: read the tickets, the design docs, the PR titles, and the incident

write-ups.

Chair technical discussions where the outcome is a decision with an owner and a date, not a

longer discussion.