LLenny's Podcast
← All episodes
Eilon Reshef (co-founder and CPO)02 January 2025

Inside Gong: How teams work with design partners, their pod structure, autonomy, trust, and more

7Frameworks
14Insights

Frameworks in this episode

Insights & moments

The myth-busts, hot takes, explainers, and tools worth keeping.

Hot Take· 1

Hot Take28:00

If It's a 51/49 Call, Just Decide — Even One-Way Doors

Eilon pushes making decisions fast, even large one-way-door ones, before you have all the information. His logic: when a choice is close (51/49 rather than 70/30), neither option is super wrong, so gathering more data or people rarely changes the outcome. He cites deciding not to buy a company that, in hindsight, wouldn't have changed Gong's position, and notes decision-making drains you like physical exertion.

  • Close calls (51/49) mean no option is badly wrong — just pick one
  • More data and more people rarely improve a genuinely close decision
  • A company they chose not to buy wouldn't have radically changed their position
  • Decision-making is depleting, like physical exertion — overthinking rarely raises quality

you end up being like 51 40 49 no decision is going to be like super wrong

Eilon Reshef · 28:30
#decision-making#speed#leadership

Explainer· 3

Explainer06:30

Every Gong Pod Builds With 6–12 Design Partners, Hand in Hand

Gong takes the design-partner concept to an extreme: every product pod works directly with a set of customers (often 6–12, sometimes as few as one for niche features) while building. Eilon argues customers know their pain better than the product team, so building alongside them removes the risk of shipping something nobody uses. This is unusual because many companies bar product teams from talking to customers at all.

  • Each pod works hand-in-hand with a set of design partners, not just one or two
  • A dozen partners is smarter than one so you build for the customer base, not a single account
  • Building this way removes the risk of shipping features that never get used
  • Contrasts with companies that forbid product teams from talking directly to customers

I do believe customers know much better than that what they need

Eilon Reshef · 16:30
#design-partners#product-teams#customer-development#b2b
Explainer09:30

The "Research Coordinator" Role Borrowed From Recruiting

Coordinating design partners across 25–30 pods is huge overhead, so Gong borrowed the recruiting-coordinator idea from talent acquisition. One person acts as a research coordinator: she takes the PM's target market and learning goals, sifts the customer base via a micro-CRM and micro email campaigns, and books the meetings so PMs just show up.

  • Idea borrowed from the recruiting-coordinator role in talent acquisition
  • PMs specify target market/ICP and what they want to learn
  • She uses a micro-CRM and micro email campaigns to source and schedule partners
  • Frees PMs from the scheduling burden of coordinating a dozen companies

in our in our product team there's one person who's basically a research coordinator and she's responsible for reaching out

Eilon Reshef · 10:00
#design-partners#operations#product-teams#scaling
Explainer42:00

The Power of a Narrow ICP: 5,000 Companies and a "Small Pond"

Gong deliberately started ultra-narrow — US, English, video conference over WebEx, selling software worth $1K–$100K — a bucket of only ~5,000 companies. Eilon's earlier company failed by spanning wildly different industries with no common lingo. A tight ICP creates a "small pond" where similar companies talk to each other, producing a rare B2B viral effect: a prospect became a customer because a salesperson they interviewed would only work at companies using Gong.

  • Deliberately narrow ICP: US, English, WebEx video calls, $1K–$100K software
  • Only ~5,000 companies fit the initial bucket
  • A previous company failed spanning industries with no shared lingo
  • A tight pond of similar companies creates a rare B2B viral effect

there was no way we could scale it because everybody had their own lingo

Eilon Reshef · 42:30

well I'm only going to work for companies that use gong

Eilon Reshef · 43:30
#icp#go-to-market#crossing-the-chasm#positioning

Story· 4

Story07:00

The PM Who Showed a Half-Built Product and Told the Customer to "Hit Save"

A PM demoed a not-yet-built forecast feature to a design partner. When the customer hit save he got an error, and the PM promised it would work in a week. Customers later said they appreciated that the team interpreted and digested their feedback rather than literally building what they asked for.

  • The team showed a half-built product before it functioned
  • They built to what the feedback meant, not the literal request
  • Customers valued seeing progress move according to their feedback

I asked him to hit save he hit save and got an error message and I told him let's meet again in a week

Eilon Reshef · 07:00
#design-partners#product-development#customer-feedback
Story17:30

Why Autonomy Is "Selfish" — the Picnic Potluck Lesson

Eilon frames giving teams autonomy as selfish: you get more out of people when you let them be themselves. He tells the story of a school picnic where a rigid ingredient list produced the lowest-common-denominator food, but telling everyone to "bring your own thing" produced a feast — people drove miles for specialties and brought their personality to the table. The same holds for software teams.

  • You get more from people when you let them work their own way, within limits
  • A fixed list drives everyone to the easiest, cheapest contribution
  • "Bring your own thing" produced a feast and repeated every year
  • Autonomy keeps people thinking and motivated, better short and long term

I just think you get more from everybody if if you kind of let them be themselves and and do things in the way that…

Eilon Reshef · 17:30

here's a different method just tell everybody bring your own thing

Eilon Reshef · 18:00
#autonomy#leadership#culture#management
Story20:00

He Never Installed Control Software on His Kids' Devices

Eilon applies the same autonomy principle at home: he never installed antivirus or screen-time software on his kids' devices, treating self-protection as their responsibility. After negotiating a two-hour computer limit, his daughter came back three days in a row asking him to install limiting software — flipping the dynamic so she owned the decision and he was helping.

  • He installed no protection or control software on his kids' devices by choice
  • Self-protection was framed as the child's own responsibility
  • His daughter later asked him to install the limiting software herself
  • When responsibility flips to the person, the parent becomes a helper

