身為創業者的我們，有野心是好事。創業者絕對不能沒有“野心”，因為這是創業者與一般人的唯一的區別。如果你連變強大的野心沒有，那就絕對不適合創業。但誤區也是客觀存在，創天下不得不指出來警惕創業者。

　　産品應為先，平臺化是之後的事

　　很多年以前我也寫過程式，認識一些技術大牛，大家根本不在乎小白們會不會用，只在乎其他人覺得我的東西屌不屌，追求的是用最少的代碼，用最屌的方法，把這個功能寫出來，至於功能本身能不能幫別人解決問題，我一點也不在乎，因為那是産品經理的責任。我的大腦要用在更有意義的地方，像是去研究更新、更屌的技術。

　　如果創始人不懂技術，又一味追求技術負責人的技藝高超，很容易找到一些“純粹”的工程師。而問題是，大多數用戶根本不知道技術是什麼，對他們來説這個東西也一點都不重要。Paul Graham寫了幾十年的程式後，提出一項真知灼見：“不要開發聰明的東西，而要開發人們想要的東西。”

　　過去十年，技術發展十分迅速，大量公開的代碼和工具可以幫助工程師設計出強大的程式。但是長期如此就造成了現在人們往往更想去設計出聰明的東西，但卻不易聚焦于開發用戶想要的東西。現在是一個以産品為中心的世界，用戶並不關心某某産品的程式是不是用C語言寫的或者是用別的語言寫的，他們只在乎：運作速度飛快，界面清楚明瞭，操作合乎直覺。

　　若要打造最好的産品，必須了解使用者是誰。經常關注和滿足使用者的需求，這一點至為重要，為什麼?因為人們的品味和流行的事物是瞬息萬變、競爭激烈的，除非用心了解使用者的改變、成長和發展方向，否則不可能創造出跟上他們腳步的産品。

　　這時候有人會疑惑了 —— 到底是應該先有內容，再有平臺;還是先有平臺、 再找內容呢?這就好比該先把生産線設備都準備好，再接訂單;還是先接到訂單，再來搞定這些設備。其實答案是很簡單的 —— 沒有哪個公司，會在不知道自己要生産什麼産品前，就大興土木蓋工廠。也沒有哪個客戶，會在不知道你葫蘆裏面賣的是什麼膏藥前，就把寶貴的訂單下給你。所以，重點是先找到那個能夠幫客戶解決問題的産品，而且最好是個痛點，那麼訂單和生産線，都只是時間的問題罷了。

　　也就是説，建立平臺要在殺手應用之後。試想一下：如果不是打車打不到、拒載這些迫切的問題的存在，打車應用也不會迅速竄紅;如果不是在上網的交互體驗上有所突破，iPhone也不會在市場上熱賣。平臺化，都是之後的事情。平臺大夢雖好，但如果沒有殺手應用帶來的第一批用戶，都是白搭。

　　為了創造殺手應用，你必須想出好的産品功能，並且快速開發，與小部分的用戶一起測試，蒐集數據。接著，要是有個新功能提高了一項關鍵指標(例如人們使用的頻率、時間或花費增加)，你就將此功能提供給所有用戶。如果産品某功能改良後效果不佳，則必須調整或刪除。

　　數據不會説謊，在此過程中沒有太多出錯的空間，除非你不擅長做這些：

　　想出可供測試的産品改良方法;

　　厘清如何評估産品改良的成效;

　　判定手中産品功能的相關數據會讓核心指標提高或降低。

　　早期團隊需要什麼樣的人?

　　轉型到網際網路領域，會充滿對未知的恐懼和想像，會希望有一隻夢幻團隊。在理想世界裏，你在早期階段可以真的雇用到這些人，但在現實中恐怕要呵呵。所以我們只能先看看理想的團隊的結構，確認前進的方向無誤，那麼這時候最好先深入研究誰能提供下列三個關鍵問題的答案：

　　1、你正在開發什麼産品?

　　2、該産品是否解決真正的問題?

　　3、我們在為誰(目標用戶)解決問題?

　　尚未打磨出符合市場需求的産品前，團隊裏專門負責産品的人不太可能超過一位(理想情況下，還會有一位出色的設計師，也就是共2人)。只有等到産品上軌道，才需要擴大産品團隊的規模。打車類的産品相對複雜：由乘客和司機組成，兩個應用必須同時運作，才能到達産品符合市場需求的階段，所以需要的開發量比較大。如果應用不複雜，那麼産品經理只需一位就好，其他的錢最好先花在聘請工程師上，全心為公司開發更好的技術。這個時期會遭遇的瓶頸通常不是産品功能的點子不足(是的，點子往往太多)，而是如何快速讓用戶使用所有的産品功能。

　　在開發過程中，通常還會突然冒出其他問題，比如：這個應用看起來如何?這個應用使用起來如何?……負責回答這些問題的是設計團隊(通常隸屬於産品團隊的一部分)。也許你真的只有聘請一位設計師的預算(有時候還是兼職的)，但為了提供殺手級産品，你必須與設計師更密切合作。

　　所有産品人員其實都是在回答“開發什麼”的問題，有的團隊劃分出産品經理、設計師、用戶體驗專員等職位，對早期團隊來説，真是既無聊又沒意義。實際上，應該整個團隊齊心協力，密切合作。每個人的專長的確不同，但到頭來，大家都是應用的使用者，而且許多領域會重疊，所以應該鼓勵所有人都注重整個産品經驗，而非只是單一的、自己的那部分。

