Gong 的产品机器：小队、设计合作客户，以及快速拍板的 51/49 决策

Lenny introduces the pod model as the entry point into Gong's operating system, and Eilon Reshef traces it to roughly 2016, when Gong was scaling from about 50 to 60 people. The first group was already a pod: a product manager, a UX designer, backend and frontend engineers, and other roles. When the company considered moving to the traditional frontend/backend split, it decided instead to replicate the pod.

Today, Eilon describes a pod as product management, UX, writing and analyst support, an engineering team leader, and five to seven engineers. A pod receives an agenda—such as launching the forecast product—and then has substantial autonomy in figuring out how to solve the problem. It also works closely enough with customers that Eilon can sleep knowing the team is not 'hallucinating' a direction.

Eilon says Gong took the pod concept to an extreme: each pod works with sometimes a dozen design partners, sometimes two dozen, and sometimes only five for a niche or fringe capability. He recalls a forecast-product PM showing a design partner a half-built product and asking the customer to hit save; the save failed, and the PM promised it would work within a week. Customers appreciated seeing progress shaped by their feedback—not literal compliance, but interpretation and digestion of what they said.

Design partners are usually existing customers who have already expressed interest in the capability, and Gong can search its conversation database to find who asked for what. Scaling this across roughly 25 to 30 pods required a new role: a research coordinator borrowed from talent acquisition. The coordinator talks with PMs about target market and ICP, uses a micro CRM, runs targeted email campaigns, and puts meetings on the PM's calendar.

The cadence depends on the work. For a new product, Eilon describes a more linear path with weekly or biweekly reviews showing design partners progress; for enhancements or extensions, the work can be more free-form. A language-expansion example illustrates the looser mode: Gong recruited non-English-speaking design partners to test account questions across languages, with shorter interactions and no strict launch timeline.

Eilon treats feedback interpretation as a core PM skill: the PM must decide what is a must-have and what is not. A useful starting question is how happy the customer is today on a zero-to-10 scale, with the goal of moving a six to an eight or nine. Gong will still do one-customer customizations for very large enterprise deals, but design-partner work should aim at something that works across the customer base, which is why a dozen partners is often smarter than one or two.

In Eilon's experience, requests start to converge around seven to nine design partners; there may be an outlier, but the same themes recur. Gong's early history followed the same pattern: the company started with about 12 design partners, and when it began charging, 11 of the 12 said they would buy. The design-partner approach is therefore a repeatable way to de-risk new products, not just a one-time origin story.

Eilon estimates that more than 95% of the capabilities Gong builds are used in a significant way, though not all are charged for. Some features may please design partners but apply to a smaller segment than hoped, or fail to justify payment; quality and edge-case bugs are a separate launch concern that the design-partner program is not designed to solve. Still, Eilon argues that customers reliably know their pain, even if they do not know the right solution.

When Gong employees were asked what to probe with Eilon, the most common words were autonomy and trust. Eilon calls his motivation selfish: he believes he gets more from people when they are allowed to be themselves and work in the way they believe is right, within limits. He illustrates this with a school picnic where a sign-up list led everyone to bring the easiest item; when parents were told to bring their own thing, people drove 30 miles for favorite hummus, baked, and created a feast.

He extends the same principle to his family: he never installed protection software on his kids' devices because he wanted them to own the problem. One daughter negotiated screen-time limits with him and then asked him to install software to help her enforce the limits she had chosen. Eilon likes that inversion because she became responsible and he became the helper, rather than the enforcer.

Day to day, autonomy means a pod working with design partners owns the decision about whether to act on a customer idea and how far up to escalate. Eilon says teams are not punished for acting on a customer opinion, but they are expected to solicit feedback and initiate reviews. Gong has a weekly review session, but the pod has to bring its work and drive the process rather than being forced through a gate. A concrete example is an AI fine-tuning effort that started in a hackathon, got early resources as it showed promise, and was later fully funded.

Autonomy also requires leadership discipline. Eilon says the leader must let go and accept more mistakes, and must get peers on board because sales will ask what is happening and finance will ask about ROI. Gong treats sales, product marketing, and customer success as part of a virtual pod around the core product team, though salespeople are often too busy to be deeply involved. Eilon would not go back: launching products and then seeing whether people like them leaves too much to luck.

Eilon recommends Isaac Asimov's short story 'The Machine That Won the War' as a parable about decision-making: people trust a superhuman machine, but the decisive input turns out to be a coin toss. In real life, Eilon says many decisions are not close calls—opening an office in China probably has many reasons against it—so they do not need debate. When two options are roughly equal in value and cost, a 51/49 decision can be made quickly because neither is likely to be catastrophic.

