以產品為導向的軟體工程師
深耕技術，精通產品，為團隊帶來獨特價值的創新者。
作者: Gergely Orosz
以產品為導向的軟體工程師，是指對產品本身懷抱高度興趣的開發者。他們渴望了解決策背後的緣由、使用者如何使用產品，並熱衷參與產品決策。如果他們決定放棄工程師的 coding 樂趣，很可能成為優秀的產品經理。
我與許多優秀的以產品為導向的軟體工程師共事過，也認為自己屬於這類開發者。在打造世界級產品的公司裡，這類工程師能將團隊的影響力提升到新的層次。
Atlassian 的產品經理 Sherif Mansour 曾寫過一篇關於產品工程師的精采文章，他的結論與我類似：
過去十年的產品管理經驗讓我得出一個結論：產品工程師是打造成功產品、提升自我並成為更優秀產品經理的關鍵要素。
他也引用了 Shopify 工程主管 Jean-Michel Lemieux 對產品工程師的定義：
在奠定產品基礎後，你需要的是能主動思考「為什麼」的開發者。他們渴望運用科技解決使用者痛點，並富有同理心，致力於創造絕佳的使用者體驗。這才是我心目中的產品工程師。差的產品工程師會過度妥協，而優秀的產品工程師知道，即使是 MVP (最小可行產品) 也需要在建構階段就考慮到一定的深度。
在負責開發使用者介面功能，並與產品經理密切合作的團隊中，以產品為導向的軟體工程師能發揮巨大的影響力。他們通常會成為重要的貢獻者、產品經理的得力助手，並經常晉升為團隊主管。
那麼，以產品為導向的軟體工程師有哪些主要特質？又該如何培養產品思維？本文將總結我觀察到的這類工程師的 9 個共同特質，以及我對所有工程師如何培養產品思維的建議。
1. 主動提出產品想法和意見
以產品為導向的軟體工程師不會滿足於拿到規格就埋頭苦幹。他們會思考其他的可能性，並向產品經理提出。他們也經常挑戰現有的規格，提出可能更有效的替代方案。
2. 對業務、使用者行為及相關數據感興趣
以產品為導向的軟體工程師提出的想法並非天馬行空。他們會花時間了解業務如何運作、產品的定位和目標。他們也會設身處地為使用者著想，思考使用者使用產品的感受和獲得的益處。
他們經常鑽研業務和使用者指標數據，想方設法取得這些數據。如果可以直接取得數據，他們就會直接取得；如果不行，他們會向產品經理或數據科學家尋求協助。他們這麼做是出於好奇心，而這正是我觀察到的下一個特質。
3. 充滿好奇心，並熱衷於探究「為什麼」
以產品為導向的軟體工程師喜歡了解所有事情背後的「為什麼」。為什麼要開發這個功能，而不是另一個？為什麼要先推出這個里程碑，而不是選擇另一個更容易開發的？如何衡量成效——為什麼不採用更完善的衡量方式？
他們會自主尋找答案。至於其他與產品相關的問題，他們會向產品經理和其他業務相關人員請教。雖然他們經常提問，但由於與團隊成員建立了良好的關係，所以不會造成別人的困擾。
4. 優秀的溝通能力，並與非工程師團隊成員保持良好關係
以產品為導向的軟體工程師喜歡與工程部門以外的同事交流，了解他們的工作內容和原因。他們善於溝通，並展現出對其他領域的濃厚興趣。我經常看到他們與非工程師團隊成員一起喝咖啡、吃午餐，或在走廊上閒聊。
5. 預先提出產品/工程的取捨建議
由於他們對產品的「為什麼」和工程方面都有深入的了解，因此他們能夠提出其他人難以想到的建議。舉例來說，在評估產品開發工作量時，某些關鍵功能的工程工作量可能相當龐大。
許多工程師會開始想辦法減少工作量，並試圖了解減少工作量對功能本身的影響。而以產品為導向的軟體工程師則會從兩個角度來思考這個問題：設法在工程上找到取捨的空間，同時評估對產品的影響。
他們也會在產品面上思考取捨，評估對工程的影響。他們經常會向產品經理提出開發完全不同功能的建議，理由是：產品效益類似，但工程工作量卻可以大幅減少。
同時考量產品和工程的取捨，以及各自的影響，是以產品為導向的軟體工程師的獨特優勢。他們能夠快速地在產品功能和工程工作量及取捨之間來回切換。由於他們在腦海中運用工程和產品的洞察力進行思考，因此能迅速得出有價值的結論。
6. 務實地處理邊緣案例 (Edge Cases)
邊緣案例是一個有趣的主題。有些工程師經常忽略許多邊緣案例，必須等到收到測試人員或終端使用者的回饋後才回頭處理。另一方面，在新產品或功能中處理所有可能的邊緣案例又可能曠日廢時。
以產品為導向的軟體工程師能快速找出邊緣案例，並思考如何減少處理這些案例的工作量，通常會提出不需要工程作業的解決方案。他們專注於「最小可愛產品 (MLP)」的概念，並評估邊緣案例的影響和處理的難易度。他們會提出兼顧兩者的建議：列出所有可能出錯的情況，並針對在推出早期版本前需要處理的邊緣案例提出建議。
例如，如果千分之一的使用者可能會遇到錯誤，他們會考量修復這個錯誤所需的工作量，以及不處理會發生什麼事。在驗證階段，客服人員能否協助使用者解決問題？使用者能否重試，並在下一次成功？能否稍微修改產品，避免這個邊緣案例發生？
7. 快速驗證產品
即使正在開發的功能還沒準備好上線，以產品為導向的軟體工程師也會想辦法提早取得使用者回饋。這可以透過在公司內部進行測試、向產品經理展示開發中的功能、針對 Beta 版本進行團隊除錯活動，以及其他各種方式來達成。他們不斷思考：「我們如何驗證使用者會照我們預想的方式使用這個功能？」
8. 端到端負責產品功能
大多數經驗豐富的工程師會端到端地負責自己的工作：從取得規格、實作，到上線並驗證功能是否正常運作。以產品為導向的軟體工程師通常會更進一步。
只有在取得使用者行為和業務指標數據後，他們才會認為工作完成。產品上線後，他們仍然會積極與產品經理、數據科學家和客服團隊互動，了解功能在實際使用中的狀況。要取得足夠的可靠數據才能得出結論，可能需要數週的時間。即使他們可能正在進行新的專案，他們仍然會將追蹤結果列為優先事項。這並不會花太多時間，但需要額外的堅持，才能了解：「我的作品 實際上 表現如何？」
當功能的成效不如預期時，他們會積極探究原因。他們就像除錯程式碼一樣，努力找出產品規劃與實際結果之間的落差。他們經常花很多時間與產品經理和數據科學家討論各種假設和學習心得。
9. 透過不斷學習，培養對產品的敏銳直覺
以產品為導向的軟體工程師的典型專案流程通常如下：
- 他們會提出許多問題，以充分了解為什麼要開發這個產品功能。
- 他們會提出建議和取捨方案，其中一些會被納入修改後的規格中。
- 他們會快速開發功能，並在過程中取得早期回饋。
- 功能上線後，他們會積極追蹤，了解功能是否符合預期。
- 如果不如預期，他們會深入探究原因，並從中學習關於產品在實際使用中的新知識。
每個專案結束後，他們對產品的理解都會加深，並開始培養更敏銳的產品直覺。下次他們就能提出更適切的建議。久而久之，他們會成為產品經理倚重的對象，在專案開始前就會徵詢他們的意見。他們在團隊外建立了良好的聲譽，為未來的職涯發展開啟更多機會。
如何培養產品思維
如果你正在開發使用者介面產品，以下提供一些我認為有效的培養產品思維的建議：
- 了解你的公司如何以及為什麼會成功。 商業模式是什麼？如何獲利？哪些部門最賺錢？哪些部門成長最快？為什麼？你的團隊如何融入其中？
- 與你的產品經理建立良好關係。 大多數產品經理都樂於指導工程師。工程師對產品感興趣，代表產品經理可以更有效率地運用自己的時間。在提出大量的產品問題之前，先花時間建立關係，並讓產品經理知道，你希望更多地參與產品相關的討論。
- 參與使用者研究、客服支援 以及其他能讓你更了解產品運作方式的活動。與設計師、使用者體驗研究員、數據科學家、營運人員和其他經常與使用者互動的同事合作。
- 提出有根據的產品建議。 在充分了解業務、產品和利害關係人之後，請主動發言。你可以針對正在進行的專案提出一些小建議，或者提出更大的計畫，概述工程和產品的工作量，以便在待辦事項中排定優先順序。
- 針對你參與的專案，提出產品/工程的取捨建議。 不要只考慮團隊正在開發的產品功能在工程上的取捨，也要提出能減少工程工作量的產品取捨建議。並樂於接受其他人的回饋。
- 經常向你的產品經理尋求回饋。 成為一位優秀的以產品為導向的軟體工程師，代表你在既有的工程技能之外，也培養了良好的產品技能。產品經理是最適合針對你的產品技能提供回饋的人。請他們針對你的產品建議的價值提供回饋，並詢問你在哪些方面可以更上一層樓。
