How Gong builds product

Co-founder and chief product officer Eilon Reshef on autonomy, OKRs, design partners, prioritizing, interviewing, and more

Lenny Rachitsky

Jan 23

∙

Preview

READ IN APP

👋 Hey, I’m Lenny and welcome to a 🔒 subscriber-only edition 🔒 of my weekly newsletter. Each week I tackle reader questions about building product, driving growth, and accelerating your career.

P.S. Don’t miss Lennybot ✨ (an AI chatbot trained on my newsletter posts, podcast interviews, and more) and my new swag store (great gifts for your favorite PM, or yourself!).

I was speaking with one of my favorite B2B founders and asked her what company she’d most love to learn from. Her immediate answer:

“Gong! I want to know everything about that company.”

Gong is one of the fastest SaaS companies in history to reach $100 million in annual revenue, has over 4,000 customers—including companies like Snowflake, Shopify, HubSpot, and LinkedIn—and has raised more than $500 million from Tier 1 investors like Sequoia Capital, Coatue, and Thrive Capital.

To get an inside look at how Gong builds product, I sat down with Eilon Reshef, the co-founder and chief product officer. Here’s what stood out to me most about Gong’s approach to product:

The incredibly high amount of autonomy teams have
Teams being organized around outcomes (aka “problem areas”), not features
The “W”-framework yearly planning process, the quarterly “M” process
Their dislike for OKRs and Scrum
Engineers, not PMs, owning prioritization of bugs
How closely teams work with design partners when developing new product lines, and their “slice” strategy for new products
The almost-real-life assignment principle for interviewing

To learn more about Gong, check out their website, demo page, and new AI platform.

For more stories of how the best product teams operate, don’t miss my deep dives into Linear, Shopify, Figma, Notion, Duolingo, Ramp, Miro, Coda, and Snowflake.

How Gong builds product

1. How far out do you plan in detail, and how has that evolved over the years?

We have two main planning cycles: annual and quarterly.

The annual process works along a “W” shape, similar to the framework Lenny suggested here.

It starts at the top, with the Gong management team setting up top company priorities—usually three or four. Based on these priorities, product and engineering determine the capacity for the different products and product areas. So for example, if we’ve decided to enter a new category, we will assign several pods that would be focused on this new category. When we decided to build our sales engagement product, for example, we reallocated some existing pods toward that goal.

Initially, a straw-man plan is built (bottom-up), with the “big rocks” that are planned for the year. It is presented to the leadership team for high-level feedback. Then a more detailed plan is put together. That plan includes more specific feature descriptions and more concrete timelines.

The output of this process is guidance for the plan one year ahead, at a decreasing level of certainty: good certainty for the upcoming quarter, lower certainty the following quarter, and a very rough sketch of the second half.

Once the plan is prepared, it is communicated broadly throughout the company. We found out that it’s helpful to have a single person on the product team (within the product operations team) assigned to handle the collection and communication of these plans.

Of course, we also involve teams other than management in the process. Over time, we’ve built various workshops with different teams (e.g. sales, customer success) to reduce the chances of having blind spots. For example, as part of our 2024 planning, we ran a workshop with the revenue leadership team, which brought up certain opportunities for addressing the needs of revenue leaders within our customer base; not all those needs were identified within the planning process.

Each quarter, we run a trimmed-down version of this process. Oftentimes, there isn’t new top-down guidance, so the process looks more like an “M,” starting from the product pods. We then create a pretty substantial document—north of 20 pages—that details the plan and what is expected to be built during the upcoming quarter.

Here’s the first page of our FY2024 Q3 plan (8-10/2023):

We also provide an abridged version of the high-level rocks, for executive consumption:

Also during this process, we provide (relatively light) updates to the annual plan. In principle, we aim to provide a rolling 12-month window of the plan, with a decreasing level of clarity.

We do not plan monthly or biweekly. Both the engineering leader and I dislike the Scrum methodology. We feel it’s trying to drive urgency via artificial deadlines versus via value to the customer. And by forcing “commitment” to deliverables within a time window, it essentially inhibits on-the-fly trade-offs between content, quality, and timelines. Yet we have internal reviews with the different groups on a monthly basis.

What’s interesting is that the process hasn’t changed materially over the years. That is, we had annual and quarterly planning almost from day one. But the process has become more structured over time: distribution across teams, deeper documentation and information dissemination, and so on.

2. How do you structure your product teams? Has this changed over the years?

When we started Gong, I built what we now call a pod: a product manager (which was initially me), a product designer, and a handful of engineers (front-end, back-end, and generalists).

Later on, as we started to scale, we debated how to structure the pods. In my prior life, I’ve seen org structures built around engineering specialization (back-end vs. front-end or platform vs. applications). Even back in 2017, we realized that we wanted to optimize for customer-centricity and velocity instead of optimizing for specialization.

So we’ve continued to build autonomous multi-skill teams (pods) around product areas—what is now known as “empowered product teams.”

Each pod is focused on a problem area (for example, “sales forecasting”), which roughly aligns with a set of “jobs” that are carried out either by a given persona (e.g. a sales coach) or by multiple people doing a business process (e.g. a pipeline review).

Now that we’re bigger, pods are assembled into “groups,” and each group roughly aligns with a product. For better or worse, products are usually aligned with an industry definition of a category (e.g. “conversation intelligence” or “sales engagement”). And in most cases, those products span multiple user types across a set of strongly connected workflows. For example, our “Engage” product is a sales engagement product, which serves account executives (working with new or existing customers), sales development managers (prospecting to new accounts), managers (driving the teams), and revenue operations (who set up the playbooks).

The structure is along the lines below:

While this works in theory, we do have exceptions.

Most notably, we have a data platform group, which is responsible for all data capture, data export, and data integrations. These tend to span multiple products, and we found out that it makes more sense to centralize those.

Another cross-functional group is a user journey group, which also spans all products and drives the user journey (home page, targeting, recommendations, and so on). That team also drives the (naturally cross-functional) mobile application.

The product group nowadays also includes non-“build” functions. I have leaders who drive new products’ go-to-market, field product management, product partnerships, and, most recently, product marketing.

3. How do your product/design review meetings work?

We are relatively extreme in letting the teams autonomously drive their own agendas. That is, once a pod has been assigned an area of responsibility, a great outcome is that they come up with the respective product design. So the leadership team is hardly involved in the detailed design or the iterations with customers along the way...