ExpertsFMThe world of voice AI, with Mati Staniszewski of ElevenLabs
Cheeky Pint · April 14, 2026
5 Selected Lessons:
framework · 2 heuristic · 2 reasoning_pattern · 1
Build internal expert data-labeling teams for domain-specific annotation gaps
Source
Cheeky Pint — The world of voice AI, with Mati Staniszewski of ElevenLabs (April 14, 2026) · at 4:48 ▸ · at 8:08 ▸
When this applies
when off-the-shelf data labeling tools can't capture the nuance your model needs, and that nuance is the actual differentiator
The takeaway
When data quality is the bottleneck and the nuance required is domain-specific, insource and train your own labeling function rather than relying on generic vendors.
Why it works
Generic labelers can mark 'what' was said but not the subtler 'how' (emotion, speaker, accent); a trained internal team calibrated on the specific domain produces higher-fidelity training data that generic vendors can't.
One level up
Invest in proprietary data infrastructure when it is the actual source of competitive differentiation, not just the model architecture.
Where it stops holding
This stops working when the required annotation is generic/commodity (e.g. simple transcription) where off-the-shelf vendors are already adequate, or when the cost of building an internal team outweighs the marginal data-quality gain.
Detail
procedure:
- Recognize that raw data is abundant but mislabeled or under-labeled for your specific need (e.g. who's speaking, what emotion).
- Build an internal team of labelers coached specifically on audio/voice understanding.
- Combine semi-automatic and manual labeling techniques.
- If no adequate tool exists to do the annotation itself, build that tool internally — it may become a spinout product.
benchmarks: {}
rationale: Most generic labelers aren't well versed in audio/voice nuance, so quality requires purpose-built internal capability.
In their words
We would invest a lot internally on effectively creating our own data labelers, our own team to be able to create those datasets that will be better
Dual go-to-market motion: self-serve PLG plus high-touch enterprise deployment
Source
Cheeky Pint — The world of voice AI, with Mati Staniszewski of ElevenLabs (April 14, 2026) · at 44:08 ▸ · at 47:48 ▸
When this applies
when a product serves both small/fast-moving customers and large complex customers with very different needs
The takeaway
Run two parallel go-to-market motions calibrated to different customer complexity levels rather than forcing one model to fit both.
Why it works
Self-serve drives distribution, awareness, and rapid feedback for product evolution; a separate high-touch motion with deployed engineers customizes the same technology for the complex integration and reliability needs of large enterprise customers.
One level up
Segment go-to-market structure by customer complexity, not just by company size or deal size alone.
Where it stops holding
This stops working when the product is too simple to need enterprise customization, or too complex/regulated to be safely self-served at all.
Detail
procedure:
- Offer a self-serve PLG layer for distribution, awareness, and feedback.
- Offer a high-touch, deployed-engineering layer for the biggest enterprise accounts to customize deployment.
- Let cross-department 'land and expand' grow accounts organically (e.g. marketing use case expanding to customer support).
benchmarks: {"net_new_ARR_one_quarter":"$100M","total_ARR_end_2025":"$350M"}
rationale: Different customer segments need fundamentally different depth of engagement to realize value.
In their words
we have the full spectrum, self serve, PLG motion that helps distribution, drive awareness of ElevenLabs. And on the completely other spectrum, we have the high touch, four deployed engineering working side by side with the customers
Self-serve as a feedback and trust-building mechanism, not just a sales channel
Source
Cheeky Pint — The world of voice AI, with Mati Staniszewski of ElevenLabs (April 14, 2026) · at 47:48 ▸
When this applies
when deciding whether to gate a product behind sales calls or make it available for self-serve trial
The takeaway
Making your best technology available for anyone to try removes trust barriers and creates a continuous feedback loop that improves the product faster than gated sales processes.
Why it works
Removing friction (sign-up forms, sales calls, hidden pricing) lets users validate product quality for themselves, which both builds trust immediately and gives the company a fast feedback loop on what's working.
One level up
Reducing friction in how prospects evaluate your product is itself a competitive advantage, independent of the product's intrinsic quality.
Where it stops holding
This stops working when the product requires heavy customization, compliance review, or integration work before it delivers value — in which case self-serve alone won't convey the real experience, and some sales-led onboarding becomes necessary.
Detail
approach: Launch core technology in self-serve form from the earliest days, even as a two-person company.
signals:
- Friction before trying the product reduces trust that there's no hidden cost
- Self-serve users surface new/unanticipated use cases ('showing us the future')
- SMBs and developers get access to high-end use case technology before it's enterprise-ready
rationale: First-principles reasoning: the more friction before trying something, the less you trust it's genuinely available without hidden catches.
In their words
the more friction elements before you're trying it out, the less you trust whether it's available, whether there'll be additional payment that's hidden behind some of those steps, so you don't want to go through them
Stay horizontal platform where generic, cede domain-specific verticals to app builders
Source
Cheeky Pint — The world of voice AI, with Mati Staniszewski of ElevenLabs (April 14, 2026) · at 10:44 ▸
When this applies
when a platform company must decide where to build first-party applications versus leave room for an ecosystem
The takeaway
Build first-party products for horizontal, broadly-applicable needs; leave highly domain-specific, contextual use cases to a surrounding application ecosystem.
Why it works
Horizontal use cases benefit from being served directly by the platform's latest capability; deep domain specificity requires contextual knowledge the platform doesn't have, which application companies are better positioned to provide.
One level up
A platform's own product surface should track the generality of the need, not just capability of the underlying tech.
Where it stops holding
This stops working when fast-moving underlying technology makes ecosystem partners prone to running outdated versions, creating quality risk for end customers — which pushes the platform to go direct even in seemingly 'vertical' cases (e.g. closed captioning).
Detail
rule: Go horizontal and power the ecosystem where the use case is broadly applicable; let domain-specific application companies form elsewhere.
threshold: If the platform knows it can handle ~99.9% of a use case's needs (as with closed captioning) and the technology changes fast, consider going direct despite apparent vertical specificity.
rationale: Avoids stale-integration risk while reserving platform resources for generalizable value.
In their words
If you have a lot of domain specificity, that's where I see a lot of kind of the application companies forming over time, where will, where that's specifically not the spaces we will go into.
Choose cascaded (text-intermediate) architecture for enterprise reliability over speech-to-speech latency
Source
Cheeky Pint — The world of voice AI, with Mati Staniszewski of ElevenLabs (April 14, 2026) · at 25:27 ▸ · at 29:32 ▸
When this applies
when choosing between a faster end-to-end architecture and a slower but auditable, modular pipeline for a business-critical application
The takeaway
For business-critical, integration-heavy use cases, prefer modular/auditable architectures over faster end-to-end ones; reserve end-to-end speed for lower-stakes, more tolerant use cases (e.g. companion apps).
Why it works
Speech-to-speech is faster (lower latency, smaller models) but loses visibility into intermediate steps, hurting reliability and controllability; cascaded pipelines expose a text layer enterprises can audit, integrate, and control.
One level up
Trade some performance for auditability and controllability whenever the deployment context requires trust and integration, not just speed.
Where it stops holding
This stops working when latency is the dominant requirement and errors/hallucinations are tolerable or even desirable, such as casual companion applications.
Detail
rule: Use cascaded pipelines when enterprise customers need visibility, accuracy, and integration; use (future) speech-to-speech for low-complexity, latency-sensitive, low-stakes interactions.
threshold: Enterprises 'will need that visibility into what happens' and 'great accuracy of all the models' — a hard requirement that outweighs latency gains from speech-to-speech.
rationale: Reliability and integration ease matter more than raw speed for serious business deployments.
In their words
as we work with, like, a lot of the businesses and enterprises, they will need that visibility into what happens.