Guru Dashboard: redesigning the mentor experience at Great Learning

Snapshot

Guru Dashboard is the tool mentors at Great Learning use to run their week. It’s where they manage sessions, set when they’re available, give feedback to learners, and track payments. The old version had grown one feature at a time without anyone owning the bigger picture, and mentors had quietly stopped trusting it.

I led this work as both Product Manager and Design Lead. I defined the problem, shaped the roadmap, and owned the design end to end. Working with engineers and partners across Ops and Mentor Success, I took the project from “the dashboard needs a redesign” (a one-line brief) to a shipped product that mentors and internal teams actively endorsed.

Mentors started describing the new dashboard as something they wanted to use, not just something they had to. Ops, Mentor Success, and Finance agreed on a single source of truth for the first time. The internal design review at sign-off raised no major objections. A first for this surface.

Context

Great Learning runs professional upskilling programs across India and globally. Mentors, who we call Gurus internally, are the humans who make those programs actually work. They run live sessions, review learner projects, give feedback, and they’re the face of the program for the learner. The Guru Dashboard is the tool they live inside every week. When it works, mentor delivery is invisible. When it doesn’t, learner experience erodes quietly, and you usually find out too late.

The problem, and why it mattered

When I picked this up, the brief was one sentence: “It needs a redesign.” No problem statement. No success metrics. No agreement across teams on what was actually broken. So the first thing I had to do was figure out what we were even trying to solve.

I spent the first few weeks doing the work a PM would normally do. Interviews with mentors. Time sitting with the Ops team who fielded mentor escalations. An audit of every existing flow. Mapping every place a mentor’s work touched the platform. A pattern showed up pretty quickly: the dashboard had been built as a collection of features we’d given mentors, not as a tool built around how they actually worked.

Three things were true at the same time:

• Mentors didn’t trust the dashboard as a source of truth. Session times, learner counts, and payment status often disagreed with what Ops told them over WhatsApp. So they just used WhatsApp.
• The dashboard treated every mentor the same. A senior mentor running cohort sessions and a 1:1 mentor doing project reviews saw the same screens, even though their jobs barely overlapped.
• The things mentors did most often, like confirming sessions and setting availability, took the most clicks. The interface was optimised for completeness, not for the work mentors actually did every day.

Once I’d sat with all of that, I rewrote the brief in my own words. The real job wasn’t “redesign the dashboard.” It was: build a tool mentors trust and reach for first, instead of going to it to reconcile what someone already told them. That reframe is what unlocked everything else. It gave engineering a clear north star, it gave Ops a reason to stop patching things over WhatsApp, and it gave me a way to say no to feature requests that didn’t serve it.

How I approached it

I ran the project in three rough phases, not a structured double diamond.

First, a few weeks of discovery across mentors, Ops, and Mentor Success. Less about what was broken and more about what each group had built to work around what was broken.

Then the reframe and the PRD work. Turning the trust diagnosis into a structured product narrative that covered session lifecycle, availability, feedback, and payments.

Then design and build, run in tight loops with engineering so the structural decisions stayed honest about implementation cost.

The unusual move was holding both PM and Design Lead roles the whole way through. It let me trade off scope and craft inside one head, but it also forced me to be explicit, sometimes literally out loud, about which hat I was wearing in a given decision.

Working with AI as a load-bearing teammate

The other thing that made the dual role workable was AI tooling, used deliberately at the points where the PM and design workloads compounded each other. A few specific places it mattered:

I drafted and iterated the PRD with Claude as a thinking partner, not as a writer. The value wasn’t producing the document faster; it was being able to stress-test my own framing in real time. “Here’s how I’m planning to define the problem. Push back on the weakest parts.” That’s the kind of conversation I’d normally have with a senior PM peer, and AI gave me a version of it on demand, at midnight, without burning a colleague’s time.

I used Claude to consolidate the multi-stakeholder design review notes. The review surfaced about eleven distinct decisions across roles (faculty, mentors, evaluators, moderators): terminology updates, metric visibility rules, onboarding changes, and deferred items. Synthesising that manually would have taken a day and probably lost some nuance. Claude turned it into a clean confirmed-decisions list in an hour, which I then verified line by line before circulating. The verification step matters. I treat AI output as a sharp first draft, not a source of truth.

I used Claude Code via MCP inside my own writing and notes environment to keep PRD, design notes, and meeting summaries in the same context. This sounds like a small thing but it changed something real: I stopped losing the thread between “what mentors said in research” and “what the PRD claims they need.” The artifacts started reinforcing each other instead of drifting.

