今年在矽谷網路公司中，除了工程師之外，另一個熱門的角色大概非 Growth Hacker 莫屬。

Growth hackers are a hybrid of marketer and coder, one who looks at the traditional question of “How do I get customers for my product?” and answers with A/B tests, landing pages, viral factor, email deliverability, and Open Graph.

成長駭客是行銷者與開發者的綜合體，當他們看待「我如何為產品找到用戶」這個問題時，答案通常是 A/B 測試、到達頁面、病毒擴散因素、email 到達率以及 Open Graph。

而早在上次這篇介紹 Growth Hacker 的文章發表之前，世界知名的 SaaS provider 37signals 也剛好在他們的官方網站上徵求 Growth Hacker，這篇文章具體的描述了 37signals 所需要的人選必須具備的條件。（可以注意到，文中沒有為這個職缺命名）

我以下條列出這篇文章的幾個重點：

• Growth Hacker 的工作著重在改善轉換率與回頭率（conversion and retention）。（你必須樂於一次只做一個小小的改變，而不是做什麼格局很大的大功能）
• Conversion 可以是財務面的（讓更多人願意完成下單，也就是直接提高銷售），也可以是產品本身的使用結果面的（ outcome-based，例如讓使用者更加依賴產品、提高某些功能的使用率）
• Retention 則是減少用戶不續約的比例，或是減少用戶退訂電子報，增加每日回訪客等。
• 實際的工作內容可能是以下這些瑣事：
  • 調整網頁上的文案，找出怎樣的文案、怎樣的用字遣詞可以帶來比較高的轉換率
  • 必須知道如何激勵使用者，必須深入了解人們為何願意買單、為何不願意買單，人們為何會願意買更多他們已經擁有的東西，或是人們怎麼不買多一點呢？
  • 畫面的配置會直接影響銷售的結果，你必須了解如何重新配置畫面、重新調整需要被 highlight 的區塊、重新調整網頁上的用字遣詞
  • edm 如何派送，例如標題的文案應該怎麼撰寫可以帶來比較高的開信率、內文的版面配置又應該如何、你希望用戶點擊的連結又應該如何呈現
• Ideas and Execution 你同時是個發想點子 & 實際執行的人，小至撰寫文案、設計頁面，從頭到尾每個環節都要實際參與 & 執行，而不只是把點子丟到別人身上、讓別人去煩惱
• 你必須熱愛提出建議、假設、實驗、實作、執行並且評估成效

事實上，我認為這樣的事情是許多公司、團隊早就在做的事情，只是當有人提出了 Growth Hacker 一詞之後，就好像變得比較不一樣，從實質內涵來看，目前談的 Growth Hacker，我個人認為著重在以下兩個重點：

• Growth Hacker 同時具備技術與行銷的能力，除了有一定程度的認知之外，也有直接執行的能力。
• Growth Hacker 本身就必須負責所有的規劃、執行、驗收、反饋，直接對於提高轉換率、提高回頭率（retention）負責。

過去的作法，可能是有個行銷企劃搭配一個工程師（一個負責想點子、一個負責執行點子），或是工程師自行研究了許多數據，但上頭老闆不買單（沒觀念或是不懂），而現在則是將規劃、執行、驗收到持續改善，交給一個混種（hybrid）的角色來進行。

在台灣，以後可能就會出現一些類似產品優化專員、產品優化工程師之類的角色吧？但實際上可能有一半還是在做客戶的專案（誤）。

我的 facebook 是 fb.com/yiru.lin，歡迎訂閱。:)

一直以來，我對於累積專業技能的期待都只停留在一個相當低的層次，對我來說，資訊技術是實現想法的重要武器，但跟資訊技術一樣重要的，還有後續的營運、行銷、銷售，我有興趣的部分在於將產品打造出來、產品營運、持續改善、持續成長的流程。

有時候我會好奇，目前佔掉我超過一半時間、佔掉我們團隊將近九成人力的開發工作，實際上究竟為我們的服務創造了多少價值？

