Over the past decade, eCommerce has moved from being an alternative sales channel to becoming part of everyday life. Cloud platforms have lowered the barrier to entry, marketplaces have reshaped retail, privacy regulations have expanded, and artificial intelligence is beginning to change how people search for and buy products.
Yet one thing has remained remarkably consistent: businesses still need technology that solves real problems.
Ivan, Product Manager at CS-Cart
Ivan joined CS-Cart as a technical writer more than ten years ago. Over time, his responsibilities expanded from documentation and interface texts to customer research, product requirements, release planning, and overseeing features throughout development and testing. Today, he works as a Product Manager at CS-Cart.
We spoke with Ivan about how customer requests become product features, why apparently simple improvements can take months to develop, and how an established eCommerce platform balances innovation with stability.
The Market Changed More Than Customer Needs
When Ivan started working at CS-Cart, online shopping was already developing rapidly, but many of the technologies and business models that now appear standard were still emerging.
Since then, cloud services have made it easier to launch digital products without configuring infrastructure, privacy regulations have become a major consideration in software development, and marketplaces have evolved into a dominant eCommerce model.
At the same time, merchants have started looking beyond large third-party platforms. Many want to build independent sales channels and develop direct relationships with their customers.
We have seen both growing demand for niche marketplaces and more sellers investing in their own websites because they do not want to keep all their eggs in one basket.
— Ivan, Product Manager at CS-Cart
Learn more: 4 Technical Approaches to Launching a Niche Marketplace
Despite these shifts, the requests that reach the product team have not changed as dramatically as the market itself.
Customer requests have not changed as much as the market has. Businesses still come to us because they need to solve a specific problem.
— Ivan, Product Manager at CS-Cart
Calendar for selecting available pickup dates and time slots on the Choplocal platform
That problem may involve changing a small element of the storefront, introducing a new business model such as hourly or daily bookings, complying with legislation, or connecting the platform to another service.
Technologies and expectations evolve, but customers rarely ask for innovation simply because it is new. They want a practical solution to a commercial or operational challenge.
Who Really Shapes an eCommerce Product?
A mature eCommerce platform is influenced by many groups: customers, developers, partners, sales teams, support specialists, marketers, and product managers.
Their roles are different, but they form a single feedback chain.
Sales and marketing teams see what prospective customers are looking for. Support teams understand the problems experienced by companies already using the platform. Technology partners contribute both development expertise and feedback from the customers they work with. Developers and product managers then evaluate what can and should be implemented.
Sales and marketing show us what prospective customers are interested in, while support tells us what matters to existing customers. Both perspectives are equally important.
— Ivan, Product Manager at CS-Cart
Users ultimately have the greatest influence because most product decisions begin with a need identified through customer behavior, data, or a direct request. However, this influence is not always immediately visible.
A request may be specific to one industry. Several customers may describe the same underlying problem in completely different ways. A valuable idea may also have to wait while the team works on security, compatibility, legislation, or improvements that affect a larger share of users.
Ultimately, users have the greatest influence on the product, even if that influence is indirect and may not always be visible to them.
— Ivan, Product Manager at CS-Cart
Learn more from: How to Write a Software Requirement Specification to Save Costs?
From a Customer Request to a Product Feature
It would be convenient if product development were simply a matter of counting requests: once 100 customers ask for something, the feature goes into development.
In practice, the number of requests is only one part of the decision.
The product team must determine what problem customers are trying to solve, how many businesses experience it, whether it represents a common need or a specialized case, and how the proposed change will affect the rest of the platform.
The team also evaluates implementation complexity. A seemingly small request may require changes to the architecture or to several connected areas of the product.
The number of requests matters, but many other factors affect the final decision: how well we understand the problem, how many customers will benefit, and whether the change requires us to redesign an entire area of the product.
— Ivan, Product Manager at CS-Cart
Read more: eCommerce Website Requirements: How to Define Functional and Business Requirements
CS-Cart records customer requests with links to the original conversations. When the team begins researching a feature, the Product Manager returns to this history to study the situations described by customers.
If you requested a feature—even several years ago—your feedback will most likely be reviewed when we begin working on that area.
— Ivan, Product Manager at CS-Cart
This is also why a detailed use case is more useful than a short request to “add a feature.” The product team needs to understand the desired result, not only the solution proposed by the customer.
Why Context Can Matter More Than Volume
The version 4.21.1 of CS-Cart introduced editabe vendor promotion conditions
The new vendor condition for catalog promotions illustrates how this process works. Marketplace administrators wanted to create promotions based on the seller to whom a product belonged. If customers had only requested “a vendor condition for promotions,” the scope would have remained broad: CS-Cart has both catalog promotions and cart promotions, and adding the condition to the latter would have required significantly more work.
Fortunately, customers included practical scenarios in their requests. One recurring example was a discount on all products except those offered by particular vendors.
By reviewing these situations, the team determined that adding the Vendor condition to catalog promotions would solve more than half of the recorded requests without introducing a large, potentially disruptive change.
The remaining scenarios were not forgotten. They were separated from the part of the problem that could be addressed safely and sooner.
Customers do not just ask for features. The details of the situations they describe often determine what we can deliver first.
— Ivan, Product Manager at CS-Cart
This approach does not always produce the broadest possible feature in the first iteration. Instead, it allows the team to deliver tangible value while continuing to research the more complex scenarios.
Why Useful Features Still Have to Wait
Not every valuable request can become part of the next release. The number of potential improvements will always exceed a development team’s available capacity.
There are always more tasks than the team has the capacity to complete. We have to decide what to work on now and what to postpone.
— Ivan, Product Manager at CS-Cart
Priorities may also change because of circumstances outside the company. New privacy requirements may appear. A supported PHP version may approach the end of its security maintenance period. A payment or delivery provider may release a new API.
Some external integrations are difficult to implement even when their functionality appears straightforward. For example, a service might not provide public technical documentation or a testing environment. Without these resources, the platform team cannot reliably test what customers will experience.
In one such case, CS-Cart contacted an international delivery service that did not offer public developer documentation. The company redirected the team to its official integrators, making a direct integration impractical at the time.
Sometimes it is better to stop knocking on a closed door and use that time to explore several open ones—especially when there are many doors you will eventually need to enter.
— Ivan, Product Manager at CS-Cart
The decision to postpone an integration does not necessarily mean that it lacks value. It may mean that another project can currently provide greater value with fewer external dependencies.
Why “Simple” Features Are Rarely Simple
From the user’s perspective, a product update may appear to add one checkbox, field, or promotion condition. Behind that interface change may be several stages of analysis, development, testing, documentation, and release preparation.
The complexity becomes greater when a feature is connected to the platform’s core business logic. A change to products, orders, payments, or vendor accounting can affect many other functions.
Updating an existing mechanism is often more difficult than creating a completely new one. The team must plan how current stores will move from the old behavior to the new behavior.
When you improve an existing feature, you also have to plan the migration from the old mechanism to the new one so that users are not required to perform additional work after an update.
— Ivan, Product Manager at CS-Cart
This work is largely invisible when it succeeds. A merchant installs an update, existing data remains available, and the store continues operating. The absence of disruption can make the underlying engineering effort easy to underestimate.
Innovation Without Disrupting Existing Businesses
Backward compatibility is especially important for an established platform. CS-Cart projects may use custom functionality, third-party add-ons, individual themes, and integrations with external business systems.
A change that improves the platform for new installations could create significant costs for existing businesses if it unexpectedly breaks those customizations.
We pay a great deal of attention to backward compatibility so that partners do not have to rebuild their add-ons and themes after every release.
— Ivan, Product Manager at CS-Cart
Absolute compatibility cannot be guaranteed forever. Some improvements eventually require changes that affect existing extensions or custom code. When that happens, partners need advance information, developer documentation, and enough time to test their solutions with the upcoming version.
The value of a large change must justify this transition.
Any large-scale change can be introduced if users and partners are given enough time to adapt. But it should deliver real value—not simply rebuild the product for the sake of rebuilding it.
— Ivan, Product Manager at CS-Cart
This also explains why rewriting a mature platform from scratch is rarely as simple as it sounds. Starting again can appear attractive because the limitations of the existing system are already known. But a complete rewrite also means recreating years of accumulated business logic and solving migration and compatibility problems on a much larger scale.
Starting from scratch may appear easier because you already know the problems in the existing system. But rebuilding something differently is not always the faster or better decision.
— Ivan, Product Manager at CS-Cart
One Commerce Foundation, Different Local Requirements
The fundamental needs of online businesses are similar across countries. Merchants need to manage products, process orders, accept payments, organize delivery, communicate with customers, and analyze performance.
The differences become apparent in the details: payment providers, shipping companies, tax rules, privacy laws, fiscal requirements, and mandatory product information.
People everywhere want a product that solves their problems well—preferably out of the box. The fundamental needs are similar across markets; the differences are mainly in payments, shipping, and legal requirements.
— Ivan, Product Manager at CS-Cart
A feature introduced in response to a regional regulation can also be valuable elsewhere.
We helped our client with his Kayamo project in adapting GDPR checkbox appearance on the check-out page
For example, European requirements may oblige retailers to show a unit price alongside the total product price. If two perfume bottles contain different volumes, displaying a calculated price per 100 milliliters makes comparison easier. Even where the law does not require this information, it still improves the customer experience.
Privacy provides another example. Requirements that initially appeared highly specific to individual jurisdictions increasingly share common principles: informing users, requesting consent, recording their choices, and giving them control over personal data.
This creates an opportunity to build a common product foundation while adapting its implementation to different markets.
Extensibility Matters More Than Any Single Integration
Ready-made integrations reduce the time required to launch and operate an online business. However, no platform can include every payment, delivery, ERP, accounting, or marketing service used in every country and industry.
A platform therefore needs more than a long list of integrations. It needs a foundation that allows businesses and development partners to create new ones.
Out-of-the-box integrations make life easier, but the product itself is about creating a foundation for business processes.
— Ivan, Product Manager at CS-Cart
Access to APIs and source code gives businesses more options when their requirements extend beyond standard functionality. It also makes the platform more adaptable when new services, channels, and technologies emerge.
That adaptability is becoming particularly relevant as eCommerce enters its next technological transition.
AI Is the Next Platform Shift, Not Just Another Feature
AI is often introduced into eCommerce products through highly visible features: a button for generating a product description, creating an image, or rewriting marketing copy.
These tools can be useful, but their presence does not automatically make a commerce platform ready for AI.
Learn more from: AI in eCommerce: How Artificial Intelligence Is Transforming Online Shopping
Adding AI features just to make the product look modern is a trend I would question. Before introducing a feature, you need to understand who needs it, how it improves their work, and how often they will actually use it.
— Ivan, Product Manager at CS-Cart
More valuable applications use the actual context and data of a business. An AI system could review descriptions recently uploaded by a particular marketplace vendor. It could generate a promotional banner using the best-selling product in a selected category. It could help create an integration, analyze catalog data, or automate a specific operational process.
To support such scenarios, AI needs access to reliable information, business logic, and appropriate interfaces.
Instead of starting with isolated AI features, platforms should first make it easy to connect AI to the entire system.
— Ivan, Product Manager at CS-Cart
Existing website infrastructure remains relevant as well. AI systems need clear, current, machine-readable information. Structured data such as JSON-LD, metadata such as Open Graph, accessible pages, and resources such as llms.txt can help systems interpret a website and identify important content.
Read more: What Is GEO? How to Optimize Your eCommerce Website for AI Search
In the longer term, AI may change not only individual workflows but also the interface through which people interact with online commerce.
An LLM could become the primary interface through which buyers receive information from one or several sellers—and through which merchants manage their stores.
— Ivan, Product Manager at CS-Cart
The degree of autonomy may vary. One merchant might use AI only for recommendations, while another allows an agent to complete routine operations. Buyers may continue visiting storefronts, or they may increasingly ask personal AI assistants to compare products and interact with multiple stores on their behalf.
Whatever model becomes dominant, commerce platforms will need to provide AI systems with accurate data while preserving access to the original information so that people can verify the results.
An eCommerce Platform Is Never Finished
Product development is not a straight path from one feature request to the next. It is a continuous process of interpreting customer needs, responding to market changes, managing technical dependencies, and deciding which improvements will create the most value.
Over the past decade, CS-Cart has had to adapt to the growth of marketplaces, cloud services, new regulations, changing integrations, and now artificial intelligence. Each shift introduces new requirements, but the underlying product principle remains the same: technology must solve real business problems without unnecessarily disrupting the businesses that already depend on it.
A mature platform is therefore not one that has accumulated the largest number of features. It is one that can continue evolving while preserving the flexibility, stability, and control its customers need.
eCommerce expert with 10+ years of experience in marketplace management and consumer behavior. Gayane tracks the latest industry trends to provide businesses with analytical, actionable insights.