None of this was about being faster, although it was faster. It was about doing the dual PM-and-design role well enough that neither side got short-changed. The AI tooling was load-bearing for that, in the same way that having a senior PM partner would have been if I’d had one.

What I learned along the way

Four things came up in passing from mentors or Ops, and each one ended up shaping a real design decision.

1. Mentors weren’t confused. They didn’t trust the dashboard.

The UI wasn’t the failure. The data was. Or more accurately, the gap between what the dashboard said and what Ops told mentors over WhatsApp. Once I started treating this as a trust problem instead of a usability problem, almost everything downstream changed, including how we’d measure whether the redesign actually worked.

2. The operational team understood the system better than the user did.

Mentors experienced friction one mentor at a time. Ops experienced it in aggregate. So Ops had a sharper, more compressed view of where things actually broke, and they’d been quietly designing around it for years. If I’d designed only for mentors and not with Ops, I’d have just made a prettier version of the same broken thing.

3. The dashboard’s biggest design problems weren’t in the dashboard.

Stale availability data wasn’t fixable inside the availability screen. Confirmation friction wasn’t fixable inside the confirmation flow. The real fixes were structural. Changing the mental model the system used (lifecycle instead of list, defaults plus exceptions instead of weekly declarations) was the work. Treating each screen as the unit of design was the trap.

4. The right structural decision makes a hundred smaller ones easier.

Once the timeline view was the frame, all kinds of smaller calls got faster and more consistent. What to show on a card. When to surface payment status. How to handle prep context. Most of the value of a redesign lives in those compound decisions, not the headline move. The headline move’s job is to make them possible.

Deep dive: redesigning the session lifecycle

The problem behind the problem

The most visible symptom was confirmation friction. Mentors were missing or delaying session confirmations. That cascaded into learner anxiety, Ops chasing mentors on WhatsApp, and last-minute scrambles to reassign sessions. The obvious read was “the confirm button is hard to find” or “we need better notifications.”

When I sat with mentors, the actual story was different. Confirmation wasn’t being skipped because the button was hidden. It was being skipped because mentors didn’t have a clear picture of what they were confirming, what came after, or what the cost of delay actually was. The dashboard showed them a list of sessions, each one a flat row. A session three days out and a session in three hours looked structurally identical. There was no sense of motion. No sense of where in the journey a session actually was.

So this wasn’t really an interaction problem. It was a visibility problem dressed up as one.

The design move

I stopped thinking of the session as a row in a list and started thinking of it as a lifecycle. A unit of work that moved through states: scheduled, confirmed, upcoming, in-session, completed, paid. The central design move was a timeline view that made that lifecycle the primary mental model. Each session sat where it actually was in its arc.

Confirmation stopped being a button on a row. It became the first meaningful action in a visible sequence, with everything that depended on it (learner notifications, prep time, payment trigger) made explicit downstream. Mentors could see at a glance that an unconfirmed session wasn’t just an undone task. It was a piece of work blocking other things.

Why a timeline, and not the alternatives

I considered state-specific screens. A different UI per session state, so each one could be heavily optimised. I also considered a status-and-actions model, where the dashboard would just tell you “you’re here, do this next.” Honestly, neither was wrong.

This is one of the places I used Claude most actively in the design phase. Not for any individual decision, but to pressure-test all three options against scenarios I hadn’t thought of. I’d describe a mentor archetype and a typical week, then walk Claude through how each model would feel for that mentor day by day. It surfaced edge cases I’d have caught later in usability testing, if I caught them at all. Mentors with split cohorts. Mentors on leave returning mid-week. New mentors with mostly unconfirmed sessions. The conversation didn’t make the decision for me, but it sharpened the trade-offs faster than I could have alone.

The timeline won for a specific reason: mentors weren’t operating one session at a time. A senior mentor might have eight sessions in different states across a week. A status-and-actions model would have forced them to context-switch between sessions to understand each one. State-specific screens would have created a navigation tax. The timeline let mentors hold the full week in their head (confirmations, prep, post-session work) in the order that matched how they actually worked, not the order the system wanted.

The trade-off I accepted: the timeline is less optimal for any single state taken in isolation. A mentor who only had one session in one state would arguably be better served by a focused screen. I made the call that the lifecycle view was right for the median mentor’s actual day, and that the cost to the edge case was acceptable.

The smaller decisions that followed

The timeline frame unlocked a series of smaller decisions that, looking back, were where most of the design work actually happened.

Confirmation got a soft deadline, not just a prompt. Every unconfirmed session showed a deadline tied to the learner’s notification window. Mentors understood urgency in the system’s terms, not Ops’s.

