雖然說作為工程師，我的經驗還算豐富，可以解決大部分的開發需求與問題，姑且可以自稱資深工程師吧。
但是做為產品經理(PM)，我就是全然的 Junior 了。
明明是工程師，為什麼要做 PM 的工作？
也沒辦法，畢竟公司目前只有我跟一位業務合夥人，很自然的，PM 的工作就落到我身上了。
風水輪流轉
以前還在當工程師的時候，常常會吐槽說，公司高層或是 PM 到底在規畫什麼爛東西？
看到需求後，工程師們最喜歡在會議室裡面噴一輪：
「這樣的系統真的有人要用嗎？這樣的流程也太違反人性了吧？」
「為什麼這些高層的決策總是出爾反爾？為什麼規格書總是亂七八糟？不好好寫清楚？」
「為什麼需求邏輯總是不流暢，甚至自打臉？」
族繁不及備載。
然而自己幹了PM一陣子後，才發現，PM 要釐清一大堆需求，並且要同時滿足各種狀況，真的是不容易啊。
工程師可以理所當然、不痛不癢的的抱怨 PM 的規劃，但是，當自己同時是 PM 又是工程師的話，難道要抱怨自己嗎？
只能自己不斷地掙扎了。
想成為好的 PM
作為一個產品經理，要決定產品的樣貌，決定產品的走向。
但是現實世界有太多雜訊，客戶的需求，公司的需求，股東的需求，自己的需求，要如何整理這些資訊，最終達到一個平衡？
這段時間，我不斷的思考的問題是，我們的平台要包含哪一些功能，做了這些功能可以達到怎麼樣的商業目的，要怎麼設計流程解決客戶的實際問題。
對我來說，不負責任的 PM 就是聽到需求，就找個地方把功能塞上去。
但我認為，好的 PM 應該要具備可以將新功能，跟既有系統良好的整合，提供流暢的體驗，並成功解決實際的問題。
爛需求的樣貌
如果一個功能上去是很突兀的，跟其他功能沒有什麼關聯性，那這個功能就沒有什麼價值。
例如，就只是其中一個客戶的小抱怨或操作習慣跟系統不合，但其實其他客戶並沒有這樣的需求，或是需求其實不符合公司的整體走向，這樣的需求也不需要被處理。
或者是明明是一個專注在處理交易的系統，卻被要求加上天氣預報的功能，就有點差太遠了，也不是一個需要被處理的需求。
客製化的處理方法
作為一個SaaS產品，最害怕的遇到的就是客製化需求，我們當然希望可以滿足最大程度的客戶的需求。
但如果幫每個客戶都客製化功能，那整個系統的 scope 就會炸開，不論是開發成本和管理成本，都會大幅提升，不符合公司成本效益。
（當然，如果有大客戶拿著超大把的銀子來，那就另當別論）
難免還是會遇到不同客戶對於同一個功能，會有不同的考量。那對於一個 SaaS 來說，我認為最好的方法是，把客製化的需求，設計成各種參數或選項。
讓使用者可以透過調整參數的方式，來滿足客製化的需求。
當然，怎樣的東西可以被抽成參數，是很考驗產品設計能力的，而且也不是所有的流程需求都可以接受調整的。
例如有些核心的商業邏輯，還是要堅守產品的底線，不能讓這些雜亂的需求，反客為主，影響了產品的本體，這樣就不對了。
資深工程師的修練
我認為，好用的 SaaS 產品應該操作容易、介面簡潔、學習成本低，整體使用的邏輯是清晰、流暢的。
但是要能達到這些目的，有太多眉角要做判斷，需要很多經驗跟知識才知道怎麼設計會比較好。
以前，作為工程師，習慣的是標準的規格，我們根據已經被消化整理完的規格來做開發。
但現在我同時也是 PM，做為 PM 要負責蒐集商業世界各種雜亂的資訊，把這些資訊梳理成流程、邏輯，然後做成好用的產品。
如果沒有認真去做思考、取捨、限制，規劃出來的東西，直白的講，就是坨屎。
只能說，以前當工程師的時候，嘴 PM 很輕鬆。實際自己做 PM，才了解確實有其難處，就當作是修練囉，希望趕快有能力可以找一個 PM 來陪我一起痛苦。