Skip to main content

Beyond the Code: 軟體工程師的 3 個產品思維

· 14 min read
Darren Lin
Blogger

產品思維的培養不只是產品經理的任務,而是每個軟體工程師都可以嘗試從工作中培養的技能,這會幫助你不再扮演被動執行者的角色,而是能主動從使用者為中心思考問題,為企業和使用者創造真正有價值的產品和解決方案。

技術快速演進和人工智慧廣泛應用的今日,軟體工程師的角色不能僅限於開發可以運作的 code 而已。因為「功能(Feature)」是技術的展現,而「產品(Product)」才是能向用戶提供價值的解決方案,對許多軟體工程師來說,如果你希望在未來的職涯、接案或打造個人產品中產生更大的影響力,以下將分享從產品經理學習營中學到的三大思維是如何改變我的工作方式和思考模式。

發揮好奇心,從使用者的角度思考

在產品營的開始指定的任務是進行用戶訪談,並且將用戶訪談的紀錄撰寫為故事文本,這次我選擇的題目是如何提升使用者在 CakeResume 個人檔案的更新率,訪談前的工作坊 Stanley 老師不斷提醒我們「不要急著想產品功能,而是先把自己調整成「對人有興趣」模式。」

產品專案管理大師 Marty Cagan:"It doesn't matter how good your engineering team is if they are not given something worthwhile to build."

訪談過程中,我不斷提醒自己不要只關注使用者表面的意見,而要去挖掘他們分享背後的每一個為什麼,因為每個人在使用產品都會有主要的目的想達成的任務,不只是功能層面,也可能具有社交或情緒層面的期待,例如以求職平台為例,在平台新增個人履歷或檔案,不一定是為了立即求職的需要,可能是希望增加自己履歷的曝光率,能跟更多潛在獵頭保持連結,以了解自己的市場價值,進而知道自己是不是應該要跟老闆提加薪或爭取更重要的任務來累積經驗等。每一個任務可能都隱藏著更深層的需求,透過好奇與持續提問「為什麼?」,能夠更深入且全面的了解使用者的核心需求與痛點,這也是為後續解決規劃奠定重要基礎。

而當你不知道怎麼深挖使用者背後的需求時,我歸納出4的關鍵提問可以幫助你一步步去探索:

  1. 他做了什麼?(What)
  2. 他怎麼做?(How)
  3. 他做這件事跟誰相關?(Who)
  4. 為什麼他要這樣做?(Why)

從表層的行為開始,一路追問下去,你會發現有時候使用者根本的痛點並不在你原本預期的地方,例如我訪談的一位使用者說他很少主動更新履歷檔案,並不是因為編輯工具很不好用,而是他不清楚自己的經歷有沒有辦法符合理想的職缺,這背後也反映出使用者其實是希望能夠探索自我、發現潛能,對未來職涯有更多明確的指引與規劃。

Why it matters

作為軟體工程師,只關注於技術層面的實作細節其實是不夠的,若能在接到開發需求時,先保持對使用者的好奇,並且使用關鍵提問去了解使用者的出發點,不僅能讓後續開發的功能更貼近實際需求,也會對手上的任務賦予意義感。

雖然訪談使用者不是工程師職責內重要項目,但透過這次的經驗,也讓我思考以用戶為中心的思維模式,其實也是幫助產品成功的重要元素,因為一個程式碼寫得再好、功能多元的產品,若是無法符合使用者的需要,其實並無法真正賦予商業的價值,只能是一個做得好的作品,而非好產品。

用輸出來驅動成長

好的產品就是不斷迭代優化的過程,在產品營中最有收穫的就是每週能與來自不同領域的同學相互分享與提問。帶領的助教與老師都會強調「做產品沒有標準答案」。每個人都會有自己的假設與理解,在分享自己的思考脈絡與解法過程中,這些回饋反而能幫助自己用多元視角去看待問題,不僅能激盪出更創新的想法,也有助於檢視之前可能忽視的盲點。

