BrioHR — bringing AI into an established platform without breaking what works.

What I joined

BrioHR is an HR platform serving small and mid-sized businesses across Southeast Asia. By the time I joined in February 2025 the product had real customers, multiple modules in production, and the kind of growth profile that tends to outrun the systems that got the company there. Hiring had stepped up sharply. The organisation was preparing for — and during my time, closing and announcing — its Series A.

I was one of two product managers in the company. That ratio mattered. With a product surface area larger than two PMs can carry by themselves, the only honest way to operate is to choose the few things that compound and let the rest wait. Most of what I did at BrioHR was about that prioritisation discipline, translated into specific shipped work.

The foundations I closed

Two foundational gaps were costing the team more than anyone was measuring.

The first was the request and issue intake layer. Feature requests were arriving from sales conversations, from current customers, and from internal teams — in different channels, with different framing, no shared language for severity or value. Reported issues followed the same scattered pattern. I kicked off an initiative to centralise both: one place where requests and reports landed, with the structure needed to triage and decide. That gave the company something it didn’t have before — a single view of what was being asked for and what was breaking, separated from the noise of who asked loudest.

The second was product analytics. Mixpanel had been evaluated but the underlying event instrumentation across the platform hadn’t been fully built out, which meant we were making product calls partly on instinct rather than on what users were actually doing. The push there was less about choosing a tool and more about getting tracking in place so the tool would have something to measure.

The modules I revamped

I worked across three modules during my tenure: Recruit, Onboarding, and Time & Attendance.

The most substantive of the three was Time & Attendance, where we went beyond the simple punch-in / punch-out model and shipped shift management as a first-class capability. For the customers BrioHR serves — SMBs across multiple industries, many of them shift-based — this is where the product earns its keep. Designing shift logic that handles the real variations operators run into, without making the interface harder for the businesses that don’t need the complexity, was the harder part of the work. Recruit and Onboarding got their revamps too, focused on the points where the existing flows were creating support load that the team felt every week.

The AI adoption strategy

The Series A close brought a question to the front of the room: where does AI actually create value in an HR platform, versus where does it look impressive in a screenshot and break in production? My role was to lead that strategy across the platform, and the principle I held was that AI features get shipped only where they answer a real product question — and they get rolled out one at a time, with the accuracy bar honest from day one.

Two AI features came out of that work in the period I was there. Inside the Recruit module, an AI capability that understands a company’s context and helps generate job descriptions when a hiring manager creates a role — reducing the blank-page friction that’s the actual reason most postings sit half-finished for days. Inside payroll, an AI capability that surfaces likely errors before payroll runs — the highest- stakes module in any HR product, because a wrong payroll is a relationship problem with employees, not a UI problem. Both were rolled out gradually and tuned against real usage rather than launched on a fixed date. That sequencing was deliberate.

The harder part of the AI work wasn’t any specific feature. It was navigating the organisational dynamics of introducing AI into an established team that had been shipping for years without it. The way through there is the same as in most senior product work: name the question the team is actually asking, make the tradeoffs visible, and let the decision get made together rather than imposed.