Case Study — How to Move Fast and Not Break Things

Case Study — How to Move Fast and Not Break Things

…especially when those things power the company’s second most important revenue stream.

How I redesigned a saturated monetisation model and its legacy technical platform to enable revenue growth while reducing usage and protecting a critical revenue stream.

Context

The story takes place at Allegro, one of Europe’s largest e-commerce marketplaces, in 2017:

• around 100k active sellers,
• over 9m active buyers,
• GMV of almost PLN 16bn,
• revenue of over PLN 1.6bn

One of its core revenue sources was the “Featured Offers” functionality — a way to boost visibility and increase sales for offers on the platform. An offer with such an option had a significantly greater position and chance to be presented to customers.

Goal

Grow revenue from the “Featured Offers” product in the current year and set it on a path for future growth.

Problem

Outdated product concept

“Featured Offers” functionality was created almost at the beginning of company’s history and had a lot of limitations:

• Enable once, almost impossible to turn off – the way it worked blocked sellers from disabling it in real situations.
• Monthly upfront payment – which was an investment in unproven effects without a guarantee that investment would pay back, so sellers were hesitant to enable it
• Lack of pricing elasticity – one price was set for all categories and contexts, which blocked price managers from better optimisation

Increasing usage was not an option

1. Buyers dependency – the “Featured Offers” usage had to be balanced. Too many “Featured Offers” led to a worse experience for buyers, oversaturation and, in the end, poorer results for sellers: lower sales and stalled revenue.
2. Visible oversaturation – in some categories “Featured Offers” were so common that the product was becoming ineffective. Growth through more usage and more customers — was no longer effective and would lead to further diminishing product value.
3. Platform professionalization – only offers worth featuring should use “Featured Offers” option, situations where low quality offers used “Featured” should be stopped.

Significant technological limitations

The technical implementation of the feature had been built almost at the beginning of the platform. It had been created in a completely different context: a different market, a company at a different stage and using technology that had since become outdated.

This made meaningful new development extremely difficult.

If nothing would change the “Featured Offers” product would die: more revenue could be squeezed from it that year, but in the long term sellers could abandon this option, undermining its long-term value.

My role

• Product lead for the product and technology redesign Planning research and participating in its execution Negotiating scope and solutions with stakeholders Roadmap planning Coordination with other teams Supporting technical architecture design Delivery planning

How the challenge was approached

Business context

Financial plans had already been set. There was almost no room for negotiation. I, together with my product team, had to work with what came out of the company’s budget planning. That year’s revenue growth target and the need to protect the revenue coming from “Featured Offers” were non-negotiable. However, how to execute it was up to us.

Understanding the customers’ perspective

My first idea was to understand the bigger picture: how customers are using that functionality, what they think about it and what value they see in it. It wasn’t as simple as it seemed. There was basic information about usage and impact on sellers’ performance (data showing popularity of “Featured Offers” and how it translates to sales). However, qualitative insights were scarce. Many insights existed, yet most of them were superficial, focusing only on issues, problems and generally negative feedback.

The picture was bleak. Judging only by that feedback, it seemed that customers hated the functionality and saw it mostly as an unavoidable cost — they felt they had to pay just to generate any income.

I suspected that this was not the full picture. Together with the UX research team I prepared and executed a series of in-depth research. My goal was to understand customers’ perspective: how and when they use that feature, what value they see, what they struggle with. Also the key change I wanted to achieve was reaching beyond the most vocal critics.

We conducted comprehensive research into “Featured Offers”. The approach focused not on asking customers what problems they had, but on understanding how they used the product – their thinking, their internal processes and approach to “Featured Offers”.

My biggest insight from research was the conclusion that the actual challenge was not only in how the product worked, but the emotional barrier.

The actual hidden issues were:

• Lack of clarity — customers didn’t understand the product
• Fear and lack of trust — customers were afraid of runaway costs
• Lack of flexibility and difficulty opting out once started — limited options for cancelling the feature reduced willingness to use it

This led me to the decision to put pressure not only on addressing goals (revenue) but also on making the product more comprehensible, which should help in the long run.

