Build vs. Buy Decision Framework

Quick Overview

Practice a structured build-versus-buy product decision framework. The solution compares build, buy, and hybrid options across strategic differentiation, total cost of ownership, time to market, reliability, maintenance, vendor lock-in, data portability, pilots, stakeholder review, and risk mitigation.

Build vs. Buy Decision Framework

Company: Google

Role: Product Manager

Category: Product / Decision Making

Difficulty: medium

Interview Round: Technical Screen

##### Question Your team needs a new system. Describe how you would decide whether to build it in-house or buy an off-the-shelf solution. Discuss evaluation criteria such as cost, time-to-market, scalability, maintenance, vendor lock-in, and strategic differentiation.

Quick Answer: Practice a structured build-versus-buy product decision framework. The solution compares build, buy, and hybrid options across strategic differentiation, total cost of ownership, time to market, reliability, maintenance, vendor lock-in, data portability, pilots, stakeholder review, and risk mitigation.

|Home/Product / Decision Making/Google
Google logo
Google
Jul 4, 2025, 8:28 PM
mediumProduct ManagerTechnical ScreenProduct / Decision Making
18
0

Product Decision Prompt: Build vs. Buy Framework

Your team needs to deliver a new system to support a product. You can either build it in-house or buy an off-the-shelf or SaaS solution.

Describe how you would decide whether to build or buy. Present a structured framework and explain how you would evaluate:

  • Cost and total cost of ownership.
  • Time to market.
  • Scalability and reliability.
  • Maintenance and operational burden.
  • Vendor lock-in and data portability.
  • Strategic differentiation: core versus commodity.

Also explain how you would gather data, compare options, de-risk the choice through pilots or proofs of concept, and make a recommendation.

Constraints & Assumptions

  • Treat build, buy, and hybrid as possible options.
  • Include product, engineering, security, legal, finance, procurement, and operations considerations.
  • Do not choose build or buy by default; tie the recommendation to strategic importance, constraints, and evidence.
  • Include exit strategy and vendor risk if buying.

Clarifying Questions to Ask Guidance

  • What system are we deciding on and what job must it perform?
  • Is this capability core to product differentiation or a commodity enabler?
  • What are the launch deadline, SLOs, security requirements, and budget constraints?
  • What integrations, data types, and compliance obligations are involved?
  • What internal team capacity and expertise do we have?

Part 1 - Define Requirements and Options

Explain how you clarify the problem, success outcomes, constraints, and possible options.

What This Part Should Cover Guidance

  • Jobs to be done, users, must-have capabilities, and non-goals.
  • Functional and non-functional requirements.
  • Build, buy, and hybrid options.
  • Success metrics and decision criteria.

Part 2 - Evaluate Criteria

Compare options across cost, time to market, scalability, reliability, maintenance, lock-in, data portability, and strategic differentiation.

What This Part Should Cover Guidance

  • Three- to five-year total cost of ownership.
  • Opportunity cost of engineering time.
  • Procurement, integration, migration, training, support, and exit costs.
  • Vendor SLA, security, compliance, roadmap dependency, and pricing risk.
  • Internal operational burden and long-term product control.

Part 3 - De-risk and Recommend

Describe how you gather data, run POCs or pilots, and make the final recommendation.

What This Part Should Cover Guidance

  • Vendor demos, reference checks, security review, architecture review, and integration spike.
  • Prototype or POC with real workflows and performance tests.
  • Weighted scorecard plus narrative recommendation.
  • Risk mitigation, contract terms, data portability, and exit strategy.
  • Decision review with stakeholders.

What a Strong Answer Covers Guidance

A strong answer separates commodity from strategic capabilities, quantifies total cost and opportunity cost, validates vendor and internal feasibility, and makes a recommendation with explicit trade-offs and risk mitigations.

Follow-up Questions Guidance

  • When would you buy now and build later?
  • How would you avoid vendor lock-in?
  • What if the vendor is faster but fails a security requirement?
  • What internal cost do teams usually underestimate?
  • How would your recommendation change if this capability became strategically differentiating?
Loading comments...