Build Pods, Not Sprints: Gong's Anti-Scrum Playbook for Product Velocity

Walk me through Gong's planning process. How does it work at the annual and quarterly level?

We have two main planning cycles: annual and quarterly. The annual process works along a "W" shape. 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.

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.

You and your engineering lead dislike Scrum. Why?

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. We do not plan monthly or biweekly.

Tell me about the pod structure. How is Gong's engineering organised?

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. 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.

How autonomous are these pods really? What decisions can they make on their own?

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.

If you want more autonomy and speed, you've got to trust your team and give them the freedom to experiment. This means that as a leader, you need to step back, give up some visibility, and accept that you'll make a few mistakes. The tradeoff is worth it — higher velocity, better morale, and more impactful products.

How do pods work with design partners? I understand Gong involves customers very closely.

Gong's pods don't just build in isolation — they partner with 12 to 20 design partners (existing customers) who give feedback every step of the way. This constant validation keeps the product on track, with about 95% of features actually getting used.

What's the "spiral method" you use for learning complex topics quickly?

To quickly learn a complex topic, use the spiral method. Start by speaking with one expert, then ask for recommendations on who else to talk to. Continue having conversations, gradually deepening your understanding. As you hear the same patterns and insights from multiple sources, you'll know you've reached a sufficient depth to make informed decisions. This iterative approach helps you gather knowledge without aiming for perfection right away.

How did the extreme focus on a narrow customer profile help Gong early on?

When starting out, extreme focus on a specific customer profile can drive faster success. Gong, for example, initially targeted U.S. companies selling software valued between $1,000 to $100,000 via Webex, narrowing their potential customer base to just 5,000 people. This laser focus enabled quicker product-market fit, word-of-mouth growth, a clear product direction, and easier customer acquisition, demonstrating the power of precision in the early stages.

What's your philosophy on decision-making speed?

When faced with a 51/49 decision, make it quickly. The more time you spend deliberating, the more energy you waste without improving the decision quality. This approach doesn't work for massive, one-way decisions like expanding to a new market or acquiring a company, but for most day-to-day decisions, don't wait until everything's perfect. Commit, move forward, and adjust as you go.