Case Study · Product Management
New Student To-Do List
How I led a cross-functional team to design, build, and ship a personalized onboarding portal for incoming UW-Madison students — from blank whiteboard to 13,000+ users.
13,000+
Users in year one at scale
98%
Adoption among enrolled students
10+
Campus departments aligned
Role
Product Manager / Steering Committee Chair
Timeline
2018 - 2020 (launch); ongoing iteration
Team
4-8 developers, 10+ campus stakeholder departments
Overview
The New Student To-Do List is a personalized onboarding portal for incoming University of Wisconsin-Madison students. It surfaces the tasks that matter most to each individual student and guides them through completing everything they need to do before and during their first year on campus.
I chaired the steering committee that created it, led the product from concept to launch, and continue to drive its iterative development today. It launched in spring 2020 with approximately 1,000 users and has grown to serve 13,000+ students annually, with a 98% adoption rate among students who actually enroll.
The Problem
UW–Madison is a large, decentralized research university. For incoming students, that decentralization creates a real problem: the information, requirements, and tasks they need to complete before arriving on campus come from a dozen different offices, through a dozen different channels — emails, PDFs, portal announcements, department websites, and word of mouth.
The result was information overload and anxiety. Students were missing critical deadlines not because they didn't care, but because they were drowning. The volume of communication during the summer months was overwhelming, and there was no single place that brought it all together.
How Might We
How might we make it easier for students to make sense of and make the most of their first year experience in a personalized, seamless, and supportive fashion?
Research & Discovery
Before designing anything, we needed to understand the full picture of the student experience — and the operational landscape across campus. Discovery involved three primary methods:
Student Interviews
Conversations with incoming and recently-enrolled students to understand where confusion, anxiety, and missed tasks were actually happening.
Stakeholder Interviews
Sessions with representatives from 10+ campus departments to understand what each office needed students to complete, and when.
Journey Mapping
Mapped the full student journey from acceptance letter through end of first year, with campus partners, to identify gaps and redundancies.
The journey mapping exercise was particularly illuminating. By walking through the student experience alongside representatives from Admissions, Financial Aid, Housing, Health Services, the Registrar, and others, we were able to see — for the first time as a group — just how many parallel communication streams were hitting students simultaneously. It created shared ownership of the problem in a way that made alignment much easier later.
Process & Key Decisions
With the problem defined and stakeholders aligned on the need, we moved into building — but not before working through some genuinely hard product decisions.
Decision 1: What earns a spot on the list?
Every department had tasks they wanted included. If we said yes to everything, we'd recreate the exact problem we were trying to solve — just in a new container. We established clear criteria: a task had to be action-oriented, time-sensitive, and have a meaningful consequence if missed. This framework became the filter for every inclusion debate throughout the project.
Decision 2: Defining MVP scope
With 10+ departments eager to participate, scoping the MVP was critical. We prioritized tasks that affected the widest population of students first, and sequenced department onboarding to allow us to learn from each cohort before adding complexity. Getting something real in front of students quickly — even if incomplete — was more valuable than a perfect product that launched a year later.
Decision 3: The enrollment confirmation gate
This was the sharpest stakeholder tension of the project. The Office of Admissions wanted every single task gated behind a "Confirm Your Enrollment" prerequisite — their reasoning was understandable, but the user experience implication was that a student who hadn't yet confirmed would see an entirely locked list, creating exactly the overwhelm we were trying to reduce.
I advocated for a more nuanced approach: only tasks where enrollment confirmation was a genuine operational dependency would carry the gate. The rest would be visible and actionable immediately, giving students momentum and a sense of progress from day one. After several conversations and a demonstration of the proposed experience, Admissions came around. It's one of the decisions I'm most proud of — it required holding the line on user experience while still respecting a legitimate stakeholder concern.
Championing across campus
Getting departments to participate wasn't automatic. It required running info sessions, meeting with department representatives, and consistently making the case for why a centralized list served their goals better than another siloed communication channel. The framing that resonated most: "Your message is competing with everyone else's. This gives it a better chance of being seen and acted on."
The harder — and more important — work was keeping partners focused on the student's experience rather than their office's needs. Every department came in with their own priorities, their own language, and their own definition of what "important" meant. Some were easy to reorient toward the student perspective; others required more sustained advocacy. The consistent anchor throughout was the research: when a debate arose about whether a task belonged on the list or how it should be framed, we came back to what students actually told us. That's what kept the product from becoming a bulletin board for institutional announcements.
Outcome & Impact
The New Student To-Do List launched in spring 2020 — the same week UW–Madison closed its campus for the COVID-19 pandemic. The timing was not ideal, but it also underscored how much the tool was needed: students navigating a profoundly uncertain transition to college now had at least one clear, centralized place to track what they needed to do.
We launched with ~1,000 users and approximately a dozen tasks. Over the following years, through consistent iteration, department outreach, and personalization improvements, the platform grew to serve the full incoming class.
13,000+
Annual users
Exceeds incoming class size due to students who apply but don't ultimately enroll
98%
Adoption rate
Among students who actually enroll at UW–Madison
10+
Participating departments
From Financial Aid and Housing to Health Services and the Registrar
4
National conference presentations
NODA regional and national, including the 2024 Regional Showcase Award
The product also became a case study in the orientation and transition field — I presented on its development process at two NODA regional conferences and two national conferences. At the 2024 regional conference, the presentation received the Regional Showcase Award, earning automatic selection to the national stage.
What I Learned
This project taught me more about product management than anything else I've worked on — not because it was technically complex, but because the organizational complexity was immense.
The biggest lesson: shared understanding of the problem is more valuable than any feature. The journey mapping session, where ten departments saw the student experience together for the first time, did more to unlock alignment than any presentation or proposal I could have written. When people see the same thing, they start pulling in the same direction.
I also learned to be a better advocate for users in stakeholder conversations. It's easy to default to whatever the loudest stakeholder wants. The enrollment gate situation required me to come prepared — with data, with a prototype, with a clear articulation of the tradeoff — and make the case calmly and repeatedly until the room came around. That's a muscle I've kept exercising ever since.
Finally: launch small, learn fast, iterate. We didn't launch with every feature or every department. We launched with enough to be useful, watched how students used it, and let that guide what came next. The 98% adoption rate didn't happen at launch — it happened over years of listening and improving.
One thing I don't take for granted: I got to talk directly to the people I was building for. User interviews, card sorting activities, casual hallway conversations — that direct connection to students is something most technologists never get, and it shaped every meaningful decision we made. It's also what made the work feel real. When you've sat across from a nervous incoming freshman and heard them describe feeling overwhelmed, "personalized, seamless, and supportive" stops being a design principle and starts being a responsibility.