After confirmation, the same session card pulled in prep context (learner names, last session’s notes, the recording link). Confirmation flowed naturally into preparation instead of being a discrete admin task.

Completed sessions stayed on the timeline until paid. This made the payment trail something mentors could trust without asking Finance. It was the single most-mentioned improvement in mentor feedback.

None of these were the big idea. But the timeline frame is what made each one obvious. The right structural decision makes a hundred smaller decisions easier, and most of the value of a redesign lives in those smaller ones compounding.

What happened

Confirmation behaviour shifted in the first cohort that used the new dashboard. Mentors started confirming earlier in the cycle. Ops reported a drop in escalations they had to chase. Mentors specifically called out the timeline view in feedback sessions, often without being asked.

Deep dive: availability management

The problem behind the problem

Mentors set their availability once during onboarding. Then most of them never touched it again. The data in the system slowly drifted from the truth. A mentor’s “available” Tuesday evenings hadn’t actually been available in nine months. Ops would book a session based on what the dashboard said, the mentor would decline or reschedule, and the learner would lose a slot.

If you looked at this as a mentor problem, the obvious fix was nagging. Reminders. Prompts. “Please update your availability” emails. We’d tried versions of that. Mentors ignored them, and the ones who didn’t ignore them resented them.

The reframe that mattered: this wasn’t a compliance problem. It was a system-design problem. The dashboard was asking mentors to do continuous maintenance work on a data structure that didn’t match how they actually thought about their time. Nobody thinks about their week as “the slots I’m available.” People think about their week as “my default rhythm, with the exceptions this week.”

Who I was designing for

This is the deep dive where the PM hat mattered more than the design hat. The user in front of the screen was the mentor. But the user whose problem I was actually solving was Ops. Ops needed predictable, trustworthy mentor capacity to plan against. Every stale availability slot was a small bet they lost.

I made that explicit early, because it changed what the design needed to do. If this had been a pure mentor-autonomy problem, the right answer would have been maximum flexibility. Let mentors block and unblock anything, any time, in any pattern. But maximum flexibility was exactly what had produced the stale-data problem. Mentors didn’t want to think about their availability often enough to keep a maximally flexible system accurate.

So the design needed to make the right thing for Ops also be the easy thing for mentors. Not by aligning their interests perfectly (they aren’t perfectly aligned), but by getting the friction on the mentor side low enough that supply predictability became a byproduct of mentors doing the bare minimum.

The design move

A recurring weekly schedule, set once, that the system treated as the source of truth until the mentor said otherwise.

Mentors defined their default week (Tuesdays 6 to 9pm, Saturday mornings, whatever their actual rhythm was) and the dashboard assumed that pattern held forever. The system stopped asking mentors to confirm availability week by week. Instead, it asked them to mark exceptions. I’m travelling that week, I have a conflict that Thursday, I want to add a one-time extra slot.

It’s a small inversion that does a lot of work. The old model treated availability as a fresh declaration every cycle, which decayed the moment mentors got busy. The new model treats it as a stable structure with edits, which matches how mentors actually hold their week mentally.

The design moves that made it work

The recurring schedule idea is obvious in retrospect. The reason it hadn’t worked in earlier attempts at other tools was the second-order details. A few that mattered:

Onboarding had to over-invest in the default week. If mentors set a sloppy default during onboarding, the whole model collapsed back into the old problem. I moved the availability setup later in the onboarding flow, after mentors had context for what their commitment would actually look like, and made it the longest step. Friction in the right place.

The exception flow had to be faster than just ignoring it. If marking “I’m out next week” took more than a few seconds, mentors would just decline sessions as they came in, which would keep the data stale anyway. So I designed the exception UI as a single gesture on the timeline view. Tap a week, mark it out, done.

The system showed mentors their own pattern back to them. A small section of the dashboard showed “your typical week,” visually, the same way Ops saw it. Partly transparency, partly a soft nudge. If a mentor’s typical week stopped matching reality, seeing it laid out made them notice. We didn’t have to send a reminder.

Ops got a confidence signal on each slot. Behind the scenes, the system tracked how recently a mentor had interacted with their schedule. Slots from a mentor who’d marked exceptions in the last two weeks were treated as high-confidence. Slots from a mentor who hadn’t touched the dashboard in months got a quiet flag in the Ops view. Mentors didn’t see this. It existed entirely to make Ops’s planning more honest about what the data actually meant.

That last one is the decision I’m proudest of, and it’s the one that wouldn’t have happened if I hadn’t been wearing the PM hat. As a designer, I’d have stopped at the mentor-facing flow. As the PM, I knew the real failure mode was Ops over-trusting the data, and I had the authority to ship a fix on the other side of the system.

The trade-off

