Piloted a new parking-reservations revenue stream in Seattle, and learned that a pandemic-driven parking glut, not the product, was likely holding adoption back.
Context
Role
Senior Product Designer on the New Revenue Streams initiative.
Timeline
2020, roughly 6 months from research to the Seattle pilot launch.
Team
Sole designer, working with a PM, engineers, and Business/Partnerships stakeholders in a cross-functional pod.
Key constraint
Tight engineering deadlines and API limitations from the reservation partner constrained both scope and where the feature could live in the app.
Where things stood
PayByPhone was built around moment-of-need parking payments. A partnership with a large North American reservation provider created an opportunity to expand into advance reservations (new inventory, a potential new revenue stream), but nothing like it existed in the product yet.
The problem
Success depended on catching them in the exact moment they needed help.
Understood at the start
The opportunity looked straightforward: a partnership made reservations technically possible and commercially attractive, so building the feature seemed like the natural next step.
What it turned out to be
Most drivers don't think about parking until they need it, and very few even knew reservations were an option. Success didn't depend on convincing people to plan ahead. It depended on catching them in the exact moment they needed help.
Process
01
Validating demand before building
What was tried
Mixed-method research: interviews with high-need segments (event drivers, reps with multiple stops, delivery drivers, caregivers) plus a 62-respondent survey across 12+ countries.
Why
The team wanted to confirm people actually wanted reservations, not just that the partnership made it possible.
What it taught us
Fewer than 20% of users had ever reserved parking. The barrier was awareness and timing, not lack of desire.
Considered and rejected
Building straight from the partnership opportunity without user validation first.
[Diagram: high-need segments and their triggers]
02
Designing for the moment of stress, not advance planning
What was tried
Scenario-based user flows built around specific situations (running late, usual spot full) rather than a generic user persona.
Why
Research showed reservations only succeed if they show up exactly when someone's already stressed, not as a pre-planning habit.
What it taught us
Testing had to focus on trust and willingness-to-commit under pressure, not just basic usability.
Considered and rejected
A traditional plan-ahead booking flow modeled on how reservation systems normally work, which didn't match how people actually behave around parking.
[Screenshot: scenario-based reservation flow]
03
Cutting scope to protect the pilot deadline
What was tried
Dropping the parking-recommendations layer to focus purely on the reservation flow, and placing the feature inside the hamburger menu rather than the home screen due to integration complexity.
Why
Tight engineering deadlines and partner API limits meant the full vision wasn't shippable in time for a pilot.
What it taught us
This bought a clearer, more testable MVP, at the direct cost of discoverability. The team leaned on push notifications and in-app messaging to compensate.
Considered and rejected
Keeping the recommendations layer in scope, which would have delayed the pilot past its window.
[Diagram: scope cut and its effect on entry points]
Research and evidence
[Research and evidence the decisions above rested on]
The trade-off
Chose
A fast, focused pilot to test real demand.
Gave up
Home-screen discoverability and the recommendations layer that would have made the feature easier to find and use.
Proving whether the core idea worked at all mattered more than polishing an experience for a concept that hadn't been validated yet.
Outcome
Primary metric
The Seattle pilot saw lower adoption than hoped, but a second COVID lockdown hit shortly after launch, cutting driving activity and flooding the city with free on-street parking, undermining the exact scarcity problem reservations exist to solve.
What shipped
A standalone reservation flow, accessible via the hamburger menu, integrated with the partner's live inventory, tracked end-to-end in Amplitude (entry points, drop-offs, booking completion, reservation management).
What happened after
The team's working hypothesis was that low adoption was driven more by pandemic-suppressed demand than by the design itself, a fair but unproven explanation. Next steps were defined: re-test under higher-congestion conditions, re-evaluate entry points, improve education.
What I’d do differently
The pilot design made it hard to tell whether low adoption was a discoverability problem created by the team's own choices (hamburger-menu placement, cutting the recommendations layer) or a genuine demand problem caused by COVID. A future pilot should isolate those two variables rather than compounding a known discoverability trade-off with an already environmentally confounded launch window.