He and co-founder Amit once considered an acquisition and ultimately did not buy the company. Years later, Eilon asked whether buying it would have put Gong in a radically different position; Amit said no. Eilon's conclusion is that the decision was 51/49, not 70/30, so either path would have been tolerable, even if one was somewhat better or worse. He acknowledges that decisions are physically taxing and easy to postpone, but argues that people should still make them.

Large one-way-door decisions deserve more time, but Eilon still thinks people overthink decisions. His personal test is that being forced to decide now versus after two weeks of pondering would not raise the quality much. He adds a caveat: this works in a domain where the decision-maker has real experience; in a genuinely new space, he would learn first rather than flip a coin.

Gong was building machine learning before it was fashionable, and Eilon says the company avoided the term AI early because people associated it with wrong decisions. He took a deep-learning course during a sabbatical, bought Nvidia stock, and sent an email saying this was the next thing. His warning today is to avoid both extremes: hiring a data scientist for every small project, or assuming an LLM solves everything.

LLMs are useful across Gong, but Eilon says they do not replace core AI competencies. Gong has a field prediction model, for example, because LLMs cannot predict fields in the specialized way the product needs. Teams still need people who can judge what is doable, what input quality looks like, and how to measure progress; Gong uses an ELO-style system and experts to compare models and prompts. Without measurement, a team may ship V1 and V2 with no real way to know whether it improved.

Even if a company outsources the core model work, Eilon argues it needs enough expertise to assess feasibility, input quality, and product implications. If an LLM is 90% accurate rather than 50% accurate, the product, workflow, naming, and user expectations should all be different. He cites Figma's 'First Draft' naming as a good example of setting the right expectation for an AI feature.

The roles Eilon values include data scientists who guide model-versus-LLM choices and measurement, and prompt engineers who optimize inputs, edge cases, and rankings. Gong combines models built from scratch, fine-tuning, and prompt rigor to make Gong AI more accurate than alternatives. It also embeds AI specialists or small teams into pods so they can iterate quickly on LLMs, small language models, or other approaches.

Eilon's spiral method is a way to learn a complex topic and know when to stop. He compares it to annealing: you start knowing nothing, ask one person what deep learning is, then ask who else to speak with, and repeat with the next people. The first conversation may be incomprehensible, the fifth may be 50% new, and eventually new material falls to 10%, 5%, or 0%; when several people stop adding new information, you have reached your level of the bullseye.

He applies the same spiral to customer and persona research. For example, when Gong wanted to serve account managers better, Eilon spoke with an account manager, an analyst, and others until the concerns repeated and he could make decisions. He notes that you can always do another spiral and go deeper with formal user research, but conversation-level spirals can get a product leader far enough to decide. The method is deliberately simple: keep asking who else to talk to.

Gong's early ICP was deliberately narrow: people selling software in the US, in English, over video conference, using WebEx, with deal values from $1,000 to $100,000. That bucket contained only about 5,000 companies, which let Gong create a small pond where customers talked to each other and the fire could be lit. Eilon contrasts this with an earlier company that had customers like L'Oreal, American Express, and Cisco in different industries, where everyone had different lingo and scaling was impossible.

The small-pond strategy produced a memorable B2B viral moment: a salesperson interviewed by a Gong customer said he would only work for companies that used Gong, and the customer became a Gong customer. Eilon says this kind of effect is hard in a wide market where buyers do not talk to each other. The lesson is to start narrow enough to create common language and peer pressure, then expand.

In Fail Corner, Eilon points to his previous company as the worst mistake: it started with a horizontal technology play and three customers in totally different segments. During the 2000 bubble, investors pushed the company to scale, so it hired about 20 salespeople before it had true product-market fit or a focused, repeatable ICP; all of them failed miserably. At Gong, Eilon says he may make new and fun mistakes, but he does not intend to repeat that one.

For books, he recommends The Ideal Executive, which he says was originally published under a less appealing title, Mismanagement. The framework divides people into administrator, producer, integrator, and change agent, and Eilon finds it useful for understanding himself and others—he admits he is horrible at administration. He also recommends Crucial Conversations for conducting hard conversations well.

His recent TV favorite is Slow Horses, the Gary Oldman spy series, which he finds fun and witty rather than lowest-common-denominator comedy. His favorite recent product is a second dishwasher cutlery basket: after losing and replacing one, he ended up with two and uses one in the sink to keep loading cutlery while the dishwasher runs. He notes that no dishwasher product manager seems to have thought of offering two baskets as an upsell.

Eilon's life motto is Hanlon's razor: never attribute to malice what is adequately explained by stupidity, which he uses as a funny but practical reminder to assume good intent. He also recommends Sabich, an Israeli pita filled with hummus, eggplant, and eggs, as a food people may not know. For follow-up, he points to LinkedIn, and for hiring, he points to Gong's careers page, noting that product roles are mostly in Tel Aviv and Dublin with some US and non-product roles.