闲谈小型软件公司创业

原文载于： http://ihower.tw/blog/archives/1602


這是一本由 geek 寫給 geeks開小型軟體公司的書。書的預設讀者是給技術出身(developer,programmer)的創業者來補足一些技術之外的知識跟概念，像是行銷/銷售/人事/經營策略/會計/產品定價等等。我想任何有 freelance 意識，進而想要有自己事業的programmer都很適合這本書，而且念起來非常有趣 (嗯，非常geek風格~)。

就如同Joel所說的，一間非技術背景管理階級的軟體公司，沒有太多機會。要創立軟體公司，還是給搞技術的人來吧… :p

by the way… 如果你對這樣的獨立創業模式(員工人數少、所需資金少，以正現金流量為導向)有興趣，我建議還可以看看這本書 Go It Alone。

回到 Eric Sink 這本書分成四個部份，Entrepreneurship 企業家精神/People 人/ Marketing行銷/Sales 銷售

Part 1 : Entrepreneurship

第一章 定義 ISV 跟本書預設讀者

independent software vendor，自行創造/行銷/銷售軟體產品。某個有技術背景的人管理小型 ISV，稱作 a geek founder。

第二章 在有大岩石的桶子中找商機

軟體工業已逐漸成熟，大公司軟體帝國已然建立，所以除非你有革命性的點子或大把資金，否則成熟的市場不歡迎新的大公司。但是較小的市場區隔還是有很好的利基點，即 small ISV。不過在大廠環伺下，機會點有那些呢? 利基在於 1.透過 internet，市場已經是 global 2. relatively safe，大公司沒興趣的小市場，但對小公司來說已非常足夠。

就像一個桶子已經裝滿由大公司擁有的大岩石，但還是有很多空間可以放小石頭。有三個理由我們看不到其中的機會:

    我們不想看到，眼界狹小只看到大岩石，而不關心小利基市場。但是一個有 $3M (三百萬美金)年獲利的小ISV(如15~30個員工)，其薪水是非常好的。而且小公司專注在服務基本客戶而不用被創投或季財務預期所干擾。
    沒有人頌揚小公司，人們總是關心大公司的新聞，小公司似乎不太酷。但是小公司跟客戶很親密，大公司的政治跟呆伯特問題不存在。
    我們看事情非黑即白，學理工的的人看事情常陷入二元思考(Binary thinking)，尤其是思考 business opportunities 的時候，忘了很多事情是灰色的，例如”使用者會買這個產品嗎?”，我們應該改問 “有多少人會買這個產品?”，這很重要。

Size does matter. 找尋小一點的空間，才有很多的酷機會。

第三章 開始你自己的公司，你適合做 software entrepreneur 嗎?

注意這本書講的是 “bootstrapped” 而非 “funded”，即不是拿創投的錢，而是只靠自己，這兩種又有很大的不同。創業前要了解自己，反省及面對自己的弱點，因為需要通才，要學習做很多雜事以及溝通能力。也要想好風險，你有多少失敗空間，克服失敗的恐懼不代表你可以去賭(例如拿房子去抵押太risk了)。

一定要做好行銷作業，市場夠大可以生存嗎?市場夠小可以避開大公司嗎? 作者建議你的市場大小不要超過 $50M USD per year。要做 vertical 而不是 horizontal，即利基市場 (niche market)，當然要進入 vertical maarket 就需要了解特定產業 (domain know-how) ，因此作者特別建議最好別做 tools company (雖然作者自己是)，就是給程式設計師用的工具軟體，因為這個市場暨不大而且大公司因為策略推廣因素又會去做(例如微軟的各式軟體開發工具)。

作者推薦 矽谷之道 這本書來幫助你評估新事業 (雖然作者不喜歡這個書名就是了)，書我買了，不是很厚的MBA書，主要是四十四個非常實務的問題，你可以不用寫完整 bussiness plan (除非要找創投)，但你一定要想過 how to make money，寫下你的財務預測(每個月的收支)，盡量壓低初期花費，小心產品 1.0 release 前就花太多錢。需要seed captial的話，除了借錢之外，作者建議創業一開始也許用接外包案來生存。

第四章 給Geeks的財務

