Product-Led Growth
2022–2024 · User Researcher & Designer · Onomondo
Research that shifted the PLG story from feature push to connectivity and deployment size. Adopted by Customer Success and marketing.
The PLG initiative
Onomondo pursued a Product-Led Growth motion to drive upgrades and expand usage on its self-service SIM platform. Free login opened the platform to prospects. Users could browse the connectivity tools and order SIMs to test.
The initial upgrade motion: feature advertising banners, content blocking, contact forms.
It did not move trial accounts. Proof-of-concept customers pushed towards debugging features did not upgrade, or moved slowly.
74 of 121
proof-of-concept companies ended as Closed Lost.
64 of 79
proof-of-concept companies had five or fewer active SIMs. The median had 2.
Design focus: the landing dashboard.
Understanding customers
I stepped back from the push motion and asked two questions. Who is the real customer on this platform? And at what point does it become worth paying for?
The scaling cohort is small. The findings show patterns, not statistics.
Two user profiles
Profile 01
The Trial User
- Looking for instant connectivity
- Motivated by price advantage in a very specific, isolated use case
- Evaluating the product, not investing in it
- Needs: fast activation, instant proof of value, low friction
Profile 02
The Scaling User
- Deploying 5,000 to 50,000 devices per year across verticals like asset tracking, micro-mobility, oil and energy, smart cities and buildings, smart farming and shipping
- Small cross-functional teams: support engineers, software engineers, project managers, CTOs, hardware engineers
- Heavy API and webhook users integrating connectivity into internal systems, not evaluating a dashboard
- Building operational tools, not testing a solution
- Needs: control, bulk actions, network list management, device-level visibility, reliable data piped into their own systems
Different definitions of value. Different willingness to pay.
Scaling behaviour
We studied 23 scaling customers and their 71 active users. They were not set-and-forget. They used the platform every day.
47%
of all SIM update API calls platform-wide came from scaling users in the last twelve months.
17 of 23
scaling customers had active API keys making calls at least every six months.
8 of 23
were piping webhook events into their own internal systems.
19%
of SIM updates in the dashboard came from scaling users. They made 94% of their own SIM updates through the API.
Role actions
Each role came to the platform for a specific job and went straight to the page for it.
| Role | SIMs | SIM detail | Traffic Monitor | Network Lists | API Keys | Key finding |
|---|---|---|---|---|---|---|
| Support engineers18 users | The SIMs table is their most used page | |||||
| Software engineers14 users | Open single SIMs from links in their own tools | |||||
| CTOs9 users | 5 of 9 edited network lists, 2 created API keys | |||||
| CEOs9 users | Update SIMs more than any other role | |||||
| Hardware engineers5 users | Straight to the SIMs that need attention |
Value
The PLG motion was optimised for the trial user, who rarely gets there. It ignored the scaling user, who does.
Successful customers kept adding custom network lists as they grew: specific devices on specific networks in specific business areas. Reviewing a list was easy with a few countries and got harder as the number grew.
Trial
Scaling customer
One scaling customer, 20 monthsAsset tracking, 2 users
Why scaling customers pay for network lists
Coverage
Cover every country they need
Coverage came first. A country left out of a list means no connection there, and not every customer knew that.
Control
One list per customer
A reseller with several end customers wanted a separate list for each. The platform allowed one list per SIM.
Cost
See the price per network
Five asset-tracking and sensor customers asked for prices per network and country. Price varied a lot, but rarely decided the choice.
From network list customer sessions and session recordings.
26,010 of 26,012
network list API reads came from scaling users in the last twelve months.
5 of 9
CTOs at scaling customers edited a network list.
Who uses is not always who buys
Decision maker
Buys
Technical leadership / procurement
Cares about cost, reliability, scalability, security.
Daily user
Configures
IT admin / network manager
Cares about control, visibility, speed of configuration.
End device user
Relies on it
The person whose device connects
Does not know the SIM exists. Just needs it to work.
Designing for one of these people while ignoring the others breaks the entire experience.
Implications
What the findings meant for the design.
| Finding | Design implication |
|---|---|
| Trial users and scaling users value different things | Design for the scaling user. Keep the trial path short. |
| Coverage of the right countries comes before price | Lead the sign-up screen with the global network, not cost |
| Each role goes straight to its own page | Place one upgrade moment on each role's page |
| Scaling users make 94% of their SIM updates through the API | Show API Keys and Webhooks, gated at Pro, to the CTOs who set them up |
| Network lists grow with the fleet | Gate the Network Marketplace at Pro, on the page where lists are managed |
Log in screen
Four themes tested against the create-account form.
Connectivity map led
Lead with the global IoT network marketplace. Show coverage and reach next to the create-account form.
SIM factor led
Lead with the form-factor timeline: 1FF through SoftSIM. Show the product's full range next to the create-account form.
Social proof led
Lead with a customer quote about expanding into new countries. Credibility from a real deployment instead of the product pitch.
Map and network marketplace led
Focus on the map and network marketplace alongside the create-account form. Matched the marketing message and the global focus.
Single global network
Chosen from the four directions. One message, one map, the form.
"The smartest IoT connectivity platform" with a glowing global network map, next to the create-account form.
Coverage first
Lead with the network, not the price
In the network list research, coverage of the right countries came before cost. The map shows coverage, the reason a fleet signs up.
Scaling users
Built for fleets across markets
Scaling customers deploy 5,000 to 50,000 devices a year across countries. A global map speaks to them. A SIM form-factor timeline does not.
One message
Same story as marketing
Matched the marketing message and its global focus, and resonated best with sales and marketing of the four directions.
Empty state
A trial user lands in an empty app: zeros on every metric and a Fleet banner over the map. The one action is ordering 10 SIMs for 30 days.
Upgrade moments
Each role meets an upgrade on a page it already uses.
- Support engineersTraffic MonitorPro
- CTOsAPI KeysPro
- CTOs and CEOsNetwork Lists, Network MarketplacePro
- Software and hardware engineersSIM detail, Signaling LogsFleet
- CEOsDashboard mapFleet
The account upgrades when one of these roles converts. Role coverage is the growth lever, not visit count.
Onomondo platform
From SIMs: one SIM and its tabs
Every page a trial user can reach. Free pages are empty, the rest sit behind a plan. Click a screen to see it full size.
Outcome
As Onomondo moved towards product-led growth, marketing added coverage map information to the website. The same coverage-first message as the sign-up screen.
