The Design-Partner Pod Model
Give each cross-functional pod 6-12 real customers to co-build with, so features ship pre-validated.
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 4
- Confidence
- 95%
Gong organizes product and engineering into self-contained cross-functional pods, and pushes the design-partner concept to an extreme: every pod builds each new product or feature hand-in-hand with a set of 6-12 existing customers who have expressed interest in that capability. The pod shows half-built work, digests feedback, and iterates weekly, so by launch the feature is already validated. Reshef reports close to 100% of features built this way end up used by a significant number of people.
Origin
Eilon Reshef, co-founder and CPO of Gong, developed the pod model around 2016 (before Marty Cagan's pod books popularized it). It replicates the way Gong itself was validated at founding, when 12 design partners were recruited and 11 of 12 agreed to pay once charging began.
Core principles
- 01Customers know better than you what they need — they may not know how to build it, but the pain is real
- 02A dozen partners beats one or two: at ~7-9 partners requests start to converge, revealing the true must-haves
- 03Interpret and digest feedback rather than building literally what each customer says
- 04Design partners guide the work, not the executive
How to run it
- 1
Assign the pod a job-to-be-done, not a metric
Give the pod an outcome framed as a customer job (e.g. 'help people forecast where they'll land', 'create conversation summaries') rather than a metric to move. This is the agenda the pod owns.
Pro tip Gong is deliberately less metric-driven than typical B2B/B2C teams — a clear job-to-be-done gives the pod room to own the 'how'.
- 2
Recruit 6-12 design partners from customers who expressed the need
Source partners almost always from existing customers who have already voiced interest in the capability. Use your own conversation/CRM data to find who asked for X, then reach out. For niche capabilities 2-5 partners suffice; for broad ones use a full dozen.
Pro tip For features spanning languages or personas (e.g. non-English support), deliberately recruit partners matching each segment.
Watch out Coordinate with customer success first — skip customers who are frustrated or mid-negotiation, as that's the wrong time to ask them to be a partner.
- 3
Build hand-in-hand with weekly show-and-tell
For a new product, run a weekly (or bi-weekly) meeting showing progress and half-built work. Show partners the unfinished product, capture where it breaks, and return the next week with it working.
Pro tip Showing a broken 'Save' button and returning a week later with it working signals responsiveness and builds partner investment.
Watch out For small enhancements or tweaks the cadence can be looser — a couple of meetings per partner, then launch and move on.
- 4
Triage each request as must-have vs not
Have the PM judge which requests are must-have versus nice-to-have. Ask each customer what they use today and to rate their happiness 0-10; aim to move a 6 to an 8 or 9. A request heard from one customer only is flagged, not automatically built.
Pro tip The design-partner logic is the inverse of enterprise deal customization: build what works across the customer base, not for one account.
Watch out One-off single-customer customizations still happen for large enterprise deals — but keep those out of the design-partner program.
In the wild
A pod built Gong's sales-forecasting product with a set of design partners. The PM demoed half-built functionality, had the partner hit a Save button that errored, then promised it working within a week. Partners later said they appreciated that the product progressed by interpreting their feedback rather than literally executing every request.
→ Launched a successful forecast product; partners felt heard and the feature shipped validated.
Common mistakes
Launch-then-see-if-people-like-it
Reshef contrasts Gong with a large successful SaaS company that launches products and then checks whether people like them. He considers this leaving success to luck — you never know in advance if the thing will be used.
Walling product teams off from customers
Many companies forbid product teams from talking to customers (sales/CS guard the relationship). This starves teams of the exact signal they need to build the right thing.
Is it for you?
Best for
B2B SaaS product and engineering leaders who want new features and product lines to ship pre-validated with high adoption
Not ideal for
Pure B2C or metric-driven teams, or bug/polish work (partners judge value, not whether it works in Safari)
From the transcript
“we just took the Pod concept to an extreme where every pod is working with sometimes it doesn't desire Partners sometimes two doesn't design partn…”
“I would say very close to 100% of the features we build end up being used by a significant number of people”
“try to try to figure out what request is like must have versus not must have”
“let's try to build something that works across our customer base versus for specific customer which is why it dozen is is probably smarter than…”
From the episode
Inside Gong: How teams work with design partners, their pod structure, autonomy, trust, and more
Eilon Reshef (co-founder and CPO)