財務之必要，財務之boring。這章簡單介紹三種財務報表(Income statement,Balance sheet,Cash flow statement)跟一些財務名詞(profit margins,revenue,cost of goods,gross profit 等)，為何 open source 營運模式困難，從財務觀點來看因為它傾向低毛利率。你需要外部資金嗎? 如果是用自己的盈餘慢慢成長，只要cash不花完就ok，但如果拿了外部資金，創投會要你快快花大錢快速成長，而且若只是 breakeven (損益平衡)還是算失敗 (投資報酬率太低)。

看完這章讓我第一次認識到 應計制會計 這個名詞… :p 接著又啃了一本會計入門書。

第五章 探索 Micro-ISVs

何謂 Micro-ISV，就是比 smail ISV 還小，只有一人負責所有事情… XDXD 話說有本書就叫 Micro-ISV ，不過那本書定義的應該不限一人。

第六章 第一份我的 Micro-ISV 報告

作者親自實驗一個 Micro-ISV 計畫，他實作一個簡單的game來賣… 不過最後失敗沒幾個人買… XD 他檢討有幾個原因，如產品不夠區隔化、不應做遊戲、需要更持續的投入… etc

第七章 犯更多錯

這章還蠻有趣的，提到幾個作者犯的錯誤。每個CEO都會犯很多錯。例如小心簽約時就固定金額的 project (後來的開發成本超出預估)、小心太新的技術、不要買房地產(隨著員工變多就不實用)、小心沒有競爭者的市場(因為根本沒有人需要那個產品)、小心 middleman (掮客)、所有合約應該要給律師看過、多用現成的技術跟標準等等故事。

Part 2 談人 People，讓我想起另一本軟體管理名著: Peopleware。我想兩本書拿來一起比較的話，應該有非常有趣的觀點差異，有機會再來分享那本書的內容。

第八章 Small ISVs 需要 Developers 不要 Programmers

你應該找多才多藝的 developer，而不要找只寫 code 的 programmer。何謂作者定義的 developers，就是除了 coding 跟 fix bugs(幸運的話) 之外，還需要做以下事情 :

    Spec documents
    Configuration management
    Code reviews
    Testing
    Automated tests
    Documentation
    Solving tough customer problems

大公司適用的 programming ，不見得適用小公司。Context is critical。不要把 programming 隔離起來，請教會他! 調整心態不要有 code-only 的想法。

延伸閱讀: Simply Patrick 的 developer vs. programmer 跟 developer vs. programmer, part II

第九章 Geeks 跟 MBAs

這章真是令人興奮，看完一整個爽… XD 一直以來好像創業應該有人負責程式有人負責business(至少眾多創業活動跟競賽都是這麼規定)，不過經過作者這們一說，一個 software company 創立根本不需要找個 businessman 來幫忙。看看這些成功的大公司(microsoft,yahoo，每家的兩個 founder都是技術出身)，其實不止軟體業，科技業的CEO也多是技術出身(這個議題想必商業週刊應該做過研究吧)。

當然，作者不是要說 developer 最偉大，畢竟你還是要跟 “會把HTML當成程式語言” 的人一起互動，但是 developer 也可以去做客服人員、銷售人員、行銷人員，公司不應害怕讓 developer 去做除了軟體開發的事情。公司在討論決策時，也一定要有非技術導向的思維，developer 要讓自己的意見被重視，就應該去學習其他非技術的東西(如行銷)來平衡。

重點是因為初期所有的決策幾乎都跟技術有關(例如一個經典問題，要自己 build 還是 buy?) ，developer 帶來的價值勝過其他人 (正確的說是隨著公司大小而定，公司越小相對價值較高，公司越大相對價值才會降低)，的確是有很多工作是 non-coding，不過那些只是 part-time job(自己或developer來做即可)，你不需要 full-time的人力，創業初期你不需要 MBA，更不需要所謂 businessman 的 co-founder。

延伸閱讀: Simply Patrick 的 developer-centric or not 和 找出 IT 產業的蠢事 末段的 joel 認為一家管理階層缺乏工程技術背景的技術公司不會有太多成功機會。我也非常同意有沒有 developer-centric 的文化是判斷一家軟體公司是否會成功的關鍵。

第十章 雇人

四個做 hire 決策的 guideline :

    直到有非常明確且持續性的職位需求時才雇用 (after)，而不是預備性的僱用(before)。這裡提到如果你有接受創投資金，往往會雇用過多的人，因為創投希望你快快成長而不是把錢放銀行。
    要了解 Hiring 全關乎機率啊~ 有可能即使看起來條件都很好，進來之後也可能不適用。你只能盡量挑機率大的。
    多了解法律合約，可詢問律師。
    多聽聽不同觀點的意見，作者建議一定要有女性的意見(畢竟軟體公司有9成的員工是男生)。