The recurring model is worse for the small group of mentors whose schedules are genuinely chaotic. For them, “default plus exceptions” is harder than just declaring each week fresh.

I made the call to optimise for the median mentor and accept a worse experience for the chaotic minority. The mitigation was that those mentors could still effectively use the system as a weekly declaration, by treating every week as an exception. Clunkier than a purpose-built flow, but functional. I wrote this trade-off down in the PRD so it would come back up if the chaotic-mentor segment grew over time.

What happened

Mentors set their schedule once and largely left it alone, which is exactly what the model assumed they’d do. Exceptions got marked at a rate that suggested mentors were actually using the feature instead of ignoring it. Ops reported, qualitatively, that the share of bookings bouncing because of stale availability dropped noticeably in the first weeks after rollout.

Working across the org

Most of the design work on Guru Dashboard happened in design files. Most of the value of the work happened in rooms.

The stakeholder group that mattered most wasn’t engineering, and it wasn’t leadership. It was Ops and Mentor Success. The people who lived inside the old system’s pain every day, and who knew better than anyone which of its failures were real and which were just noise. They were also the group whose buy-in mattered most for adoption. If Ops didn’t trust the new dashboard, they’d keep routing mentors back to WhatsApp, and the redesign would die quietly no matter how good the UI was.

Why Ops was the hardest room

Ops had spent years building a parallel system on top of the old dashboard. Informal escalation channels, spreadsheets, WhatsApp groups, mental models for which mentors were reliable and which weren’t. That parallel system was what kept mentor delivery functional. The redesign threatened to obsolete a lot of it, which sounds like a win and is partly a win, but it also meant asking the people who’d built that scaffolding to trust that the new system would actually hold weight.

The early Ops conversations weren’t about features. They were about whether I understood what they’d been carrying. Once I’d shown that I did, by reflecting their workarounds back to them accurately, naming the specific ways the old dashboard had failed them, and being honest about what the new one wouldn’t fix, the conversations got much faster.

The technical solution matters less than whether the operational team believes you’re going to inherit the problem they’ve been solving for you. If they don’t believe that, they’ll quietly hedge, and the design won’t land.

The scoping fight

The clearest moment was a request that came down from a senior leader. The ask, basically, was to add a layer of manager oversight into the mentor flow, so leadership could see and act on mentor performance in near real time. The intent was reasonable. Leadership wanted visibility into mentor quality, and the dashboard was the obvious place to add it.

Wearing the PM hat, my job was to evaluate whether it belonged in this release. Wearing the design lead hat, my job was to evaluate whether it belonged in the product at all, in that form.

Both hats said no, for related but different reasons. As PM: it would blow the timeline, and the value was speculative. We didn’t have data on whether the visibility would actually change leadership decisions, or just create a watching-the-watchers problem. As design lead: bolting an oversight layer into the mentor’s primary work surface would change what the dashboard felt like to the mentor. It would shift the product’s posture from “this is your tool” to “this is your tool, and you’re being watched in it.” That’s a small wording difference and an enormous experience difference, and once you ship it, you can’t take it back without a bigger fight.

I made the call to push back. I didn’t frame it as “no,” because that almost never works with senior stakeholders. I framed it as a sequencing argument: if we ship the mentor-trust version first and earn adoption, we’ll have a real surface to add oversight to later, with real usage data to design it against. If we ship oversight bundled in, we’ll get neither.

The senior leader didn’t agree immediately. The conversation went a couple of rounds. What carried it, I think, was that I’d already built enough trust with Ops and Mentor Success that they backed the sequencing. They wanted mentor adoption first too, for the same reason. The argument landed not because I made it well in isolation, but because the room had already moved.

That’s a lesson I keep relearning. The cross-functional moment where you “win” a decision is almost always downstream of cross-functional work you did weeks earlier. The win looks like a single conversation. It’s actually months of credit you spent in two minutes.

The dual-hat tension

Wearing both PM and Design Lead hats mostly let me move faster. Fewer handoffs. Fewer translation losses. One person who could trade off scope and craft in the same head.

Where it created friction was less dramatic than I expected. The main thing was that I had to be explicit, in some rooms, about which hat I was wearing in a given moment. Engineering wanted to know whether a pushback was a design opinion (negotiable) or a PM decision (a commitment they should plan around). Leadership occasionally wanted to know the same.

So I started saying it out loud. “I’m saying this as the PM, not as the design lead,” or the reverse. It felt awkward for about a week and then became one of the most useful conventions I introduced. It also clarified my own thinking. There were moments where I’d catch myself defending a design decision with PM reasoning, or scoping aggressively to protect a design call. Naming the hat surfaced that conflation before it shipped.

