Fleet expansion, rider adoption in geo-limited launch markets, and developer ecosystem growth all require instrumented systems – not campaign spend. Winston Francois works with autonomy teams to design and build the data pipelines, experimentation infrastructure, and activation loops that compound growth over time. We start where your engineering team is, not where a generic growth playbook says you should be.
The Problem
Fleet Expansion Is Not Measured Like Consumer Growth
Robotaxi and freight autonomy companies scale by deploying vehicles into corridors and markets, not by acquiring individual users through a funnel. Most growth frameworks are built for the second model and fail badly at the first. The metrics that matter – corridor utilization, dispatch efficiency, geofence density, asset uptime – are not covered by standard marketing analytics tools. AV growth teams often end up with a fragmented picture of what is actually driving fleet performance because the systems were not built to answer those questions.
Rider Activation in Launch Markets Stalls After Initial Interest
Robotaxi launches typically generate strong press coverage and early demand. The gap shows up at ride two and ride three – getting users from 'I tried it' to 'this is how I get around.' The onboarding and reactivation systems that consumer apps rely on do not translate directly to AV. Trust is a variable in the conversion equation that most growth engineers are not set up to optimize for explicitly, and the feedback loops are slower because the product interactions are less frequent than a mobile app.
Developer Ecosystem Growth Requires a Different Funnel
AV companies that expose an SDK or API for ADAS or mapping integration need developer acquisition, activation, and retention systems distinct from their consumer growth stack. Developer funnels are documentation-first, not ad-first. The activation metric is a successful first API call, not a purchase. The retention metric is integration depth, not session frequency. Building the infrastructure to track and improve those metrics requires engineering effort that most AV product teams deprioritize against vehicle software roadmaps.
Growth Instrumentation Is Built After the Fact
Most AV companies build their core vehicle software first and instrument it for growth second – or never. This means that when leadership asks whether a new corridor is performing, or whether a pricing change moved rider frequency, or whether a documentation update increased SDK adoption, the data is not available or is spread across systems that were not designed to talk to each other. Retroactive instrumentation is expensive and never fully closes the gap that early neglect creates.
How We Help
Winston Francois starts AV growth engineering engagements with a systems audit. We map your current data infrastructure – what events are being captured, where they live, who has access to them, and what questions they can and cannot answer. We identify the growth-critical questions that your current stack cannot answer and prioritize them by the decisions they would unlock.
From that audit we define the instrumentation roadmap. For fleet-scale AV companies, this typically means corridor-level performance tracking, dispatch and utilization metrics, and rider lifecycle event capture. For developer-facing AV platforms, it means API call instrumentation, documentation interaction tracking, and integration depth measurement. We spec the work in enough detail that your engineering team can execute it, or we embed engineers to build it alongside you.
Activation systems are the next layer. For consumer robotaxi products, this means the triggered communications, in-app moments, and operational interventions that move a rider from first trip to habitual use. We design these systems around the trust dynamics specific to AV – a rider who had a rough first experience is not just churned, they are a reputational risk. The reactivation approach has to account for that.
For developer ecosystems, activation engineering means documentation architecture, interactive quickstarts, and the event-triggered support sequences that get a developer to their first successful integration. We build or improve the systems that track where developers get stuck and route them to the right resource before they abandon the integration.
Measurement and iteration are built in from the start. Every system we design has a clear primary metric, a clear baseline, and a clear method for detecting whether interventions are working. We do not hand off a system that the team cannot maintain and improve. Every engagement ends with documentation, ownership assignment, and a 90-day measurement plan.
What we deliver
- Growth instrumentation audit and gap analysis
- Data pipeline and event tracking specifications
- Rider or developer activation system design and build
- Corridor and fleet performance reporting framework
- 90-day measurement plan with ownership assignments
Fleet utilization, corridor performance, and developer integration depth are growth metrics – but most AV companies track them in engineering dashboards that no one in growth can access. The system gap is the growth gap.
Our Methodology
Winston Francois runs growth engineering engagements in 90-day sprints with a deliberate sequence. The first 30 days are diagnostic – systems audit, stakeholder interviews, metric prioritization. We produce a written brief that names the three to five growth questions that, if answerable, would change how the business makes decisions. That brief drives everything that follows.
Days 31 through 60 are build phase. We work in your existing infrastructure, not against it. We do not propose a new data warehouse when the issue is that your existing one is not being queried correctly. We write specs, build or supervise the build of instrumentation, and deliver working systems that can be demonstrated before the engagement ends.
The final 30 days are validation and handoff. We run the first reporting cycles with the new systems, document everything, and train the team that will own ongoing operation. We do not measure success by delivery – we measure it by whether the systems are being used to make decisions 90 days after handoff.
How We Work
Growth engineering engagements at Winston Francois are structured around a defined systems scope, not open-ended retainers. We agree on the growth questions we are trying to answer, the infrastructure we will build to answer them, and the timeline upfront.
In the first 30 days we audit your current stack, interview your engineering and growth leads, and produce a prioritized roadmap. The roadmap is practical – it accounts for your current team capacity, your existing infrastructure, and the regulatory constraints that affect what you can instrument and how.
Days 31 through 60 are build. We work directly in your systems, write specs your team can execute, or provide embedded engineers when your team does not have the bandwidth. We hold weekly syncs with your engineering and growth leads to surface blockers early.
The final 30 days are validation and handoff. We document every system we build, run the first live reporting cycles, and train the team that will own ongoing operation. The engagement ends with a 90-day measurement plan that tells you what to watch and what to do when numbers move.
- Growth-critical questions answered by instrumented systems, not guesswork
- Rider or developer activation systems that improve conversion and retention
- Fleet and corridor performance visibility that informs operational decisions
- Engineering and growth teams aligned on the same metrics and reporting cadence
If your autonomous vehicles company needs growth engineering leadership, we should talk.
Expand your marketing team output with our experts
Let us take a custom approach to your growth goals by assembling and leading the best-in-class marketing team to support your next stage.
Frequently asked questions
How does growth engineering for a robotaxi company differ from growth engineering for a consumer app?
The core difference is that the product experience is physical, geographically constrained, and happens at low frequency compared to a mobile app. A robotaxi user might take three to five trips per week at most – far fewer interaction moments than a social or e-commerce platform.
What does developer ecosystem growth look like for an AV company with an SDK or API?
Developer growth in AV follows the same general shape as any developer platform – documentation quality, time to first successful API call, integration depth, and community health are the primary levers. What is different in AV is the stakes: a developer integrating your ADAS API into a production system is taking on liability in a way that a payments API developer is not. Trust and safety documentation are part of the activation funnel, not separate from it. Growth engineering for AV developer platforms has to account for that extended evaluation cycle.
When should an AV company invest in dedicated growth engineering infrastructure?
The right time is typically around Series B, when you have a product in market and a growth team that is trying to run experiments but cannot get answers from the current data infrastructure. Before that point, the vehicle software roadmap usually absorbs all engineering capacity and growth instrumentation gets deferred. After Series B, the cost of that deferral starts to compound – decisions are being made on incomplete data, experiments cannot be evaluated cleanly, and the growth team is partially blind.
Should our growth engineers be embedded in the product team or sit separately?
There is no single right answer, but the failure mode to avoid is growth engineering as a service function that receives feature requests from a growth marketing team. In AV specifically, the most important growth levers – dispatch logic, geofence expansion criteria, onboarding flow, developer documentation architecture – require close coordination with core product and vehicle software teams. Growth engineers need enough proximity to those teams to influence decisions before they are locked in, not just to instrument them after the fact.
What are the most important growth metrics for an early-stage robotaxi company?
In rough priority order: corridor utilization rate (are the vehicles you have deployed being used?), rider retention at 30 and 90 days (are early users becoming habitual?), wait time distribution (is operational reliability within the threshold where users trust the service?), and net ride request fulfillment rate (are you capturing the demand that exists in your geofence?). Revenue per vehicle per day synthesizes several of these and connects growth performance to unit economics.
Can growth engineering help if our core data infrastructure is already in poor shape?
Yes, and it often has to. Most AV companies arrive at a formal growth engineering engagement with data infrastructure built to answer vehicle safety and performance questions, not rider or developer growth questions. The first phase of every engagement is an honest audit of what you have and what it can answer. We build from where you are, not from an idealized starting point. In some cases the right first move is a targeted instrumentation project before any experimentation infrastructure is built.