要怎麼挑人呢? 首先是寧缺勿濫啊，公司這麼小若請到不適任的人相對損失非常大。

    請找至少在某一層面上比你優秀的人，有 something 這個團隊沒有的。不要怕員工比你厲害。
    最好的人就是不會停止學習的人! 這個人會學習嗎?? 會持續學習的人表示知道自己有所不知。
    了解自己的弱點，不怕討論的人。 (當然，你問的時候要小心面試書籍給他的答案)
    是否多才多藝願意去做任何能讓產品更成功的事情，而不只是 coding。
    僱用 Developers，不要 programmers。大公司找 best coder，小公司要找 best developer。
    教育程度則建議大學程度，Computer Science 領域。作者認為大學學歷最剛好，因為學校是教你成為 computer scientists 而不是 programmer或developer，還有很多學校沒教的東西。但也小心學歷太多，例如 Ph.D，除非有實作經驗。
    請實際看看來面試的人寫的 code，請問他實際寫過多少程式，coding經驗越多越好，有open source經驗最好(表示對coding有passion)。

第十一章 好 Hacker不等於好 Hire

偉大的Hacker不一定好，因為難搞。hacker常有技術偏見(例如討厭微軟)，因此雖然 productivity 高，卻可能不符合客戶需求。不了解 工作(job) 跟興趣(hobby) 差別，畢竟還是有很多東西並不是有趣的。不關心與使用者的互動，不願意幫助客戶去使用軟體(覺得客戶笨?)……etc

第十二章

偉大的 developers 不只能讓產品更好，也能讓其他人因為跟他共事而更優秀。因此在 hiring developers 的時候，請考慮以下兩個問題:

     high-notes 能力，這個 developer 能讓產品更優秀嗎? 有創造力嗎?
     choir 能力，這個 developer 能讓團隊更好嗎? 能促進團隊合作嗎?

第十三章 生涯打算

C = G + LT ，持續學習才是重點。最好的機會就是思考面對所犯的 mistakes，而不是逃避掩蓋。自己的職涯掌握在自己手裡。

Eirc Sink 開頭就提到在 smaill ISV 至少要有人得會基本的行銷概念才行。

作者把行銷跟程式設計類比在一起，程式設計的第一階段是 deisign，第二階段 implementation。行銷同樣也是兩個階段，第一是 strategy，第二才是 maketing communications(如打廣告)。奇妙的是大家都喜歡忽略第一階段的重要性…:p

14. 找產品點子

行銷第一步，就是要找到 product ideas。請先 brainstrming 先想好一堆，暫時還不要去評估。請 focus 在要解決的問題，而不是技術應用。多思考 vertical marketing，特定產業所使用的軟體(當然，最大的問題是你必須知道很多那個領域的知識)。去翻翻電話簿黃頁，看看其他公司可能會使用哪些軟體。問問別人希望有怎樣的軟體。最後是加值產品(add-on product)的可能性，記得要在大的 host application上做外掛。有了一堆點子之後，才開始評估 pick one，記得問問跟你事業無關的人的意見。

幾個重點，最好不要做 game，賣一個解決問題的軟體比較容易。一定要有競爭對手，請多search，沒競爭對手表示很有可能根本沒有這個市場需求。你的產品的差異化是什麼，要有清楚的產品定位。你可以賣的 1.0 產品最好在半年內推出，最好可以直接在線上用信用卡購買。小心目標客戶的預算問題，你的產品價格最好不要高到購買程序變複雜，最好低於$500美金。小心產品技術支援的負擔。

15. 行銷不是後來的步驟

產品定位，作者用一句範例來說明STP的概念。這句話  ”The most popular operating system for desktop PCs”，其中 “The most popular”描述位置(或常說 No.1)，為何要選擇這個產品? “operating system”描述市場分類，這個產品是什麼? “for desktop PCs”則精準描述出哪些族群，誰應該買這個產品? 另一種思考產品定位的方式是，哪一種市場區隔可以讓你的產品是第一名… :p 請注意市場事實，不要自欺欺人，例如不要定位你的繪圖軟體功能最完整(大家都知道是photoshop)。

