How do you decide whether to build a capability in-house, buy a vendor solution, or form a partnership?

The PM strategy interview question on build vs buy vs partner. A decision framework built around differentiation, data compounding, and reversibility.

"When would you build vs buy vs partner for a new capability?"

This question is not asking you to list tradeoffs. It is asking whether you can identify where your product’s differentiation actually lives, and whether the path you choose compounds it or gives it away. The failure mode is treating build-vs-buy as a cost-and-time optimization. In 2026, that is project manager thinking, not product strategy.

Structure a strong answer

Start with a clarifying question, run a three-part test, then give a recommendation with explicit trigger conditions for revisiting it.

strong

"Before I recommend a path, one question: is this capability on our core differentiation surface, or is it table stakes that lets us play the game? That judgment tells you almost everything. Then I run three tests. First, the differentiation horizon: will the gap between our version and a purchased version widen or narrow over the next year or so? If it narrows because the capability is commoditizing, buy. If it widens because we'd be generating proprietary user signal that compounds over time, build. Second, reversibility: can we architect a clean abstraction layer so we're not locked into either direction? If we can't, switching cost changes the calculus significantly. Third, the proprietary signal test: does building in-house convert every user interaction into model improvement data, or would we just be generating training signal for a vendor who aggregates it across all their customers? That is a compounding asymmetry that is hard to recover from.

In 2026, for AI capabilities specifically, I'd add a fourth step: walk the ladder before jumping to a build decision. Try prompting plus RAG first, then fine-tuning on domain-specific data, then a custom model, and only build from scratch when the differentiation is durable and you have unique training data nobody else can access.

Concretely: Apple chose to partner with Google Gemini for Apple Intelligence rather than build a competing foundation model. That is strategic clarity, not a gap. Their differentiation lives in the hardware and OS layer, the private compute architecture, the on-device experience. Owning foundation model weights would not have compounded that advantage. Figma partnered with Stripe for payments rather than building billing infrastructure because that capital and focus was better spent on the design tools that are actually their moat. My recommendation: integrate an API to ship now, accumulate real feedback signals from users, then revisit whether fine-tuning or a custom layer adds differentiation that the purchased version cannot match. Name the trigger condition explicitly so the team knows when to revisit the decision."

weak

"Build gives you control, buy is faster, and partnering gets you expertise you don't have. For this capability, I'd probably build it so we own the full stack." This treats the question as a cost-and-time optimization, jumps to a recommendation without asking what the capability is for, makes a single static call with no phasing and no trigger condition, and ignores the AI-specific decision tree entirely. Interviewers read this as someone who hasn't thought about where value actually lives in a product. Recommending build to sound bold, without addressing talent scarcity, inference cost, or whether the differentiation is durable, is the most common tell at the hard-candidate level.

The 2026 reframe

The old framework: build equals slow and expensive, buy equals fast and cheap. That is dead as the primary lens. AI-assisted development collapsed build cost, and a global API ecosystem collapsed the friction of integrating. Feasibility is now roughly free for most software capabilities.

The real question is a strategic identity question: where does your differentiation live, and does building this capability compound it or just replicate what any competitor can buy tomorrow? Viable means the market will pay for your version, not just a version. That only holds if you own the thing that makes it yours.

The proprietary signal argument is where most candidates stumble. When you buy a vendor API, every user interaction that could have trained your model instead trains the vendor’s aggregate model across all their customers. That compounding asymmetry only matters when proprietary data creates durable differentiation, but when it does, it matters enormously.

The four-way AI decision ladder

Classic build-vs-buy had three options. In 2026, AI adds a fourth. The ladder runs cheapest to most expensive:

Prompt engineering plus RAG: use a foundation model with retrieval augmentation over your proprietary data. Fast to ship, low inference cost, works well for general language tasks where you have structured knowledge to retrieve.
Fine-tuning: adapt a foundation model on domain-specific data. Appropriate when you have consistent format, style, or terminology the base model does not handle well. Typically requires tens of thousands of labeled examples to justify the cost.
Custom model: train a model architecture suited to a specific problem type. Warranted for narrow, well-defined tasks where you have proprietary data at scale and an accuracy requirement available models do not clear.
Full build: build the training infrastructure, data pipeline, and model from scratch. Only defensible when you have unique data nobody else can replicate, the differentiation is durable, and the capability sits squarely on your core differentiation surface.

Traditional ML problems like fraud detection, churn prediction, and demand forecasting default toward build because the problem shape is business-specific and the training data is proprietary by nature. GenAI capabilities default toward buy or API integration because foundation models handle general language tasks out of the box, and the differentiation usually lives somewhere else in the stack.

The partner option is underused

Most candidates treat partnership as a footnote between build and buy. API integration (what most people mean by “buy”) is a tactical decision: you consume a service someone else operates. Strategic partnership, meaning co-development, exclusive data access, or joint go-to-market, is a different decision with different governance, exit clauses, and compounding properties.

Apple’s partnership with Yelp and TripAdvisor for reviews and listings in Apple Maps is a clean example: building a competing review corpus from scratch would have taken years and still not matched the trust signals from existing community data. Buying that data outright at scale is prohibitively expensive. Partnership structures the relationship around mutual value. The decision criteria is the same core test: is this capability on your differentiation surface? If not, partner before you build.

Metrics interviewers want to hear

For AI capabilities specifically, naming these signals shows you understand the actual cost structure: cost per inference (what does it cost to serve this capability at scale?), latency threshold (what response time does the use case require, and does the API or fine-tuned model clear it?), model quality measured by win rate or human eval scores against your success criteria, and API dependency ratio (what fraction of your product’s value is determined by a single external vendor’s decisions?). That last one is the reversibility signal translated into a number.

GitHub Copilot is deployed at 90% of Fortune 100 companies, with documented 55% improvements in task completion speed. That is the current cost basis for “buy” in AI-assisted coding. Any build decision in that category needs to clear the differentiation bar, not just the capability bar.

Go deeper on how feasibility has changed the PM calculus in feasibility is free, and see how to structure AI-specific decisions in RAG vs fine-tuning.