GoSats — Fixing the Drop-Off Before the Third Transaction

Problem Statement

GoSats lets users earn Bitcoin and Gold on everyday spending — shopping, vouchers, a prepaid card. The company has crossed 700,000+ users and raised $4.82M, but the actual product question in front of me was narrower: how do you get a new user to complete their third transaction, not just their first.

I didn't have access to GoSats' internal funnel data, so I couldn't see the exact drop-off numbers. What I did have was public app store and Play Store reviews, and reading through them told a fairly consistent story. Users weren't leaving because the app was confusing. They were leaving because they didn't trust the reward system — specifically, Sats could only be withdrawn once a user hit 30,000, which for a new user can feel like a goal that's basically out of reach.

What I Designed

I started with market sizing to understand the ceiling (roughly 12M Bitcoin users in India, with GoSats realistically able to capture 1–3M of that), then worked backwards from the reviews to find the actual root cause using the 5 Whys method. Each "why" moved the answer away from "users don't like the app" and closer to "users don't believe the reward system will ever pay out."

From there I built three personas based on patterns that kept repeating across reviews — a first-time crypto user who gives up early, a regular shopper who feels her spending isn't being rewarded proportionally, and a user who wants to redeem early but can't. Then I prioritized the pain points by impact vs. effort, and the redemption threshold came out on top: high impact, low effort to fix.

The solutions I proposed:

• Restructuring redemption into sub-tiers (Bronze 3, Bronze 2, etc.) so users can cash out smaller amounts along the way instead of waiting for one distant milestone.
• A loyalty badge system with a bumper reward on every 11th transaction, to give long-term users a reason to keep going past the initial reward.
• A Portfolio feature consolidating a user's Sats, vouchers, and card balance into one view, since several reviews mentioned not knowing what they'd already earned or where it went.
• Product Combos, letting users buy a bundle of vouchers in one transaction instead of five separate ones.

How I Approached It

I treated this less like a features list and more like a diagnosis. Before proposing anything, I wanted to be reasonably sure the actual problem was trust in the reward system, not something more obvious like UI friction or lack of awareness (both of which showed up in reviews too, but at lower volume). That's why the 5 Whys step came before any solutioning — jumping straight to "add more rewards" would have missed that the core issue was the shape of the redemption structure, not the reward size itself.

Key Design Decisions

• Prioritized the redemption threshold over bigger, splashier features like the AI chatbot or product combos, because it was the one pain point directly tied to why users disengage early, not just what would make the app nicer to use.
• Kept the sub-tier redemption idea additive, not a replacement for the existing tier system, since redesigning GoSats' whole rewards architecture wasn't realistic to propose without knowing their backend constraints.
• Backed every feature with a metric (redemption rate by sub-tier, badge acquisition rate, portfolio adoption rate) so the recommendations could actually be tested rather than just sounding reasonable.

What This Demonstrates

• Sizing a market and validating a hypothesis using only public information.
• Turning scattered, unstructured complaints (app reviews) into a specific, testable root cause.
• Prioritizing based on impact vs. effort rather than defaulting to the most interesting feature to build.
• Thinking in terms of what's measurable, not just what sounds good in a deck.

Project Artifacts