有了產品定位，你才能決定你的產品要有哪些功能。行銷不只是宣傳你的產品，同時也決定了你要開發什麼樣的產品。

16. 選擇你的競爭對手

在選產品點子的時候，不要因為有競爭對手就太快放棄點子。因為有競爭對手表示有這個市場，完全避開競爭對手也意謂著完全避開了顧客。全新的點子並沒有想像中的重要，較好的方式是找已經有人做但沒做好，而你可以做更好的。建立一個全新的產品區隔是非常困難的。

因此如何選擇你的競爭對手呢? 那種又大又笨的對手最好了，例如 FedEX 對 U.S.Postal Service。還有 partners 也要選擇一下，第3或第4都可以。至於位於2的公司是活不久的。
Big Small
Dumb 1 2
Smart 3 4

競爭者會不斷加入，要如何防禦你的產品市場呢? 別擔心，只要你的產品區隔夠 fragmentation，即你的市場由很多公司所共享，例如不要去加入有90%市佔率的desktop os市場，反之 embedded os 就足夠分散。還有你的產品要夠 differentiation。分散的市場會讓有差異化的產品能夠生存。

17. Act Your Age

跨越鴻溝。產品生命週期可以分成 Early Adopters / Pragmatists / Conservatives / Laggards 四個階段，並可以畫成一個鐘型圖 (以下圖片從網路上抓的)。 其中 Early Adopter 只是喜新厭舊的人，你不能只靠這些人長久生存下去，因此 Pragmatists 才是成功產品最重要的關鍵 (他會引導更多 Pragmatists 跟 Conservatives 購買)，但是請注意這中間有個巨大鴻溝，為了跨越鴻溝，你必須不惜代價要對 Pragmatists 特別好，想辦法去滿足 Pragmatists 的需求。

2-3.jpg

最大的重點就是不同階段要做不同的事情。一開始針對 Early Adopters，你的產品要又cool又new，且不需要提供 conservative 才需要的boring功能(?)。針對 conservative 則要穩定實用。Early Adopters很有可能也是聰明的geek，對技術多有涉獵，你可以得到一些很棒的想法。而 Pragmatists 跟 Conservatives 並不是 geeks，並不懂技術，你需要更小心的聆聽，記住要解決他們的問題而不是提供很炫的功能。到了 Conservatives 階段則動作要慢，更改任何功能都要慢慢來。

18. Geek Gauntlets

小心geeks的科技偏見，Early Adopter的feedback也要小心 (也是geeks)。例如喜好用最新技術等等。重點還是 users。

19. Be Careful where you build

小心平台 platform 的選擇 (這裡廣義包括 Hardware,OS,Programming language,Class libraries,Components,Runtimes,Other Applications等)，畢竟若把房子蓋在沙灘上，大雨一來馬上就垮了。

平台的功能越多越大開發時間可以越短，但是可能 1.效能變慢 2.整合測試變難 3.使用者安裝變冗長 4.透過平台的做法跟一般不同，例如 Java Swing的GUI跟windows native的不同。因此還是要回歸到 users 第一。因此 .NET 雖好，但作者仍建議用C++&MFC。舊技術並不可恥，只要對使用者最好。著重使用者友善跟喜好是第一考量，開發的生產力才是第二。

例如作業系統的選擇，當然支援windows是一定要的，MacOS其實可以考量，市場並沒有想像中的小，只是你產品要做的 really pretty，至於 Linux 就不要考慮了，尤其是桌面應用程式，使用 Linux 的人不但少而且顯然不喜歡花錢。

20. The Game is Afoot

作者用遊戲來比喻一些競爭策略跟現象:

    一個自然現象: 產品越老，開發時間越久。Version 4.0 的開發時間比 1.0長，因為你必須處理向下相容/處理現有客戶想要的功能/不要把之前的功能弄壞了… etc
    產品第一次就要成功比較困難，看到別人的經驗才做叫做 second-mover 優勢。例如 C# 之於 Java。(當然，若 first-mover就能成功，報酬更大)
    方法論不等於 talent 跟人才，不能用方法論打敗競爭對手。當然這兩種不是互斥，例如 agile 跟 XP 就是讓 smart 開發者更 smart。

21. 參加 Trade Show

作者這章分享參展經驗。參加展覽不只是為了銷售，而是最好的機會與顧客直接溝通，甚至可以把展覽日期當作你產品的milestones的deadline!

