A CEO at a mid-sized enterprise SaaS company recently described a situation that would have sounded unusual not long ago, but is starting to feel increasingly relevant.
One of their largest customers had asked for a specific new feature which would help their workflow, the kind of request that was clearly valuable to the customer but not necessarily important enough to jump it to the top of the roadmap.
As usually happens in enterprise software, the request needed to move through business and product discussions, design work, engineering prioritization, testing cycles and security reviews before anyone could even commit to a timeline.
The customer understood that. But after waiting for some time, it raised a different possibility: Rather than continue waiting for the vendor to ship the feature, it was considering using AI coding tools internally to build something themselves that would solve the problem well enough.
That single comment reflects a broader shift that SaaS companies are only beginning to fully absorb as their stock prices take a hit, precisely because of this sentiment.
For years, a feature request was a request to the vendor. It entered the backlog, competed with other priorities, and if the customer was important enough or the use case broad enough, eventually it would make its way into the product.
That logic is now starting to weaken. If customers can increasingly generate narrow workflows, lightweight internal tools or customized interfaces on their own, the role of the traditional feature begins to change. And once that happens, it is worth asking a deeper question: Will features even exist in the way the software industry has historically understood them?
Features were once the product
For decades, SaaS companies built value through predefined functionality. A roadmap was essentially a sequence of decisions about which features to build, which customer pain points to prioritize, and how quickly the product team could turn demand into software.
In many categories, feature depth and feature velocity became the core of competitive differentiation. The company that could ship faster, cover more use cases, and respond more effectively to customer requests often had the advantage.
That model made sense in a world where software creation was expensive, slow and highly constrained by engineering capacity. A feature had weight because it represented significant investment. It required planning, development, quality assurance, release management and support. Customers understood that process because there was no real alternative. If they needed something badly enough, they could ask for it, pay for customization, or wait.
AI-assisted development begins to change that equation. When internal teams can describe a workflow and generate a usable version of it in days rather than quarters, the meaning of a feature starts to erode — not because functionality is no longer important, but because it no longer has to arrive in the same packaged form.
In some cases, customers may not need the vendor to build every layer of functionality for them. They may only need enough access, flexibility and context to shape part of it themselves.
Functionality may become something dynamic
The real question may not be whether AI will help SaaS companies build features faster, although it clearly will. The more important question is whether the concept of a feature as a fixed unit of product development starts to fade.
For many years, teams gathered requests, translated them into product requirements, scheduled them into roadmaps, and released them as standardized functionality for a broad user base. That process may increasingly look inefficient in a world where software can be generated more dynamically.
In an AI-native environment, the customer may not ask for a feature in the traditional sense at all. They may simply describe the workflow they need, the output they want, the approvals required, the data sources involved, and the rules that should govern the process. The platform could then generate that capability inside the product environment rather than waiting for a formal release cycle. In that scenario, functionality becomes more fluid.
That would represent a meaningful shift in how enterprise software is defined. The feature would no longer be the product’s smallest strategic building block. Instead, the platform would provide an environment in which functionality can be created, modified and governed with greater flexibility.
This matters because it changes where value sits. If the workflow can be generated on demand, then the defensibility does not lie in the isolated feature itself. Rather, it lies in the system that makes that generation possible in a secure, reliable and scalable way.
The platform becomes the real moat
This is also why AI is unlikely to simply make serious SaaS platforms irrelevant. Even when a workflow can be generated quickly, it still needs to operate inside a much larger enterprise reality. It must connect to structured data, respect access controls, interact with existing systems, produce auditable outputs, comply with security policies, and function with a level of reliability that internal experiments rarely match on their own. These are not minor details. In many enterprise environments, they are the actual product.
Itay Sagie is a strategic adviser to tech companies and investors, specializing in strategy, growth and M&A, a guest contributor to Crunchbase News, and a seasoned lecturer. Learn more about his advisory services, lectures and courses at SagieCapital.com. Connect with him on LinkedIn for further insights and discussions.
Related reading:
Illustration: Dom Guzman
Stay up to date with recent funding rounds, acquisitions, and more with the
Crunchbase Daily.
