Product Case Study · Fedshi

Leaderboard: turning solo reselling into a social game

Fedshi Engagement features 2 cover: Leaderboard turning solo reselling into a social game

A tier-fair, anonymized ranking layer built on top of Fedshi's loyalty system, designed to break the engagement plateau that hits resellers the moment they finish a perk cycle.

Feature Owner Product Design B2B Marketplace Gamification Mobile-first
What the feature set out to move
3 tiers
Segmented boards so new sellers never face insurmountable numbers
15%
Hard cap on reward cost as a share of the margin each rank generates
Daily
Trend signals and quests engineered to create a reason to open the app
The Problem

Loyalty alone created a ceiling, not a habit

Fedshi already ran a tiered perks system: admins set thresholds, resellers unlocked benefits. But the system was private and self-referential. A reseller only ever saw their own progress, which created three failure points we needed to solve.

To get there fast, I used AI to cluster raw reseller interview responses into themes, then pressure-tested the clusters myself rather than taking the groupings at face value. The "unclear benchmarks" pain point below surfaced directly from that synthesis.

Engagement plateau

Once a user hit the threshold for a perk like Gold, motivation stalled until the next cycle reset. The product went quiet exactly when it should have stayed sticky.

Solitary experience

Resellers worked in isolation with no benchmark for what good looked like. Without a sense of where they stood against the market, churn risk rose.

Incentive gap

There was no systematic channel to distribute Fedshi Points as a performance reward beyond standard margin and commission.

Unclear benchmarks

New and mid-tier sellers had no way to answer a basic question: am I doing well? Nothing in the product told them how they compared to peers.

Why This, Why Now

The plateau showed up in the data before it showed up in a roadmap

This feature was not handed to me as a ticket. It started as a pattern in the engagement data: resellers who hit a perk tier went quiet, their activity dropping off because they didn't have any motivation to compete. The perks system was doing its job and then, by design, going silent for weeks at a time. That gap was the opening.

I did not run a formal RICE score to justify it. With a small team and a clear signal, the call was a deliberate judgment rather than a spreadsheet. Here is the reasoning I weighed.

Why the impact was high
  • It targeted an active, recurring drop-off rather than a one-time gain, so the upside compounded every cycle
  • It opened a second engagement loop on top of perks instead of competing with the one we had
  • It gave us the distribution channel for Fedshi Points
Why the effort was low
  • It reused the existing perk tiers and cycle, so most of the hard infrastructure was already built
  • The scope could start lean: one ranked view, anonymized, synced to a calendar we already ran
  • As feature owner and designer, I could move from problem to prototype without a handoff

High impact on a problem we could measure, low effort because the foundation already existed and these engagement features were meant to be built with AI, no coding. That combination is why the leaderboard moved ahead of other backlog candidates, even without a formal score behind it.

The Reframe

The fix was not more perks. It was a second motivation loop.

Perks are internal goals. They tell you about yourself. What was missing was an external loop: comparison, competition, and a public sense of standing. The leaderboard was designed as a social layer on top of perks, not a replacement for them.

Perks tell a reseller where they are against a fixed target. A leaderboard tells them where they are against people just like them. The second one is what makes you open the app on a Tuesday for no reason.

Framing that anchored every design decision below
Benchmarks

Borrowing from products that already nailed competition

Before designing anything, I studied how mature consumer apps make ranking motivating instead of discouraging. I used AI to speed up the research, gathering and comparing the mechanics across apps, then pulled the two that mapped most directly onto our reseller problem.

Strava · segments

Strava scopes competition to comparable athletes rather than one global ranking, so a casual rider still has a leaderboard worth chasing. This validated scoping every Fedshi board to a perk tier, so a Bronze seller never competes against Gold volume.

Duolingo · leagues

Duolingo runs weekly leagues with promotion and relegation and a hard reset, which keeps the pool of realistic winners fresh. This shaped locking the season to the perk cycle and the "top advance to the next league" promotion logic visible in the prototype.

To go deeper than a feature checklist, I pulled the real screens into a moodboard and studied how each app handles tiers, promotion zones, quests, streaks, and reward moments. Seeing the patterns side by side is what made the mapping to our own decisions concrete.