22. 雜誌廣告指南

作者分享在雜誌登廣告的經驗。登雜誌廣告既貴又難以估計效果，如果不確定要不要登，就是不要。另外無論如何請先用google做 online ad.

呼，脫稿好久，終於把最後的 Part 4 整理好了。雖說是 Sales，其實都是在強調行銷 Marketing 的重要性。其中 Closing the Gap 這兩章同時也收錄在 Joel 的 Best Software Writing 1一書當中，也可以說是這本書最總結的部分，非常值得一讀。

23 透明化信條 Tenets of Transparaency

不同的產品有不同要求的 trust 程度，例如買車會要求高度信心跟信任才會買，買小文具就不會。而買 software 則偏向 “high-trust” 的那端，客戶要相信你的軟體可以解決他們的問題，他們才會掏錢出來買。然而若沒有互信的條件，這樣的關係就無法建立，透明化政策是ISV信任客戶的方式，讓客戶看到更多內部的資訊。當然這會有風險沒錯，但沒有信任，這層關係就無法建立。

就像有餐廳會讓你可以看到廚師做菜，這樣你就可以知道是怎麼煮出來的。又如微軟等公司，產品weblog越來越多，時而堆出beta試用版，讓客戶在軟體開發階段就可以feedback意見……等等

參考的作法有哪些呢?作者提出以下

    產品(公司)部落格
    提供討論區 Web-Based Discussion Forums
    不要隱藏你的產品問題，一個會隱藏bug的公司，通常最後都不會修正那個bug。會fix bug的公司才是值得信任。已經在使用的客戶會希望產品成長跟成熟，希望功能越來越深(works better for the users it already has)，而不是越來越廣(appeal to new users)，一個常見的ISV錯誤就是產品只會變廣(例如模組越做越多)，而不是變深(例如加強現有模組的功能跟使用性，修正現有模組的bug等)。
    不要擾人，軟體的 license認證程序不要太複雜。一來沒有不能破解的軟體，二來會讓守法的使用者變難用。我們都很討厭 product activation 程序，雖然微軟是做的不錯(但他們是有本錢做啊)，但作者自己公司的經驗是非常費事，會增加很多技術支援負擔(例如客戶打電話來說有問題不能啟動云云)。
    提供無痛線上Demo下載版本，建議用時間限制(例如一個月試用版)，而不要用功能限制。要下載不需要先註冊。
    提供不滿意保證退費機制 (例如三十天保證退費)，因為只有極少數會退費，但大多數人會感受更好。
    公開一點點財務概況，尤其是你經營良好的話，讓客戶多了解可以增加信任感。
    談談未來計畫，客戶會想要知道下一版什麼時候推出?會有什麼功能等等，小心不要講大話即可。

當然，以上建議不是每個都適用，也不是事事都要透明，relationships不能沒有互信，也不能沒有適當的界線。

24 產品定價

Revenue = Quantity * Price，而 Quantity 跟 Price 成反比。

要思考定價，就必須跟產品定位一起思考，然後試著決定你產品價格的 range。

    誰是你的競爭者，如果你真的認為沒有，那麻你很大大成功要麻大大失敗。
    什麼是你的產品跟競爭者的差異? 你應該有很簡短的答案。這個差異不該是價格。
    你的產品定位是什麼?市場如何看待你。
    競爭者的產品售價是? 客戶一定會拿來比較。

一個重點是你的產品售價應該跟產品定位傳達一致的訊息，例如你要賣一套比 access 更棒的 desktop database application，那你的售價就不應該比 access 還便宜。

思考你的花費，雖然我們不應看成本來定價，但是也要知道成本才能了解價格下限。主要的成本有開發成本(人月)、技術支援成本、通路銷售成本(若有業務則有佣金、代理商、信用卡手續費、團購折價等)、管銷成本(網路費、電費等)。

思考你的產品可以帶給你的客戶多少價值(value)。試著估計產品替代方案的價格，例如你發明電波傳輸器可以把人傳到地球另一端，每次傳送只要100元成本。而替代方案是坐飛機跟住宿要3300元，那你的價格至少應收3300元以上(因為有同樣的價值)。

