編輯導讀：很多企業在選擇SaaS產品的時候，都會從自身需求出發，要求進行定製開發。要不要做呢？這是大部分SaaS產品都會遇到的一個問題。本文作者依據自身工作實踐，從業務、需求和設計三個方面，對這個問題進行了分析討論，與大家分享。
一方面迫於營收的壓力，接受定製就會有收入；但另一方面，普適性差的功能一旦多了，後續維護成本就高。
首先，從整個業務角度考慮明確自己是做產品還是項目：
- 【項目】是客户的；
- 【產品】是公司自己的。
- 【項目】滿足特定人羣或者使用者需求，更偏向於個性化；
- 【產品】滿足特定應用場景或者特定行業領域的需求，更加具有兼容性。
- 【項目】側重於時間驅動，因為時間就是成本，滿足交付任務即可；
- 【產品】側重於功能驅動，更注重體驗。
- 【項目】是以客户的需求為驅動，按照客户的需求進行定製開發；
- 【產品】是為了滿足市場某一痛點可產生的，對於產品的性能以及快速迭代擴展的要求更高。
- 【項目】型公司可以賺到錢，但賺的是“人頭錢”。一般項目公司都是按照工時收費，比如X元/人/天，人/天越多，項目總收入越多。項目越多，需要人越多，人數不夠往往需要進行項目排期，公司的總收入也是和人頭息息相關。一旦項目太多，人數不夠，營收就陷入瓶頸，項目就處於停滯延期狀態。
- 【產品】型公司賺的是產品的使用費或其他增值費，一個很小的團隊，只要產品足夠好，客户足夠多，營收往往不可估量，人均創造價值遠大於項目型公司。
SAAS產品客户越多，收到的需求越多，個性化需求也就越多，那麼到底要不要接受客户的需求？
首先理解客户提的到底是需求還是方案當客户説的是“我想吃饅頭了”一定要繼續追問到具體原因，只有知道需求了，才能判斷到底要不要實現；
然後判斷需求的適用度- 通用需求：適用於大部分客户，可以做到產品裏；
- 假需求：要説服客户放棄；
- 真需求，但通用性很差：個性化需求，其他客户不存在此類需求，要和客户商討有沒有更好的處理方法。
同樣通用型需求，實現方案可以是針對單個客户定製，也可以做成通用型功能。
在考慮的時候，一定儘量往通用型設計方向考慮，我們接定製開發的目的
是為了積累對行業的經驗，完善我們的產品適用度。
假如碰到不知道怎麼做成通用型產品的時候：
- 不妨想想把我們的SaaS產品轉化為平台PasS產品，或加強API能力，避免未來產品升級對定製開發部分的影響。
- 是否可以做出可配置的方案來儘量滿足所有人的個性化需求
舉個簡單的例子，我做思拓雲投票的時候，這個一個很簡單的在線投票選舉SaaS軟件，遇到客户提了一個需求：希望用户投票前必須關注他們的公眾號，以此來增加公眾號的粉絲量。
同時，也提出瞭解決方案：客户投票賬户的ID和他們提供的公眾號賬號相互綁定，每次用户投票前調用接口去判斷用户是否關注他們的公眾號。
拿到這個需求，假如説按項目來做，客户提的方案是可行的，將對應賬户ID和公眾號賬號寫死在系統裏即可。
如果按照產品來看，這種實現方式只適合一個客户，不滿足SAAS產品設計的初衷。
那到底要不要做？
做，很明顯這是一個通用型需求，加強我們API能力，如果將投票賬户ID和公眾號綁定功能做成可授權的。每個賬號可自己去授權綁定不同的微信公眾號，這樣即可滿足所有客户。
那麼從項目轉型到產品需要注意什麼？
- 加強API能力，即便定製，也要只做邊界內的定製，邊界外找成熟產品，沒有就找第三方系統集成商做（某大佬建議）。
- 合適的時機，定製開發的比例越高，越要儘早轉型做產品開發，很多項目性公司都是產品開發出來後，幾年不更新產品，一直在項目中根據客户提的需求改產品功能，複用性極差。到後期就是堆人頭，邊際效應遞減，人均產值下降，而且項目開發組與銷售部門摩擦越來越大，幾千萬營收就出現瓶頸。
- 產品和項目不是相互獨立的，是相輔相成的關係，產品的開發是可以通過一個個項目去完成。通過項目不斷迭代開發，推進產品版本的更新。要注意的是儘量做通用型需求，產品設計也要考慮普適性。
張論，微信公眾號：張論（ID：woshipm123），人人都是產品經理專欄作家。關注新零售電商、供應鏈金融的產品經理，擅長產品設計與需求分析。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash ，基於 CC0 協議。