Product design · Founder story · 2017–2021

Wabu: designing a peer-powered university network from MVP to 120k+ students across three countries.

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.

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.

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 supply wedge

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 first

Willing supply

The 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.

Social motivation

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.

Pure demand

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.

Seasonal demand

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.

Research in the field: these archetypes came from real focus groups, interviews, and time inside the student communities we recruited from.

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.

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.

Research

Focus groups and surveys tested which evaluation dimensions genuinely drove a student's decision — not the ones they claimed mattered.

Decision

Compress 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.

Interaction

Tinder 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.

Result

Contribution spiked and Wabu went viral — “Tinder, but for professors.” The interaction broke the cold-start and seeded 310k+ professor ratings.

Edge case

To 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.

A note on the wireframes: Wabu was acquired and later shut down, and the original design files went with it. The screens below are reconstructions of the flows I designed, rebuilt from the shipped app and my own notes.

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?

Research

User interviews surfaced a constant, invisible behavior — students were always hunting for notes, summaries, and past exams, but supply was trapped in private chats.

Decision

Ship document sharing organized by course, so Wabu became a place students returned to whenever they studied — not once a semester.

Result

Weekly, 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 pressure Professor 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 stress Documents by course

The recurring need. Notes and past exams organized by course turned Wabu into a weekly return visit.

Daily

everyday campus life Social connection Groups & community

The ambition: everyday use. Groups moved the product from a study tool toward a place students just lived in.

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.

Research

We tested the completion flow task by task, watching where students dropped off and which fields read as extraction rather than value.

Decision

Turn data entry into visible progress — bars, profile completion, and level progression made adding courses feel like leveling up, not doing us a favor.

Principle

The 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.

What we killed: Wabu Work. The internship-matching layer was the whole reason we were collecting coursework data — and we cut it. Talking to the companies that would post the roles, their hiring ran on manual processes; making matching work meant effectively building them a CRM, and that operational load would have landed on our team. We kept the data model and deferred the feature. It's the decision I'd defend hardest: the design was sound, the operations behind it weren't.

04 — 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 led a multidisciplinary team of 4+ developers and 2 designers, working in weekly sprints with agile methodologies, managing tickets and bugs in Jira, and monitoring 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.