Business Analyst, Product & AI

Zeya Labs is a small AI-native engineering team based in Ho Chi Minh City. We are the central technology delivery engine for a diversified group spanning financial services, F&B, retail, hospitality, and real estate.

Our product function does not hand off specifications and wait. It builds. The problem is that there are multiple sectors worth of stakeholders with things they need, and a small team that can only be in one room at a time.

This role exists to close that gap — not by writing documents for someone else to interpret, but by getting to the real problem fast enough that what reaches the build team is already validated.

Concretely, you are responsible for:

• -Getting to the real problem, fast. Sit with stakeholders across whichever entity needs it and find out what they actually need, not what they first describe. Days, not weeks.
• -Validating before you hand off. Use AI to pressure-test the problem before it reaches the build team — quick prototypes, structured synthesis of messy stakeholder input, sanity-checking assumptions against whatever data exists. What you hand off should already carry some confidence, not just notes from a meeting.
• -Owning the handoff. Structure what you've found into something the product and engineering team can act on immediately — a clear problem statement, what success looks like, the real constraints. Stay in the loop through build to confirm it's still solving the right thing.
• -Covering ground. There is no fixed patch. You go where the surface area is — that's the reason this role exists.

Your background is probably business analysis, product, or consulting — but you've never been satisfied producing a document and calling it done. You want to see the thing get built, and be right.

You can walk into a room in financial services on Monday and a room in F&B on Wednesday and be credible in both, because you're asking about the problem, not pretending to be a domain expert. You have a low tolerance for vague asks and know how to get specific without being annoying about it — you can tell the difference between a stakeholder who genuinely doesn't know what they want yet and one who's just being slow, and you handle both without losing the room.

You're comfortable being judged on whether the thing that got built actually worked, not on how thorough your discovery document was.

You use AI as your default way of moving faster through ambiguity — synthesizing a messy pile of stakeholder input, building a quick prototype to test an assumption, checking your own thinking before you commit to a direction. Not as something you reach for occasionally to polish a deliverable. If your AI experience is "I used ChatGPT to write up my requirements doc," that's not what we mean.