The BD-Product Operating Contract
Test deals with hacky ops before code, build platforms not bespoke, time product's entry.
- Difficulty
- Moderate
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 91%
Three rules Yandell learned running BD at DoorDash for protecting the most precious resource in a product company — engineering time — while still doing impactful deals. Prove the partnership thesis with hacky manual operations before requesting any product work; when you do build, build a negotiable platform rather than a one-off integration for each partner; and time product's entry into a deal so they aren't burned on dead deals or brought in after you've conceded terms you shouldn't have.
Origin
Keith Yandell's BD/Corp Dev experience at DoorDash. The platform principle and the 'dream big, start small' application to BD were taught to him by DoorDash's head of product, Rajat Shroff. 'Do things that don't scale' is a founding DoorDash core value (originating with Paul Graham).
Core principles
- 01Engineering and product time is the most precious resource in the company — every BD ask spends it.
- 02Do things that don't scale is as relevant at DoorDash's scale as it was on day one.
- 03A platform lets you negotiate at velocity because you know your own parameters; bespoke builds make every deal a new engineering request.
- 04Corporate enthusiasm is not distribution — verify the party who actually controls the customer touchpoint cares.
How to run it
- 1
Give product visibility into the pipeline without pulling them in
Share the deal pipeline so product can flag what looks high-impact and what looks like a waste, without committing them to full discussions on deals that may never close.
Pro tip This makes product a filter on your pipeline rather than a downstream contractor.
- 2
Time the engagement — early, but not too early
Bring product in too early on a deal with no chance of closing and you burn your scarcest cycles. Bring them in too late and you may have already conceded terms you shouldn't have, damaging the partnership itself. Both failure modes are real; the calibration is the skill.
Watch out Late engagement is the more expensive error — you can't renegotiate a term you already gave away.
- 3
Test the thesis with hacky operations, not product
Before requesting engineering resources, validate the deal's core behavioural assumption with manual operations. Yandell's example: stand out front with a promo code, hand it out, and see whether customer behaviour actually changes. Start small — DoorDash's core value is 'dream big, start small'.
Pro tip Run the test at one site (one hotel, one store) with hacky ops and measure uptake before anyone writes code.
Watch out This is where Yandell says he has two or three failure examples, not one. The pull to skip straight to integration is strong and expensive.
- 4
Verify who actually controls the touchpoint
Confirm that the party who will physically present your product to the customer — not just the corporate signatory — is incentivised to do so. Franchisees, store managers, and front-line staff can silently kill a deal that corporate loves.
Pro tip In a franchised business, corporate prioritisation is close to worthless without franchisee buy-in.
- 5
Ask product for a platform, not a bespoke build
Instead of asking for a custom build per partner, ask what the scalable solution is. Rajat Shroff's counter to Yandell's per-partner requests: figure out the scalable solution, we'll build you a product, you won't need to come ask us every time — and then you'll know the parameters within which you can negotiate.
Pro tip The platform's real gift to BD is negotiation velocity: knowing your own parameters means you can close without a round-trip to engineering.
Watch out The first version costs more product time than a bespoke build. That's the trade — the second through Nth deals cost almost nothing.
In the wild
DoorDash invested heavily in a partnership with a hotel chain, aiming to replace room service as the new in-hotel dining experience, and asked for a large amount of product work to build the integration. The chain was franchised: corporate thought it was an important priority, but the franchisees — who controlled in-room visibility — didn't care.
→ A total flop. All the integration work was wasted because the operations were never right. Yandell's takeaway: they should have tested at a single hotel with hacky operations first, which would have surfaced the franchisee problem for near-zero cost.
Yandell had been negotiating individual DashPass subscription partnerships (e.g. with Chase) and asking product to build a bespoke integration for each. Rajat Shroff pushed back and proposed building a scalable platform product instead, spending more effort on the first version and very little on each subsequent one.
→ BD gained a high return on product/engineering hours, plus known negotiating parameters that let deals be closed at greater velocity without a new engineering request each time.
Common mistakes
Building the integration before testing the behaviour
The hotel partnership consumed significant product work on an assumption — that franchisees would promote it — that could have been falsified in a week with one hotel and some manual operations.
Treating the corporate signatory as the distribution
In franchised or multi-tier partners, the entity that signs is not the entity that puts your product in front of the customer. Uncheck this and your integration ships into a void.
Requesting a bespoke build per partner
Every deal becoming a fresh engineering ask throttles your deal velocity, burns your scarcest resource, and leaves you negotiating without knowing your own build parameters.
Is it for you?
Best for
BD, partnerships and corp dev leaders inside product-led companies who must repeatedly requisition scarce engineering time to close deals.
Not ideal for
One-off strategic deals where no repeatable pattern exists to platform, or true M&A where operational pre-testing isn't possible.
From the transcript
“trying to figure out what the right Cadence is when you bring in the product team because if you bring them in too early on…”
“why don't you figure out what the scalable solution is for this”
“I have probably two or three other examples of situations where I learned I should have just gone out and stood out front with a…”
“the last thing would be to engage early but not too early on Deal opportunities”
From the episode
Leading with empathy
Keith Yandell (DoorDash, Uber)