Case Study: B2B subscription redesign and revenue protection

Case Study: B2B subscription redesign and revenue protection

One-line summary

Redesigning a legacy B2B subscription model to protect recurring revenue, create a premium monetisation path and make future subscription changes easier.

Context

• A huge marketplace, the first in Poland and among the top 3–4 in Europe, with over 100,000 active sellers, 13M+ buyers, revenue in the hundreds of millions of euros and GMV of several billion euros.
• The company was running several subscription products at the same time. Over the years, various teams had built separate subscriptions for different functionalities, and some of those functionalities had become hugely popular among sellers.
• The existing subscriptions no longer fully aligned with the evolving product and monetisation model.
• As a result, some functionalities previously available through subscriptions needed to be replaced.
• Yet those subscriptions generated recurring revenue that needed to be protected despite the changes.

The business problem

The problem was not just how to sunset old subscriptions.

The real problem was how to protect existing recurring revenue while replacing outdated subscription logic with a model that still made sense for sellers and could support future monetisation changes.

The risk was clear: if we simply removed old subscriptions or replaced them with a weak package, we could lose revenue, damage seller trust and create a product model that would need another redesign soon.

Goal

• Sunset old subscriptions while keeping revenue flowing.
• Build a new subscription model from both product and technical perspectives.
• Offer customers enough value to convince them to stay.
• Create a subscription setup that would be easier to manage and evolve in the future.

My role

Role: lead product manager.

Responsibilities:

• Product strategy — define the approach to the problem, boundaries, intermediate goals and alignment with company strategy.
• Alignment with stakeholders — negotiation and coordination with key sponsors, legal, customer support and account managers.
• Coordination of delivery — defining and refining the roadmap, planning sprints and releases, verifying tests with customers and coordinating technical dependencies.
• Planning and driving research — defining goals and the approach to research, helping prepare and execute research activities: surveys, customer interviews and data analysis.

Constraints

• Limited time — a tight delivery window.
• Limited capabilities — engineering capacity was limited. The ability to introduce major changes to existing functionalities was constrained by business and product dependencies.
• Unknown possibilities — knowledge of the existing subscriptions was limited. People responsible for building them had left the company or moved to other areas years earlier. The market had also moved forward.
• Limited customer understanding — we didn’t know enough about our customers, their needs or how they used the product.

Diagnosis

We started with a simple question:

Why are customers actually paying for the subscription?

We looked at:

• Usage data — what sellers actually used.
• Feedback — a series of surveys and customer interviews to understand sellers’ perspectives.
• Product context — what existing functionalities could be used in a new offer.

The conclusion was clear:

Sellers were looking for ways to improve their effectiveness and sell more. They perceived subscription functionalities as a boost, not just as additional tools.

That changed how we looked at the problem. We were not only replacing access to old functionalities. We were looking for a way to package seller growth.

Initial direction

The first idea was conservative:

Replace the subscription with another package: same price, different content, and aim to retain existing customers.

In theory, this was a low-risk approach.

In practice, it was highly uncertain.

We focused on finding functionalities that sellers could see as improving their effectiveness. We identified a few existing functionalities that had received little attention.

That was not enough.

So we kept looking further.

Decision

At some point, we decided to explore a bold pivot and face the problem directly.

Instead of treating the change as a simple replacement, we decided to use that moment to build a genuinely new product with a stronger value proposition.

Other research suggested that sellers wanted access to functionalities they saw as game changers, but access to those functionalities was limited.

Those functionalities also had implications for the buyer experience, which we needed to take into account.

We made a bold decision:

Let’s see whether we can package that value into a subscription while taking the buyer experience into account.

That led to an important insight:

Customers may be willing to pay more for functionality that is clearly valuable to them. Moreover, when functionalities have a “price sticker” on them, it can be easier for customers to see the value they provide.

Solution

We came up with the idea not just to replace existing subscriptions at the same price, but to use that opportunity to rethink the seller subscription model.

The subscription should move from a “nice to have” to an “important part of a seller’s growth strategy”.

Key decisions:

• Instead of a single package, we decided to propose 3 packages.
• First, to give users options.
• Second, to help them choose.
• 3 subscription levels made the value easier to understand and helped users choose the right option.
• We created a premium option around functionalities that sellers valued most.
• We baked in options for further evolution: avoid hardcoding assumptions, make it possible to change subscription packages, add new packages, change their content and move functionalities between plans.

This made ongoing management easier, for example when introducing new features into subscriptions.

Results

• Recurring revenue was retained at previous levels through the transition.
• Identifying growth potential through higher-priced plans led us to offer a top tier at about 77 times the base price: 3,000 PLN vs 39 PLN.
• The new model generated additional revenue from premium options.
• Building it from scratch made future changes faster to deliver.
• It enabled new business and product options.
• The subscription system was rebuilt to make it simple to move functionality from free to paid, from paid to free, or between plans through a configuration change.

What this shows

This case shows a pattern that appears in mature digital businesses:

Monetisation becomes scattered across old product decisions, legacy functionality, billing limitations and unclear customer value.

Fixing it requires more than changing prices.

It requires understanding:

• why customers pay
• what customers actually value
• how packaging influences perception and behaviour
• what the platform can support
• where revenue risk appears during transition
• how to design monetisation in a way that can change later

The main lesson is simple:

Revenue and monetisation should be baked into the product and platform, not built as an add-on.

When this is relevant for your company

This type of work is relevant when:

• revenue is attached to old product logic that needs to change
• subscriptions or packages are hard to explain, manage or evolve
• customers pay for functionality, but the company is not fully sure why
• pricing and packaging decisions are blocked by product or platform constraints
• the company needs to protect revenue during migration, sunset or strategic shift
• the current monetisation model worked in the past, but no longer fits the company strategy
• the company wants to create premium packages, but does not know what customers would actually pay for

Conclusions

• Bold moves may lead to interesting results and uncover completely new options.
• Before you actually test a subscription with end users, you are just guessing.
• Users know where they see value. Sometimes it is completely surprising.
• Nothing is certain forever — even an established subscription may not work next year.
• Revenue and monetisation should be baked into your platform and product, not built as an add-on.
• Don’t try to build everything perfectly, but remember that things will change and be prepared.