I am …Vignesh
Nice to meet you.
I am …
i · it started with “how do we build this?”
I started as …
Mechanical engineer by degree, frontend by obsession — voice-controlled interfaces, ML prototypes for industrial predictive maintenance, performance forensics when production broke at enterprise scale. That engineering depth is why I can sit with architects and customers in the same conversation. It's the foundation the product work stands on — not the destination.
Infosys · voice-enabled prototypes · ML proof-of-concepts · JMeter · LoadRunner · Dynatrace · Udacity × Google
ii · then “how do we make this easier to use?”
I am also …
Technically correct software can still be unusable — I've watched powerful systems people quietly resent. So I made UX my core instrument: workflow design, user journeys, Figma and Adobe XD — designing the end-to-end experience of enterprise platforms myself, not delegating it. A product manager who designs the answer beats one who only writes the requirements.
end-to-end UX — enterprise aviation workforce · pharmacy management mobile · workflow design · information architecture
iii · then “why are users doing this in the first place?”
I am …
The turning point: feature requests are symptoms. The question moved from what should we build? to what problem is the customer actually solving? — and that question is the job I do now. Discovery workshops, workflow analysis, user observation, across enterprise AI, aviation, healthcare and operations. Same lesson everywhere: the real product lives in the why.
discovery workshops · workflow analysis · Singapore Airlines GenAI Challenge — shortlisted · QRDI Global Innovation — shortlisted
iv · today · “what is the business outcome?”
I am …
For a Fortune 500 airline, I led delivery end to end — from customer discovery through sprint and milestone planning, UAT and production rollout — on a workforce platform serving 35,000+ employees and 285,000 schedule lines, roughly 40,000 users with 4,000 concurrent at peak. I introduced a milestone-based delivery approach so the customer validated progress continuously rather than waiting for the end. Enterprise scale rewards the same thing every time: steadiness.
enterprise aviation · Discovery → Build → Demonstrate → Validate → Adjust · agile delivery · milestone planning · UAT → production
v · today · “how does the work actually move?”
I am …
Roadmap into milestones, milestones into sprints, sprints into stories I write, point and assign. I run refinement so the backlog stays buildable, and retrospectives so the team fixes its own process instead of repeating it. What I watch isn't the status column — it's planned versus completed, velocity trends, recurring spillover, blocked work and dependency aging. Momentum is a leading indicator. You can see a deadline slipping weeks before it does.
roadmap & backlog · user stories & acceptance criteria · story points · refinement · sprint planning · retrospectives · velocity & spillover · Jira · Azure DevOps
vi · today · “how do we build with AI — and prove it works?”
I am …
A multi-agent testing platform from concept to production in six months. An agent that reads legacy repositories and turns them back into documentation. A forecasting Q&A agent put through structured evaluation rounds until it scored 100/100 — after catching a regression manual testing missed. A forecasting engine running model tournaments — SARIMA against LightGBM — checked against what actually happened. My rule: AI is regression-tested, not trusted because it demoed well.
multi-agent architecture · repository understanding · grounded agents · evaluation & regression testing · SARIMA · LightGBM · backtesting
vii · today · “who needs to agree, and what does it cost?”
I am …
I partner directly with the C-suite, engineering leadership and enterprise customers to align what gets built with what it costs. I own effort estimation, proposals and change-request planning, and run discovery, demonstrations and UAT — surfacing the trade-offs between value, engineering effort, dependencies and timeline before they harden into commitments. Scope changes get an impact analysis, not resistance. Good product management isn't saying yes — it's making the trade-offs visible.
C-suite partnership · engineering leadership · enterprise customers · effort estimation · proposals · scope & change management · impact analysis · UAT
viii · “who grows because I was here?”
I am …
I gave engineers ownership of whole milestones — the feature, the demonstration, the customer conversation, the issues that follow — because people grow when they own outcomes, not tasks. Some of them lead their own now. The same discipline applies to my own ideas: when the evidence said my original scope was too broad, I narrowed it myself and the product got better. Leading is deciding in the open — and being the first one held to it.
milestone ownership · coaching engineers into customer-facing roles · narrowing my own scope on evidence · PMP — PMI approved, exam 2026 · ISB Co'27
Nice to meet you.
the record · since recruiters ask
the numbers behind the story.
customer reality · product thinking · UX · engineering · AI · delivery · adoption