Product design + product ownership - 2017 to 2021
Wabu: designing a peer-powered academic network from MVP to scale.
I co-founded and led product for Wabu from MVP to V3, designing the core flows, research loops, gamification system, QA process, and contribution mechanics that helped students rate professors, share class materials, and make better academic decisions.
Product design case study
Scale120k+ students, 20 universities
ScopeMVP to V3, utility to network
My roleCo-founder and Product Lead
MethodsResearch, flows, QA, iteration
TL;DR - Why this is a product design case
Product ownershipMVP to V3Owned roadmap, shipped releases, QA cycles, maintenance, and prioritization across multiple product stages.
UX strategyDesigned the core loopsProfessor trust, document utility, profile completion, points, levels, rewards, and the Wabu Work data layer.
Research habitBuilt with studentsFocus groups, interviews, surveys, usability testing, behavioral observation, and user-reported issues shaped the roadmap.
Business logicUtility + incentivesAligned user value, contribution supply, sponsor rewards, and monetizable student data without making the product feel extractive.
From student pain point to shipped product, network effects, and measurable scale.
This was not only a founder story. I owned the product decisions that turned scattered student knowledge into a working academic marketplace: discovery, UX strategy, core flows, contribution loops, rewards, QA, monetization, and iteration after launch.
120k+ students310k+ ratings67k+ documents20 universities$550k raised4.8 app rating
00 - Context
Students already had the information. It just lived everywhere except one place.
Students already had everything they needed to help each other - notes, summaries, past exams, hard-won experience with specific professors. The problem was that all of it lived scattered: buried in Facebook groups, WhatsApp chats, even hand-written surveys passed around campus. There was no single source of truth.
Wabu set out to centralize that knowledge - and to become more than a tool. We wanted a genuinely social space for university students, not just an academic utility. It grew into a peer-powered network where 120k+ students across Peru, Mexico, and Chile rated professors, shared class materials, and helped each other through the semester.
I owned the product end to end - from the first MVP to V3, from discovery to shipped releases to QA. Every major decision was grounded in user interviews, focus groups, surveys, usability testing, and behavioral data. Research was never a one-off discovery phase; it was the engine behind every release, shaped by a user-first, business-aware way of working I developed early in my career.
01 - Product Thesis
The real challenge was designing trust, structure, and incentives - not content.
Wabu was never a content app first. It was a trust-and-contribution problem: professor evidence, class materials, motivation, and business model all had to reinforce each other. This case study isn't the startup story - it's the chain of product questions we had to answer, in order.
Academic decisions were high risk
Students chose professors and courses with incomplete information scattered across friends, chats, and informal networks.
Build with students, not just for them
Every major release came from a mix of interviews, focus groups, surveys, usability testing, and behavioral data - research as a habit, not a phase.
A peer-powered academic network
The product scaled to 120k+ students and validated a two-sided contribution marketplace of documents, ratings, rewards, and sponsored prizes.
TrustProfessor ratings helped students make safer enrollment decisions.
UtilityDocuments turned Wabu into a weekly study tool, not just a seasonal app.
ContributionGamification and rewards created the supply engine behind the network.
02 - Who we designed for
Before building supply, we had to know who would actually create it.
A network of shared documents only works if someone uploads. So early research went into identifying the real student archetypes inside the communities we were recruiting from - not to describe everyone, but to find who was easiest to activate as the first supply. User personas, drawn from interviews and community observation, gave every later incentive decision a specific person to design for.
The hub
The student everyone already messaged for notes, summaries, and past exams. They were constantly re-sending the same files by hand - so they didn't need convincing, they needed one place to put everything.
Easiest to activate firstThe sharer
Already generous by default - shared to build reputation and be seen as helpful. Gamification gave this behavior visible status instead of leaving it invisible.
The free rider
Consumed everything, contributed nothing. Not a villain - just unmotivated. The challenge wasn't blocking them, it was converting a slice of them into occasional contributors.
The crammer
Appeared around midterms and finals hunting for past exams and summaries. High-intent, but only a few weeks a year - the persona that justified document sharing as recurring utility.
The climber
Driven by status, ranking, and not falling behind peers. Leaderboards and the level ladder were built with this student in mind - competition as the engine for contribution.
Why these, not all
These weren't demographic buckets - they were behavioral levers. Each one mapped to a different product decision: who to seed, who to reward, and who to gently convert.
Research in the field: these archetypes came from real focus groups, interviews, and time inside the student communities we recruited from. Drop that evidence here.
Focus group sessionadd photo
Student interviewadd photo
Community recruitingadd photo
03 - Core product flows
The product worked because each flow solved a different behavior.
Before going deep into the individual product questions, this is the quick map: Wabu was designed as a set of connected loops. Students came for trust, returned for utility, contributed for status and rewards, and completed profile data because the product made progress visible.
Rate a professor
Break the cold-start by making recognition and rating fast enough to do at scale.
Recognize professorSwipe to continueRate key dimensionsSeed searchable trust
Result: 310k+ professor ratings
Find or upload documents
Turn Wabu from a seasonal enrollment tool into a weekly academic resource.
Select courseFind study materialUpload notes / examsEarn value back
Result: 67k+ documents uploaded
Earn points and level up
Make contribution visible through progress, status, competition, and rewards.
ContributeEarn pointsClimb levelsRedeem prizes
Result: repeat contribution supply
Complete profile
Collect structured academic data by making completion feel useful, not like a form.
Add universityAdd coursesComplete profilePower Wabu Work
Result: product + business model aligned
Question 01 - Bootstrapping trust / MVP
How do we bootstrap trustworthy professor data from zero?
The MVP had two problems stacked on top of each other. First: what actually makes a professor worth choosing? Rating "is this professor good?" is too vague to be useful. Second: the cold-start. No ratings meant no reason to use Wabu, but no users meant no ratings ever got created - and rating was tedious, since students recalled professors by face or course, not by name.
ResearchFocus groups and surveys tested which evaluation dimensions genuinely drove a student's decision - not the ones they claimed mattered.
DecisionCompress the rating into a few high-signal dimensions: learning quality, grading difficulty, and approachability - readable at a glance.
Tradeoff"Buena onda" was fuzzy and hard to operationalize, but students treated it as decision-critical social proof, so we kept it.
InteractionTinder was everywhere, so we user-tested a swipe: a professor appears, swipe left if you don't recognize them, right if you do and want to rate.
ResultContribution spiked and Wabu went viral - "Tinder, but for professors." The interaction broke the cold-start and seeded 310k+ professor ratings.
Edge caseTo protect data integrity with no university integration, we capped ratings by academic year and cross-referenced each student's major against the courses they could realistically have taken.
Wireframe
Swipe to recognize
Framing recognition as a single left/right swipe removed the friction that had been killing contribution - the low-effort gesture that broke the cold-start and seeded the first ratings.
Wireframe
The rating that compresses trust
The professor detail screen carried the three dimensions that actually moved a decision - learning quality, grading difficulty, approachability - plus "buena onda" as social proof. Everything else was cut to keep the judgment readable at a glance.
Question 02 - Weekly utility / V1
How do we make Wabu useful every week, not just at enrollment?
Professor ratings solved a sharp problem, but the need spiked around enrollment and went quiet after. The next question came from the student, not the calendar: what academic need shows up every week?
ResearchUser interviews surfaced a constant, invisible behavior - students were always hunting for notes, summaries, and past exams, but supply was trapped in private chats.
DecisionShip document sharing organized by course, so Wabu became a place students returned to whenever they studied - not once a semester.
SignalWeekly, sometimes daily, return use - setting up the harder problem of who actually supplies those documents.
Each feature answered a different rhythm of student motivation. Mapping frequency to feature is how the product grew from a sporadic tool into a daily habit - and it told us which problem to solve next.
the same product, three rhythms - usage grows left to right
Sporadic
once a semester
Enrollment pressureProfessor ratings
The rare, high-stakes moment: deciding who to take. Enough to seed the network, not enough to build a habit.
Weekly
every study week
Exam & prep stressDocuments by course
The recurring need. Notes and past exams organized by course turned Wabu into a weekly return visit.
Daily
everyday campus life
Social connectionGroups & community
The ambition: everyday use. Groups moved the product from a study tool toward a place students just lived in.
Question 03 - Motivation and business model / V1
Getting students to consume was easy. Getting them to supply was the real design problem.
Documents were only valuable if students actually uploaded them. Gamification here wasn't cosmetic; it was the core product mechanism that converted passive academic demand into active supply. Research through interviews and user personas showed students didn't share out of generosity - they shared for status, recognition, and the pressure of not falling behind their peers. So the system was built on visible social proof, not private rewards.
Upload notesStudents contribute useful class material.
Earn pointsImmediate feedback rewards the action.
Gain statusLevels and leaderboards make contribution visible.
Redeem rewardsSponsored prizes create tangible motivation.
Return and inviteMore students create more content and trust.
Business model, designed into the same loop: rewards had to stay free to students, so someone else had to fund them. We ran a parallel research track with brands - business development to find which sponsorship model worked for them, and how to tie it back to student motivation. One system solved gamification and monetization at once: students earned real rewards, brands got visibility, and Wabu got a monetizable supply engine, with no student fees and no intrusive ads.
Screen
Status and competition
Ranking made contribution visible, so students climbed to be seen. Visible status - not generosity - was the pull that drove uploads.
Screen
Immediate payoff
Points and animation gave instant feedback the moment a student contributed, closing the loop between action and reward.
Screen
Brand-funded, free to students
Sponsors paid for the rewards, so contribution never cost the student anything - the moment gamification and business model became one system.
Seven levels, from Egg to Genius, so contribution had a ladder to climb.
Uploading earned points; points earned status; status drove more uploads. The character system gave contribution a playful, visible identity - and the loop grew the shared library to 67k+ documents while pushing Wabu toward weekly use.
LV 1Egg
LV 2Noob Wabuer
LV 3Cool Wabuer
LV 4King Wabuer
LV 5Knight Wabuer
LV 6Sensei WabuerLV 7Genius WabuerWhy this belongs in the case study: it shows product design beyond screens - a single system connecting behavior, motivation, supply, monetization, and retention.
Question 04 - Data without integration / V2
How do we get the academic data we need - without being pushy or making it feel like a chore?
One of Wabu's deepest product problems: we wanted precise data on exactly which courses each student had taken - to power segmented offers and, eventually, Wabu Work, matching students to internships based on their actual coursework. But with no university integration, that data didn't exist on our side. The only path was to have students provide it themselves - and people don't fill long forms for free.
ResearchWe tested the completion flow task by task, watching where students dropped off and which fields read as extraction rather than value.
DecisionTurn data entry into visible progress - bars, profile completion, and level progression made adding courses feel like leveling up, not doing us a favor.
PrincipleThe line we held: every field had to create student value, not just business value.
Wireframe
Completion as progress
Reframing data entry as a filling profile - bars rising, sections checking off, a level to reach - turned a boring form into something students wanted to finish, without it feeling like extraction.
03 - Keeping the product alive
Ownership didn't stop at launch. Running the product was part of the design work.
As co-founder and product lead, I ran the product as an ongoing operation, not a handoff. I worked in weekly sprints with the development and maintenance team using agile methodologies, managed tickets and bugs in Jira, and monitored user-reported issues so real feedback fed straight into the roadmap. QA on core flows and edge cases ran before every release, and priorities shifted as each academic season changed student needs.
01
Student reports issue
Bug, missing course, confusing flow, or request - captured continuously.
02
Ticket is triaged in Jira
Feedback becomes prioritized product or development work.
03
QA validates the fix
Core flows and edge cases tested before every release.
04
Roadmap re-prioritized
Fix, improve, defer, or build next - re-scored each season.
This matters because it shows product ownership, not just UI craft: agile delivery, support, QA, tickets, app quality, and release-level judgment sustained over years.
Sprint / team working sessionadd photo
Jira board or roadmapadd photo
The 30-second version
I designed the system that made students help each other.
From an ambiguous student problem to a viral MVP wedge, mixed-method research, a motivation system, a working business model, and a product that grew from utility into a network.
120k+registered students
310k+professor ratings
67k+documents uploaded
20universities across 3 countries
$550kraised across 3 rounds
4.8app rating through product quality
Top 5educational apps in Peru
Trendingfeatured in the app store
Product ownership: real users, shipped releases, discovery, behavioral segmentation, gamification, monetization, QA, and product operations. Not "I made screens" - I designed the system behind them.
Wabu was eventually acquired. The acquiring company later shut down, and the app no longer exists - but the product reached six figures of students and validated a full contribution marketplace before it did.
Press & recognition
Newspaper features, a top-5 spot among educational apps in Peru, and app-store features - the full set also lives on my LinkedIn.
Newspaper featureadd photo
App-store featureadd photo
Media mention / interviewadd photo