文章
在Hacker News上看到這篇心得分享文，歸納了幾個原作者Ben Bloch發行第一支App – Whim，然後收掉的經驗心得。原文經驗整理的結構與邏輯不錯，順著原作的寫法，加上小部份自己看法，整理如下：
經驗一：挑產品名
這很基本，除了腦力激盪，集思廣益，找出如何符合產品意象，好念順口的產品名外，底下提供幾個也該注意的事項：
1. 檢查產品名是否被註冊商標
註冊商標是個有法律效應的東西，事前檢查絕對不會吃虧。
2. 先檢查這個名字能不能送App Store
這部分就是檢查是否已經有同名產品在App Store上面了，可上itune作關鍵字搜尋，看能不能查到什麼樣的產品。如果沒有同名產品，建議先想辦法佔住那個你要的名字，不然等到App做好的時候，或許會發現有人早你一天送上去，豈不氣死？
占住的方法，可能可以想辦法早點送上alpha版的app，即便審過了，不要發佈就不能被使用者下載。
3. 檢查網域名稱是否可用
基本上，App領域裡網域名稱不像做網站的那麼關鍵。不過，如果整體服務中有關鍵的網路部分功能，需要個網址，就必須早點檢查。
Ben建議，如果網名已經被拿走了，也別緊張，可以試試 後面加App，或是前面加Get。以DoodleTimer為例，就是申請 DoodleTimerApp.com 或是 GetDoodleTimer.com這樣的網址也是個好選擇。
4. 工具與技巧
選產品名是個有趣的過程。先把產品的感覺抓一抓，產品走向或族群也寫下幾個關鍵字，接下來就可透過這些字來想產品名稱。Ben建議了RhymeZone，可用來找相關字，這對英文非母語的我們來說應該是特別有用的一個取名網站工具。
經驗二：關於開張前後該注意的事
在公佈App之前，Ben已經給大約一百個朋友測試過他們ad-hoc的app版本了。
不過，送上架之後才發現各式各樣的問題，而這些都不是透過Testflight + ad-hoc 測試app能解決的。 讓Apple審核通過，而且發行之後的版本，還是需要好好的測試一下。
不過，要測試這種版本就意味著他已經公開了。為了避免這個未經完整測試的版本被使用者下載了（抱怨），Ben提供了兩個作法：
- 定高價，讓人不會去下載它。對於要加入測試的人，則給他promotion code。
- 限定只有特定地區的人可以下載app。
如果是social類的app，一開始用封閉邀請的beta模式上架，也可以避免在產品沒達品質前，被太多人下載。
經驗三：分享 擴散的做法
Whim的致命問題之一就是專注於分享擴散這件事情。 讓用戶分享給他人，然後訊息或app就擴散出去了，這件事情說起來很容易，但做起來很困難。沒有動機的用戶會讓這整個擴散計劃崩潰。 Ben另外推薦了閱讀Plancast發佈在TechCrunch上的這個心得分享 – The Uphill Battle Of Social Event Sharing: A Post-Mortem for
Plancast 。該文探討了分享擴散計劃中該注意的八大重點，若是採分享為擴散途徑的app開發者，可以讀一下。
經驗四：隨時要注意什麼是對的事情
在Whim上線前，加了一個功能 – 當你附近有朋友打開了Whim，你會收到通知。不過，”附近”的定義挺難的，在舊金山這樣擁擠的城市裡，兩英哩不太算“附近”，即便知道朋友開了這個app，也沒辦法去參與相關活動，因此這應該算是個惱人的功能。不過，Ben注意到，通知發出後，朋友的確會打開app，而這又觸發了其他的朋友打開這個app。雖然因為距離的關係，Whim沒辦法進一步地造成用戶間的互動，但是這個觀察到的行為變成現在Ben他們在專注的新專案了。
經驗五：要知道自己擅長什麼
大部份開始創業iOS app的人都是從工程角度出發，是擅長寫程式的人。跨技能的學習很重要，但考慮時程與資源限制，適時地將設計包出去給更有專長的人來處理肯定是個好主意。
經驗六：為何而戰？
創業者通常會犧牲睡眠，收入以及體力，因此你必須常問自己：為什麼要做？
是為了做的不一樣？改變世界？
還是這太有趣了，停不下來！
抑或是 這有一個賺錢的契機，不達目標絕不停止。
能全職做這樣的一件事情，是種幸福，也是很讓人興奮的一件事。
隨時問自己，你為什麼要做這個app??
結語
(轉載自:http://www.inside.com.tw/2012/03/03)
