01
Customer Success Manager dashboard
Traces back to
The Priority Queue I scoped as P1 — a ranked view of a CSM’s drivers, with the score in the list so risk is visible before opening anyone.
02Anda
Deciding what Anda’s team should build first
Anda helps drivers in Angola earn a living while working toward owning their vehicles. The data needed to understand driver performance was scattered across Odoo, spreadsheets, GPS, and Yango.
Product managementAllison Qiu
Product designTiffany Liu · Isabella Raffo
- Timeline
- Feb — May 2026
- Role
- Product Manager
- Focus
- Requirements · Roadmapping · Data model
- Team
- 2 designers · Tech lead · Developers
- Client
- Anda, Angola
The build order I setSee the full roadmap →
- P0 Ship firstTrustworthy driver data, and a score that can explain itself.
- P1 Once the data held upPriority Queue and risk scoring for Customer Success Managers.
- P2 DeferredDriver-facing app, rewards, and CSM messaging.
01The problem
No one could tell when a driver actually needed support.
Activity and payment data lived across Odoo, manual spreadsheets, and GPS and Yango APIs that didn’t talk to each other. So an inactive driver could be underperforming, dealing with a vehicle issue, or falling behind on payments — and admins couldn’t tell which.
- 01
Admins and CSMs had no easy way to see how a driver was doing — driving regularly, offline for stretches, keeping up with payments, or falling behind.
- 02
Checking on one driver meant opening several disconnected systems.
- 03
There was no clear way to decide which drivers needed help most urgently.
02Who we designed for
The Customer Success Managers who had to decide who needed help first.
CSMs needed to know whether a driver needed intervention before reaching out — and understand why the system had flagged them.
What he needs
A ranked view showing who needs help most urgently and why, grounded in activity and payment signals he can explain to a driver.
- Role
- Customer Success Manager
- Systems he checks
- Odoo, GPS, Yango, spreadsheets
- Decision he makes
- Who to check on first
What that meant for the roadmap
Two things had to be true before anything else: the activity and payment data had to be reliable, and a flagged driver had to come with a reason. That’s why explainability went into P0 and the ranked Priority Queue into P1.
03My role
I owned the roadmap, requirements, and prioritization.
Tiffany Liu and Isabella Raffo led product design, while I kept design and engineering aligned around the same priorities.
Product managementAllison Qiu
Product designTiffany Liu
Isabella Raffo
Isabella Raffo
EngineeringTech lead · developers
What I owned
Requirements
Wrote the PRD and the requirements the designers and developers built from.
Prioritization
Set P0, P1, and P2, including what we chose not to build this semester.
Data model
Worked with the tech lead to define the activity and payment data the product needed.
Product decisions
Decided to make explainability P0, hold predictive scoring in P1, and move forward with synthetic data while real data was delayed.
Dependencies
Separated blocked work from what the team could keep moving while dependencies were unresolved.
Coordination
Kept design and engineering working from the same priorities week to week.
04The data problem
Before we could design the dashboards, we had to know which data we could rely on.
Driver activity and payment data came from four places. Their reliability and availability shaped what we could prioritize first.
System of recordOdoo
Where driver and payment records lived.
ManualSpreadsheets
Filled in by hand, so gaps and errors were possible.
ActivityGPS API
Vehicle movement, speed, and engine status.
ActivityYango API
Trip and earnings activity from the ride-hailing side.
Why this set the order
The screens were only going to be useful if the activity and payment data behind them held up, so I worked with our tech lead on the data model before we scoped any views. Reliable data and interpretable performance logic had to come before the views built on top of them.
05Roadmap
I wrote the PRD, then split the product into what we’d build first, next, and not yet.
I worked with our tech lead to define the data we needed, then prioritized the product around those dependencies. Each tier reflects what we needed first and what we intentionally deferred.
P0Ship first
Authentication and the core Driver Performance Overview — nothing else mattered if admins couldn’t trust the data.
Admin and CSM dashboards focused on the same two things: real activity and payment status.
P1Once the data held up
The Priority Queue view and risk scoring, giving CSMs a clear read on who to check on first.
Trade-off
Held predictive risk scoring until the system could explain itself — flagging a driver without a reason wasn’t good enough.
P2Deferred
Trade-off
The driver-facing mobile dashboard and rewards, since admins and CSMs needed visibility first.
Trade-off
CSM messaging and CSM performance scoring, so CSMs had support tools before messaging tools.
We treated explainability as a requirement from the start.
If the platform flagged a driver, admins needed to see which activity or payment signals contributed.
Decision — explainability as P0
06Decision — explainability as P0
Product question
What does someone need to see to understand a driver’s score?
My decision
I made explainability a P0 requirement: admins needed to see which activity and payment signals contributed to a driver’s score.
- 01
The breakdown shows the weight behind each factor: payment timeliness, hours worked, collection rate, portfolio risk.
- 02
Collection Rate and % Portfolio at Risk are shown as ratios, so an admin can check the math.
- 03
An admin can point to the reason a driver was flagged, which is what the requirements asked for.
07Decision — holding predictive scoring
Predictive scoring stayed in P1 until we could explain the results.
Why it was valuable
Risk scoring would give CSMs a clear read on who to check on first, instead of working through their drivers one by one.
Why it wasn’t P0
A risk label without a clear reason wouldn’t give CSMs enough information to understand or act on it.
Decision — working with synthetic data
08Decision — working with synthetic data
- The dependency
Access to real driver data was delayed beyond our team’s control.
- My decision
I chose to move forward with synthetic activity and payment patterns so design and development could keep moving while we waited.
- What it didn’t fix
Synthetic data kept the team moving, but it did not validate that the scoring would behave correctly with real drivers.
09The team’s output
What the team designed from those requirements.
- Credit
- Product design: Tiffany Liu · Isabella Raffo
- Product management: Allison Qiu
02
Vehicle activity
Traces back to
The P0 requirement that inactivity carry context: whether a vehicle is moving, parked, or has been offline for a longer stretch.
03
Revenue and default rate
Traces back to
The payment half of the P0 data set, shown as trends rather than a single current balance.
04
Manage users
Traces back to
The verification and role requirements, including Drivers Assigned so admins can see CSM workload.
05
Authentication
Traces back to
P0 alongside the core data — role-based access was a prerequisite, not a feature.
10Outcome & reflection
This was my first time owning the product roadmap instead of contributing to one part of a project.
What the team got done
By the end of the semester, the team had designed the P0 experience — authentication, driver performance and score breakdowns, and the admin and CSM dashboards — along with the P1 Priority Queue. The driver-facing app, rewards, and CSM messaging remained intentionally out of scope. Tiffany Liu and Isabella Raffo designed the interfaces from the requirements and priorities I defined.
What I learned
01
Product decisions depended on the data.
I learned that I couldn’t make useful roadmap decisions without understanding the data and logic underneath the interface. Working closely with our tech lead made me more comfortable asking technical questions until I understood the constraints well enough to make the call.
02
Prioritization meant choosing what not to build.
Putting reliable driver data first meant delaying the driver-facing app and CSM messaging. I also learned to separate the work we could keep moving from dependencies, like real data access, that the team couldn’t control.
What still needed validation
Synthetic data kept design and development moving while access to real driver data was delayed, but it never showed that the scoring would behave correctly on real drivers. That was still open when the semester ended.