Bringing a new concept to the table

Start from scratch

On the other front technical decisions waited. My dev team did great work of analysing and understanding existing architecture and implementation. I challenged them with a question: what options did we have? After a sprint of testing, validating and discussing various approaches, the conclusion was:

Rebuild implementation from scratch.

This gave us much more freedom in designing the product: no limitation in new functionalities, utilisation of learnings from previous version.

Yet total rebuild led to a huge risk:

all customers and offers had to be migrated to a new solution without any disturbance in revenue.

Think about customers not only about revenue

We made it easier for sellers to make and change decisions. Previously, decisions could not be reversed, sellers paid a larger charge once per month and had very limited ways to cancel.

Now, we enabled them to make changes more easily, lowered the upfront investment and addressed dependencies with newer types of offers that had not previously been properly supported.

• Flexibility: the ability to support different charging cycles, use different prices depending on cycle length, category and offer configuration, and provide actual reporting on usage and the impact of the “Featured Offers” option.
• Lower the entry level: make it cheaper to test, try and validate. Yes, I know the goal was to increase revenue, not to make it drop. There was logic behind it.
• Provide more insights: help customers better understand what was happening.

Delivery

Starting with validation

Verifying the idea with customers wasn’t as simple as asking, “Do you like the new pricing?”

Especially since we weren’t able to reveal the new charging model before it was officially announced.

I decided to validate it part by part, without showing the full solution ahead of its public announcement. This let us test individual changes while protecting commercially sensitive details.

The next difficulty was asking the right questions.

Even with typical B2C products, this can sometimes be tricky. Here, the level of difficulty was much higher:

• It was a B2B product with a significant impact on customers’ financial health. Asking “Do you like it?” wasn’t an option — in fact, it never is.
• Existing negative sentiment made it harder to separate valid insights from noise and false negative signals.
• I wanted to measure facts: not only ask about opinions, but also measure the impact on customers by reviewing actual usage.

Being prepared

The concept was one part. The second was how to switch to the new model without breaking anything.

One of the company’s most important revenue streams depended on it, and each potential issue could lead to significant financial losses.

• Deep understanding of the technical consequences
• Testing both the technology and user reactions
• Preparing for every possibility

Controlled release before the public announcement

Thanks to cooperation with business ops, I was able to gather a group of customers who agreed to switch to the new solution and provide feedback before the public release.

On top of this closed-group pre-release, I asked my dev team to limit migration risk by testing the new solution in parallel across the platform, simulating usage, verifying results and validating performance before migration.

The first changes went live in August 2017 (Allegro’s public announcement).

Results

• Pricing time to market was reduced — we replaced a hardcoded solution, where every change required development, with configuration-level settings. Thanks to this, our internal stakeholders and pricing managers were able to react quickly to market changes and adjust pricing without constantly bombarding my team with development requests, freeing up time for other work.
• Successful migration of 130m+ offers and 100k+ users to the new system. There was no revenue interruption or incident, and the whole platform was switched to the new solution.
• Lower usage — thanks to the new solution and subsequent pricing management, usage of “Featured Offers” declined. This increased the value of the feature, as fewer offers were competing, while helping protect the buyer experience.
• Long-term flexibility — the architecture built in 2017 enabled further monetisation changes without another rebuild, including daily billing for a featured-offer promotion package introduced in March 2019.
• Business impact over time — Allegro’s reported marketplace take rate grew from 8.0% in 2017 to 9.3% in 2019 (public financial results). This was not caused by this project alone, but the redesigned product contributed by enabling subsequent pricing optimisation.

Summary

• Don’t be afraid to be bold when it comes to monetisation. What worked five years ago may no longer be the right option, so be willing to completely change the monetisation approach.
• Research the market and your customers deeply. Asking for feedback is not enough. Listening only to the most vocal critics may distort the actual insights. Look beyond that.
• Model the impact, but also test, verify and assess it thoroughly using actual data. Monetisation is not an area where we can release a change and simply see what happens. A single wrong assumption released publicly may break the whole company.