讓我想到《精準思考》中提到:「思考答案的過程比答案本身更重要」。 追問為何對方可以想到這種方式,他可能使用了哪些思維方法,這其實非常適合應用在工作場域中,許多卓越的「資深」工作者並不是因為工作多長的年資,而是他能夠將過去個人有限的經驗提煉出解決問題的方法與流程,將原先隱性的知識顯性化,所以才能在面對問題時,能比其他人更快找到有效解決的策略。

有哪些分享與輸出的方式能夠驅動你的成長?除了與人討論分享外,我想從工程師的角度分享 3 種方式:

1. 帶著問題去閱讀

當你在工作或生活中遇到難解的問題時,除了詢問同事、主管或 Mentor 外,其實最好的學習夥伴就是閱讀,但不同於一般的閱讀,我建議可以將所遇到的問題帶進閱讀中,因為作者已經將他們過去的經驗都彙整在書裡,你可以從他們踩過的地雷去借鑒經驗。前陣子正在讀 Robert Martin 的 Clean Architecture 時,我其實在工作上遇到主管要求將同一個 code base 能夠延展到更多家系統使用的問題,在閱讀的過程我才發現原來有許多在最初設計架構上,有哪些方法可以使用,又該怎麼去思考效益。

2. 寫作

寫作的是練習思考最好的方式,透過有系統、結構整理的過程,能夠將你所會的知識由點、線、面串連起來,除了能夠檢視自己既有的知識外,也能發現自己不足的地方進行改善,開始建構屬於自己的知識庫,至於寫作的方法網路上有相當多推薦的資源及分享,有興趣的人可以自行搜尋。

3. 撰寫問題解決文件

工作中可能會在不同專案中遇到類似的問題,還記得之前被分配一個專案開發的任務時,由於沒有留下技術文件,加上相關人員都接連離職,與其抱怨所處的團隊或公司沒有給予完整的文件,我當時做的選擇就是使用 Notion 將負責每一套系統的 API 整理出來,方便前後端工程師能方便協作,後續大家依循著文件就能更快同步資訊,也減少自己要去反覆溝通的成本。

Why it matters

作為工程師,我們都清楚主動學習和發問的習慣非常重要,透過與不同背景的人交流想法和提出疑問,不僅能讓我們打破常規思維,更能促進團隊內部有效的協作。過程中將解決問題歷程內化為明確的思維模式,這也是我現階段需要想努力的部分,透過輸出來打磨解決問題的能力。

有效的提案表達力

產品規劃提案關係公司未來的產品規劃方向以及資源配置,也是產品經理展現能力與爭取資源的關鍵,在產品學習營的最後一週,每個人都要負責將自己過去從用戶訪談、User Journey Map、產品功能規劃提出一份讓老闆願意買單的提案,從這次的提案預備到分享的過程,我學習到一份好提案需要具備的 2 個關鍵:

1. 用決策者的角度來思考

除了呈現問題本身,更重要的是設身處地思考決策者最關心的議題為何?他們做決策時會考量的風險和機會在哪裡?

2. 幫決策者找到行動的理由與動機

有時候不是你的規劃解法不好,而是每件事都是機會成本,想要讓決策者支持你的提案,還需要幫公司找到為什麼需要做的理由和不做的影響。

Why it matters

提案表達能力是優秀工程師非常重要的特質,因為任何合作都有溝通成本,降低溝通成本,就能提高團隊工作效率、團隊協作、降低錯誤和達到更好的品質,同時工程師有相當多機會要去支援或負責新的專案,如果無法清楚團隊最主要的目標是什麼,或透過會議有效說明解決方案,就可能因訊息不明確、誤解,甚至最後延誤產品交付。最後如果你是想要升遷,能夠在評估工作表現與爭取加薪機會上,除了基本技術能力要達標外,提案表達能力將會是勝出的關鍵。

總結

感謝這一個月一起學習跟討論的助教與夥伴,以及商業思維學院的老師及營運團隊。透過這次產品學習營的經驗,獲得許多工作以外的啟發,從一次次輸入與輸出的過程,在忙碌加班回到家還在燒腦想產品解法與整理使用者洞察的經驗,由衷佩服產品經理的專業,期待未來跟更多優秀的產品經理合作時,也能夠扮演好自己的角色,成為產品開發團隊的幫助。