could you please install the software on my machine so I can help me like control my limits and I love it when it's the…

Eilon Reshef · 21:00
#autonomy#parenting#responsibility
Story45:00

Fail Corner: Going Horizontal Without a Focused ICP

Eilon's worst repeated mistake, from a previous year-2000 company, was going horizontal instead of specializing in a market. They landed three customers in three different segments, then scaled to ~20 salespeople on investor advice — all failing, because there was no true product-market fit and no focused, repeatable ICP. He vows to make new mistakes, not that one again.

  • Going horizontal instead of specializing was the core error
  • Three customers in three segments looked like traction but wasn't
  • Scaling to ~20 salespeople on investor advice before PMF failed
  • Root cause: no focused, repeatable ICP

we didn't have a true focused ICP with like a very very repeatable product Market

Eilon Reshef · 46:00
#failure#product-market-fit#icp#go-to-market

Tool· 2

Tool50:30

The $10 Two-Cutlery-Basket Dishwasher Hack

Eilon's favorite recent "product" is a second silverware caddy for the dishwasher. After losing and re-buying one, then finding the original, he realized keeping a second basket in the sink lets you continuously load cutlery while the machine runs or before you unload it. He notes a guest's related idea — Rory Sutherland's pitch that everyone should own two dishwashers, one clean and one dirty, so you never put dishes away.

  • Keep a second cutlery basket in the sink to load continuously
  • Costs roughly $10–15 and reorganizes the kitchen workflow
  • Rory Sutherland's variant: own two dishwashers, one clean and one dirty
  • No dishwasher maker thinks to offer a second basket

if you have two of those baskets you put one of them in the sink and you can just like continuously load your Cutlery

Eilon Reshef · 51:00
#product#life-hack#recommendation
Tool46:30

Book Rec: "The Ideal Executive" (originally "Mismanagement")

Eilon's top management-book recommendation is The Ideal Executive, originally titled Mismanagement. It defines people by four characteristics — producer, administrator, integrator, and change agent — and argues nobody embodies all four. He values it less for the specific model than for the habit of viewing yourself and your team through key characteristics, which makes leadership discussions far faster. He also recommends Crucial Conversations.

  • The Ideal Executive was originally titled Mismanagement
  • Four types: producer, administrator, integrator, change agent — no one is all four
  • Value is a shared vocabulary for high-velocity team discussions
  • Also recommends Crucial Conversations

nobody wants to buy a book called mismanagement much rather buy a book that's called ideal executive

Eilon Reshef · 47:00
#books#management#leadership#recommendation

Takeaway· 4

Takeaway15:00

Nearly 100% of Features Built This Way Get Used

Because features are co-built with design partners, close to 100% of what Gong ships ends up used by a significant number of people — more than 95% of capabilities, which Eilon believes is higher than most companies. Not everything gets charged for, and the occasional miss comes from value being narrow or quality gaps, not from nobody wanting it.

  • Very close to 100% of features end up used by a significant number of people
  • More than 95% of capabilities are used in a significant way
  • Misses are usually narrow applicability or willingness to pay, not lack of use

I would say very close to 100% of the features we build end up being used by a significant number of people

Eilon Reshef · 15:30
#design-partners#product-metrics#success-rate
Takeaway32:30

LLMs Don't Solve Everything — Keep Real AI Expertise In-House

Having built AI products longer than most, Eilon warns against swinging from "you need data scientists for every project" to "LLMs will solve everything." LLMs have huge utility but can't do specialized tasks like predicting deals. Companies still need core AI competencies and measurement (Elo-style ranking) to move past a V1, or they hit a glass ceiling.

  • Don't swing to the extreme of assuming LLMs solve everything
  • Specialized tasks like deal prediction need purpose-built models, not LLMs
  • Without measurement you can't tell if V2 beats V1
  • Lack of operational rigor around AI creates a glass ceiling

hey llm is going to solve everything because LMS don't solve everything they have huge utility we use LMS over the place

Eilon Reshef · 33:00
#ai#llms#product-strategy#machine-learning
Takeaway35:00

Treat AI Output as a "First Draft" — Figma's Framing

Eilon likes Figma's naming of its AI feature "first draft" because it sets the right expectation: not best, not great, but a good starting point. Knowing whether an LLM's output is 90% or 50% accurate changes how you build the product, design the workflow around it, and train users on what to expect.

  • Naming AI output a "first draft" conceptualizes it correctly
  • 90%-accurate vs 50%-accurate output demands different product design
  • The framing shapes the workflow and what users are trained to assume

figma calls their AI feature like first draft H which is a term I like

Eilon Reshef · 35:30
#ai#product-design#llms#user-expectations
Takeaway52:30

Hanlon's Razor: Don't Attribute to Malice What Stupidity Explains

Eilon's go-to life motto is Hanlon's razor — never attribute to malice what is adequately explained by stupidity. He finds it genuinely useful because people so often read malice into behavior (a customer not replying, someone withholding feedback) when the real cause is that the person simply didn't know, didn't care, or wasn't trained.

  • The razor: never attribute to malice what stupidity adequately explains
  • People routinely misread neutral behavior as malicious
  • Usually the cause is ignorance or inattention, not ill intent
  • A funnier phrasing of "assume good intent"

never attribute to melice that that which is adequately explained by stupidity

Eilon Reshef · 53:00
#mental-models#life-motto#psychology