ExpertsFMMati Staniszewski on ElevenLabs, Voice AI & Building the Communication Layer for AI
David Senra · September 9, 2026
5 Selected Lessons:
heuristic · 2 framework · 2 case · 1
Forward-Deployed Engineers embedded in product (not go-to-market) with a mandatory feedback loop
Source
David Senra — Mati Staniszewski on ElevenLabs, Voice AI & Building the Communication Layer for AI (September 9, 2026) · at 26:34 ▸ · at 29:09 ▸ · at 32:15 ▸
When this applies
when using embedded technical staff to solve individual customer integration problems
The takeaway
When deploying embedded technical staff to solve customer-specific problems, organizationally attach them to the product function and require they feed generalized learnings back into the product — otherwise the work degrades into pure services.
Why it works
Placing FDEs inside the product org (not sales) ensures the knowledge gained from solving one customer's hard integration problem is deliberately abstracted and fed back into the core product roadmap, benefiting all future customers rather than staying as one-off services work.
One level up
The value of frontline customer work compounds only if there's a designed mechanism to convert tacit field knowledge into reusable product capability.
Where it stops holding
This stops working when customer problems are truly one-off and non-generalizable, in which case feeding learnings back into the core product adds overhead with no reuse benefit.
Detail
procedure:
- Embed engineers directly with customers, treating them as partners solving a shared problem (not vendor/customer relationship).
- Organizationally place FDEs inside the product team, not go-to-market, so their primary loyalty is to improving the product.
- Require that any domain-specific hard integration work be abstracted into reusable product features (e.g., a built integration becomes available to all customers).
- Keep the customer's domain expertise as theirs, but make the product experience built around that expertise generalizable.
rationale: If these are effectively doing a lot of the hard integration work to solve the problem, but if you don't do the second step of how you actually learn the expertise and bring it back to the product, then it's effectively just services.
In their words
But there's a second reason, which is one, you want all the FDEs to actually solve the customer problem and stretch your product in that direction. But second thing you want them to do is bring any of that knowledge back to the product so the product becomes better for the next generation of companies building on top of it.
Flat, no-title organization with small-team, wide-span management, infused with engineering talent everywhere
Source
David Senra — Mati Staniszewski on ElevenLabs, Voice AI & Building the Communication Layer for AI (September 9, 2026) · at 29:09 ▸ · at 32:15 ▸ · at 34:42 ▸ · at 36:55 ▸
When this applies
when designing organizational structure for speed and decision quality in a fast-growing company
The takeaway
Minimize organizational distance between frontline knowledge and decision-makers, and embed technical capability inside every function rather than centralizing it narrowly, to scale judgment and automation simultaneously.
Why it works
Removing hierarchy layers and titles reduces friction for 'best idea wins' decision-making; embedding engineers in every function (HR, legal, ops, talent) lets those teams both automate work and raise their own technical capability, compounding leverage without ballooning headcount.
One level up
Speed and quality of decisions in a fast-moving company come from collapsing distance to ground truth, structurally and technologically.
Where it stops holding
This stops working when functions require deep specialized compliance/process rigor (e.g., heavily regulated industries) where flat, fast structures create risk rather than speed — as the contrasting BlackRock example suggests.
Detail
procedure:
- Keep organizational hierarchy very flat: cap max depth of layers (ElevenLabs: ~5 today, Palantir: 3-4 between him and C-suite).
- Avoid formal titles to reinforce 'best idea wins' culture.
- Give managers wide spans (ElevenLabs: close to 10 direct reports) to preserve small, autonomous team structure.
- Embed engineers in every team, technical and non-technical (talent, ops, legal), to both automate and upskill.
- Use AI to summarize frontline information directly to leadership, bypassing manager-filtered reporting, to stay proactive rather than reactive.
- Maintain radical internal transparency (open docs/data) so anyone can tap into organizational knowledge.
benchmarks: {"layers":"max ~5 at ElevenLabs; 3-4 at Palantir between individual contributor and C-suite","span":"close to 10 direct reports per manager at ElevenLabs","team_size":"FDE/product teams under 10, Palantir considered 5 'big'"}
rationale: No titles, relatively flat organization, very few layers... helps in that best idea wins approach.
In their words
No titles, relatively flat organization, very few layers. It's like between me and the C suites, I worked there before the DPO, it was four, five steps or less.
The 'does it have an engine' test for whether to enter a new product category
Source
David Senra — Mati Staniszewski on ElevenLabs, Voice AI & Building the Communication Layer for AI (September 9, 2026) · at 15:42 ▸ · at 18:36 ▸
When this applies
when deciding whether to enter an adjacent product category that uses your core capability
The takeaway
Only enter a new product space if your core unique capability is the thing that removes the dominant bottleneck in that product's quality; if the bottleneck is elsewhere, don't enter yet.
Why it works
If the bottleneck limiting product quality lies outside your unique capability (e.g., video quality, not audio), investing there dilutes focus without yielding a defensible advantage, since competitors with equal or better capability in the actual bottleneck will win.
One level up
True focus means saying no to adjacent opportunities until your core strength becomes the limiting factor that determines quality there.
Where it stops holding
This stops working when the external bottleneck (e.g., video models) matures enough that your core capability becomes the differentiator — at that point re-evaluate and enter, as ElevenLabs later did.
Detail
rule: Before building a new product, ask: do we have a unique advantage from our core model in this product's primary bottleneck? If not, don't build it.
threshold: If the product's quality bottleneck is NOT in the audio/voice domain, ElevenLabs treats it as 'not our fortress' and pauses/avoids it.
rationale: Honda's founder refused to build any product without an engine at its core because engines were his unmatched advantage; ElevenLabs applies the same logic to audio.
In their words
When we think about new products, the big question is, do we think we have a unique advantage by applying our audio models in that product experience? If the product experience does not have a big bottleneck in that audio and the voice communication side, then it is not our fortress.
Imperfection (pauses, 'ums') in voice drives higher engagement than polished perfection
Source
David Senra — Mati Staniszewski on ElevenLabs, Voice AI & Building the Communication Layer for AI (September 9, 2026) · at 52:46 ▸
When this applies
when designing a product's interaction style — tone, voice, copy — and deciding how 'polished' to make it
The takeaway
When optimizing an interface meant to feel human or authentic, deliberately preserve natural imperfections rather than engineering them out, because authenticity often outperforms technical perfection for engagement.
Why it works
Human communication inherently includes imperfections (pauses, filler words) that signal authenticity and relatability; stripping them out removes the cues people subconsciously use to judge something as human/trustworthy, hurting engagement even though it seems like a quality improvement.
One level up
Perceived authenticity, not technical perfection, is frequently the actual driver of user trust and engagement.
Where it stops holding
This stops working when the use case demands precision/efficiency over relatability (e.g., safety-critical instructions), where imperfection could reduce clarity or trust instead of increasing it.
Detail
rule: Add natural imperfections (pauses, filler words) to voice/communication products rather than stripping them for 'perfection'.
threshold: Staniszewski reports performance 'skyrocketed' once pauses/ums were reintroduced after initially trying to eliminate them.
rationale: The imperfection is really important... people admire authenticity way more than they do perfection, applied even in a non-human, voice agent's way.
In their words
the obvious thing that was the clearest is like the ums, the ums, the pauses, and suddenly the performance of working with that voice agent like skyrocketed.
Starting with a narrow, real pain point (Polish movie dubbing) before realizing the larger platform opportunity
Source
David Senra — Mati Staniszewski on ElevenLabs, Voice AI & Building the Communication Layer for AI (September 9, 2026) · at 0:00 ▸ · at 4:49 ▸
When this applies
when deciding what problem to start a company on, anchoring to a specific, personally experienced failure mode rather than an abstract market thesis
The takeaway
Pick a narrow, visceral problem you deeply understand as your entry wedge, even while believing the long-term vision is much bigger.
Why it works
A vivid, repeatedly-experienced personal pain point gives founders conviction and a concrete first product to build and test, even if the eventual market is much larger than the initial wedge.
One level up
Big platforms are often built by solving a small, deeply-felt problem first and only later discovering the scope of the underlying shift.
Where it stops holding
This stops working when the narrow pain point turns out to be a shrinking or niche market with no path to a larger underlying need.
Detail
situation: Staniszewski grew up watching Polish movies dubbed by a single monotone narrator voice, still happening in 2021, which bothered him and his co-founder.
decision: They started the company to solve dubbing/localization rather than going directly after a broad 'AI voice platform' vision.
outcome: They discovered the real underlying research and product gaps (transcription, translation, speech regeneration) were far from solved, which led them to build foundational audio research first, eventually becoming a much larger communication platform.
lesson: A specific, personally-felt problem can be the correct entry point even when the eventual ambition is a much broader platform shift.
In their words
The actual trigger point comes from where you're from, from Poland. Very peculiar thing. If you watch a movie in Polish, all the voices, whether it's a male voice or whether it's a female voice, get narrated with one single character.