看了 Growth Hacker is the new VP Marketing 一文之後，我隱隱約約的覺得這篇文章某程度描寫了我們正在做的事情，也描繪了一個更清晰的發展輪廓給我參考，我同時也認為，這就是在小規模團隊中，開發者或行銷者應該努力的一個方向，團隊中一定要存在著 Growth Hacker，為產品帶來發展初期的顯著成長，以及後續持續的成長（無論是訪客數、營收還是 retention 等各種數字），這也是產品部門的夥伴們能為公司帶來更具體的貢獻（當然，打造產品本身也很重要）。

Growth hackers are a hybrid of marketer and coder, one who looks at the traditional question of “How do I get customers for my product?” and answers with A/B tests, landing pages, viral factor, email deliverability, and Open Graph.

成長駭客是行銷者與開發者的綜合體，當他們看待「我如何為產品找到用戶」這個問題時，答案通常是 A/B 測試、到達頁面、病毒擴散因素、email 到達率以及 Open Graph。

文中舉了一個 Airbnb 將租屋訊息大量擴散到全球流量最大的訊息發佈網站 Craigslist 上，並且說「傳統的行銷人是想不到這種作法的」。我想，Growth hacker 不需要是由一個人來擔任，兩個人加起來等於一個 growth hacker 也不錯，重點在於對於資訊技術與平台的敏銳度、熟悉度。

我認為，我們團隊存在著好幾位 Growth hacker（雖然我個人完全不覺得自己的能力稱得上 hacker），或是說，我們總會需要在團隊中隨時保有幾位 growth hacker。在看這篇文章之後，我突然覺得運氣很好，我們團隊的行銷人 fOx，其實是知道資訊技術如何運作的，而其他的 developer 們，也對於數據的追蹤，有著高度的好奇心，我們也確實的在努力追蹤各種數據以提高我們的營運績效。

過去我曾經疑惑，倘若不懂產業、不懂產品、不懂一些技術，如何扮演稱職的業務、行銷人。後來我發現，我遇到的優秀業務員、優秀行銷人，都是對於產品有高度了解並且具有相對充足的產業知識，而在網際網路這個變化如此迅速的產業裡，我認為無論是何種角色，都應該廣泛地理解、掌握各種關鍵的知識與工具。

舉例來說，我們公司營運的網站發現使用站上社交功能的使用者人數，是使用 facebook 按讚人數的三倍（等於失去按讚為我們帶來的曝光效益）於是我們迅速的利用 Facebook Timeline，讓我們自己的社交功能也有機會在 facebook 上曝光。倘若沒有掌握新功能所具備的能耐，或許在產品功能的調整上，不會想到要這麼運用。（儘管我也還在觀察，效益如何）

另一個例子，facebook 即將推出 App Center，假使有一個中文版的 App Center 頁面，早期上架的中文 App 或許有很高機會優先曝光，你的 App 準備好了嗎？

歡迎訂閱本部落格的 facebook 專頁： https://www.facebook.com/punk.tw

• AOL 花了 9 年達到百萬用戶規模。
• Facebook 花了 9 個月達到百萬用戶。
• Draw Something 花了 9 天達到百萬用戶。
• 2000 年，Napster 是成長速度最快的網路應用，2000 年七月時擁有 490 萬用戶，是同年一月份的三倍。
• 2005 年，Skype 是成長速度最快的應用，從 0 開始累積到 5,400 萬用戶，只花了 25 個月。
• 2007 年，Facebook 上的 iLike 是成長速度最快的應用，上線第一週就取得百萬用戶，接下來的 5 天又有另外的一百萬用戶加入。
• 2009 年，Facebook 上的 FarmVille 是成長速度最快的遊戲，上線第一週就有超過百萬的活躍用戶（active users）。
• 2011 年，Instagram iPhone 版在一年內達到 1,200 萬用戶。隔年，2012 年的一月份到三月份，又有另外的 900 萬用戶加入。
• 2012 年，Angry birds Space 在 iOS、Android、Mac 以及 PC 等平台上架後，只花了 3 天，就達到 1,000 萬次的下載。
• 2012 年， Draw Something iPhone 版花費了 6 週超越 3,500 萬次下載。
• Angry Birds 花了 1 年達到 3,000 萬次下載；Instagram 花了 15 個月累積 2,700 萬用戶； Draw Something 則花了 6 個禮拜就達成。