Benchmark moodboard of leaderboard and gamification screens from Strava and Duolingo, showing challenges, leagues with promotion and demotion zones, daily quests, streaks, achievements, and ranked lists.
Figure 3 · Benchmark moodboard. Strava challenges and Duolingo leagues, quests, and promotion zones, studied for tier, reset, and reward mechanics.
Key Decisions

Four calls that shaped the whole feature

Every gamification feature can demotivate as easily as it motivates. Most of the work was deciding what to deliberately avoid.

1

Segment by tier, never one global board

A single global leaderboard would show new users insurmountable numbers from top performers. We scoped every board to the user's current perk tier, so Bronze competes with Bronze. Fair competition was treated as a requirement, not a nice-to-have.

2

Anonymize by default, with a graceful fallback

Resellers needed to protect their business identity from competitors. Boards display nicknames only. If a user never sets one, the system falls back to a generated handle like User_1234. Real names, phone numbers, and exact sensitive data are strictly forbidden on the surface.

3

Pin the "me" view so rank 500 never has to scroll

The list shows the Top 3 for aspiration, then pins the user's own rank with two neighbors above and below for live competition. A user at rank 500 sees their realistic next target, not an endless list.

4

Lock the season to the perk cycle

The leaderboard season starts and ends at the exact same time as the perk calculation period. A user who starts the month in Silver races in Silver all month, even if they hit Gold numbers on the 15th, then moves up next cycle. This keeps the race fair and the two systems legible together.

My Role

Where design ownership met product ownership

Feature owner and designer, one person

I led this as a feature owner inside an agile team, which meant I owned both the product judgment and the interface. I wrote the user stories and business acceptance criteria, defined the anonymity and tier-fairness rules, designed the mobile-first reseller view, and built the points logic with a feasibility check Finance could actually sign off on.

The design background was the differentiator, not a gap. Knowing how the "me" view would feel to a rank-500 user shaped the data model behind it. Knowing the reward had to feel real shaped how I structured the points budget below.

The Design

One screen, two jobs: aspiration and competition

The reseller view balances a podium a user can aim for against a tight cluster they can actually beat this week. Trend arrows show movement since yesterday, which is what gives the board daily value rather than monthly value.

I built both the admin and reseller flows as working prototypes in Lovable, which let me brainstorm and then interact with the "me" view and tier switching as real screens instead of static mockups. Testing the flow live is how I caught interaction issues before they reached the data model.

Leaderboard reseller view with quests, tier league, and ranked board
Figure 1 · Mobile reseller view. Top 3 for aspiration, pinned rank with live neighbors for competition, trend arrows for daily signal.

Behind the table sits a multi-metric model. Users level up on a combination of order volume and the number of mentees they graduate, and they can choose which metrics define their standing rather than being locked to a single number.

Quests

A daily reason to open the app

The leaderboard is a monthly race. Quests are the short loop that keeps it alive day to day. They sit at the top of the Leaderboard page, so the first thing a reseller sees is a fresh, beatable goal with a clear reward attached.

A quest is a small, bounded challenge: a title like "Sell 10 items from the Home category," a time window, a point reward, and a short description. A reseller taps to join, and on completion gets a notification that they won and earned points. Those points spend in the Fedshi Shop, where they unlock things like service discounts. The loop is deliberately tight: see the quest, do the work, get told you won, spend the reward.

Admin-configurable

Business admins design any quest they need around a sales priority. They set the title, a time period or range, the points awarded, and a description, all without engineering involvement.

Steerable by behavior

Because admins author the goals, quests double as a steering tool. If resellers are ignoring a category or a feature, a targeted quest nudges activity exactly where the business wants it.

Closed reward loop

Quest points pay out into the Fedshi Shop as discounts and services, so a win is immediately spendable. The reward feels real rather than cosmetic, which is what sustains the habit.

A daily win

Where the leaderboard rewards the long climb, quests hand out a win on a shorter cadence. That frequent payoff is what gets a reseller back into the app between rank changes.

Part of one engagement system

