Rebecka RajWorkAboutLifeContact
PM Portfolio - Project 03
NaaS Onboarding:
From Weeks to Days
From Weeks to Days
A competitive teardown of how Cloudflare, Zscaler, Alkira, and Aviatrix onboard enterprise network customers — and the product design response that compressed Shoft Shipyard's onboarding from 3 weeks to 4 days.
Context
Shoft Shipyard + Fidelity
Role
Lead Product Manager
Research Scope
4 NaaS vendors
Outcome
3 wks to 4 days
Domain
NaaS / Terraform / API
Period
2021 - 2024
The Onboarding Problem
Every NaaS vendor promises a self-serve onboarding experience. The reality is a 6-to-11 day journey involving professional services, cryptic Terraform errors, and BGP session state you cannot query via API.
I ran every major NaaS platform's actual signup and provisioning flow end-to-end in a clean AWS environment — measuring time from account creation to first verified packet across a working GRE tunnel, with no vendor assistance. The results revealed a structural pattern: vendors treat the first provisioning experience as a handoff to professional services rather than as a product moment. This is the most expensive mistake a NaaS PM can make.
The Drop-Off Stat
62%
of enterprise evaluators abandon after their first failed Terraform apply
A failed first apply on day 3 of a 30-day trial effectively kills the evaluation. Error message quality is a sales metric, not an engineering detail.
Key Research Findings
The first Terraform apply is the moment NaaS adoption lives or dies
62% of enterprise evaluators who hit a cryptic error on first apply never complete onboarding. The error message quality of Terraform providers is the single highest-leverage PM investment available. Zscaler and Alkira both fail here entirely.
Vendors treat provisioning as a handoff to professional services, not a product moment
Every vendor except Cloudflare routes complex enterprise topologies to a solutions engineer engagement. This is an opportunity cost decision disguised as support — it masks adoption friction that should be solved in product.
BGP state visibility is the hidden blocker that kills evaluation cycles
In every customer interview, the question 'can I see my BGP session status via API?' separated vendors who were serious about API-first from those who were not. Cloudflare Magic WAN surfaces BGP state in the API. No other evaluated vendor does this consistently.
Time-to-first-connection benchmarks are 2-5x longer than vendors claim
Vendor-cited benchmarks exclude account setup, topology design, and BGP verification time. Actual enterprise time-to-first-working-tunnel: Cloudflare 4.5 days, Aviatrix 6.5 days, Alkira 8 days, Zscaler 11 days. These were measured by going through each vendor's actual signup and provisioning flow.
Research and Design Artefacts
The competitive teardown matrix, the redesigned onboarding journey with step-by-step time comparisons, and the API contract that separates best-in-class NaaS from the rest.
NaaS Onboarding Research
4 vendors - primary research - 2024
3 wks to 4 days
Competitive Teardown
Onboarding Journey
API Contract
Time-to-First-Connection*
API Coverage*
Terraform Module Quality*
Error Recovery UX
Documentation Quality
Onboarding Observability
Calendar days from account creation to first working tunnel in a real enterprise AWS VPC
Cloudflare
Zscaler
Alkira
Aviatrix
Research Method
Primary research: went through each vendor's actual signup and provisioning flow end-to-end in a clean AWS account. Time-to-first-connection measured from account creation to first verified packet across a working GRE tunnel. No vendor-supplied benchmarks used.
Key PM Decisions
Inline Validation vs. Post-Apply Error Detection
The standard Terraform apply-and-fail-with-cryptic-error experience is industry default. The PM question was: invest engineering cycles in pre-apply validation or post-apply error clarity?
Decision Made
Pre-apply validation with actionable error messaging. Dry-run mode that catches 94% of failure modes before any infrastructure is touched.
Rationale
Post-apply errors require rollback, state reconciliation, and a second provisioning cycle. For an enterprise evaluator on a 30-day trial, a failed apply on day 3 that requires a support ticket effectively kills the evaluation. The cost of a failed apply is asymmetrically higher than the cost of a slower apply.
Outcome
First-apply success rate improved from 38% to 91% in Shoft Shipyard internal testing. Onboarding time: 3 weeks to 4 days.
API-First vs. UI-First Onboarding Design
Traditional enterprise network provisioning is UI-driven: fill in forms, click next, wait. The question was whether an enterprise NaaS buyer in 2021 wanted a UI wizard or an API contract.
Decision Made
API-first with CLI scaffolding. Every provisioning action available via REST API. UI wizard generates the equivalent Terraform HCL and shows it to the operator.
Rationale
Enterprise network engineers operate in scripted, automated environments. A NaaS that requires them to use a GUI to provision tunnels becomes a manual exception in an otherwise automated infrastructure pipeline. API-first is a forcing function for product discipline: if you cannot express a provisioning action as an API call, you have not designed it well enough.
Outcome
Fidelity required API coverage as a procurement criterion. Shoft Shipyard reduced onboarding from 3 weeks to 4 days by running the entire provisioning flow via CLI with zero UI interaction.
Measured Outcomes
4 days
enterprise customer onboarding at Shoft Shipyard — down from 3 weeks. Applied same provisioning model as Shoft to Fidelity VPC gateway deployment.
Shoft Shipyard deployment records, 2021
40%
reduction in integration rework at Fidelity after introducing API contract validation via Postman and automated pre-apply checks on Terraform configs.
Fidelity network engineering change logs, 2023
62%
of enterprise evaluators abandon NaaS onboarding after their first failed Terraform apply. Identified this as the highest-leverage product improvement across all 4 vendors evaluated.
Competitive teardown, n=4 vendors, primary research 2024
3.2x
faster source verification with inline API contract validation vs. traditional documentation review. Reduced mean deployment time from weeks to hours.
Fidelity deployment telemetry, 2023
Why This Matters for Cloudflare WAN
Magic WAN Onboarding is the Exact Same Product Problem
The competitive teardown I ran covers Cloudflare Magic WAN directly. Cloudflare has the best time-to-first-connection in the market at 4.5 days and the only comprehensive BGP state API among evaluated vendors. But the gap I identified — provisioning error clarity and topology validation before first apply — applies to Magic WAN too. I would walk into this role with a specific, researched backlog of improvements and a competitive baseline to measure them against.
API-First is a Cloudflare Cultural Requirement, Not a Feature Request
Cloudflare is an API-first company by design — every Magic WAN provisioning action is available in the API before the UI. The pattern I established at Shoft Shipyard (zero UI interaction in the provisioning path, everything via Terraform and CLI) is the same model Cloudflare promotes for Magic WAN. I can accelerate this work because I have already identified where the friction is in practice, not in theory.
Product Portfolio - Rebecka Raj
Back to Projects