應該客戶多/價格低? 還是客戶少/價格高? 這要看你的產品定位。不過傳統上如果報酬相同，當然是客戶少點較好，因為成本會較低，事情較少。不過作者偏好客戶多點價格一點的方式，因為客戶多較有力量，規模經濟下也可能降低平均每位客戶的成本。反之高單價的產品常常比較需要業務員來推銷，產生業務成本。

你的產品價格太低了嗎? 價格不應該是產品的主要差異，如果便宜是唯一可以講的東西，就會淪落到 便宜 == 低品質 的刻板印象。

其它的因素還有如果你的產品是 add-on 類型，那應該不會比 base product 還貴。如果你的客戶是大企業環境，有固定的預算上限，那你就可以定出讓客戶不需再往上呈報的價格。(例如以台灣的環境來說，公家機關買東西如果超過10萬就會受到公開招標法限制，會比較麻煩，所以如果可以低於10萬元就會比較省事)

請思考差別訂價，不要死定一個價格而已。你可以有各種優惠價格(例如學術優惠)，找各種方法讓客戶願意付更多錢。最常見的方式有分版(標準版、專業版、企業版)，最常又分三種，最便宜的給那些買不起貴的客戶，最貴的給不想失去任何功能的客戶。但小心定價太複雜不好看懂就是了。

總是會有客戶會報怨嫌貴，別太在意。反而是若都沒有人抱怨貴，那就是你賣太便宜囉。

小心促銷價格的方案，短期可以刺激銷價，但長期來看一定不划算(人們會期待你下次的促銷而停止購買)。

25 Closing the Gap 1

你需要業務(sales guy)嗎? 其實你可以不必要有。

Product—————–Customer

這樣說好了，預期的客戶和你的產品中間有一道 gap，有著各種讓購買行為不會發生的理由，客戶可能沒聽過你的產品或不了解、覺得太貴、產品缺少某種功能或不夠成熟等等。因此ISV必須想辦法越過gap，方法有二，一是將你的產品往右移，告訴大家你的產品是什麼，讓你的產品更好。二是將客戶往左移，找到客戶並說服他購買。

讓我們來定義一下傳統 Proactive Sales 好了，sales 是一種找到目標客戶，然後個別說服他們購買的過程，而做這種事情的人，作者稱呼 sales guy。注意而 marketing 不是 sales，行銷包含更多層面，從策略到廣告。行銷是 1 to many，而業務總是1 to 1。另外在辦公室處理客戶訂單(不是來自sales的客戶)的人不是sales guy，他們是 customer service…

另一種定義業務的點是，他們收佣金，拿成交金額的%數。當然這個%數算法有很多因素，但是在很多組織，有最高所得的人常常是業務員!! 即使如此，每次 sales guy跟developer出去喝酒，常常還是developer買單(?)

作者提醒一個重點是，不要讓你的developer花太多時間在幫忙 sales guy，一個極端是業務員帶著developer去拜訪客戶(由developer回答技術問題??)。一種常見的解法是乾脆不同地點辦公室。

sales guy的一個特質就是一定要愛錢，由錢所驅動，只做有利益的事情。因此再發佣金錢，可以考慮先等在客戶滿意沒問題了才發佣金。sales guy也一定要厚臉皮。

為什麼我們得有 sales guy? 作者列了三個理由 :p

1.因為沒有人會買我們的產品

沒錯，有些產品不太有趣，例如沒有人會非常想去買保險，所以需要業務。重點是你的目標客戶對你的產品要解決問題沒感知。如果你的產品對客戶不是真的非常需要，那你可能需要業務來讓你的客戶了解他們其實有多麼需要，這叫做創造客戶的不滿足(dissatisfaction)，好來買我們的產品。

如果你才要開始新的 small ISV，作者建議你做一些客戶真的想要而且會感到興奮的東西吧。

2.你的產品非常貴

越貴的東西，越需要業務來幫助客戶下決定，例如車子跟房子。錢越多的產品需要下越大的決心，因此大多數的組織都會用手控(hand-holding)的方式跟客戶完成交易。

3.你的產品不會再有任何改進

隨著產品週期末期，會傾向越來越多業務，然後更少developers，因為你的產品已經不打算進步了，不會再往右跨過gap。所以需要更多的業務來拉攏客戶。

總之，作者根本是建議，大部分的small ISVs最好是不需要任何sales guys… 當然也許有例外，但很多公司往往在需要有業務前，就已經找了業務 ，預設了要有業務的立場。

