1. The contradiction
2. The bridge
3. Why judgment matters
4. Macro, meso, micro
5. Micro: the touchpoint level
6. Meso: the journey level
7. Macro: the strategic level
8. Reflection
Methodology
Not every product problem needs Design Thinking. Here’s how I manage complex work, from the big picture to the smallest detail
I promise this is not another Design Thinking (DT) is dead article. We are all tired of those!
This is about my relationship with methodology and working process, even with DT or any textbook or practical way to get things done.
About Kilo
- One of the first apps in Vietnam, alongside VinShop, serving 10K+ mom-and-pop stores to manage their business;
- I worked closely with founder Kartick Narayan from day zero through the full product lifecycle to exit (2019–2023), translating his big-picture vision into a launched product that scaled to its peak.
1. The contradiction
As a senior manager who has worked across many teams and alongside 1K+ practitioners, I keep noticing the same contradictions between how we think and how we act:
- We admire people who read widely and we secretly hunt for some bestseller that promises to fill the void in our minds, yet on the job we call ourselves pragmatic then wave books off as theory.
- Similarly, we roll our eyes at frameworks, then reach for whichever one looks trendy and run it blind.
Let me zoom in on Design Thinking (DT), and when I say DT here I mean the whole family it spawned (design sprints, double diamond, and the workshop formats built on the same logic). Our industry ran it for years, and the workshop photos made it to LinkedIn far more often than the decisions did. When I asked dozens of practitioners which decisions actually came out of those sessions, few could name one.
What you may already sense is that DT is only the loudest example of a pattern that cuts across most frameworks we touch. If we keep living with this contradiction, we all lose in the long run.
Kartick walked me through how commerce actually worked in Vietnam, in business and product terms, and where Kilo’s vision had to land. That sketch became the framework for every conversation after.
→ A framework is not a complex formula from the textbook. It is a shared way of working, defined clearly enough that the people doing the work can align on a goal.
2. The bridge
I believe there is a saner approach — a two-way bridge that holds a middle position with no contempt for frameworks and no blind devotion either.
- Read widely to understand the nuance real problems carry, then live the work and see what holds and what breaks. Over time, we learn which books to trust for which situations.
- Learn frameworks well enough to know which problem each one answers. When we face a real one, we adjust the method to the resources we have and the outcome the project needs. Real expertise is knowing the framework is a tool, not a script.
Which brings me to the claim in the title: Not every product problem needs DT, because most of our industry has run frameworks blind for so long that it now resents frameworks altogether.
3. Why judgment matters
To see why judgment matters, look at what AI did to DT.
DT and its whole family are mental models for innovation, built for one specific moment when technology was opening up and startups were everywhere. Back then, shipping a real product was still expensive so the most common way to fail back then was overconfidence.[2]
But DT does not fit the work I actually do, for two reasons:
1. In Southeast Asia (SEA), innovation and disruption sound like industry clichés.
Real innovation is rare, and most of our work here is execution, maintenance, and calibration, solving the same problems as they come back around. Our industry rewards execution over invention.
2. In the AI era (of course, insanely), DT lost its reason to exist at full scale.
The whole logic of DT rested on one condition, that building was brutally expensive and could swallow months before anyone saw a result. Now AI broke that condition. A new phase of the industry cannot run on a framework built for the old one.