How to answer should we build buy or partner in PM interviews
When asked whether to build, buy, or partner, clarify the goal, analyze constraints, and compare options using cost, speed, risk, and strategic fit. Make a reasoned recommendation, explain your trade-offs, and propose a practical way to test your decision before full commitment.
PMMockr.com
Start with the underlying business goal
Jumping straight into options risks missing the real purpose of the question. When asked whether to build, buy, or partner, first clarify the business objective. For example, if the company wants to add video chat to its app, what outcome matters most? Is it speed to market, differentiation, cost control, or technical quality? State your assumptions if the interviewer hasn’t specified. This helps ground your analysis and shows you can frame ambiguous problems.
Clarify constraints and context
Before comparing solutions, collect context about timelines, available resources, technical capabilities, and company priorities. Are there strict deadlines, budget limitations, or regulatory hurdles? If you don’t have this information, state reasonable assumptions and invite correction. For instance, assume the team has limited video expertise and wants to launch in six months. This step prevents proposing options that are unrealistic or irrelevant.
Lay out the three options clearly
Define what each path—build, buy, or partner—would mean in this case. Building in-house usually means maximum control but higher cost and longer timelines. Buying an off-the-shelf solution is often faster but may limit customization. Partnering can mean co-developing with another firm for shared expertise or resources, but might introduce dependency risks. Avoid vague generalizations and tailor your descriptions to the specific scenario.
Worked example: Adding video chat to a productivity app
Suppose your company wants to add video chat to its productivity app. The goal is to enable remote teams to collaborate seamlessly. Assume the company has 10 engineers, minimal video expertise, $300,000 budget, and needs to launch in six months to stay competitive.
Segment users: The core users are small remote teams who already use the app for chat and document sharing. They expect reliable, secure video calls but don’t need advanced features like background blur at launch.
Prioritize requirements: Must-haves are secure group calls, stable performance, and integration with existing authentication. Nice-to-haves are screen sharing and recording. Timeline and reliability are more important than deep customization in this launch phase.
Option 1: Build. Given minimal expertise, building would likely take 8-10 months (assumption), cost $400,000 in engineering time (exceeds budget), and risk quality issues. Option 2: Buy. Purchasing a reliable third-party SDK costs $150,000/year, takes two months to integrate, and offers all required features but little brand differentiation. Option 3: Partner. Co-developing with a niche video startup would cost $200,000, deliver in five months, and allow some customization, but could create ongoing dependency if the partner’s business changes.
Weighing these, buying allows the team to ship on time and within budget. The main risk is vendor lock-in and lack of differentiation. Partnering offers more customization but is slower and riskier if the partner cannot deliver. Building is not feasible given timeline and budget constraints.
To validate this choice, propose launching a pilot with the third-party SDK to 10% of users, monitoring reliability, user satisfaction, and integration effort. If the pilot shows poor reliability or integration pain, revisit the partner option. If the SDK meets needs, scale up. New evidence that the SDK is unreliable or users complain about missing features would prompt reconsidering the partner route, despite higher cost and risk.
Comparing trade-offs and making a recommendation
After laying out the options, directly compare them using explicit criteria: speed, cost, control, risk, and strategic alignment. Explain which criteria matter most for this context and why you’re prioritizing them. In the worked example, speed and reliability outweigh customization due to competitive pressure and limited resources.
Make a clear recommendation, own the trade-offs, and state what evidence would prompt you to change your mind. This shows structured thinking and humility without being indecisive.
Weak reasoning versus strong reasoning
A weak answer might say, 'Buying is fastest, so we should do that,' without considering reliability, cost, or long-term risks. This ignores trade-offs and can sound superficial.
A stronger response weighs multiple factors: 'Buying is fastest and within budget, but if the SDK lacks reliability or features our users expect, we may need to consider a partner or eventually build. I’d propose piloting the SDK to test these assumptions before a full rollout.' This approach demonstrates critical thinking and risk management.
Addressing competing options and changing course
Interviewers often push back or present new information. If, for example, the SDK’s vendor is unstable or new privacy requirements emerge, be ready to revisit your recommendation. Articulate how you’d adapt: 'If we learn the SDK doesn’t meet our security needs, I’d either negotiate for improvements or shift to a partner who can guarantee compliance, even if it means higher cost or longer timeline.'
Show you’re comfortable updating your plan as evidence changes, rather than sticking rigidly to your first answer.
Practical experiment: Testing your choice
Before committing to a full rollout, propose a practical experiment to reduce risk. In our example, testing the SDK with a subset of users allows you to measure reliability, integration effort, and user satisfaction. Define clear success metrics—such as call drop rate, integration time, and user feedback scores.
If the pilot fails to meet thresholds, use this evidence to pivot or escalate. This concrete validation step demonstrates you’re thinking beyond theory and are focused on execution.
Practice exercise and self-review
Set a timer for 20 minutes. Choose a hypothetical product (e.g., a fitness app adding live classes). Outline the business goal, constraints, and three options. Work through user segmentation, prioritization, a focused recommendation, and a validation step. Afterward, review:
- Did you clarify the goal and constraints? - Did you define each option and compare trade-offs? - Did you make a clear recommendation and propose a test?
Aim to practice twice a week. Use PMMockr or a similar tool for varied scenarios, but focus on depth of reasoning over quantity.
FAQ
What if I don’t have enough information to choose between build, buy, or partner?
State your assumptions clearly and explain how you’d seek missing information. Offer a reasoned recommendation based on these assumptions, and invite the interviewer to clarify constraints or priorities.
Should I always pick the fastest or cheapest option?
No. Highlight trade-offs: the fastest or cheapest choice may introduce unacceptable risks, limit differentiation, or cause long-term issues. Explicitly weigh what matters most given the business goal and context.
How can I show flexibility if the interviewer challenges my recommendation?
Acknowledge new information, explain how it affects your analysis, and outline how your recommendation would change. This demonstrates adaptability and structured thinking rather than indecision.