要移動客戶往左跨過gap是費力的，特別是 small ISVs。較好的方式其實是將心力放在gay的左邊，也就是你的產品上。改善你的產品，將你的產品往右移跨過gap，聆聽你的客戶，給他們想要的，讓你的客戶Happy (他們會告訴他們的朋友你有多棒)

專注在你的產品上也會建立出你的核心競爭力，你知道如何將你的產品變得更好。如果你不知道，那你就算有 sales guy，最後也會輸。另一個好處是槓桿作用，當你努力針對某一位客戶改善產品，其實也是對所有的客戶都有幫助。

26 Closing the Gap 2

相對於上一章的 Proactive Sales，這一章作者大力提倡不需業務的 Responsive Sales方式。前者需要業務主動接觸客戶，說服客戶購買。後者由客戶在需要的時候，透過可能是從朋友那邊或從blog看到，查了所有可以查到的資料，然後來跟公司詢問，最後購買。

這章也可以算是這本書的總整理精華。

聽起來 Responsive Sales有點天真，如何相信客戶會自己上門? 是的，我們可以辦到。而且好處多多，實情是客戶喜歡被信任，喜歡自己下決定而不是被業務說服。Responsive Sales不表示我們沒事做，為了達到成功的 Responsive Sales，作者建議以下動作:

1.確定你的客戶知道你的產品

如果客戶連你的產品都沒聽過，當然也就不會發生交易。這部分的工作屬於 Marketing行銷(不是 sales)，更精確的說是指 marketing communications，作者有以下建議:

    要小心花錢打廣告，尤其是錢多又難以衡量效益的。
    試著參加展覽。
    開發過程開放(Develop “in the Open”)，建立產品blog,公開討論區，preview 下載，讓你的客戶們討論。既然開發產品需要時間，何不在開發的時候就吸引注意。

2.確定你的產品有東西是客戶要的

一個好的 proactive sales 可以克服這個問題。但你沒有業務，所以你得更專心在產品吸引力上，你得說服自己你所做的東西是客戶渴望的。這個議題也是行銷的範疇:

    選擇產品定位，你希望你的產品如何被認識?
    選擇競爭對手，你需要競爭對手。沒有競爭對手的市場，要嘛你大賺只有你看到商機，要嘛其實根本沒有客戶需求。
    Develop “in the Open”，承第一點不只有廣告的效果，你還可以觀察到哪些東西是客戶真正關心的，可以早點知道市場反應，趁機調整你的產品功能。

3.確定客戶可以承受你的產品價格

流行的說法是你應該主張(claim)價格高點，當你把價格設高一點，也表示你告訴大家你認為你的產品比較有價值。但低價格也有好處，小心客戶預算。

4.提供完整功能的產品 Demo Download

記得下載要非常容易，功能是完整版本，要容易安裝，不需要註冊就能使用。

5.回答客戶問題

作者認為能夠回答深入的技術問題非常重要，在作者的公司，developer也必須幫助客戶。當然作者有建立第一層的客戶支援人員，full-time幫助客戶，但是如果有不能解決的問題，每個 developer 都有責任去做第二層支援。客戶會喜歡可以直接真正寫程式的人聯繫。

6.提供討論社群

潛在的預期客戶會希望可以跟已經購買的客戶做討論 (例如詢問這個產品好不好啊?)，在 Responsive sales 中你應該提供這種機會，你應該對自己的產品有信心，沒有什麼好隱藏的。

當然也許可能會有不好玩的地方(例如現有客戶跟預期客戶抱怨?)，但是這是一個很棒的feedback機制，將迫使你不斷改進產品，讓你的客戶滿意。你的客戶會看到你的努力的。

7.讓產品在Web上就可以容易購買

    別讓你的客戶一定要註冊才可以購買
    你不需要購物車，你才幾樣產品啊(perhaps only one)，東西少不需要購物車。
    實體的東西要寄送就算了，不然最好是下單後，馬上就可以使用!!

最後，你還是覺得 Responsive Sales 行不通嗎?請自身處地想想，以上這些建議，不就是你自己當客戶的時候，所希望的對待嗎?

書末，作者再次提醒真正執行的重要(Just do it)。

这么多 我只看重了这句话
“C = G + LT ，持續學習才是重點”

书名是什么？？

广告贴吧？

不管是不是广告贴,繁体字都没有耐心看下去.

对呀 怎么不是简体字，看着老费劲儿啦 。。。

+1