An Unconventional Path into Product Engineering

I did not complete a traditional computer-science degree. My career grew through small product teams, difficult handoffs, performance problems, customer-facing failures, and a gradual shift from completing tasks to owning outcomes.

The salary change—from ₹25,000 per month in my first product role to senior engineering—is part of the story, but it is not the useful lesson. The important change was learning how to make increasingly consequential decisions and remain accountable after the code shipped.

Starting without a map

In 2018 I joined Edmingle and worked across marketing pages, authentication, dashboards, mobile surfaces, and partner integrations. There was no clean boundary between “learning” and “production.” A small change could expose a weak assumption in the UI, API, deployment, or support process.

I learned HTML, CSS, JavaScript, Ember, PHP, MySQL, React, and deployment tools because the product needed them—not because I had completed a curriculum in that order. That was useful, but also inefficient. I spent too long equating activity with progress and sometimes rebuilt things before understanding the existing system.

The shift from tasks to ownership

At QikPod, work across React and React Native put software closer to operational workflows. “Done” could not mean that the happy path rendered on my machine. It had to include the person using the interface, the device and network they had, and the operational recovery when something failed.

The habits that mattered were uncomplicated:

• Read surrounding code before proposing a new abstraction.
• Clarify failure and permission states before implementation.
• Ask product, design, backend, and QA questions early.
• Follow a feature through review, release, instrumentation, and support feedback.

Ownership is not doing every role yourself. It is keeping the right people and constraints connected until the outcome is reliable.

Performance became a product problem

At HyperVue, formerly Frrole AI, I led frontend work for data-heavy social analytics and white-label products. Large datasets and chart-rich screens made performance visible to customers. The work produced a more-than-3× dashboard improvement recorded in my public résumé.

That experience changed how I thought about frontend engineering. Rendering speed, loading feedback, information hierarchy, API shape, and customer trust were one product problem—not separate optimization tickets. You can read the public evidence and limits in the HyperVue case study.

Small-team accountability

I had already been working primarily on the Humantic AI product while employed at Frrole/HyperVue. When Humantic became a separate company, I moved with the core team and stopped supporting Frrole so I could focus fully on Humantic’s product and platform.

The role then expanded across React, Node.js, integrations, production support, and a customer-facing Chrome extension. The team migrated that extension to Manifest V3 while continuing to ship and support customers as the company grew from pre-revenue to more than $1M ARR.

Small teams expose weak handoffs quickly. I became more deliberate about migration plans, authentication boundaries, observability, rollback paths, and communicating tradeoffs in language that product and business teammates could use. The public summary is in the Humantic case study.

What actually changed at senior level

At RingCentral, the scale and number of stakeholders increased. Most of my Events work focused on organization analytics, configurable reporting, and Data Apps. That included bringing key Marketo and Salesforce setup workflows into a RingCentral-owned interface. A later assignment moved into Content Hub and Creator Lab. I now work in ACE on a configurable analytics and dashboard experience; the first prototype is available for internal lab validation, while unpublished product and impact details remain private.

The senior-level change is less about a title and more about the questions I now carry:

• Which behavior must stay compatible while the product evolves?
• Where can data, permissions, or retries create a misleading user experience?
• What should be generalized now, and what should remain specific?
• How will QA, support, and operations understand a degraded state?
• What evidence will tell us whether the shipped change helped?

Advice I would keep—and advice I would discard

I would keep building, reading production code, seeking ownership, and learning from people in adjacent roles. I would discard the idea that constant tool churn proves growth. Depth comes from maintaining decisions long enough to see their consequences.

• Use courses and talks as inputs; validate them in maintained work.
• Keep a record of decisions, outcomes, and what you would change.
• Learn the business and operational context around the interface.
• Ask for feedback on judgment and communication, not only code style.
• Do not let the absence of a degree become either an excuse or an identity.

My route was unconventional, but the durable part was ordinary: sustained practice, increasingly difficult responsibility, and a willingness to correct my own work.