　　所以一般來説，團隊成員會包括：

　　1人：創始人人引領産品願景和管理;

　　2-3人：理想上，另一位創始人是工程師，有天使資金後，應該至少再招另一位工程師(或兩位)加入;

　　1人：你可能無法聘請一位出色的全職設計師，但至少每週要能交流一次;

　　1人：此時大概也無法聘請一位全職的QA人員，實際上，確認應用運作無礙的重任，落在僅有一人的産品部門上。

　　綜上所述，團隊成員共為五、六人。如果應用較為複雜，需要建立一個較大的團隊。需要全職設計師、iOS工程師、安卓工程師、幾位後端工程師、幾位外包人員以支援開發，最後再找來一位QA，這樣團隊成員約為十到十二人。

　　敏捷開發與同地開發

　　人有了，一般來説會採用敏捷開發的模式進行具體工作。所謂敏捷開發，是指在一段固定的短時間內，提供有價值的功能或改良，一般持續一或兩周，目標是從頭開始，提供某個有價值的東西(一個特定功能)讓用戶使用。為什麼它很普及?因為每兩周就可以為用戶提供新功能或改良，代表每兩周用戶能測試新功能，讓你評估是否要留下這個功能。

　　敏捷團隊的定義，是指一群人完全獨立自主，採用、執行、測試、配置一個産品功能，最後讓用戶使用。這個概念相當棒，如果團隊規模小，運作成效會很好。這裡很重要的一點是，團隊成員應該在同一個地方，尤其是只有産品/設計/開發等少數成員的小團隊。原因如下：

　　我們先從理想情況開始，如上所述，組織(目前小規模)産品開發團隊的真正目標，是讓他們有能力快速推出應用的新版本，這件事仰賴有效溝通，過程並不容易。為了能經常“推出新功能”，就要持續改善代碼，等用戶使用後提供反饋，再看看應用是否因此變得更好，你必須在每個可能的層面上追求效率。也就是説，要讓整個産品/設計/開發/品控團隊都在同一個地點，隨時待命。如果其中一位或多位成員在遠地工作，只會讓溝通效果不佳，少了大家在同一個房間面對面溝通的機會，也無法隨時私下交流。目前你的團隊規模還太小，尚無法各自為政。但如果你的應用在之後以瘋狂的速度成長，溝通絕對仍是關鍵，因此你現在所建立的溝通文化，未來將得到豐厚的成果。

　　推廣策略：先找競品

　　把應用開發出來只是萬里長征第一步，更重要的是如何讓用戶來用。基本上沒有經驗的人的答案千篇一律：“我們會用盡各種方法推廣。”這和什麼都沒説一樣。每個創業者都非常努力在推廣他們的應用，但最終真能在市場上獲得海量活躍用戶的屈指可數。所以非常努力去推廣，只是基本的工作(或者説願景)，但不是一種致勝策略。

　　除了有願景，還有要務實、按部就班的市場策略。你首先要思考的就是：競品是誰?

　　拿一款APP來説，如果説什麼是最大的競品，我會説是遊戲産業。這不是玩笑，只因為一款應用上市在這個紅海中的紅海最先決的條件就是被找到，用戶都找不到的應用有什麼價值可言?而當遊戲把各種應用市場的榜單佔滿時，你連最基礎冒頭的機會都沒有了。再舉個例子，假設你製作了一款鬧鐘，想的可能是放在生活類別，但詳細觀察當你將鬧鐘放在生活品味這個類別後，會發現什麼房屋出租、二維碼之類都在此類，那麼這些就都是你的競爭對手。所以説，在曝光這個角度上，競爭對手並不是類似功能的産品，而是放在同個類別、能佔據用戶時間的産品。

　　要想一上來就對所有用戶産生網路效應，大公司恐怕也很難做到。但如果先針對幾千人、幾萬人的小群體，而後漸漸擴展，則是小團隊也做得到的，這也是絕大多數成功公司最初使用的策略之一。Facebook從校園開始流行、知乎從網際網路/媒體圈開始發展，都是一個道理。現在問題來了：哪個小圈子最能從你的第一版産品中得到價值?而累積了這些用戶後，又能夠延展到哪去?

　　如何獲取用戶，很多人一定會立刻想到社交媒體。社交媒體是窮人的原子彈，但要提醒的是，玩社群是非常花精力和金錢的，叫原子彈是因為人與人的互動具備散播性，一旦切中角度，後續發酵將超乎預期。所以在産品上線前，先要問問自己各類媒體的發佈與運作是否都準備好了。

　　另外，作為創業者，生存就是一切。當上線後，創業者要根據市場反饋情況，在最快的時間對産品做出修正，市場喜歡什麼就做什麼，拋開一切原則，迎接市場才是。

　　最後，如果創業者做的是需要在短時間內有大量用戶來沉澱的産品時，就沒辦法等待社群慢慢的發酵，只能用用廣告大量、精準地取得用戶。但是關於“如何精準取得大量用戶”也是一門深奧的技巧，並且背後還需要耗費大量的預算，如果沒什麼學費可以繳的話，建議還是先在大公司相關的部門先工作幾年再出來創業，或者直接找到一個能把這塊搞定的合夥人會比較好。