How to Design an E-commerce Platform Together with the Customer

Product Approach and Customer Interviews in Practice

Many e-commerce projects begin with a list of features. The team gathers requirements, creates a backlog, plans sprints and starts development. From a technological perspective, the process appears correct. From a business perspective, however, it often turns out that the platform responds to internal assumptions rather than to real customer behavior.

In 2026, designing a sales platform without the real involvement of the end user is one of the biggest strategic risks. E-commerce is no longer just a transactional system. It is a decision-making environment in which customers make choices under pressure from time, information and alternatives. If the platform does not reflect the real purchasing process, even the best technological architecture will not translate into increased conversion or scalable sales growth.

This is why the product approach and the systematic use of customer interviews are becoming increasingly important as integral parts of the design process, rather than one-time UX exercises conducted at the beginning of implementation.

Why the Traditional Project Approach Is No Longer Sufficient

The traditional implementation model assumes that the company knows what it needs. Product owners, e-commerce managers and marketing teams define requirements based on experience, historical data and inspiration from competitors. A technology agency then translates those requirements into platform architecture and functionality.

The problem is that business requirements are not always aligned with the actual way customers make purchasing decisions. They are often based on assumptions that were valid a few years ago but no longer reflect changes in user behavior, new comparison models or new ways of consuming product content.

As a result, platforms are created that are functionally extensive but misaligned with the user context. They include advanced filters, complex configurators and multiple navigation paths that in practice complicate the purchasing process instead of simplifying it.

The product approach requires a different mindset: the e-commerce platform is treated as a product that undergoes continuous validation, iteration and development based on real user behavior.

What the Product Approach Means in E-commerce

The product approach is not merely a change in terminology. It is a shift in organizational logic. Instead of treating implementation as a project with a defined beginning and end, the platform is treated as a digital product developed in cycles, with clearly defined hypotheses and measurable outcomes.

In practice, this means:

• defining user problems before defining functionalities,
• building the backlog based on customer needs rather than solely internal ideas,
• regularly validating assumptions through interviews and testing,
• designing the architecture in a way that enables iterative changes without
• destabilizing the system.

In this model, technology is not an end in itself. It is a tool for solving specific user problems that have been identified and verified.

Customer Interviews as an Architectural Element, Not Just UX

Customer interviews are often treated as a research phase before a website redesign. In practice, their role should be much broader. Conversations with customers make it possible to understand:

• how the decision-making process actually unfolds,
• at which point uncertainty arises,
• which information is crucial for making a decision,
• which elements of the offer build trust,
• which barriers prevent the completion of a purchase.

This information directly influences the architecture of the platform. It affects category structure, price presentation, configurator models, stock visibility and the way delivery information is displayed.

In B2B projects, the importance of customer interviews is even greater. The purchasing process is often multi-stage, involves several decision-makers and is closely integrated with the customer’s internal systems. Designing such a platform without a real understanding of the buyer’s processes leads to solutions that are formally correct but operationally inconvenient.

Platform Architecture and the Ability to Work with the User

The product approach requires a flexible architecture. If the platform does not allow for rapid iterations, testing new presentation variants, changing content structures or adjusting pricing logic, the organization loses the ability to respond to insights gathered from customer interviews.

For this reason, technology selection matters not only from a functional perspective but also from an operational one. Platforms built on an API-first architecture, with clear separation of layers and a stable extension system, allow changes to be introduced without destabilizing the entire environment. This makes it possible to develop in a controlled, data-driven way rather than through expensive one-off revolutions.

In practice, this also changes the relationship between business and IT. The technology team ceases to be merely an executor of backlog tasks and becomes a partner in defining hypotheses and determining how they should be validated.

From Interview to Product Decision

A key element of the product approach is translating insights from interviews into concrete decisions. Customer interviews cannot end with a report. They must lead to changes in platform structure, product presentation models or purchasing logic.

For example, if interviews reveal that customers compare products primarily based on availability and delivery time, the architecture should clearly and prominently expose this information. If in B2B the key factor is fast reordering, the platform should support shortened purchasing paths instead of forcing users to go through the full process every time.

The product approach therefore consists of building the platform as an environment adapted to real behaviors rather than to a theoretical customer model.

Organizational Consequences of Designing “With the Customer”

Building a platform together with the customer means changing the way teams work. It requires:

• a willingness to question internal assumptions,
• openness to iterative change,
• working with both qualitative and quantitative data,
• close collaboration between business, UX and technology.

It also means that implementation is not the closing stage of a project but the beginning of the next phase of product development. In an environment where user behavior evolves dynamically, the lack of such an approach gradually leads to a loss of competitiveness.

The Platform as a Shared Product

Do not build a platform for the customer. Build it with the customer. This difference is not semantic. It represents a shift in focus from internal assumptions to real user needs. It means designing an architecture that enables continuous learning and adaptation. It means treating e-commerce as a product that evolves together with the market.

At CREHLER, we work with organizations that want to build sales platforms based on a product approach and real market data, rather than solely on a list of functionalities. If you are planning to implement or further develop your e-commerce platform and want your decisions to be grounded in actual customer behavior, we invite you to a consultation. Together, we will analyze your architecture, processes and ways of working to create a sales environment that scales together with your business.