Quests, the leaderboard, and the Fedshi Shop are pieces of the same engagement set, all under my ownership. The leaderboard creates standing, quests create momentum, and the Shop turns earned points into tangible value. Designed together, they push resellers to sell more and check the app more often, rather than three features competing for the same attention.

Rewards Logic

The Service-Anchor Method

A leaderboard that hands out points nobody can spend feels like a cheat, not a reward. Instead of inventing a number, I worked backward from the service catalog: a podium finish in any tier must buy at least one real, relevant Fedshi service immediately.

Tier Rank 3 (anchor) Rank 2 (1.5x) Rank 1 (3x)
Bronze 200 pts · 1 Ad Copy 300 pts 600 pts · 1 Video Edit
Silver 500 pts · 1 Video Edit 750 pts 1,500 pts · 3 Video Edits
Gold 2,000 pts · 4 Video Edits 3,000 pts 5,000 pts · Premium Pack

The Bronze rank-1 reward deliberately gives a taste of the Silver-level service, which creates a pull to upgrade. Gold rewards run higher because Gold users generate the margin that funds them, and losing them to a competitor costs more.

The Safety Check

Making sure a reward never bankrupts the margin

The reward structure only ships if Finance can verify it. The rule: the internal cost of fulfilling a reward must not exceed 15% of the gross margin that user generated at their rank.

Worked example
  • Bronze rank 3 performance: 50 orders / month
  • Profit per order: about 1.00
  • Profit generated: roughly 50.00
  • Reward cost (Video Edit, 500 pts): about 5.00
  • Ratio: 5 / 50 = 10%, inside the cap
The principle
  • Anchor the reward to a real service, not a vague lifetime-value formula
  • Set the floor at rank 3 equal to that service cost
  • Confirm the user's own margin covers the gift
  • Keep performance-reward spend in the 5 to 15% band
  • If it fails the check, the reward does not ship
Edge Cases

The cases that decide whether gamification helps or hurts

Onboarding

Existing users have no nickname. We prompt for one without blocking their workflow, and fall back to a generated handle so a missing nickname never breaks the board or exposes a real identity.

Winner-takes-all

If the same three users win every week, everyone else disengages. Tier segmentation plus a per-cycle reset keeps the pool of realistic winners wide.

Data leak

Nothing on the board can identify a user to a competitor. No real names, no phone numbers, no exact sensitive business figures are ever surfaced.

How I Worked With AI

AI as a faster thinking partner, not a decision-maker

AI shows up at three points in this project. In every case the pattern is the same: it accelerated a step, and I stayed the one filtering and deciding what to keep.

1

Clustering interview results

I fed raw reseller interview responses to AI to group them into themes, then reviewed and reshaped the clusters by hand. It compressed hours of affinity-mapping, but the call on which themes were real product problems stayed mine. The "unclear benchmarks" pain point came out of this.

2

Benchmark research

I used AI to gather and compare how apps like Strava and Duolingo structure competition, reset cycles, and reward progress. I used it to widen the search, then selected the two mechanics that actually mapped to our tier-fairness and season-reset decisions.

3

Prototyping with Lovable

I brainstormed and built full interactive prototypes of both the admin and reseller flows in Lovable. This let me test interactions like the pinned "me" view and tier switching as real screens early, instead of discovering problems after the logic was committed.

Reflection

What worked, what I would carry forward

What worked

  • Treating fairness as a hard constraint kept the feature from quietly demotivating the majority of users
  • The Service-Anchor Method gave Finance a number they could defend, which is why the rewards were viable rather than hypothetical
  • Pinning the "me" view turned a long ranked list into a personal, beatable target

What I learned

  • Anonymity and competition pull against each other, and resolving that tension upfront saved rework later
  • Syncing the season to the existing perk cycle mattered more than any single screen, because two clocks would have confused everyone
  • Owning both the design and the product logic let me catch model decisions a handoff would have buried
Try It

Walk the prototype

The reseller view is mobile-first, so set your viewport to a phone size for the intended experience.

Reseller Roadmap · Leaderboard prototype

Interactive mobile flow, best viewed at phone width.

Open the prototype