以上數據取自 lukew，這個年代，選擇一個平台、體系（Kobe 梗，A system）、生態系（ecosystem），加入它、相信它、善用它，壯大自己的服務，並且隨時準備好離開，因為你不知道它是不是明天就會一夕瓦解。

get your content ready to go anywhere because it’s going to everywhere. via Brad Frost

過去總有人說內容為王，到了這個年代，內容還要能登上各式各樣的載具，才真的能夠稱王。A list apart 的文章一向都相當有深度，認真讀完一篇文章加上文章裡面的連結通常就能對一個議題能有頗不錯的認知（例如 Responsive web design ），認真讀過 Future-ready content 這篇文章之後也有些收穫，整理幾個重點如下：

1. 目的明確（Get purposeful）
   為平台累積內容時，意圖要明確，內容的類型對於營運者、使用者都要有價值，想清楚一些具有策略意圖的重要問題後，才能轉化為平台設計的決策，接著也才能確定究竟網站上堆的那些內容，對組織本身是不是真的有幫助。換言之，沒用的內容，堆再多也沒用。
2. 細節（Get micro）
   如果已經很肯定你的內容是什麼類型的，那麼接著是要注重屬於該類型內容的核心元素。舉例來說，如果你的內容以食譜為主，重要的元素包括：標題、出版社、發佈日期、 署名、份量、簡介、照片、主要食材、其他食材、準備步驟、建議搭配的酒、評價、評論、類別、給節食減重者的建議、相關的食譜建議等等，都應該要能提供資訊給使用者。
   文中有提到，負責資訊架構或是內容策略發展的夥伴（Information architect or content strategist）應該要決定這些細節，但是團隊中的每一個人都應該參與其中，因為當這些內容有機會出現在不同的裝置上時，你可能就是決定哪些元素會有所取者的關鍵角色。
3. 要有意義（Get meaningful）
   了解內容具備了哪些重要元素只是第一步，更重要的是這些元素之間應該如何組織、排序，哪些比較重要、有多重要？可以思考的問題，例如個別元素對於整份內容的重要性、如果拿掉這個元素會有何影響、這些元素是否建立了內容之間的連結？
   如果在比較小的螢幕上呈現資訊時，拿掉不重要的元素是最簡單的作法， 但是也因此讓使用者瀏覽的頁次減少；螢幕變窄的時候，把側邊欄搬到最下面，會不會造成使用者的疑惑；如果食譜沒有圖片，會不會減少使用者的興致；如果食譜只有標題，沒有簡介，對使用者來說有意義嗎？
   唯有我們深入了解所有內容元素之間的關係，才能在呈現資訊的設計上有所取捨。
4. 要有組織（Get organized）
   COPE（Create once, Publish Everywhere），NPR 提出的概念，讓 CMS 之間可以透過 API  進行內容交換時可以確保同樣內容在不同的平台上都可以調整呈現方式（我沒仔細看細節），姑且稱之為一源多用（這是我的指導教授常在 meeting 時對於類似概念的說法）。這一段的重點在於，未來是很美好的，但是內容管理系統卻不美好，內容在交換、流通、整合的過程必須要有組織。
5. 要有結構（Get structured）
   探討內容儲存、傳送的結構，例如 schema.org 上面的標準都很重要。

技術會改變、標準會進化，但是我們理解內容的需求，卻會持續存在，唯有具備如此心態，才能迎向未來。（理解內容，包括理解內容存在的目的、意義、結構、關係以及價值）

Refereces

• Future-Ready Content