Product leader, builder, and lifelong student of how software actually gets made
I'm Khang, a product management professional based in Ho Chi Minh City, Vietnam. For more than eighteen years I've worked at the intersection of product, technology, and business, moving between the United States and Vietnam and across industries as different as clinical nutrition, logistics, education, financial services, and enterprise SaaS. Along the way I've kept one foot firmly in the code. I still write PHP, still design MySQL schemas, still spin up Docker containers on a Friday night to test an idea, and I think that combination of product thinking and hands-on engineering is the thing that most defines how I work.
This page is my attempt to tell that story in one place: where I come from, what I've built, what I believe about building products, and where I'm heading next.
I studied Digital Design and Information Technology at the University of California, Irvine. It was an unusual degree for its time, sitting somewhere between an art program and a computer science program, and it turned out to be exactly the right foundation for a career in product. Design taught me to care about how things look and feel to the person using them. Information technology taught me to care about whether they actually work. Product management, as I eventually discovered, is the discipline of caring about both at the same time, and then adding a third question: does anyone need this, and will they pay for it?
My early career was in the United States, in the years when the web was transforming from a place you visited into a place you worked. I started close to the screen, building interfaces and web applications, and gradually found myself pulled toward the questions that sat upstream of the code. Why are we building this? Who is it for? What happens if we're wrong? Those questions were more interesting to me than any particular technical problem, and following them led me from development into product roles.
I've chosen not to list every company and title from those years here. What matters more is the pattern: I learned to ship software in small, resource-constrained teams where the product person also had to write the spec, sketch the wireframe, review the pull request, and explain the release to customers. That generalist muscle has served me in every role since.
At some point the pull toward Vietnam became too strong to ignore. I'm bilingual in Vietnamese and English, and I wanted to be part of a technology ecosystem that was growing faster than almost anywhere else in the world. Ho Chi Minh City in the 2010s and 2020s has been an extraordinary place to build software. The talent is deep, the ambition is enormous, and the problems are real. Companies here are digitizing entire industries that skipped several generations of technology and are now leapfrogging straight to mobile-first, cloud-native platforms.
Working across both markets has shaped how I think. In the US I learned rigor: structured discovery, well-formed requirements, disciplined roadmaps. In Vietnam I learned speed and pragmatism: how to make good decisions with incomplete information, how to lead teams through ambiguity, and how to translate not just language but expectations between offshore developers, local stakeholders, and overseas clients. A large part of my career has involved sitting in the middle of distributed teams, making sure that what was promised in one time zone gets delivered in another.
My experience spans five domains, and each one taught me something distinct.
has been the deepest thread. Healthcare software is unforgiving: the data is sensitive, the regulations are real, and mistakes have consequences beyond a bad quarterly number. I've worked on clinical platforms, electronic medical record systems, analytics tooling built around published quality indicator standards, and health insurance workflows specific to the Vietnamese market, including BHYT card lookup, ICD-10 coding, and drug database integration. Most recently, I served as Product Lead at NutriMx and Nutricare, working on a clinical nutrition platform with heavy AI integration. That role sits at the frontier of what's possible right now: taking large language models and retrieval-augmented generation architectures and making them safe and useful enough for clinical contexts, where a confidently wrong answer is worse than no answer at all.
was my most recent leadership chapter before that, as Head of Product at 247 Express Technologies. Logistics is a domain where the product is inseparable from operations. A beautiful app is worthless if the parcel doesn't arrive, so the job was as much about understanding warehouses, routing, driver behavior, and last-mile economics as it was about building screens. I learned to respect how much invisible complexity sits behind every "track my package" button.
is where I learned the business side of product: pricing, onboarding, retention, and the long game of building something customers renew year after year. B2B SaaS in Vietnam has its own character. Sales cycles run through relationships, buyers expect customization, and the gap between what a legacy system does and what a modern SaaS platform offers has to be bridged carefully, one workflow at a time.
taught me about engagement and learning design. It's easy to build a content library; it's hard to build something people finish. That experience feeds directly into work I still do today around training and curriculum, which I'll come back to.
taught me about trust and precision. Money is the one area where users have zero tolerance for ambiguity, and building for it sharpened my instincts around edge cases, reconciliation, and what "done" really means.
If you ask the people I've worked with what it's like to have me on a team, I hope they'd say three things.
First, I'm technical enough to be dangerous, in the good sense. My working stack is PHP with the Slim 4 framework on the backend, Vue 3 and Tailwind on the frontend, MySQL and MongoDB for data, and Docker for everything in between. I don't say this to position myself as an engineer; I lead product, not engineering. But I can read the code, I can prototype an idea over a weekend, and I can have a real conversation with a senior developer about tradeoffs without needing a translator. That fluency changes the dynamic. Engineers trust product managers who understand the cost of what they're asking for, and I've found that trust to be the single most valuable asset in shipping software.
Second, I'm relentlessly structured about how I approach a project. Before I write a single user story, I want research and analysis: what does the market look like, what are the alternatives, what could go wrong. Then I want options, ideally a few competing approaches with honest tradeoffs, rather than one plan presented as inevitable. Only then do I break the work into phases, define the file structure and architecture, enumerate the features in detail, and build a checklist that lets the whole team see what's done and what isn't. This is how I've run products for years, and it's also, not coincidentally, how I now work with AI coding tools. The discipline of decomposing a problem clearly turns out to be exactly what makes AI-assisted development effective.
Third, I care about the people on the team. Product management is a coordination job. Much of what I've done over the last decade has been leading remote and distributed teams, running Scrum ceremonies across time zones, recovering offshore engagements that had gone sideways, and building the kind of shared understanding that lets a developer in Saigon and a stakeholder in Toronto or California feel like they're working on the same thing. I don't think there's a trick to it beyond clarity, consistency, and respect.
I write and think a lot about how AI is changing the product role, and I hold a couple of positions that some of my peers find provocative.
The first is that AI is making technical skills necessary for product managers rather than optional. For a long time the industry told PMs that they didn't need to code, and that was true when the bottleneck was engineering capacity. That bottleneck is dissolving. When a product manager can describe a feature clearly enough for an AI agent to build a working prototype, the constraint shifts to the quality of the description, and describing software precisely is a technical skill. The PMs who thrive in the next decade will be the ones who understand data models, APIs, and system boundaries well enough to specify them, not just gesture at them.
The second is that the classic Agile Scrum ceremonies are going to give way to something closer to test-driven development as the organizing rhythm of AI-assisted teams. When code is cheap to generate, the scarce resource becomes a clear definition of correct behavior. Writing the tests, the acceptance criteria, and the specifications first, and then letting humans and AI agents iterate until they pass, is a more natural fit than two-week sprints and story points designed around human typing speed. I don't think Agile's values are obsolete, but I do think its rituals will look very different in a few years.
I try to practice what I preach. My own side projects are built with AI tooling in the loop, from a logo-generation SaaS that orchestrates several image models behind a PHP backend to internal tools I use to plan and track work. I lean toward cost-efficient model providers where quality permits, because I believe the economics of AI products matter as much as their capabilities.
One of the things I'm proudest of is the work I've done helping business analysts grow into product owners. In Vietnam there is a large pool of talented BAs who have the analytical skills to become excellent product people but haven't had a structured path to get there. I've built a full training curriculum for exactly that transition: interactive HTML lessons, slide decks, facilitator kits, take-home assignments, and reference documents like BRD and PRD templates, all delivered bilingually in Vietnamese and English and anchored in a realistic B2B procurement case study so learners practice on something that feels like a real job.
I find teaching clarifying. Explaining product management to someone who is just starting forces you to separate what actually matters from what is just habit, and every cohort I've worked with has sharpened my own thinking.
I'm a builder by temperament, and that doesn't switch off when I close the laptop on work. I run small digital product ventures on the side, including design template shops and productivity tools, partly for the income and partly because I think every product person should ship something they're personally accountable for, end to end, including the marketing and the customer support. There's no better way to stay honest about what users actually want.
I'm also curious about the world outside software. I read about geopolitics and economics, I enjoy playing with data visualization for its own sake, and I spend as much time as I can with my family, in Vietnam and on the road.
Eighteen years in, I feel like the most interesting part of my career is just beginning. The tools available to product builders today are unlike anything I had access to when I graduated, and the problems worth solving, especially in healthcare and in emerging markets like Vietnam, are as big as ever. I'm looking for opportunities to lead product for organizations that take both the technology and the human impact seriously, and for people who want to build with me.