Indonesia Singapore ไทย Pilipinas Việt Nam Malaysia မြန်မာ ລາວ
← Back to Blog

Why Your Product Team Is Your Worst User Tester

Dogfooding is a quality gate, not a research method — treat them as separate tools with distinct success metrics.

An engineer raising their hand inside a giant mechanical loom, surrounded by tangled data threads
Illustrated by Mikael Venne

Dogfooding catches bugs, not blind spots. Here's why internal testing alone fails Southeast Asian digital teams — and what to do instead.

Your product team uses your app every day. They file bug reports, stress-test edge cases, and debate pixel alignment in Figma at 11pm. And yet, somehow, your onboarding still confuses first-time users in Surabaya, your checkout flow loses people in Cebu, and your power users in Bangkok are doing workarounds that nobody on the team ever imagined.

This is the core paradox of dogfooding — and it has a measurable cost.

Dogfooding Finds Bugs. It Doesn’t Find Blind Spots.

Nielsen Norman Group’s Therese Fessenden makes the structural problem precise: internal teams know too much. They understand the product’s logic, its naming conventions, its quirks. That knowledge doesn’t make them better testers — it makes them categorically different users. They will never experience the confusion of someone who doesn’t know what a “workspace” is in your SaaS product, or why a Grab-like superapp has five tabs instead of three.

Dogfooding is genuinely useful for catching regressions, broken flows, and performance issues before they ship. Think of it as a quality gate — it stops bad code from reaching users. What it cannot do is tell you whether the right thing was built in the first place. That distinction matters enormously when you’re allocating research budget. A team that treats dogfooding as user research is, functionally, running a study where every participant has a PhD in your product.

The Loom Principle: Building Systems That Catch Their Own Failures

There’s an instructive parallel in industrial engineering. Ninety years of loom manufacturing — as explored in a recent UX Collective piece — produced machines sophisticated enough to detect their own thread breaks and stop automatically, rather than weaving the defect deeper into the fabric. The insight wasn’t just mechanical; it was systemic. The machine needed to know what a failure looked like from the inside.

Product teams can apply the same logic. If your analytics instrumentation is precise enough, your data will raise its hand before users start leaving. Drop-off at step three of onboarding isn’t a UX opinion — it’s a signal with a timestamp. The question is whether your team has built the equivalent of that loom sensor: a feedback loop that surfaces failure modes in production, not just in internal testing.

For Southeast Asian digital products, this matters acutely. Mobile-first users in the region move fast and abandon faster. Shopee’s conversion optimisation team doesn’t rely on internal intuition — they run continuous A/B tests across millions of daily active users precisely because the behavioural data is richer than any internal walkthrough could produce.


User Research Fills the Gap Dogfooding Can’t

The fix isn’t to stop dogfooding — it’s to stop expecting it to do something it was never designed to do. NNGroup’s framework positions these as complementary tools with non-overlapping jobs: dogfooding for technical quality, user research for behavioural truth.

For brands operating across Southeast Asia’s linguistic and cultural diversity, this separation is especially important. A Bahasa Indonesia speaker navigating a multi-language e-commerce interface faces friction that no Jakarta-based product team will ever naturally encounter. Unmoderated usability testing with recruited participants — even 5-session rounds — will surface issues that six months of internal use missed entirely. The cost of a monthly research cadence is a rounding error against the revenue impact of a checkout flow that converts 2% better.

Implementation note: if your team is resource-constrained, start with session recordings (Hotjar, Microsoft Clarity) and exit surveys on high-value pages. These are passive research instruments that run continuously and require no scheduling overhead. They won’t replace moderated research, but they will tell you where to look.

Scaling These Principles Into a Design System

The deeper organisational issue is that most teams don’t have a clear protocol for when each testing method applies. Dogfooding happens informally. User research gets scheduled when something is already broken. Post-launch analytics arrive too late to inform the current sprint.

Building a testing taxonomy into your design system documentation is an underrated move. Define explicitly: what gets dogfooded (new feature flags, performance changes, content updates), what triggers a research round (new user flows, significant navigation changes, post-launch anomalies in funnel data), and what gets monitored passively in production. When this is codified, it removes the political friction of deciding how to test each initiative — the protocol makes the call.

For teams managing multi-platform experiences across LINE, in-app web views, and standalone mobile apps, this taxonomy also needs to address platform-specific behaviour. A flow that tests cleanly in an Android webview may behave differently in LINE’s in-app browser, which strips certain JavaScript events. That’s a dogfooding catch — but whether the flow made sense to users in the first place requires actual users.

The most honest thing a product team can say about internal testing is this: we are experts at using our own product, and that expertise is a liability when we’re trying to understand someone who isn’t. The loom that catches its own mistakes is valuable. But it still needs a weaver to tell it what to make.

The real question for Southeast Asian digital teams: how much revenue are you leaving on the table by confusing quality assurance with user understanding?


At grzzly, we work with digital teams across Southeast Asia to design research and testing frameworks that connect directly to conversion outcomes — not just UX scores. If your internal testing process has outgrown what dogfooding alone can tell you, we’d like to compare notes. Let’s talk

Inkblot Grizzly

Written by

Inkblot Grizzly

Crafting dashboards that tell the truth, and monetisation frameworks that make that truth commercially useful. Turns abstract data assets into revenue-generating products for publishers and brands alike.

Enjoyed this?
Let's talk.

Start a conversation