The other thing the dual role made obvious: a lot of what gets called “design vs PM tension” in healthier orgs is actually one person inside their own head, switching between considerations that should be in tension. Holding both made me a better designer than I would have been holding one, because I stopped being able to defer hard product calls to someone else. And it made me a better PM, because I stopped being able to defer hard experience calls either.

Final design

The shipped product is organised around the four flows that structure a mentor’s relationship with the dashboard. Each flow has its own surface, but they share the same underlying frame: lifecycle-first thinking, structural defaults with explicit overrides, and Ops-side instrumentation that mentors don’t see but benefit from.

Impact

Guru Dashboard shipped recently, so the metrics layer is still maturing. Here’s what I can report honestly.

In feedback sessions, mentors specifically called out the timeline view and the recurring schedule as the things that changed how they used the product. Several mentors described the new dashboard as something they reached for first instead of after being prompted, a shift from the old behaviour where Ops escalations were the primary trigger for opening the tool at all.

The internal design review surfaced no major objections at sign-off, which was a first for this surface. Ops and Mentor Success, the teams most affected by mentor behaviour, actively endorsed the rollout rather than tolerating it. That alignment was the precondition for the redesign actually changing anything. Without it, Ops would have kept routing mentors back to WhatsApp regardless of what shipped.

Ops also reported early reductions in the volume of mentor escalations they were chasing, particularly around session confirmations and availability conflicts. These are leading indicators, not fully measured outcomes. I’d want a full cycle of data before claiming them as outcomes the redesign caused rather than correlated with.

What I’m not claiming: I don’t yet have post-launch numbers on confirmation rates, time-to-confirm, booking-bounce rates, or mentor NPS at the level I’d want to publish. The instrumentation is in place. The data isn’t yet. I’ll update this section when the first full cycle’s worth of numbers is in.

Reflection

What I’d do differently. I’d start with Ops, not with mentors.

The sequencing instinct I came in with was the standard one. Talk to users first, then talk to the people who serve them. I spent the early weeks mostly with mentors, building the mental model of how their work flowed, what frustrated them, what they wanted. That work was real and I don’t regret doing it. What I regret is the order.

Ops and Mentor Success had been carrying the system’s failures for years. They had a more compressed, higher-signal view of what was actually broken than the mentors did, because mentors experienced individual frictions and Ops experienced the aggregate of every mentor’s friction, every day, in their inbox. If I’d started with Ops, I’d have arrived at the reframing (that this was a trust problem, not a feature problem) three or four weeks earlier than I did.

The deeper version of this lesson: when an operational team is the shock absorber for a bad system, they often understand the system better than anyone, including the people the system is supposedly built for. They’re easy to talk to last because they’re not the “user.” That’s a bias I’ll be slower to fall into next time.

What the project taught me. With operational teams, trust isn’t built by listening. It’s built by inheriting.

The thing I genuinely didn’t know going in was that the early Ops conversations weren’t really conversations about the dashboard. They were conversations about whether I was going to take work off their plate or quietly add to it. Ops teams who’ve been burned by previous redesigns (and most have been) read every new initiative through that lens, and they’re usually right to.

What shifted those conversations wasn’t research rigour or good listening. It was the moment, a few weeks in, when I started naming the specific things Ops had been doing manually, and proposing concretely which of those the new dashboard would absorb and which it wouldn’t. The honesty about what it wouldn’t do mattered more than the promises about what it would.

I’d internalised “design for the user” as a default. What I hadn’t internalised was that for any operational product, the user in front of the screen is one of several users, and the people downstream of the screen often have stronger feelings about whether the product is actually good. I’ll carry that into every operational tool I work on from here.

What’s next. I’m watching before I’m building.

The dashboard shipped recently, and the instinct after any launch is to immediately scope the next phase. Keep the momentum going. Keep the team busy. Give leadership a roadmap. I’ve done that on previous projects and watched the next phase get built on assumptions that turned out to be wrong, because we hadn’t yet seen how the current phase actually behaved in the world.

What I want for Guru Dashboard is a few months of watching. How mentors actually use the timeline view. Where Ops still routes around the system. Which of the smaller decisions held up and which didn’t. The roadmap I’m carrying in my head is real, but I’m holding it loosely on purpose, because the most useful version of it will be the one shaped by post-launch behaviour, not by pre-launch intuition.

The question I’m most curious about is whether the trust we earned with Ops in the design phase will hold up the first time the new dashboard fails them. Because it will, in some way. That’s the moment that’ll tell me whether the redesign actually changed the relationship between the tool and the team, or just changed the surface.