Rethinking the Product Dev & Corporate Dev Relationship: The 5 Half-Truths

Zuckerberg is responsible for setting the overall direction and product strategy for the company. He leads the design of Facebook's service and development of its core technology and infrastructure.It is no secret that some of the most successful entrepreneurial CEOs of our time have promoted a strong “Product First” or “Customer Experience” doctrine within their organizations.  Gates, Jobs, Page, and even Zuckerberg are often cited as prominent promoters of this doctrine. Their companies were built around a strong “Product First” culture along with the recruitment and advancement of talent with strong product and technology backgrounds.

Naturally, most of these companies had to evolve to grow both organically and inorganically.  They could not innovate fast enough nor hire quickly enough to sustain high growth once the law of big numbers began catching up with them.  Inevitably, Corporate Development had to become as important to these companies as Product Development or R&D was to them.

If these stalwarts could depend on inorganic growth to maintain competitive advantage, innovate, and drive growth once they become large, why shouldn’t small and medium sized companies be doing the same, even before the big number laws catch them?  While some mid-sized companies have begun adopting this approach, particularly those with private equity backing and encouragement, there are fundamental shortcomings in the strategy, planning, and execution of M&A departments within most organizations.  These prevalent shortcomings can be best summarized through the Five Half Truths outlined in this article.

1.     Acquisitions are the riskiest initiatives companies pursue

Most executives and Board Directors subscribe to the premise that acquisitions are extremely risky.  One need not look any further than recent debacles such as EBAY/Skype, Google/Motorola and HP/Autonomy to find obvious illustrations.  Numerous studies point to the fact that 50% of mergers and acquisitions fail to meet expectations.  In that light, it is not surprising why many Boards are reluctant to invest significantly in M&A.  What these studies fail to point out is that the alternative to M&A, organic product development and R&D, is even more risky.  While few studies have been done around the risks of R&D projects in software companies, studies that do exist around software R&D in government-related industries (defense, intelligence, etc.) indicate that far greater than 50% of projects fall well short of expectations.

Further exacerbating this phenomenon, in the hypercompetitive technology sectors we live in today, it is nearly impossible to enter into any sizable software project (18 months or more) without the requirements and competitive landscape changing significantly during the development cycle of the project.  So even when “expectations” are met, that is often not sufficient for outright success since expectations that once correlated to adequate results might no longer correlate to even minimally sufficient results.  While M&A is far from risk-free, it should be thought of as “the devil that you know”.  While what is acquired via M&A may not be perfect, if you do your homework (i.e. diligence) you know exactly what you are getting on day one – strengths, weaknesses, threats and opportunities.   In contrast, when you embark on a large software R&D project, what comes out the other end of the sausage factory is far from knowable in advance – in capability, quality, duration, and of course cost.

2.     If we did a thorough analysis, we would always build

Many executives believe that M&A is a tool of last resort, reserved for those occasions when a product organization has trouble adding capacity or acquiring the talent required to build great product in a timely fashion.  This belief stems from the idea that in technology centric industries it is important to have an organic capability to innovate, build product, and sustain differentiation.  Furthermore, whatever formal calculus for buy vs. build analysis might have existed historically within mature organizations often came out on the side of build.

However, the past 10 years has brought us a paradigm shift in this calculus in several dimensions.  Firstly, the cost and complexity of integration often weighed on the scale in favor of build.  In past cycles, even when products and technology could be acquired cost effectively, by the time the risks and time required to integrate an acquired product were factored in, the benefits rarely outweighed the alternative of just building organically.  However, the technological advances of the past decade in terms of managed code, web services, loosely coupled APIs, and cloud computing have made it much easier, less risky, less time consuming, and less capital intensive to integrate what otherwise could be two very differently architected software products.

