Adobe agreed to pay $20 billion for Figma in September 2022. Fifteen months later, regulators killed the deal, and Adobe wrote a $1 billion termination check. By mid-2025, Figma’s independent valuation had soared past $60 billion. Adobe’s decision to buy rather than build collaborative design tools became one of the most expensive strategic miscalculations in recent enterprise software history.
Every product manager faces a version of this decision, usually at a smaller scale, but with the same underlying tension: do we build this capability ourselves, buy an existing solution, or partner with someone who already has it?
Most teams answer this question by default. Engineering wants to build. Procurement wants to buy. Nobody thinks about partnering until the first two options fall apart. The result is a pattern I’ve seen across 20+ years in IT operations: teams commit to building something that should have been bought, buy something that should have been built, or never consider a partnership that would have saved six months and half the budget.
The Decision Sits Upstream of the Roadmap
The build, buy, or partner question is not a tactical implementation detail. It is a strategic choice that determines what your team works on for the next 6 to 18 months.
Custom software projects take a median of 12 months from kickoff to first release. The Standish Group’s CHAOS research has tracked custom software outcomes for decades: roughly 31% of projects get cancelled outright, and those that survive cost an average of 189% of their original estimates. Off-the-shelf solutions, by contrast, deploy 40 to 60% faster than custom builds.
When a PM chooses “build” for a capability that is not a core differentiator, the roadmap absorbs that work. Features that would move your competitive position get pushed back. Engineering capacity gets locked into maintenance. The opportunity cost compounds every quarter.
When Building Is the Right Call
Building makes strategic sense when three conditions are true simultaneously.
The capability is your competitive differentiator. If the feature or system is the reason customers choose your product over alternatives, owning it end to end is worth the investment. Stripe built its own payment processing infrastructure because payment reliability IS the product. A SaaS company building its own internal analytics dashboard is a different calculation entirely.
Your team can sustain ownership long-term. A custom build requires three to four senior engineers plus technical leadership, running roughly $1M to $1.5M annually before shipping a single feature, according to 2024 Bureau of Labor Statistics salary data for senior software engineers. Tech industry turnover sits at 13.2%, the highest across all sectors. If you build it, you need to staff it permanently.
The problem is well enough understood to scope. McKinsey has found that 17% of large IT projects go so badly they threaten the company’s existence. The common thread: teams started building before they understood what they were building. If the requirements are still shifting, building is the highest risk option available.
When all three conditions hold, build. When even one is missing, look at the other two options first.
When Buying Saves the Strategy
Buying a solution is the right move when the capability is necessary but not differentiating.
Gartner Digital Markets reported in 2024 that 68% of fast-growing businesses regret at least one software purchase. The regret usually stems from buying for the wrong reason: choosing the vendor with the best demo instead of the best strategic fit.
The buy option works when the capability is a solved problem. Project management, CRM, communication tools, payment processing for non-fintech companies: these categories have mature solutions that have already absorbed billions of dollars of development investment. Building your own version means competing with that investment using a fraction of the resources.
It also works when time to market is the strategic constraint. If the competitive window closes in three months, a 12-month build cycle is not a strategy. It is a forfeit.
Before committing to buy, validate that the solution will actually get used. The Zylo 2025 SaaS Management Index found that 52.7% of SaaS licenses sit unused, with the average company wasting approximately $21 million annually on software it bought but never fully adopted. A purchase decision that skips adoption planning is just a different kind of waste.
The Partner Option Most Teams Skip
Partnering sits between building and buying. It is the option that product managers consider last, if they consider it at all.
A partnership means collaborating with an external company to co-develop, integrate, or white-label a capability. You get more customization than buying off the shelf and faster delivery than building from scratch.
Partnerships make strategic sense in three scenarios.
You need a capability that is adjacent to your core but not inside it. An e-commerce platform that needs shipping logistics, a healthcare app that needs payment processing, a project management tool that needs document editing. These are capabilities where a partner’s existing infrastructure saves years of development.
You want to test a market before committing engineering resources. Partnering lets you offer a capability to users, measure adoption, and decide whether to bring it in-house later. It is the build, buy, or partner equivalent of an MVP: validate demand before investing. This connects directly to the discipline of documenting what you will not build, because a partnership lets you serve a need without expanding your build surface.
Integration standards make it feasible. Modern API ecosystems and cloud platforms have made partnerships technically viable in ways they were not ten years ago. If the integration is clean, a partner can feel native to users while costing a fraction of an internal build.
Three Questions That Cut Through the Debate
In my work running IT operations teams and advising companies as a fractional COO, I have watched dozens of teams get stuck in circular build, buy, or partner arguments. The teams that decide well tend to answer three questions early.
1. Is this capability the reason customers choose us?
If yes, build it. If no, the default should be buy or partner. Most capabilities are not differentiators. Email notifications, user authentication, reporting dashboards, onboarding flows: these are table stakes. Building table stakes in-house means your best engineers are working on things that do not move your market position.
2. Can we staff and maintain this for three years?
Custom software does not end at launch. It starts at launch. If you cannot commit engineering resources to maintain, update, and extend the system for at least three years, the build will become technical debt faster than it becomes competitive advantage. This is the same logic behind reviewing which strategic bets to keep, kill, or double down on: every capability you own is a bet you are making with future resources.
3. What happens to the roadmap if we build this ourselves?
This is the question teams skip most often. Every capability you build in-house displaces something else on the roadmap. If building an internal analytics engine pushes your core product improvements back by two quarters, the strategic cost may exceed the dollar cost.
The Real Risk Is Not the Wrong Choice
The biggest risk is not choosing build when you should have bought, or buying when you should have partnered. The biggest risk is making the decision by default.
When engineering starts building because “we can do it better,” that is not a strategy. When procurement buys the leading vendor because “nobody gets fired for choosing the market leader,” that is not a strategy either. When nobody suggests a partnership because the company has never done one, that is an unexamined assumption, not a strategic position.
The product manager’s job is to force the question before the team defaults into an answer. Write the decision down. Document which of the three options you considered and why you chose the one you did. Revisit that document when the project is six months in and the original assumptions have been tested by reality.
Adobe’s $20 billion Figma bet was a buy decision. When it failed, Adobe had to fall back on building, and Figma’s independent growth has made the competitive gap wider. The decision itself was not necessarily wrong. The failure was that Adobe did not have a credible build alternative ready when the buy option collapsed.
Product managers who treat build, buy, or partner as a genuine strategic decision, not a reflex, avoid that trap. The teams I have seen do this well are the ones that make the choice explicitly, document it, and build contingency into whichever path they pick.