When We Talk About FDE, What Exactly Are We Talking About?
In the article "Chinese-Style FDE Is Doomed to Fail," I conducted an industry analysis of FDE, which drew some attention.
In the comment section below, I saw all kinds of discussions about how to do FDE. Some talked about needing business acumen, some about technical capability, and some about being tough and resilient. In short, mastering all eighteen martial arts, covering everything from mountains to seas, capable of reaching the heavens and diving into the earth. If you put all these discussions together, it's probably the most complete career competency evaluation index for FDEs today.
Rarely does anyone talk about the business itself.
Actually, in that article, I used FDE to tell a story about the client-vendor relationship in China, and the template for that story comes from the awkward position the SaaS market has been in for years. The reason I believe FDE is doomed to fail is precisely because this model has not broken through the client-vendor business relationship of the SaaS era.
The biggest problem with a strong client and a weak vendor is that the client naturally holds the power to define the problem. But FDE happens to be a model that is highly dependent on the power to define the business. If you can only accept whatever the client decides on a whim, then no matter how well FDE understands the business, how strong the technical skills, or how hard they can work, in the end it's just piece-rate or hourly outsourcing.
So seeing the comment section buzzing with discussions about what capabilities FDE should have actually strikes me as particularly interesting.
I've noticed that every time a new trendy concept comes out, we can quickly find a dozen ways to do it well.
Yet very few people stop to ask first, why do it?
Technical discussions can't solve real-world problems.

Engineers are best at solving problems, but in real business scenarios, many truly important issues aren't execution problems at all—they're direction problems.
For example, when a product's DAU or MRR numbers look bad, we easily start researching how to change the interaction design, how to optimize the process, whether to add more features, yet we rarely start from demand and answer the most basic question: "What do users actually need?"
The more we discuss, the more polished the solution becomes, but the further we drift from the real problem.
I work with quite a few small and medium-sized enterprises, and when many SMEs run into operational difficulties, there's rarely just one cause. It's usually a tangle of issues—orders, production, branding, team management—all intertwined, making it impossible to attribute the problem to a single quantifiable metric.
Technical discussions very easily exclude the many non-quantifiable problems from the scope of discussion. Don't understand branding? Skip it. Management requires PR work; drinking hurts the liver and it's troublesome, so skip it. Product marketing looks unprofessional, can't do it, skip it.
So in the end, all you can do is hammer away relentlessly at the production side. And FDE happens to require engineers to define the problem, which creates a very subtle deviation.
When engineers start identifying problems for a company, the easiest things to see, the easiest to quantify, and the easiest way to prove value are, of course, efficiency, processes, automation, and the like. So in the end, FDE can easily retranslate "what exactly is wrong with this company" into "where else can we improve efficiency."
This is a perfectly reasonable logic, and even in many of our discussions about FDE, the biggest focus is on how to use AI to improve efficiency. After all, that's what they're doing abroad, so why wouldn't we do the same?
We really shouldn't do that.
China and beyond China—it's a different kind of trial by fire.

Abroad, it makes a lot of sense for companies to use AI to improve production efficiency. Because the problem many companies face is that labor is too expensive, time is insufficient, and things can't move forward quickly.
Many mature overseas companies already have stable products and markets—what they lack is good employees who actually want to come to work.
Using coding agents to let programmers write less code and take on more projects, using office agents to help sales teams write emails and organize materials so they can spend more energy on clients—these are all highly valuable scenarios. Because for them, the hardest part is getting employees to do more.
So they have plenty of motivation to shift large amounts of work from human labor to automation.
In contrast, the thing Chinese companies have never lacked in the past few decades is the ability to get things done quickly, well, and economically.
The problem many Chinese companies face isn't that employees work too slowly, but rather what to do once the product is made. It's about how to build brand recognition, how to break free from dependence on a single client, how to expand the business into other areas—it's about answering the question "why should anyone choose me over anyone else?"
At the end of the day, it's a demand problem.
We copied someone else's methodology, then copy-pasted someone else's problems onto ourselves. We're using FDE to solve a problem that doesn't exist.
Create more valuable increments.

Back when real estate was raking in money, the old-timers would take one puff of a cigarette and toss it away, calling it self-care. It's the same for businesses—as long as profits keep flowing, efficiency is never the real problem; it's just a necessary cost of production.
Being able to compress efficiency from 10 hours down to 2 hours is indeed quite impressive. But when 10 hours already gives you a significant lead over competitors, the marginal business value of further compressing from 10 hours to 2 is limited.
Where FDE truly creates value is in helping companies discover pain points in their operations and solving those pain points with technical means, with AI being a very useful tool in that process. That's what I understand FDE to be—not about various personnel evaluation metrics or implementation methods, but about whether it is driven by demand.
The dilemma of SaaS still exists in the AI era, because our mainstream corporate culture is rule by people, where permission control matters more than process optimization, and relationship coordination matters more than factor management. This means that if FDE focuses on optimizing existing business, it will quickly hit organizational boundaries.
Change the process? But who's willing to give up authority? Rebuild the system? But which department is willing to change its existing interest structure? Instead of squeezing out a few percentage points of efficiency within rigid processes, it's better to create increments in new business.
Who says a housekeeping company can only make money from cleaning? Wouldn't selling data to a robotics company earn even more? It just depends on whether you dare to think big enough.