野心是一箇中性詞，有好的一方面，也有壞的一面，但作爲一個創業者有野心是一件好事，因爲這是你與一般人唯一的分別。如果你連強大的企圖心都沒有，那就絕對不適合創業。但誤區也是客觀存在，不得不指出來。
產品應爲先，平臺化是之後的事
很多年以前我也寫過程序，認識一些技術大牛，大家根本不在乎小白們會不會用，只在乎其他人覺得我的東西朖不朖，追求的是用最少的代碼，用最朖的方法，把這個功能寫出來，至於功能本身能不能幫別人解決問題，我一點也不在乎，因爲那是產品經理的責任。我的大腦要用在更有意義的地方，像是去研究更新、更朖的技術。
如果創始人不懂技術，又一味追求技術負責人的技藝高超，很容易找到一些“純粹”的工程師。而問題是，大多數用戶根本不知道技術是什麼，對他們來說這個東西也一點都不重要。Paul Graham寫了幾十年的程序後，提出一項真知灼見：“不要開發聰明的東西，而要開發人們想要的東西。”
過去十年，技術發展十分迅速，大量公開的代碼和工具可以幫助工程師設計出強大的程序。但是長期如此就造成了現在人們往往更想去設計出聰明的東西，但卻不易聚焦於開發用戶想要的東西。現在是一個以產品爲中心的世界，用戶並不關心某某產品的程序是不是用C語言寫的或者是用別的語言寫的，他們只在乎：運行速度飛快，界面清楚明瞭，操作合乎直覺。
若要打造最好的產品，必須瞭解使用者是誰。經常關注和滿足使用者的需求，這一點至爲重要，爲什麼?因爲人們的品味和流行的事物是瞬息萬變、競爭激烈的，除非用心瞭解使用者的改變、成長和發展方向，否則不可能創造出跟上他們腳步的產品。
這時候有人會疑惑了—— 到底是應該先有內容，再有平臺;還是先有平臺、 再找內容呢?這就好比該先把生產線設備都準備好，再接訂單;還是先接到訂單，再來搞定這些設備。其實答案是很簡單的—— 沒有哪個公司，會在不知道自己要生產什麼產品前，就大興土木蓋工廠。也沒有哪個客戶，會在不知道你葫蘆裏面賣的是什麼膏藥前，就把寶貴的訂單下給你。所以，重點是先找到那個能夠幫客戶解決問題的產品，而且最好是個痛點，那麼訂單和生產線，都只是時間的問題罷了。
也就是說，建立平臺要在殺手應用之後。試想一下：如果不是打車打不到、拒載這些迫切的問題的存在，打車應用也不會迅速竄紅;如果不是在上網的交互體驗上有所突破，iPhone也不會在市場上熱賣。平臺化，都是之後的事情。平臺大夢雖好，但如果沒有殺手應用帶來的第一批用戶，都是白搭。
爲了創造殺手應用，你必須想出好的產品功能，並且快速開發，與小部分的用戶一起測試，蒐集數據。接着，要是有個新功能提高了一項關鍵指標(例如人們使用的頻率、時間或花費增加)，你就將此功能提供給所有用戶。如果產品某功能改良後效果不佳，則必須調整或刪除。
數據不會說謊，在此過程中沒有太多出錯的空間，除非你不擅長做這些：
1、想出可供測試的產品改良方法;
2、釐清如何評估產品改良的成效;
3、判定手中產品功能的相關數據會讓核心指標提高或降低。
早期團隊需要什麼樣的人?
轉型到互聯網領域，會充滿對未知的恐懼和想像，會希望有一隻夢幻團隊。在理想世界裏，你在早期階段可以真的僱用到這些人，但在現實中恐怕要呵呵。所以我們只能先看看理想的團隊的結構，確認前進的方向無誤，那麼這時候最好先深入研究誰能提供下列三個關鍵問題的答案：
1、你正在開發什麼產品?
2、該產品是否解決真正的問題?
3、我們在爲誰(目標用戶)解決問題?
尚未打磨出符合市場需求的產品前，團隊裏專門負責產品的人不太可能超過一位(理想情況下，還會有一位出色的設計師，也就是共2人)。只有等到產品上軌道，才需要擴大產品團隊的規模。打車類的產品相對複雜：由乘客和司機組成，兩個應用必須同時運作，才能到達產品符合市場需求的階段，所以需要的開發量比較大。如果應用不復雜，那麼產品經理只需一位就好，其他的錢最好先花在聘請工程師上，全心爲公司開發更好的技術。這個時期會遭遇的瓶頸通常不是產品功能的點子不足(是的，點子往往太多)，而是如何快速讓用戶使用所有的產品功能。
在開發過程中，通常還會突然冒出其他問題，比如：這個應用看起來如何?這個應用使用起來如何?……負責回答這些問題的是設計團隊(通常隸屬於產品團隊的一部分)。也許你真的只有聘請一位設計師的預算(有時候還是兼職的)，但爲了提供殺手級產品，你必須與設計師更密切合作。
所有產品人員其實都是在回答“開發什麼”的問題，有的團隊劃分出產品經理、設計師、用戶體驗專員等職位，對早期團隊來說，真是既無聊又沒意義。實際上，應該整個團隊齊心協力，密切合作。每個人的`專長的確不同，但到頭來，大家都是應用的使用者，而且許多領域會重疊，所以應該鼓勵所有人都注重整個產品經驗，而非只是單一的、自己的那部分。
所以一般來說，團隊成員會包括：
1人：創始人人引領產品願景和管理;
2-3人：理想上，另一位創始人是工程師，有天使資金後，應該至少再招另一位工程師(或兩位)加入;
1人：你可能無法聘請一位出色的全職設計師，但至少每週要能交流一次;
1人：此時大概也無法聘請一位全職的QA人員，實際上，確認應用運作無礙的重任，落在僅有一人的產品部門上。
綜上所述，團隊成員共爲五、六人。如果應用較爲複雜，需要建立一個較大的團隊。需要全職設計師、iOS工程師、安卓工程師、幾位後端工程師、幾位外包人員以支援開發，最後再找來一位QA，這樣團隊成員約爲十到十二人。
敏捷開發與同地開發
人有了，一般來說會採用敏捷開發的模式進行具體工作。所謂敏捷開發，是指在一段固定的短時間內，提供有價值的功能或改良，一般持續一或兩週，目標是從頭開始，提供某個有價值的東西(一個特定功能)讓用戶使用。爲什麼它很普及?因爲每兩週就可以爲用戶提供新功能或改良，代表每兩週用戶能測試新功能，讓你評估是否要留下這個功能。