Lenny's PodcastEilon Reshef: Why Gong pods use dozens of design partners
How autonomous Gong pods pair with dozens of design partners each; narrow ICP picking, forecasting bets and trust replace heavy product reviews.
CHAPTERS
- 0:00 – 6:34
Gong’s pod model: origin, structure, and why it replaced functional teams
Eilon explains how Gong formalized its early “pod” setup as the company began to scale, choosing to replicate a small cross-functional unit rather than organize by function (frontend/backend). Each pod is built to own a problem space end-to-end, enabling autonomy while maintaining customer-grounded direction.
- •Pods replicate Gong’s earliest team composition (PM, UX, engineers)
- •Rejected traditional functional org (separate frontend/backend groups)
- •Typical pod makeup includes PM, UX, engineering lead, and ~5–7 engineers plus fractional roles (analytics/writing)
- •Pods get an agenda and are trusted to execute without “hallucinating” away from customer needs
- 6:34 – 7:52
Design partners at scale: taking customer collaboration to an extreme
Gong’s pods work with an unusually large number of design partners—often 12 to 24—for each product area. Eilon shares an example of showing partially built functionality to customers, using tight feedback loops to ensure meaningful progress without blindly implementing requests.
- •Each pod partners with many customers (often 12–24)
- •Very hands-on, iterative customer collaboration while the product is still half-built
- •Customers value progress that reflects interpreted needs, not literal requests
- •Design partners function as ongoing guidance for each pod
- 7:52 – 8:35
What pods own: job-to-be-done focus over metric ownership
Rather than anchoring pods on narrow metrics, Gong tends to organize pods around jobs-to-be-done within sales workflows. Once a pod has its problem space, it has wide latitude to decide how to solve it, with design partners serving as a practical compass.
- •Pods are aligned to jobs-to-be-done (e.g., prospecting, conversation intelligence, summaries)
- •Less metric-driven than many B2C/B2B orgs
- •Autonomy in solution discovery and delivery
- •Design partners help steer direction within the pod’s mission
- 8:35 – 9:14
Case study: Gong Forecast—what it is and how it works
Eilon describes Gong’s forecasting product as a tool to improve bottoms-up sales forecasting by combining rep submissions, manager overrides, AI prediction, and analytics. This example serves as a concrete anchor for how pods deliver new product lines.
- •Supports bottoms-up forecast processes in B2B sales orgs
- •Combines human inputs with AI-driven prediction
- •Includes analytics to evaluate forecast health at scale
- •Illustrates a pod owning a full product area
- 9:14 – 11:31
How Gong recruits and coordinates design partners (and the research coordinator role)
Design partners are typically pulled from existing customers who have expressed interest, with Gong leveraging its own conversation data to find signals of need. To remove operational drag from PMs, Gong created a “research coordinator” role that effectively runs scheduling and outreach like recruiting coordination.
- •Design partners usually come from existing customers with expressed needs
- •Gong can search conversation records to identify interested accounts/personas
- •A dedicated research coordinator runs outreach and scheduling at scale
- •Uses segmentation (ICP/persona) and a lightweight CRM plus micro email campaigns
- 11:31 – 12:10
Adding light process: coordinating with Customer Success without creating bureaucracy
Gong evolved from loosely coordinated outreach to a more deliberate check with Customer Success to avoid contacting accounts at the wrong time. The aim is to protect relationships while keeping the bar low for product teams to speak directly with customers.
- •Early days: minimal coordination with Customer Success
- •Now: sanity-check timing (avoid frustrated accounts or sensitive negotiations)
- •Still avoids heavy approval chains and slow sign-offs
- •Maintains a culture where PMs/pods can directly engage customers
- 12:10 – 13:13
Cadence choices: structured design-partner loops vs. freeform research
Eilon distinguishes between building entirely new products (often requiring weekly or biweekly progress reviews with design partners) and iterative enhancements that can be more ad hoc. He also gives an example of recruiting partners for multilingual quality validation without rigid timelines.
- •New products often use recurring weekly/biweekly partner check-ins
- •Enhancements may use lighter, more flexible engagement
- •Example: validating “ask questions about an account” feature in multiple languages
- •Recruit design partners to match specific learning goals (e.g., non-English speakers)
- 13:13 – 15:10
Balancing customer feedback with product judgment: convergence over customization
Gong expects PMs to translate customer requests into underlying needs and decide what’s truly must-have. With enough design partners, feedback tends to converge, helping teams avoid overfitting to one customer while still making exceptions for major enterprise deals when warranted.
- •PMs are expected to interpret feedback, not implement it verbatim
- •Use simple satisfaction baselines (e.g., move from 6→8/9) to gauge improvement
- •Outliers trigger additional validation rather than immediate commitment
- •Design-partner work optimizes for broad applicability; customizations are handled separately
- 15:10 – 17:06
Why adoption is so high: 95%+ of shipped capabilities get meaningful use
Eilon attributes Gong’s strong feature adoption to the design partner model: building with real customer pain ensures utility. He notes the distinction between features being used and being monetizable, and clarifies that the design partner program isn’t designed primarily for QA across all edge cases.
- •“Very close to 100%” of features are used by a significant number of users
- •Not all features are monetized; willingness to pay is a separate question
- •Design partners validate value/clarity more than exhaustive bug discovery
- •Large partner sets reduce reliance on luck and post-launch surprise
- 17:06 – 21:19
Autonomy and trust as operating principles (and the ‘picnic’ analogy)
Eilon frames autonomy as a “selfish” leadership choice: letting people bring their strengths yields better outcomes and morale over time. He illustrates this with a story about replacing assigned picnic items with “bring your own,” resulting in higher-quality contributions and happier participants.
- •Autonomy increases motivation, ownership, and long-term performance
- •Leadership must resist over-control to unlock higher-quality contributions
- •Analogy: “bring your own” created a feast vs. lowest-common-denominator assignments
- •Parallel to Montessori-like principles: don’t interrupt focus; encourage self-direction
- 21:19 – 24:16
What autonomy looks like in practice: decision rights, reviews, and accountability
In Gong’s culture, teams decide when to execute on customer ideas and when to escalate; they aren’t “punished” for making reasonable calls. Autonomy comes with responsibility: teams are expected to proactively solicit feedback and initiate reviews rather than waiting for top-down checkpoints.
- •Teams own the decision of whether to act or seek input
- •Culture avoids punishment for good-faith decisions
- •Expectation to proactively request feedback and run reviews
- •Weekly forum exists, but teams must bring work forward rather than being forced
- 24:16 – 27:08
Implementing this model without chaos: leader buy-in, peer alignment, and visibility trade-offs
Eilon explains that autonomy requires leaders to let go and accept some additional mistakes, and it also requires alignment with exec peers who may demand control (Sales, CFO). The trade-off is reduced visibility in exchange for higher velocity, engagement, and ultimately better products; sales and other functions become part of a “virtual pod.”
- •Leaders must commit to letting go and tolerating more mistakes
- •Exec peers need to buy in despite reduced control/visibility
- •Autonomy trades visibility for velocity and morale/engagement
- •“Virtual pod” includes Product Marketing, Customer Success, and Sales when available
- 27:08 – 31:47
Speed and decision-making: avoiding 51/49 paralysis and embracing momentum
Eilon argues that many decisions are close calls where more debate doesn’t meaningfully improve outcomes, so teams should decide and move. He uses an Asimov story to illustrate the illusion of certainty, and shares an acquisition example where a 51/49 choice likely wouldn’t have radically changed Gong’s trajectory.
- •Many product decisions are 51/49; either option is acceptable
- •Overthinking creates drag with limited decision-quality gain
- •Asimov story: apparent “machine certainty” masked by randomness
- •Domain expertise matters; don’t apply coin-flip speed to unfamiliar domains
- 31:47 – 38:15
Gong’s AI lessons: LLMs are powerful, but rigor, measurement, and expertise still matter
Gong adopted ML early, before “AI” was a favorable label, and Eilon warns against swinging from “data scientists for everything” to “LLMs solve everything.” He emphasizes the need for measurement systems, AI expertise, and operational rigor—especially for specialized tasks like deal prediction—and describes team roles that support this work.
- •LLMs don’t solve every AI problem; specialized models still matter (e.g., deal prediction)
- •Measurement is essential to improve beyond V1/V2; Gong uses structured evaluation (e.g., Elo-style comparisons)
- •Key roles: data scientists for feasibility + measurement; prompt engineering expertise for optimization
- •Pods can include embedded AI specialists to iterate quickly across approaches (LLMs/SLMs/other models)
- 38:15 – 41:24
The spiral method: learning complex topics quickly through iterative conversations
Eilon shares his “spiral” approach: start by asking basic questions, then repeatedly talk to suggested experts until new information approaches zero. The method helps you know when you’ve reached a useful level of understanding for decision-making, even if you’re not becoming a deep specialist.
- •Start with one person; ask “who else should I talk to?” and iterate
- •Knowledge compounds; comprehension increases each conversation
- •Stop when novelty drops to ~0–10% (signals you’ve reached the bullseye for your level)
- •Applicable to learning tech (deep learning) and customer/persona discovery
- 41:24 – 44:06
Starting narrow on ICP: constraints that created a ‘small pond’ and viral-like B2B pull
Eilon explains why Gong intentionally narrowed its initial ICP with multiple constraints to create a tight community where word-of-mouth could propagate. He contrasts this with a prior company’s mistake of going too horizontal, noting that focus enabled repeatability, shared language, and surprising hiring-driven demand (“only joining companies that use Gong”).
- •Narrow ICP enables repeatable PMF and shared customer language
- •“Small pond” drives conversation-driven adoption (bowling alley/Crossing the Chasm)
- •Prior failure: horizontal spread across industries prevented scaling
- •Example of pull: candidates asking if a company uses Gong before joining
- 44:06 – 56:42
Failure corner and lightning round: lessons from past mistakes + personal picks
Eilon recounts scaling too early and too broadly in a previous startup—hiring many salespeople before true PMF and focused ICP—creating costly failure. The lightning round covers books, communication, favorite shows, a quirky kitchen workflow hack, a guiding life motto, and a few Israeli food notes.
- •Failure lesson: don’t scale sales headcount before focused, repeatable PMF
- •Mistake: going horizontal across unrelated segments and languages/needs
- •Book recs: The Ideal Executive; Crucial Conversations
- •Lightning: Slow Horses; “two cutlery caddies” productivity hack; Hanlon’s razor; Sabich mention
