Nobody owns the car because mobility-as-a-service isn't one product with one user — it's three markets stapled together: riders who want low prices, drivers who want predictable earnings, and fleet operators who want vehicle utilization. A feature that delights one side routinely taxes another, so the real job of a MaaS product manager is arbitrating tradeoffs, not maximizing satisfaction.
Quick answer: In fleet, ride-hail, and MaaS products, riders, drivers, and fleet operators each define "good" differently — cheaper trips, higher earnings, and higher utilization pull in different directions. Score every feature against all three before shipping, and treat any feature that only wins for one side as a zero-sum tradeoff wearing a positive metric.
Why "The User" Is a Fiction in Multi-Sided Mobility Products
Mobility-as-a-service has no single user because one trip creates at least three distinct transactions: a rider buying a service, a driver selling labor and vehicle capacity, and an operator managing a fleet's utilization, safety, and compliance. Collapsing these three into one persona hides the tradeoffs that actually decide whether a feature works.
Each side's definition of "good" is genuinely incompatible with the others' at the margin:
- Rider's good: low price per trip, short wait, a reliable ETA, safety, and comfort.
- Driver's good: high earnings per hour actually online, low idle and dead-mileage time, predictable demand, and a dispatch algorithm perceived as fair.
- Operator's good: high fleet utilization, low churn on both sides simultaneously, healthy margin per trip, and defensible safety and regulatory compliance.
Product teams often inherit persona habits from single-sided software, where "the user" and "the customer" are close enough to blend without real cost. Ride-hail and fleet products don't get that shortcut: the rider requesting a trip and the driver accepting it sit on opposite sides of the same transaction, and the operator underneath funds the vehicles, insurance, and dispatch logic that makes the transaction possible at all.
Economists Jean-Charles Rochet and Jean Tirole formalized this pattern as a two-sided market: a platform's central design problem is the price and allocation split it sets between two participating sides, not the experience of either side alone. That body of work fed into Tirole's 2014 Nobel Prize in Economics for his analysis of market power and regulation — a reminder that "balance the sides" isn't a soft PM heuristic, it's the platform's actual economic function.
For a broader map of how mobility products differ from ordinary software in shape and risk, see the complete guide to automotive and mobility product management — this article goes deep on one slice of that terrain.
None of the three sides' definitions of "good" above are wrong. They're just not the same "good," and a feature that improves one routinely taxes at least one of the others.
It Isn't Just Ride-Hail
The same three-sided pattern shows up anywhere a fleet sits between a rider or user and an operator. A corporate car-share program has an employee (rider), a maintenance or repositioning technician (the driver-equivalent), and a fleet manager (operator) balancing utilization against a fixed capital budget. A scooter or bike-share network swaps the human driver for a field technician who rebalances and charges vehicles overnight, but the tension between rider price, technician workload, and operator utilization is identical.
Even a transit-integrated MaaS app bundling buses, trains, and micromobility into one subscription still has to arbitrate between passenger price sensitivity and each operator's own utilization targets. Fleet product manager is a broader job title than "ride-hail PM," and the three-ledger discipline in this article applies regardless of whether the vehicle has a human driver in it at all.
The Three Ledgers Every Mobility Feature Touches
Every mobility feature moves three separate ledgers at once — the rider's price-and-wait ledger, the driver's earnings-and-effort ledger, and the operator's utilization-and-margin ledger. A metric improvement reported on only one ledger is incomplete evidence, not proof the feature is a net positive for the product.
Making the ledgers explicit is what stops a roadmap review from turning into a debate about whose anecdote is more persuasive. Instead of "riders love it" versus "drivers hate it," you name the specific metric each side tracks and argue from there.
| Ledger | Owned by | Core metrics | What "winning" looks like | What quietly breaks it |
|---|---|---|---|---|
| Price-and-wait | Rider | price per trip, wait time, ETA reliability, completion rate | lower effective price, short predictable wait | surge spikes, forced detours, unexplained cancellations |
| Earnings-and-effort | Driver | earnings per online hour, acceptance rate, idle time, dead mileage | higher take-home per hour worked, predictable demand windows | reassignment mid-trip, price cuts chasing rider volume |
| Utilization-and-margin | Fleet operator | utilization %, revenue per vehicle per day, maintenance cost per mile, safety incidents | high utilization without rider or driver churn | overpromising ETAs, underpaying to protect margin, deferred maintenance |
The same lever frequently moves all three ledgers in opposite directions. Cutting price to win rider volume helps the price-and-wait ledger and can lift utilization short-term, but it squeezes driver earnings-per-hour unless the operator absorbs the difference — which surfaces later as a margin problem or driver attrition.
Fleet uptime is its own quiet lever here. A vehicle stuck for a firmware or dispatch-software update is a vehicle earning nothing on any ledger, which is why how a fleet handles over-the-air updates to vehicles already in service is a genuine product decision, not just an engineering one.
A Framework for Scoring Features Across Riders, Drivers, and Operators
Score every roadmap feature from -2 to +2 on each side's primary ledger metric, sum the three for a net score, and separately track the spread between the highest and lowest side score. A high net score built on one deeply negative side score isn't a win — it's a subsidized loss waiting to surface as churn.
Call this a Tri-Side Score. It borrows the discipline of RICE-style prioritization — force a number instead of a vibe — but replaces a single blended "impact" field with three, because blending is exactly where multi-sided products lose information.
- Define the primary metric per side from the ledger table above (price/wait for riders, earnings/hour for drivers, utilization/margin for operators).
- Score expected directional impact, -2 (much worse) to +2 (much better), from actual evidence — a pilot, historical price elasticity, driver survey data — not intuition.
- Sum the three scores into a Net Tri-Side Score.
- Compute the spread: highest side score minus lowest side score.
- Flag anything with a spread of 3 or more, or any single side scoring -1 or below, as a zero-sum candidate that needs an explicit compensating mechanism before it ships.
| Feature | Rider score | Driver score | Operator score | Net | Spread | Verdict |
|---|---|---|---|---|---|---|
| Surge multiplier increase | -2 | +1 | +2 | +1 | 4 | Zero-sum flagged |
| Forced pooling as default | -1 | -1 | +2 | 0 | 3 | Zero-sum flagged |
| Guaranteed driver earnings floor | 0 | +2 | -1 | +1 | 3 | Zero-sum, intentional cross-subsidy |
| Predictive fleet rebalancing | +1 | +1 | +1 | +3 | 0 | Aligned win — ship |
Only the last row is genuinely positive-sum: every side moves the same direction, so the spread is zero. The first three all post a positive net score, which is exactly why net score alone is a dangerous single metric here — it hides which side is quietly funding the "win."
The exact spread threshold is a judgment call your organization should set deliberately, not borrow from this article. A subscription MaaS product with thin per-trip margins might treat a spread of 2 as disqualifying, while a fleet with a stronger balance sheet might tolerate a spread of 3 if the compensating mechanism is explicit and funded. What matters is picking a number in advance, in a planning meeting, rather than deciding case by case under launch pressure — that's when a genuinely zero-sum feature quietly gets waved through.
How to Detect a Zero-Sum Tradeoff Before You Ship It
A zero-sum tradeoff is hiding whenever a feature's net score looks positive only because one side's loss is being averaged away by another side's gain. Run three checks before shipping: does any side's score fall below zero, does the spread cross your threshold, and can you name the specific mechanism that compensates the losing side.
Surge pricing is the clearest case study. The naive read is that surge is a clean win: the platform earns more per trip, drivers earn a bonus, and only the rider pays the difference. A 2015 Northeastern University study of Uber's surge algorithm, "Peeking Beneath the Hood of Uber" by Chen, Mislove, and Wilson, found the pricing engine ran on discrete geographic cells with sharp boundaries — riders a block apart could see very different multipliers.
The same research documented drivers learning to game those boundaries, clustering or briefly going offline to help trigger a surge. Earnings went up, but so did driver distrust of the algorithm itself, a cost that never shows up in an earnings-per-hour metric. If you only score the driver ledger on earnings per online hour, you miss the algorithmic trust sub-metric entirely — a feature can look driver-positive while quietly eroding the thing that keeps drivers on the platform long-term.
Forced pooling is the mirror case. Dynamic ride-pooling can be a genuine operator win: a widely cited MIT study (Alonso-Mora et al., published in PNAS in 2017) modeled Manhattan taxi demand and found that roughly 3,000 four-passenger vehicles, dispatched by a real-time pooling algorithm, could serve about 98% of it with an average wait near 2.7 minutes — versus the roughly 13,000 taxis operating today. That's a substantial gain on the operator's utilization ledger.
Forced pooling moves the rider ledger the opposite direction, though: less control over route and stop order, a longer and less predictable trip, and a real safety-and-comfort dimension around riding with an unknown co-passenger — the kind of concern covered in why safety-critical UX carries physical consequences.
The driver sits in between on this one: more fares per hour, but the dispatch algorithm is now making real-time multi-stop routing decisions the driver must execute correctly under time pressure. That's a version of the handoff problem explored in how AI dispatch decisions hand off to a human driver.
Three tells that a reported "win" is actually zero-sum in disguise:
- The metric moved because of a transfer, not a genuine improvement — price didn't fall, it shifted from one side's ledger to another's.
- The win required no corresponding investment. A free lunch across a real marketplace is rare; if nobody visibly paid for the gain, look harder for who did.
- A blended metric diluted a negative score — a combined satisfaction index averaging rider and driver responses can post "up" while one side is actually down.
Separating the Jobs Instead of Collapsing the Persona
The fastest way to stop blurring three stakeholders into one persona is to write each side's job-to-be-done separately, with its own outcomes and its own forces of progress, instead of one "user" story that quietly favors whichever side the team talks to most often.
Jobs-to-be-done framing, formalized by Clayton Christensen and extended into a scoring method by Tony Ulwick's Outcome-Driven Innovation, forces you to state the outcome each side is "hiring" a trip for. A rider is hiring the ride to arrive predictably and safely; a driver is hiring the shift to convert hours into income at an acceptable effort level; an operator is hiring the fleet to convert capital into utilized, compliant, revenue-generating vehicle-hours.
Ulwick's opportunity-scoring formula — importance plus the gap between importance and satisfaction — gives each of those three jobs its own underserved-outcome number instead of one blended one. Bob Moesta's Forces of Progress (the push toward change, the pull of a new solution, the anxiety about switching, and the habit of the status quo) does the same for the why now.
A feature can carry strong pull for riders while simultaneously spiking anxiety for drivers, and a single persona document has no way to show both at once. For the underlying mechanics of this method, see the complete guide to jobs-to-be-done.
Written as job stories, the difference is concrete. A rider's job story might read: when I need to cross town in rush hour, help me arrive in a predictable window, so I don't overcommit to a meeting I might miss. A driver's version of that same feature might read: when demand is unpredictable, help me forecast my earnings for the shift, so I don't waste unpaid hours sitting online. Side by side, these are clearly different jobs — not two facets of one persona.
This is exactly the gap Prodinja's Customer Jobs tool is built to close. It lets you write out separate job stories for rider, driver, and fleet operator side by side, score each one's underserved outcomes with Ulwick's opportunity formula, and map each side's Forces of Progress independently.
Instead of a single "user" card sitting on your board, you get three — so a feature that scores as a strong opportunity for riders but a high-anxiety, low-opportunity job for drivers is visible before it ships, not discovered afterward when drivers start declining trips.
It's also worth mapping each side's emotional arc through the same trip separately rather than as one shared timeline — a rider's anxiety typically peaks at pickup, a driver's often peaks at drop-off in an unfamiliar zone. That kind of divergence is exactly what a customer journey mapping approach is built to surface once you stop forcing both journeys onto one line.
Key Takeaways
- Mobility-as-a-service has no single user — riders, drivers, and fleet operators each define "good" differently, and a persona that blends them hides the real tradeoff.
- Every feature moves three ledgers at once: rider price-and-wait, driver earnings-and-effort, operator utilization-and-margin — score against all three, not just the one your team is closest to.
- A
Tri-Side Score— net score plus the spread between sides — catches zero-sum tradeoffs that a single blended metric hides. - Surge pricing and forced pooling are textbook zero-sum patterns: an operator or platform gain that reads as a "win" while quietly taxing rider control or driver trust.
- Watch for the three tells of a disguised zero-sum: a transfer mislabeled as improvement, a win with no visible funding source, and a blended metric averaging away a real loss.
- Score each side's job-to-be-done separately, with its own
Ulwickopportunity score andForces of Progress, instead of writing one persona for three different economic actors.
Frequently Asked Questions
What does "mobility as a service product management" actually mean day to day?
It means every feature decision gets evaluated against three separate stakeholders — rider, driver, and fleet operator — rather than one blended "user." Day to day, that shows up as scoring roadmap items on each side's ledger metric before prioritizing, and writing separate job stories instead of a single combined persona brief.
How is fleet product management different from ride-hail product management?
Fleet product management usually owns the vehicles and operations side directly — utilization, maintenance, uptime, depot logistics — while ride-hail product management typically also owns the two-sided marketplace of independent drivers and riders on top of that. Many modern MaaS products now do both at once, which is exactly why the three-ledger framing in this article applies to either job description.
Is surge pricing actually fair to drivers?
Surge pricing does raise driver earnings during the surge window, but published analysis of Uber's algorithm found sharp, cell-based price boundaries that some drivers learned to game by clustering or briefly going offline. That erodes trust in the algorithm independent of the earnings bump, so fair on the earnings ledger and fair on the trust ledger are two different questions.
Why do riders dislike forced pooling even when it's cheaper?
Forced pooling trades rider control and predictability — route, stop order, and who else is in the vehicle — for a lower price and better fleet utilization. Research modeling large-scale ride-pooling shows real utilization gains are achievable at scale, but that gain is funded by the rider's loss of control and privacy, not created for free.
What framework should a PM use to compare rider, driver, and operator impact?
Score each side's primary ledger metric from -2 to +2 for a candidate feature, sum for a net score, and separately compute the spread between the highest and lowest side score. Treat any high spread, or any negative individual side score, as a zero-sum tradeoff that needs an explicit, named compensating mechanism before shipping, not a hopeful assumption.