Secondly, the ability of organizations to identify, hire, and retain the talent they need to build significant new products has been hampered by the widespread talent gap most technical organizations now face.  The lack of national immigration reform combined with even the shortage of quality, well-managed, off-shore development organizations has made it nearly impossible for growth organizations to meet their hiring goals without significantly sacrificing their quality criteria.  Forward thinking organizations such as Google and Facebook have recognized that M&A is an important tool for innovation – so much so that they start thinking of M&A and “acquihires” – particularly when associated with tuck-in features or new start-up products – as part of their “organic” innovation strategy, somewhat redefining the term “organic”.  Furthering this paradigm, progressive organizations prefer to use the terms “insourcing” and “crowdsourcing” rather than “inorganic”.

3.     When M&A fails, it is for business reasons

In Soul of a New Machine Kidder quite famously describes various scenarios where the software folks blame the hardware and the hardware folks blame the software for anything that went wrong with the product.  In M&A there is a similar phenomenon.  R&D people blame the business and finance people for ills having to do with M&A.  How often do you hear “we didn’t understand the cultural issues”, “our channel can’t sell the new products”, or “we overpaid for that garbage”.   Truth be told, most often it is all about the product – when it goes well and when it goes poorly.  Was there a compelling product vision, was it delivered to the customer in a timely fashion, and was it looked upon favorably by the customers?

While it remains to be seen whether several of the blockbuster deals of the past few years will turn out to be successful, the fates of HP/Autonomy, Microsoft/Nokia, Facebook/WhatsApp, and even Microsoft/Skype will surely rest at the feet of the newly integrated products and their impact on customers, not on the financial models, the valuation multiples, nor even the effects on the acquirer’s balance sheet.

4.     Corporate Development should lead the M&A Process

Most organizations rest the fate of their M&A program in the hands of Corporate Development. Corporate Development heads are typically chartered with developing the strategy for acquisitions, identifying the targets, vetting the targets, and executing on transactions.  Naturally, they work with business units primarily in the areas of diligence and integration – although most would argue that Corporate Development quickly gets out of the way and leaves the challenges of integration to the business units (and in the process avoids blame when things go bad).

What is needed, and what progressive companies have adopted, is a more agile and integrated approach.  While a good Corporate Development organization has to be adept at organizing diligence, evaluating businesses, and negotiating deals, even more importantly it needs to be tightly integrated with the business and product organizations.  In fact, Corporate Development should take a cue from, and be a part of, Product Development.  In truth, Corporate Development is a tool for executing growth and product strategy.  It must be looked at as a sibling of R&D, not a parent nor even a close cousin.

While Corporate Development heads might quarterback an M&A process, leadership for growth – organic or otherwise – must come from business and product leaders.  Decisions regarding M&A must be tightly integrated with product development decisions.  Those companies most successful at generating consistent growth, with a healthy organic/inorganic mix, have managed to drive product innovation from product centric organizations, and have tightly integrated Corporate Development as a component of, and not the master of, Product Development.

5.     Agile is for Software Development

While it is true that Agile was coined in 2001 when a group of software developers published the Manifesto for Agile Software Development, it is astonishing that the principles of Agile Software Development have not yet been extended beyond Software R&D.  Agile promotes short, iterative development cycles and other processes that allow organizations to reduce the risks associated with unknowable variables.  Innovation driven industries have many of the same characteristics of software development – changing product requirements, radical shifts in underlying platforms, and significant deltas in the economics of infrastructure.  In addition, these industries are littered with examples of leading companies going from zero to dominant market share, because of the characteristics enumerated above, in as short as two or three years, often with minimal capital consumption.

It is these factors that make these industries ripe for a new approach to strategy that follows the Agile model that is now adopted by 35% of software development organizations.    The companies in these industries need to develop an Agile, iterative, strategy framework that allows the organization to rapidly adapt to changing requirements and assumptions.  The departments within the organization need rapid feedback cycles where ideas, products, strategies, and tactics can be developed but more importantly tested in iterative fashion with effective feedback amongst the internal functions as well as between the organization and its customers and business partners

Ironically, software engineering, a profession that for years lacked any type of professionalism (as recently as in 2002 there were only two U.S. universities offering degrees in software engineering – most schools prefer the more theoretical computer science), has suddenly overtaken its corporate parents in terms of adopting an approach appropriate for the new innovation economy.  It is time that the rest of industry followed suit and promoted Agile from the R&D labs to the boardroom.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s