Product Managers: Build/Buy/Partner. Do You Really Have a Choice?

A product manager discovers a new market problem and believes it represents a great opportunity. After completing some initial discovery he/she creates an initial product vision statement. As the 280 Group describes, “The Product Vision Statement is a description of the essence of your product: what are the problems it is solving, for whom, and why now is the right time to build it.” At this point the product managers faces a difficult decision. Should they buy an existing solution/company? Or should they build it themselves? Or should they partner with another company to take a solution to the market? Contemporary product management gurus and methodologies present this as an important function of product management. In reality, do product managers really have a choice when it comes to build/buy/partner?

Build/Buy/Partner: Contemporary Conventional Wisdom

Google returns over 35 million items for the search Product Managers: Build/Buy/Partner. Deborah Henken of the Highland Team and Norma Watenpaugh from the Phoenix Consulting Group do an excellent job of summarizing the conventional wisdom in their article Build, Buy, Partner: The challenges of product management. The following graphic summarizes their thinking:

Conventional wisdom implies that product managers actually have a significant impact on the Build/Buy/Partner decision. Practical experience shows that this is rarely the case.

The Build Solution

Once a product vision has been crafted and a product business case has been approved by executive management, 90%+ of the time the build option will be selected. The exceptions are when the product vision covers a market problem that is not close to your enterprise’s core competency. Even then, if the idea is adjacent to your existing competencies the build option will be preferable to buy or partner opportunities.

There are a couple of reasons behind this type of decision making. First, the development organization will point out that they have built the core products that have made the company successful. They are a professional, agile software engineering organization. Second, it is the product manager and product owner’s responsibility to define the epics, user stories, and backlog items. Product defines ‘what’ the product should do, Development determines the best way ‘how’ to implement the backlog. If there is an issue of ‘core competency’ it lies with the product managers and product owners – not Development. If the product managers and product owners do not have the necessary expertise, then perhaps the product vision should not be pursued at this time.

Development organizations have a natural tendency to strongly favor ‘building’ solutions. It is their core competence. Choosing the build option allows them the potential of growing their headcount and influence in the organization. It provides an opportunity for their existing staff to work on something new, innovative, and exciting.

The Buy Option

In reality, only about 2% of product manager’s recommendations to ‘buy’ a solution are acted upon. Product managers do not have the credibility with CEOs, board members, and investors when it comes to mergers and acquisitions. The only time a recommendation is acted on is when the company a product manager is interested in acquiring is already on the list of potential acquisition candidates maintained by the CEO and your company’s corporate development team.

Acquisitions are a complicated process. A product manager can pitch an acquisition candidate, but it is a complicated process. Check out Product Leaders Should Learn How to Pitch M&A Candidates to get an idea about what would be required. Acquisitions are complex. When Twilio acquired SendGrid in 2020 the process took almost 16 months and required over 60 meetings among the executives of both companies, boards of directors, investment bankers, and lawyers. You can see the entire chronology here in SendGrid’s proxy statement for the acquisition (pages 98 – 114).

Buy decisions require cross organizational support. When I was a corporate development executive for a private equity backed provider of B2B integration solutions, I pitched an acquisition candidate. There was initial interest and a small team that included me, the SVP of Development, and the CTO went on a two day trip to learn more about the company. We received extensive demos and presentations in response to our initial due diligence questions. The company had a solution that addressed the lower end of our 10,000 customer base. They had an innovative demand generation approach that leveraged Google Ads that drove most of their sales pipeline. They were very profitable and by combining our businesses could become even more profitable. At dinner after the first day of presentations I asked my colleagues what they thought. To my surprise they were not inclined to move forward with the deal. The company use a Microsoft-centric technology stack while we were primarily Java and UNIX focused. Our existing technology that served the same market segment was originally a 16 bit Microsoft product that had been maintained over the years. The SVP and CTO thought they could build a similar solution to the acquisition candidates leveraging technology we already had. Their lack of support for the deal was a major challenge. The deal blew up due to valuation concerns. While the CEO was in favor of the deal, our private equity owners were only willing to support a bid that was 40% of what the target was looking for.

The Partner Option

The partner option represents the lowest risk option. Partnering faces a number of challenges. Financials are first. When you partner with a company you split the revenues based on an agreed upon formula. 60% for you and 40% for them is a  common arrangement. One issue a revenue split introduces is that when a sales person sells a $100K deal, they usually only get commission on your share of the revenues. So if they have to spend 150 hours to close a $100K deal, they will be more likely to focus on your core offerings where they can earn full commission. Another challenge is that you will have to invest in advance of major sales in training customer support, pre-sales, and professional services personnel in the partner’s technology. As Henken & Watenpaugh point out another challenge is that you will not own the IP or control the roadmap of the partner product. This may cause issues in the long term. On the plus side, profits from partner product sales can be higher than your own products.  You will not incur the costs of developing and maintaining the product. To sell an effective partnering opportunity inside your company you need to get the consent and support of the entire organization. Almost any department can tank a deal if they believe it is not in their best interest.

Partnering can lead to an acquisition. In 2010 I ran product management for a provider of enterprise scale workload management systems. We were approached by a Los Angeles based startup in the workload automation space. Workload automation solutions have two major components – a centralized job management system and software agents that ran on each server in a customer’s environment. My firm specialized in universal agents that ran on mainframes, UNIX/Linux servers, ISeries servers, and specialized servers for SAP. We did not offer a centralized job management solution – instead our agents could replace the agents for all of the leading job scheduling solutions – at a significantly reduced cost. The startup had recently lost a number of RFP competitions because they did not have a certified SAP agent. We quickly struck a deal for them to OEM our SAP agent. A few months later we decided to OEM their workload automation solution. Our technology was politely referred to as Late Majority. In reality it was in the Laggard stage of the technology adoption life cycle. By partnering with them we could offer a modern complete solution to our existing customer base.

After we had made some initial sales we asked them if they were interested in merging with us. The price they quoted us was about four time what we were willing and able to pay. We happily continued on with the partnership. About six months into our relationship we conducted a joint roadshow for our leading European customers. One night in Amsterdam after a particularly good meal and a few adult beverages my counterpart at the startup told me that they might have some flexibility on the acquisition price. They cut their ‘ask’ by over 60% and were willing to do a deal that had a cash and equity component. Six weeks later we closed the acquisition. The deal worked because we had already proven that our combined offering was selling to our customers. Both sides had a chance to get to know and trust each other from a marketing, sales, customer support, development, professional services, and finance perspective.

Summary

It turns out that product managers really do not have a choice when it comes to Build/Buy/Partner decisions. The most logical option for companies for companies to pursue is the build option. There are many hurdles that a product manager has to overcome for the buy or partner options to be viable. People like to point out that a recent Harvard Business Review report, the failure rate for mergers and acquisitions (M&A) sits between 70 percent and 90 percent. (Lake Capital). Famous tech M&A failures like AOL-Time Warner, eBay-Skype, and Microsoft-Nokia are prime examples. Partnerships face challenges from a financial and operational perspective. Sometimes they work out spectacularly, many times they just fade away due to incompatibilities between the partners.  So product managers really do not have a choice when it comes to Build/Buy/Partner decisions.