How LLMs Are Dissolving the Boundary Between Product and Professional Services
English
For the past thirty years, there have been domains that software simply could not reach. Per-customer processing logic, operations that depend on tacit knowledge, local rules that vary by organization. In domains with this much variability, traditional software could not be made to work economically. The reason was simple: you could not standardize.
So humans filled the gap — and kept filling it. That structure has not changed in three decades.
Traditional software scaled by unifying inputs, standardizing operations, and locking down workflows. Large-scale deployment only became possible when enterprises agreed to reshape themselves around the software's assumptions. Which means that any domain that could not meet those assumptions was out of scope from the start.
LLMs are beginning to change that. LLMs understand context, absorb ambiguity, and handle variability. One company writes "NVY," another writes "Navy Blue," a third writes "ネイビー" — and an LLM treats all three as the same thing. What once required mountains of rules, mapping tables, and human intervention can now be absorbed on the LLM side. That is a significant shift.
Beyond individual judgments, agentic processes are now making it possible to run multi-step business workflows end-to-end with a reasonable degree of reliability. This matters. Even if an LLM can absorb a single decision, as long as a human has to step in somewhere to stitch the process together, the gain is limited. Reliable agentic execution is what makes it possible to actually push the boundary of what can be turned into software.
What LLMs changed is not just individual decisions — it is the underlying structure. The old model was two layers: a rule-based system, and humans bending themselves to fit it. LLMs insert a new layer in between, absorbing variability from the real world and passing it to the system in a form it can handle. Instead of people adapting to the software, the software reaches toward people. That new layer is what allows software to finally enter domains it could never reach before.
How that bridge layer gets built and evolved has become the core of competitive advantage. Which parts should be delegated to an LLM, and which require human judgment? Which exceptions can be absorbed, and which expose a need to change the underlying rules? Answering those questions continuously is what defines the product's frontier — and that frontier is only visible from the field.
This is what is fundamentally changing the relationship between Product and Professional Services.
In the traditional software company, the Product team defined the rules — what gets handled and how — and distributed them outward. Professional Services lived on the outside, adapting the product to fit the customer. Knowledge flowed in one direction: from the product organization out to the field.
In the LLM era, that direction reverses. The field is what reveals how far software can reach. What kinds of exceptions exist? Where does inference fail? Which operations are generalizable, and where does customer-specific logic begin? This knowledge only emerges from actual operations — from failures, edge cases, and evaluation loops in real deployments. The interaction with the field grows the product's rules and drives its evolution.
That is why the FDE — Forward Deployed Engineer — becomes important. An FDE is not a deployment consultant. The role is to convert the variability encountered in the field into reusable form, and to continuously push forward the boundary of what can be made into software. This loop is only possible because of LLMs. Without them, the cost of translating field variability back into a product was too high for the loop to turn.
AI-native software companies going forward will not be companies that distribute finished features. They will be companies that keep learning from variability in the field — and keep expanding the frontier of what software can cover.
日本語 {#japanese}
この30年間、ソフトウェアが届かなかった領域がある。取引先ごとの個別処理、暗黙知に依存した運用、組織ごとのローカルルール。こうしたばらつきが多い領域では、従来のソフトウェアは経済的に成立できなかった。標準化できなかったからだ。結果として、そのギャップをずっと人間が埋めてきた。
従来のソフトウェアがスケールするためには、入力を統一し、運用を標準化し、ワークフローを固定する必要があった。企業側がソフトウェアの前提に合わせることではじめて大規模展開が可能になっていた。裏を返せば、その前提に合わない領域は最初からソフトウェアの射程外だった。
LLMはその構造を変え始めている。LLMは文脈を理解し、曖昧さを吸収し、ばらつきに対応できる。ある会社はNVYと書き、別の会社はNavy Blueと書き、さらに別の会社はネイビーと書いていたとしても、LLMはそれらを同じ意味として扱える。従来なら大量のルールやマッピングテーブル、人手による運用調整が必要だったものを、LLM側が吸収できるようになった。
さらに、Agenticなプロセスによって、単発の判断だけでなく複数ステップにまたがる業務プロセスを、ある程度の信頼性を持って回せるようになってきた。これは重要な変化だ。LLMが判断を吸収できても、プロセス全体を通しで動かせなければ、人間の介在はなくならない。Agenticな信頼性が出てきたことではじめて、ソフトウェア化できる領域の境界を実際に押し広げていくことが可能になる。
LLMが変えたのは、個々の判断だけではない。構造そのものが変わった。従来は、ルール通りに動くシステムと、それに合わせようとする人間の二層だった。LLMはその間に入り込み、現場のばらつきを吸収してシステムへ渡す橋渡し役を担う。人間がシステムに合わせるのではなく、LLMが人間の側に寄り添う。この層が生まれたことで、これまでソフトウェアが届かなかった領域に、はじめて手が届くようになった。
この橋渡しの層をどう作り、どう育てるかが、プロダクトの競争力そのものになった。どこをLLMに委ね、どこは人間が判断すべきか。どの例外は吸収できて、どこから先はシステム側のルールを変える必要があるのか。この問いに答え続けることがプロダクトの最前線を形作る。そして、その最前線は現場でしか見えない。この変化が、ProductとProfessional Serviceの関係を根本から変えつつある。
従来のソフトウェア会社では、Product Teamが「何を・どう扱うか」のルールを決め、それを現場へ配布していた。Professional Serviceはその外側にいて、既存のプロダクトを顧客に合わせる役割だった。知識の流れは、プロダクト側から現場へ向かう一方通行だった。
LLM時代では、この向きが逆になる。現場のばらつきを観察することではじめて、どこまでをソフトウェア化できるかが見えてくる。どのような例外が存在するのか。どこで推論が失敗するのか。どの運用は再利用可能で、どこから先は顧客固有なのか。こうした知識は実際の運用、失敗、例外処理、評価ループの中からしか得られない。現場との相互作用そのものが、プロダクトのルールを育て、進化につながる。
だからFDE（Forward Deployed Engineer）が重要になる。FDEは導入支援ではない。現場で得たばらつきの知識を再利用可能な形に変換し、ソフトウェア化できる領域の前線を引き直し続ける役割だ。LLMがあるからこそ、このループが成立する。LLMがなければ、現場のばらつきをプロダクトに戻すコストが高すぎて、ループは回らなかった。
今後のAI-nativeなソフトウェア会社は、完成済みの機能を配布する会社というよりも、現場のばらつきを学習し続けながら、どこまでをソフトウェア化できるかを押し広げていく会社になっていくはずだ。