The Problem Problem

Fri, 24 Apr 2026 01:34:00 +0700

A while back, I was working on building a tax engine system, one that connects accountants and household businesses to help them declare taxes. Near the end of the development cycle, we received feedback from our own accountants’ team. We hadn’t rolled out to external accountants yet; the project was still in its testing-the-waters phase. The request came from the Business Analyst at the time:

“The users cannot export data from our system, so we will need to build an export feature for them.”

Sounds simple? It did, until he requested an export of an entire dataset that had nothing to do with the project domain.

Picture it like this: Project E-Commerce helps users sell. Those sales generate invoices and receipts, which get synced to our Tax-man project. Tax-man only cares about invoices and warehouse movement records. The rest is optional: products? Just the raw data on the invoice is fine; we don’t need attributes or last-7-days sales figures.

But the accountants wanted exactly the same export feature, with the same sheets and the same columns, as the one in Project E-Commerce, implemented in Tax-man. Things were starting to smell off. In his defense, the business analyst was an intern, so it is understandable that his response whenever I pushed back was: “The users want it! It’s a real need; I talked to them directly.”

I might have let that slide. But just a few years of experience had already taught me one thing: users know their pain, not the solution.

After countless back-and-forths: pending tickets, meetings, chats, escalations, near-arguments. The answer came down to one simple question: “Why do they need to export?” The wall cracked. Turns out, the users didn’t trust the data in Tax-man. They saw a number with no breakdown, no context, no way to verify it was even correct. So they fell back on the thing they trusted: Excel.

By that point, we had spent months building for… nothing. We built the system hoping to replace Excel, to push digitalization forward. Instead, it became a glorified data sheet. Users would glance at the calculated numbers, decide they couldn’t trust them, and fall back to doing it themselves.

We had ideas to fix this. But the system was built on the corpse of a previous project, which was itself built on another before it. Each time: temporary, just to save time, we’ll build it properly later. Nothing is more permanent than a temporary solution. With a growing user base and mounting expectations, the rotting foundation couldn’t hold. Would we ever be given time to rebuild, or would we stay stuck forever; firefighting bugs, never moving forward?

It’s a shame I didn’t get the chance to finish that project. It was a good idea serving a real need, but the execution was lacking, and not just in the way I described here. I’m not here to badmouth a former employer. But one lesson stuck: “An idea is just a grain of salt in the sea. Execution is the true whale.” But that’s a story for another day.

Lessons-Learned on Vinh-Phuoc Tran

The Problem Problem