Turning WhatsApp coaching into a scalable onboarding system
Fedshi's new resellers were dropping off before their first sale, not because the product was broken, but because no one had explained why each step mattered. I designed and owned the Reseller Roadmap: a milestone-based onboarding engine that automated the full new-user journey, gave the growth team control to iterate without engineering, and removed the dependency on manual mentorship.
→ Add your specific activation rate lift, time-to-first-sale improvement, or support ticket reduction here once you have post-launch data.
New resellers had intent but no map
Fedshi is a social commerce and drop-shipping platform. Users pick products, find customers, and Fedshi handles logistics but the earning model depends entirely on resellers running their own ads through Meta or TikTok. That's a non-trivial ask for someone who signed up to "earn money online."
Before this feature, every new reseller followed the same path: sign up, get confused, send a WhatsApp message to the care team. A human coach would then manually walk them through the business logic: why a Facebook page, what a pixel does, what makes a product worth running an ad on. This was personal, effective, and completely unscalable.
"What do I do next?"
After sign-up, there was no clear path. No north star guiding users toward their first sale.
"Why am I doing this?"
Users were asked to create a Meta Ad Account with no explanation of how it connected to profit. Technical tasks without business context feel like busywork.
No momentum
The jump from "pick a product" to "run an ad campaign" felt like a giant leap rather than a series of small, winnable steps.
Human-dependent scaling
The care team was the onboarding product. Every new cohort multiplied the coaching burden without any compounding return.
"Why do I need a Facebook page? I just want to sell."
Recurring question surfaced in care team interviews
I ran structured interviews with the care team to map the most common questions they received, the exact sequence they used to coach new users, and where drop-offs consistently happened. To make sense of the raw findings, I used AI to cluster the interview responses into themes, which surfaced the four problem areas above faster and with more confidence than manual affinity mapping alone. This research was the foundation for every prioritization decision I made.
End-to-end feature ownership
I was the sole owner of this feature from discovery to launch. That meant leading the research, defining the product architecture, designing the user experience, writing the specs, and collaborating with engineering and the growth team to validate every design decision against technical and business constraints.
Coming from a design background, I brought two things to this role that pure PM frameworks don't always provide: user empathy at the interaction level (understanding what makes a reseller feel confused vs. confident in the moment) and systems thinking (designing a verification engine flexible enough that the growth team could change the journey without touching code). The admin configurability was not a feature request; it was a design decision I made to solve the scaling problem permanently, not just for the current journey.
How I prioritized this feature
I used an Effort-Impact framework to compare this work against other onboarding improvements on the backlog. The Reseller Roadmap scored high on impact (it addressed the root cause of L1 support volume, not a symptom) and medium on effort (high design complexity, and it required building the admin configuration layer from scratch). That combination still made it the right bet: a one-time investment that would compound as the care team's time freed up.
A milestone-based journey that teaches the why, not just the how
The core insight from my research: before this feature, Fedshi had no in-product onboarding at all. The care team was the product they manually reached out to new resellers over WhatsApp, sending screenshots, videos, and links to walk them through creating a Meta or TikTok account, picking a product, and running their first ad. It worked for the users who stayed engaged, but it was entirely dependent on a human being available, and it didn't scale.
What that told me wasn't just "we need to automate the how." It was that resellers needed both things the care team was providing: the tactical steps and the business reasoning behind them. A care coach could explain "create a Facebook page because it's your storefront without it, your ads have nowhere to drive traffic." The app needed to do the same. The gap wasn't just process; it was narrative and context, delivered at the right moment in the journey.
The journey is structured into four stages. Each stage contains roughly four milestones, each milestone includes both the technical task and a short "why this earns you money" explanation. Completing milestones awards points and those points are where the second system I owned comes in.
Alongside the Roadmap, I designed and owned a points engine to keep resellers motivated through the full journey. Every completed milestone earns points from +25 for basic setup tasks to +500 for graduation. Resellers can spend those points in the Fedshi Shop: a dedicated rewards store (separate from the product marketplace resellers sell from) where they can redeem points for learning resources and promotional discounts to fuel their next campaign.
The points system is a standalone case study this page focuses on the Roadmap. But the two features were designed together as a single motivation loop: the journey creates the behavior, the points reward it.
Admin configurability as a product philosophy
I deliberately designed the roadmap to be fully configurable from the admin panel, not hard-coded in the app. The growth team can create, reorder, or retire steps. They can attach videos, guides, and "why" messaging in any language. They can toggle steps between manual and automated verification. This decision meant the product could evolve with changing market conditions for example, shifting focus from Meta to TikTok without a single engineering sprint.
To validate this before involving engineering, I used Lovable to build a full working prototype of both the reseller-facing roadmap and the admin panel. This let me test the configurability logic, share a clickable demo with stakeholders, and pressure-test the admin UX all without writing a line of code. It compressed what would have been weeks of back-and-forth into a single review session.
For the milestone micro-copy the "why this earns you money" explanation inside each step I used AI to generate first drafts, then edited for Fedshi's tone and the specific business logic of each task. This was particularly useful for the Setup stage where the connection between a technical action (linking a Meta account) and a profit outcome needed to feel motivating, not instructional.
Milestone verification logic
Some milestones can be verified automatically (the system detects that a Meta account was linked). Others require user confirmation (the reseller marks a task done themselves). I designed a dual-verification system with three trigger types:
User-verified
- User clicks "Mark as done"
- Points release after user confirmation
- Used for tasks the system can't detect (e.g., "Watch this video")
System-verified
- Event-based: system detects a database event (e.g., Meta_Account_Linked)
- Threshold-based: a metric is reached (e.g., Order_Count ≥ 100)
- Retroactive: if a user already met criteria, the step auto-completes on next login
This architecture meant the points engine couldn't be gamed rewards only release when the backend validates the trigger. And it meant admins had full control over which tasks needed human judgment vs. which could be fully automated.
Built in Lovable explore the full reseller journey and admin configuration panel.
What I chose and why
These were the calls that shaped the product, not just the design. Each one involved a real trade-off.
Rather than pitching this feature on instinct, I mapped it against alternatives using Effort-Impact. This gave me a defensible argument for why the roadmap should come before UI polish or new feature work, and it aligned the team before a line was designed.
Hard-coding the journey would have delivered faster. But it would have made every future iteration an engineering ticket. I chose to invest in the admin interface so the growth team owns the journey permanently. The short-term cost was design complexity; the long-term payoff is zero engineering dependency for content updates.
A pure manual system would have been simple but gameable. A pure automated system would have missed tasks that can't be detected in the database. I designed the dual-trigger model to get the benefits of both: automation where possible, user trust where necessary, and backend validation as the arbiter of points in both cases.
The care team's most effective coaching moment was always the explanation before the instruction "here's why this matters to your income" before "here's what to click." I designed the roadmap to replicate that: every milestone surfaces the business rationale before asking the user to act. This reframing addressed the root cause of drop-off, which wasn't technical complexity but motivational disconnection.
I set a < 5 orders threshold for showing the onboarding widget. Above that, it minimizes automatically. This kept the experience targeted to users who actually needed it, and avoided adding UI noise for power resellers who already understood the platform.
I defined the tracking schema, not just the design
I specified the analytics events the engineering team needed to instrument to prove our D30 retention and activation goals. This wasn't something handed to me I identified what we needed to measure to validate the feature was working, then used AI to help draft the event schema and property definitions in a format engineering could act on directly. Working this way cut the spec-writing time significantly and reduced the back-and-forth with the team over naming conventions and property structure.
| Event | What it tells us | Properties tracked |
|---|---|---|
| onboarding_checklist_viewed | How many eligible users are actually seeing the roadmap | user_type, orders_count |
| onboarding_task_clicked | Which steps are generating curiosity vs. being skipped | task_name (e.g., "Create Pixel") |
| onboarding_tutorials_clicked | Whether embedded educational content is being used | tutorial_name |
| onboarding_task_completed | Funnel completion rate and time-to-complete per step the core activation metric | task_name, time_to_complete (seconds) |
The goal was to build a funnel I could analyze: from "viewed the checklist" → "clicked a task" → "completed a task" → "progressed to the next stage." Any drop in that funnel is a signal to investigate a specific step, not the whole journey.
The scenarios I thought through before shipping
Thinking through failure modes before launch is where product ownership separates from pure design. I used AI as a stress-testing partner here prompting it with the core user flows and asking "what could go wrong at each step?" That exercise surfaced failure scenarios I hadn't considered, and helped me triage which ones were worth speccing explicitly. Here are the three I considered significant enough to build into the product.
The Pro Reseller: skips the checklist entirely
Scenario: A user makes their first 5 sales without using the roadmap they already understand the model. Resolution: The system auto-detects completion criteria for automated steps (e.g., Meta account already linked, order count already ≥ threshold) and marks them done on next login. The user isn't penalized for being experienced, and the journey state stays accurate without manual intervention.
The Flagged Account: Meta bans the reseller mid-journey
Scenario: A user follows the checklist to create a Meta ad account, but Meta flags or bans it. The roadmap's "happy path" breaks. Resolution: I designed a troubleshooting branch triggered by a "My account was flagged" option. The branch surfaces three sequential steps: (1) education on why accounts get flagged, (2) a direct link to Meta's appeal process, (3) a strategy for warming up a new page. This keeps the user moving forward instead of abandoning.
Quantity Milestones: how does the system know "100 orders" was reached?
Scenario: Admins want to create threshold-based milestones (e.g., "Submit your 1st order," "Reach 100 orders"), but these can't be toggled manually by the user they need to resolve automatically. Resolution: I introduced Milestone Thresholds: a library of hard-coded order-count events that Admins can toggle on or off in the checklist. When a threshold is met, the backend fires the completion event and the points engine releases the reward. No user action required.
What worked, what I'd do differently
- Starting with care team interviews the real coaching sequence became the product architecture
- Using AI to cluster interview findings surfaced the four core problem themes faster than manual affinity mapping
- Building the full prototype in Lovable validated the admin logic and got stakeholder sign-off without engineering involvement
- Admin configurability removed the growth team's dependency on engineering for content changes
- Dual-verification covered the full range of task types without forcing everything into one model
- Framing milestones around "why this earns you money" addressed motivation, not just navigation
- Define success metrics before design, not after I specified analytics late and had to retrofit some instrumentation
- Prototype the admin panel experience earlier it was underspecified compared to the reseller-facing design
- Run a lightweight usability test on the troubleshooting branch before launch the flagged account flow was designed by inference, not by testing