Using customer evidence to reposition an ecommerce platform

The need

Work out what problem the company should really be known for solving

The company had established itself as a frontend technology for ecommerce, but both its product and the market around it were changing.

Its technology could play a broader role in complex enterprise commerce environments, allowing companies to modernize the customer-facing frontend while continuing to use established backend systems.

The technical argument made sense internally. The question was whether it reflected the problems enterprise customers actually experienced.

Before broadening the company's proposition, the team needed evidence about where incumbent commerce environments created friction, what customers valued about more modular approaches and how those issues differed between technical and business audiences.

The starting point

A strong product hypothesis that needed to be tested against the market

Enterprise ecommerce customers had already invested heavily in platforms, integrations, development teams and surrounding technologies.

Moving toward composable commerce meant weighing flexibility and speed against migration risk, integration complexity, existing investment and the organization's own ability to operate a more modular stack.

The company needed to understand those trade-offs from the perspective of the organizations it wanted to reach rather than build its repositioning around architectural theory.

What we did

Researched the friction behind enterprise commerce decisions

We designed a bespoke quantitative study around 200 verified SAP Commerce users.

The research examined how SAP Commerce Cloud fitted into organizations' wider technology environments, including integration, content-management experiences and dependency on developers for changes.

It then moved into the architectural choices facing those organizations: attitudes toward separating frontend and backend systems, perceptions of composable versus monolithic approaches and the advantages and risks customers associated with greater modularity.

We also explored where teams were spending time and money maintaining standard ecommerce capabilities rather than creating something distinctive for customers.

The analysis looked beyond overall satisfaction. We examined needs, pain points, priorities and purchase considerations across different kinds of stakeholders.

A technical team could experience developer dependency as a resource or workflow problem, while an ecommerce or marketing leader could see the same issue as an inability to respond quickly to customers or market changes.

We translated those patterns into practical personas that showed who experienced the problems, why they mattered and what different audiences needed to understand before changing their existing environment.

What they got

Customer evidence for a broader proposition and audience-specific messaging

The research challenged a proposition defined primarily by the technology itself.

Customers were not looking for a particular JavaScript framework. They were trying to make complex commerce environments more flexible, easier to evolve and less dependent on expensive or slow-moving development processes.

That gave the company direct customer evidence for positioning itself around the role it could play in the wider commerce architecture: helping organizations modernize the frontend without automatically replacing backend systems and investments that still worked.

The findings and personas informed messaging, product positioning and go-to-market thinking, including how the story should differ for technical and commercial audiences.

The team also received detailed findings, an internal workshop, an interactive crosstab and underlying data so marketing, sales, product and leadership teams could continue using the research. A messaging brief translated the evidence into practical guidance for the relaunch.

Why it mattered

The relaunch could be built around the customer's problem rather than the company's original product category

The research gave the company an external reference point as it broadened its identity beyond the frontend technology it had originally been known for.

Instead of asking only what its technology could do, the company had evidence about the friction customers were trying to remove, the trade-offs they considered and how different buyers understood the problem.

That grounded the broader positioning, messaging and go-to-market strategy behind the relaunch in customer evidence rather than architectural theory.