De-risking a product bet through rapid generative research with drivers, dispatchers, and fleet managers
Embedded UX Researcher via Craft, partnering directly with Arrive's product team
Designed and executed multi-channel recruitment across US, Norway, Germany
Built screeners, discussion guides, and synthesis frameworks
Conducted 30-minute guided interviews across 3 persona types
Led 3 stakeholder readouts and final recommendations
I partnered directly with Leander, a product manager based in the Netherlands who oversaw EU markets. I collaborated closely with product designers on Craft's side who were iterating on concepts in parallel, and with Arrive's regional directors who were invested in the EU market potential.
Finding blue-collar field service workers in 5 weeks
The target persona was hard to reach: blue-collar field service workers who park at multiple job sites daily, report to a dispatcher or fleet manager, and work in urban environments. Traditional research panels were unlikely to have strong coverage of this population.
| Channel | Pros | Cons | Decision |
|---|---|---|---|
| Existing B2B Contacts | High relevance, context-rich | Limited pool, compliance risk | Skip |
| Fleet Manager Referrals | Warm intro, better context | Slow, dependent on third party | Skip |
| Recruitment Platforms | Quality participants | 3-week lead time, limited persona | Skip |
| Craigslist | Fast, cheap, proven for persona | Manual screening needed | Selected |
Previous Craft researchers had found success recruiting blue-collar drivers via Craigslist. Given the 5-week timeline, this was the right tradeoff between speed, cost, and targeting precision.
Posted targeted ads across 10 US cities: NYC, Boston, Chicago, LA, SF, Miami, Seattle, Houston, Philadelphia, Phoenix
Limitation: Craigslist had no meaningful reach in Germany or Norway, so recruitment was US-only. This geographic constraint is a caveat on the findings.
Designed a Typeform Screener Survey to only target relevant personas
Field technicians who park and complete service jobs
Responsible for routing and scheduling
Strategic decisions about fleet operations
Deliberate oversampling of small fleets where product team believed the opportunity was largest
I used semi-structured interviews combining workflow discovery and concept evaluation. Each session followed a consistent structure, with discussion guides iterated between rounds based on emerging patterns.
Recommended parking per job, in-app navigation, availability data, distance and cost tradeoffs
Job-level recommendations, aggregate metrics, congestion patterns, cost trends
Shared research brainspace where internal Craft team members and external Arrive stakeholders could observe sessions and contribute notes in real time
Service drivers confirmed that finding parking near urban job sites is a consistent friction point. They described circling blocks, double-parking, feeding meters, and absorbing tickets as a cost of doing business. But parking existed within a broader context of fragmented workflows. Drivers were juggling Google Maps, SpotHero, Jobber, text messages, and phone calls. The desire was not just for parking help but for a single tool that handled routing, timing, parking, and client communication together.
"I was waiting 20 minutes, then parking really far and having to walk with my technician & our equipment. It was really bad. So a 7:30am - 3:30pm day, we went back to the branch to exchange our vehicles and leave and it was 7:45 pm."
Service Driver, Medium Fleet
The initial assumption was that fleet size would be the primary segmentation variable. Small fleets would have different needs than large fleets. This turned out to be incomplete. What actually predicted needs was technical maturity: how sophisticated a fleet's existing tooling was. Low-maturity fleets (using spreadsheets, Google Calendar, paper logs) had fundamentally different needs than high-maturity fleets (using Ignite, Fleetio, Samsara). A 30-vehicle fleet with no dedicated tools looked nothing like a 30-vehicle fleet with a full tech stack.
Google Calendar, paper logs, spreadsheets
7 participants
Need: Full workflow tool
One core tool (Jobber, ServiceTitan)
5 participants
Need: Parking guidance layer
Full tech stack (Ignite + Fleetio + Samsara)
7 participants
Need: Data enrichment only
This reframe changed the conversation from "how do we build this planner" to "who would actually use it, and in what form."
Even when dispatchers attempted to plan parking in advance, the final responsibility landed on the driver. Dispatchers might suggest options or provide general guidance, but when the driver arrived at a job site and the recommended spot was taken, they had to figure it out themselves. This meant the driver experience was critical, but it also meant that a dispatcher-facing planner alone would not solve the problem.
"One guy's got to go out and find the parking because they couldn't park anywhere at the job site. So that's all on them. They're big boys and girls out there. They can figure that out."
Dispatcher, High-Tech Maturity, Small Fleet
Users did not expect perfect accuracy for parking availability data, but they did expect accuracy to increase closer to the moment of parking. Trend-based data ("this area is typically 60% available at 10am") was seen as useful for planning. But if a driver was five minutes away from a job site, they expected near-real-time information or they would fall back to tools they already trusted, like SpotHero.
"[If it's not accurate in real-time], I think it's adding value. I think the question is whether it's adding enough value. If I was in a bind and I was worried about parking and I didn't have any alternative options, I would give it a try. But if I didn't know it was completely accurate and I was in a rush, I'd probably use SpotHero."
Service Driver
The research pointed toward a clear conclusion: a standalone Parking Planner was unlikely to achieve adoption. For low-maturity fleets, parking recommendations were only valuable bundled with job planning functionality. For medium and high-maturity fleets, the concept was only compelling as a data enrichment layer within their existing tools. This was not a failure of the concept but a clarification of where it could and could not fit.
Dark = Arrive standalone tool | Gray = Data enrichment into existing systems | Highlighted = Primary opportunity
The product team chose to pause MVP development pending further opportunity sizing. Rather than build a parking planner that lacked clear product-market fit, they redirected effort toward validating the low-maturity fleet hypothesis with quantitative research and exploring integration feasibility for the enrichment model.
"The most valuable contribution was the reframe around technical maturity. That shift changed the conversation from 'how do we build this planner' to 'who would actually use it, and in what form.'"
This project was an exercise in navigating through compressed, ambiguous engagements where the goal is not to polish a feature but to answer higher-level strategic questions. I was responsible for the full research arc, from recruitment logistics to stakeholder alignment to final recommendations, and I had to make continuous judgment calls about tradeoffs between speed and rigor.
The recruitment approach was unconventional. Craigslist is not a typical research channel, but it was the right tool for this persona and timeline. I documented risks, built in screener calls to validate quality, and was transparent about geographic limitations in the final findings.
This is the kind of research I find most interesting: work that sits at the intersection of product strategy and user understanding, where the output is not a design recommendation but a clearer picture of where opportunity exists and where it does not.
Recruitment Strategy Matrix
Typeform Screener
Craigslist Campaign
Driver Discussion Guide
Dispatcher Discussion Guide
Research Brainspace
Synthesis Framework
Stakeholder Presentations
Back to Arrive