企業併購產品整合問題

在我在領英的三年半間，參與了三個併購案，三個案子的產品整合方式，不知道是什麼因素，剛好走上了三條不一樣的道路，可以讓大家比較看看，看那一條是最好的道路。

第一條的道路是我自己的案子，「飛向」的併購案，在領英收購飛向之後，除了收購時的技術審查（Due Diligence）外，我們又花了一個月的時間，通過內部工程團隊跟法務團隊的審查後，打算把原本的產品接上領英的皮，後端則是稍為小改，搬進領英的資料中心後，就直接上線。總共花了六個月的時程就完成，在上線後半年後，有一千個舊企業用戶使用，在一年間增加到兩千個企業用戶，這些企業用戶供獻了兩億美金的營業額，因為我們產品增加了 10% 的客戶留存率，實際上對營業額的貢獻度是一年兩千萬美金。

快樂的故事就到此結束，在我們證明了自己的產品是有用戶的之後，就是要把整個產品，用領英的技術重新寫一遍。這個過程後來花了我們團隊三年的時間，到我離開的一年之後，原本的併購進來的團隊都走光之後，才真正把飛向第一版的程式碼下線。

第二個收購是既飛向之後，收購的「驅動點」，驅動點跟飛向一樣是把程式跑在 AWS 雲端的，同樣也是在換皮之後，六個月內產品上線，然而產品在上市之後反應不佳，我們在繼續維護一年之後，就把人力抽走了。

前面兩個併購案，都算是成功的併購案，領英在併購後，半年就把產品上市，透過領英的行銷能力，快速的測試市場反應，不管最後市場反應如何，這兩個併購案都算是成功的併購案。

第三個收購案「增長」則是比較不幸的例子，在併聘之後，我們並沒有採用「增高」原本的產品，而是修改了產品本身的設計，並且使用領英的技術重新開發，在工程師使用不熟悉的技術下，這個團隊花了十八個月的時間才把產品上線，而在上線前，有一半的工程師已經離開，而帶頭的產品經理也在上線前半年就離開了。一般來說，上線後才是真正的挑戰的開始，產品經理要聽客戶的返應，修改產品的功能，經過幾輪的修修改改，最後才會是一個好用的產品，然而這個新產品在上線前就損失了產品經理，沒有人接手產品的修改，上線後變孤兒，人力也早早被抽走了。

縱觀這三個案子，我的體會是，產品開發的速度是最重要的，如果在收購後，原本的產品可以快速上線，有個正向的反應迴路，客戶反應好，工程團隊就高興，收購進來的工程團隊才不會早早就離開，才不會讓收購進來的產品線變孤兒。