Can a Company Without Its Own Product Still Have FDEs?

Lately, I have been thinking about a question: can a company without a product of its own have genuine FDEs?

My answer is yes, but the conditions may be more demanding than they are for a product company.

It is not enough simply to say that you “start with the customer’s problem.” Traditional consultancies, SIers, and outsourcing teams can all say the same. If every customer’s problem ultimately becomes a separately scoped, developed, and maintained project, calling the work FDE does not change its nature.

What truly distinguishes FDE is not just that engineers go on-site with customers. It is that field delivery changes how the organization solves the next problem.

FDEs at product companies have one clear advantage: they already have a familiar, condensed set of capabilities at hand. Their own platform may already have handled much of the difficult work around permissions, data integration, model calls, deployment, and monitoring. They do not have to start by laying the foundation and can spend their time on what is genuinely unique about the customer.

An SIer can gain the same capabilities through platforms from different vendors, but that places even greater demands on its FDEs. They must know not only what each platform can do, but where its boundaries lie, when to choose which one, how to combine them, and when none of them should be used.

But a product also exerts a kind of gravity.

A customer says its sales operation is inefficient. Investigation may reveal that approvals take too long, that its CRM data is a mess, or simply that two systems are missing an ordinary piece of synchronization code. AI may not help, much less an Agent.

Yet when the FDE comes from an Agent company, the question can easily and imperceptibly become: how can we solve this with our Agent?

The danger is not that engineers have hammers. Every engineer has familiar tools and technical preferences. The real danger is that the organization embeds its goal of selling hammers into the diagnosis, reducing what was originally an open question to a single class of answers before the investigation even begins.

When the product is not right for this customer, does the FDE have both the ability and the organizational permission to set it aside?

If the answer is no, then the FDE’s responsibility for the customer’s problem is actually quite limited. The role is closer to that of a highly capable product implementer. That role is certainly valuable, but it is still some distance from what I understand FDE to be.

At the same time, pursuing a “completely neutral technology choice” is not realistic either.

Without product constraints, the theoretical solution space is indeed larger. A team can change a process, write code, combine SaaS products, or choose among different models and open-source components. But a larger solution space does not automatically produce better judgment. It can also lead to another familiar outcome: every problem appears to deserve a custom solution.

The work is done once for the first customer, then done again for the second by a different group of people. Projects are delivered and revenue grows, but the organization’s cost of solving the next problem does not fall. Experience remains in an engineer’s head, code is locked inside the customer’s repository, and the maintenance burden grows with every project.

At that point, the work still looks more like project-based services than FDE.

Making the system improve as it is used should be an outcome of FDE, but it is not enough to define FDE. Strong product and platform teams can also improve systems continuously, while consultancies can accumulate methods, templates, and components. More troublingly, an architecture can make a team increasingly efficient at forcing every problem into the same kind of solution. Compounding amplifies capability, but it also amplifies errors in judgment.

What makes FDE more distinctive is the presence of two feedback loops at once.

The first is the loop at the customer site. What an FDE receives is usually not a well-formed requirement, but a vague complaint: “We are too inefficient,” “This thing is hard to use,” or “Can AI help us?” The FDE has to turn that statement back into a testable problem, identify the process that should change, the software that should be written, and the things that should not be done, put the solution into a real environment, and continue refining it based on actual use.

The second is the organizational learning loop. After a delivery ends, the organization must extract what the field has validated from the customer project, carry it into the next delivery, and see whether it still holds.

What accumulates does not have to become a complete product right away. It may be only a permission model, a data interface contract, a reusable component, a set of evaluation cases, or an architectural judgment validated across multiple customer environments.

Architecture is one way to carry this learning, but it is not the only source of compounding. Some requirements are inherently local, and forcing them into the platform would only contaminate the product. Some projects cannot contribute reusable code but can leave behind evaluation methods, failure modes, and judgment about when something should not be done. The real challenge is distinguishing which things are unique to one customer, which have begun to recur, and which reveal a general capability missing from the platform.

For a company without a product of its own, the second loop is especially important. It cannot prove on its own that the team is doing FDE, but it can show that the team is not starting over with every project. The condition is that something can actually be transferred between those projects. If the team faces an entirely different problem every time, the supposed compounding can easily amount to nothing more than a vague methodology.

The Platform–Delivery Flywheel does not define the FDE role. It describes the result produced by the two loops together: when facing a similar problem, is the next delivery faster, more reliable, or at least burdened by fewer unknowns?

This requires more than engineering capability. The organization must also give FDE enough authority to make technical decisions, and someone must be responsible for extracting field experience from customer projects. Otherwise, “learning” is only a pleasant-sounding claim, and nothing has changed when the project ends.

From this perspective, product and FDE do not have a simple sequential relationship.

Some companies build a product first, then have FDE bring it into complex customer environments. The problems exposed in the field continue to reshape the product’s boundaries.

Other teams may begin with open-ended problems, gradually develop shared components and platform capabilities across multiple deliveries, and only then arrive at a product.

Both paths are valid. What truly connects product and FDE is whether field experience flows back into the organization, not whether the company begins with a product it can sell.

If every deployment only consumes engineering capacity, FDE eventually degenerates into expensive outsourcing. If every problem has to prove the value of the company’s own product, FDE instead degenerates into sales with delivery capabilities.

The hammer itself is not the problem. The real test is whether you are entitled to judge that what lies before you is not a nail—and whether, after setting down the hammer, you are more capable the next time than you were this time.