我們為何而戰:產品領導者的核心價值觀與行動指南

我們為何而戰:產品領導者的核心價值觀與行動指南
Photo by Hack Capital / Unsplash

在最近一次由產品長們(CPOs)參加的產品週末聚會上,我們探討了產品領導力的價值觀以及什麼能夠振奮我們的心。這轉變成一場關於「我們為何而戰」的對話:那些作為產品領導者,我們堅守的廣泛原則和具體行動。以下是我的看法:

  • 我們為用戶而戰
  • 我們為我們的(擴展)團隊而戰
  • 我們為企業的整體健康而戰

我曾從愛與情感能量的角度寫過/談過這個話題:我們如何將心投入到這個無邊界、不受重視且複雜的工作中。在這裡,我從更多組織角度來重新架構這個話題。

1. 我們為用戶而戰

在我看來,優秀的產品經理每天都會為我們的終端用戶站出來—那些在電話、鍵盤、麥克風、代理商或自助服務亭另一端使用我們產品的人。我們應該有義務提供對他們真正有價值的產品。順便一提,這與B2B世界中的購買者不同。我們當然必須回應購買者,為採購組織提供經濟效益,並幫助銷售團隊成交。但購買者常常投資於從不使用的軟體,可能與實際用戶相距太遠而無法優先考慮需求,並且可能有與終端用戶相衝突的目標。

當我們(作為產品經理)為用戶而戰時,我們:

  • 持續深入挖掘,理解實際情況以及我們的終端用戶是否/如何取得成功。通過重要人物進行訪談、展現同理心、進行直覺判斷、測試我們的假設。我們應該比公司中的任何人(除了一線支援外)更了解我們的用戶。
  • 不僅用我們公司的獲利能力來衡量成功,也使用終端用戶指標。客戶購買(以及用戶使用我們的產品)並不是為了提高我們的銷售收入。他們可能用一生一次的旅行(旅行軟體)、節省雜貨費用(價格比較軟體)或更可靠的汽車(汽車維修軟體)來衡量成功。我們的用戶如何衡量成功和價值?我們是否提供了這些?
  • 從外向內思考產品變更和升級。是否有後備方案或測試組?安裝基礎能多快吸收新功能?我們是否以終端用戶的語言解釋?

作為產品領導者,我們應該爭取給予我們的產品經理(以及設計師、工程師、研究人員、客戶支援團隊、銷售工程師...)組織支持和目標明確性,讓他們能夠為終端用戶而戰:

  • 創建獎勵系統(OKR、指標等),始終將用戶放在中心位置,與收入和交付並列。
  • 推動(一再推動)使團隊能夠進行真實、頻繁、直接、個人化的發現,以及製造方與活躍用戶之間的互動。我們拒絕將深度解釋性學習外包給演算法。
  • 穿上我們的特氟龍外套,成為產品團隊構思的良好用戶解決方案的高管擁護者。承受壓力。貫徹言行。成為保護傘而非漏斗
  • 避免明知故犯地對用戶造成傷害,否決暗黑模式,只收集我們需要的資料。多年來,我見過數百種欺騙性、有害或無用的產品。我現在將這些產品和公司稱為道德分歧的。(我們的保險理賠系統是否被設計為拒絕合法的報銷請求?我們是否以我們知道對兒童不利或破壞民主的方式調整社交媒體演算法?我們的「提高信用評分」應用程式是否不可避免地推薦來自資助我們的銀行的額外信用卡?首要原則是不造成傷害...

2. 我們為我們的(擴展)團隊而戰

在軟體遊戲中,我們在製造團隊(開發、設計、品質、架構、可支援性、安全性等)中所做的大部分工作對公司的面向市場組織而言大多是不可見的,且興趣有限。因此,很容易根據交付日期、代碼行數和NPS來評分。僅關注可計量的美元、訂閱者和交易(這些確實很重要,見下文)。而忽略什麼能最好地服務終端用戶。但擁有出色人才、熱情、奉獻精神和同志情誼的團隊對於構建重要產品至關重要。而產品經理往往最接近前線—能夠看到什麼有效並推動進步。

當我們(作為產品經理)為我們的擴展團隊而戰時,我們:

  • 與我們的工程和設計對應方肩並肩工作
  • 識別並明顯欣賞良好工作。宣傳勝利。在站立會議開始時鼓掌,為重要里程碑準備T恤,偶爾請全隊吃午飯,代表我們的內向者發聲(經許可)。
  • 與團隊分享業務結果,使他們能夠理解更大的市場/收入背景並慶祝我們的貢獻。示範金錢語言。向他們展示他們很重要。將「我們做什麼」與「公司為何關心」聯繫起來。
  • 當其他成員可能缺乏組織准入、業務術語、外向聲音或預算來獲取所需時,升級團隊需求。幫助描繪投資不足於安全性、穩定性、可擴展性和可擴充性的災難性下行風險。將業務案例強行應用於改善工作流程。為團隊完成工作
  • 記住,我們的GTM(Go-To-Market,上市策略)同事不是客戶(除非我們正在構建僅供內部使用的系統)。他們是合作夥伴、利益相關者、盟友、阻礙者、決策者...但我們將「用戶」和「客戶」保留給那些付錢給我們並使用我們產品的外部人員。

作為產品領導者,我們爭取支持和獎勵我們的產品經理以及他們強大、富有創意、鼓舞人心的團隊,當我們:

  • 真正關心我們組織中的人員。提供政治保護。指導、獎勵和晉升良好工作。將下一代拉上梯子跟隨我們。
  • 向公司其他部門強調研發的價值和貢獻。推廣產品驅動的收入和帳戶勝利;宣傳支持更多用戶且成本更低的架構;講述升級的UX如何減少我們的支援負擔;指出當我們出色的工程師找到比客戶規格好3倍且便宜30倍的解決方案時。識別跨職能貢獻者並感謝他們的經理。在內部銷售良好的產品工作。
  • 倡導支持性、人道的辦公行為。抵制強制排名的裁員、過於簡單化的生產力指標和「開發人員是可外包的零件」思維。做正直的人。建立我們想要工作的部門。
  • 記住產品管理是一個狹窄、模糊、挑剔、專業的角色,不適合大多數人。我們對向我們報告的每個人都有義務...幫助他們找到在更大的組織中(如果可能)或在世界上取得成功和貢獻的方式。
    在我擔任臨時CPO的15份工作中,我通常發現我剛繼承的30%以上的產品經理/產品負責人不太適合產品工作。但他們擁有廣泛的才能、經驗、抱負和潛在價值。因此,我採取內部招聘人員/導師的方法:「我的第一印象是,產品可能不是您的最佳選擇。您有何想法?公司內是否有您認為更適合的角色或職能?您接下來想成為什麼?我如何幫助實現這一目標?」

3. 我們為企業的整體健康而戰

我看到許多職能部門主要基於其部門需求和短期獎勵系統行事。(你的立場取決於你的位置。)但產品(應該)為C級決策帶來更長期、謙虛現實的視角。更少的魔幻思維,更多硬核分析,更少害怕錯誤。我們(應該)像投資者一樣思考,同時也是產品人。畢竟,如果買家和用戶成群結隊地逃跑,我們都會失業。(我們要麼團結一致,要麼分別被絞死

當我們(作為產品經理)為整體業務而戰時,我們:

  • 了解我們公司賺錢的基本方式。我們是產品業務還是服務業務?這個產品是現金牛、大賭注、收穫機會還是收益拖累?我們是否有能力進行長期投資?
  • 考慮提案(提高價格、重新平台化、加速部分功能、白標或外包核心開發)基於其對整個公司的影響 - 以及我們特定的產品。如果我們做X,對研發、支援和銷售等會有什麼廣泛影響?這些如何融合在一起?
  • 理解作為產品經理,什麼是「我們職權範圍內」的。我們能改變什麼(組織上或財務上),我們能影響什麼,以及什麼是根植於這家公司DNA的?我們為重要的戰鬥節省精力,並將困難的問題上報給我們的CPO。

作為產品領導者,我們看到所有部分如何融合在一起。我們:

  • 深刻理解我們的公司在營銷、銷售、運營方面的實際行為 - 特別是在高管層面。我們圍繞關鍵問題(例如單一交易需求)建立C級聯盟,而不是讓自己被忽視。我們學會與大人物一起玩,而不是將其視為政治。我們弄清楚如何做正確的事情。
  • 金錢的語言,以及研發的語言。我們認識到,我們的大多數同行專注於以貨幣計價的頂線(或底線),對構建產品的細節不太感興趣。我們在他們所在的地方與其他高管會面,而不是在我們希望他們所在的地方。
  • 使權衡明確且痛苦。不是「我們可能必須推遲路線圖上的一些未命名事項以支持您的新寵項目」,而是更清晰地描繪未來為「是的,我們可以做到,但我們需要推遲發布v12.1 - 財務部門預計每月將賺取800-1200萬美元 - 並將我們對JPMC的300萬美元承諾延遲幾個季度。還有風險再次合規審計。這筆交易會填補1500萬美元的收入缺口嗎?」
  • 我們講真話,並努力成為CEO的誠實顧問。當其他群組/部門需要幫助時(尤其是在研發之外),我們會集結支持。我們通過成為我們能做到的最好領導者來展示良好的領導力。

總結要點

產品管理不適合膽小的人。而產品領導力則大大擴展了問題的範圍。了解我們為什麼而戰與了解什麼給我們帶來快樂同樣重要。讓我們選擇我們的戰鬥,並為我們的用戶(以及我們的團隊和我們的公司)贏得勝利。

Read more

當輸入為空:探討技術開發中的空值處理與意義

當輸入為空:探討技術開發中的空值處理與意義

在軟體開發的世界裡,我們經常會遇到一個看似簡單卻深具哲學意味的問題:當輸入為空時,我們該如何處理?這個問題不僅是技術層面的挑戰,更反映了我們對於「無」這個概念的理解。今天,讓我們深入探討這個在程式設計中無處不在,卻又常被忽視的重要議題。 空值的本質:從哲學到程式碼 當我們談論「空」時,我們究竟在談論什麼?在程式設計的領域中,空值可以有多種表現形式:null、undefined、空字串、空陣列、空物件等等。每一種形式都代表著不同的含義和使用情境。null 通常表示「有意的空缺」,代表我們知道這個位置應該有值,但目前沒有;而 undefined 則更像是「尚未定義」,暗示著這個變數可能還沒被初始化或賦值。這種微妙的差異在實際開發中至關重要,因為它們會影響我們如何設計 API、如何處理錯誤,以及如何與使用者溝通。在東方哲學中,「空」並非單純的虛無,而是一種充滿可能性的狀態,就像老子所說的「無為而無不為」。同樣地,在程式設計中,正確處理空值往往能為系統帶來更大的靈活性和健壯性。當我們面對一個空的輸入時,

By Eric Lau
AI 是否做得越來越少?從全自動到混合架構的演化之路

AI 是否做得越來越少?從全自動到混合架構的演化之路

當我們談論人工智慧的進步時,通常期待它能處理越來越多的任務。但在實際應用中,一個有趣的現象正在發生:許多開發者發現,隨著 AI 系統的成熟,真正需要 AI 介入的部分反而越來越少。這不是退步,而是一種更精明的進化。本文將深入探討這個看似矛盾的趨勢,以及它對未來 AI 應用開發的啟示。 從完全依賴 AI 到混合架構的轉變 六個月前,當開發者開始建構 AI 代理系統時,最直覺的做法是讓大型語言模型(LLM)處理所有事情。每一個任務、每一個決策點都交給 AI 來判斷和執行。這種做法看似充分利用了 AI 的能力,但實際運作後卻發現了許多問題。LLM 確實會自信地推進各項任務,但準確性並不總是令人滿意。更重要的是,這種全 AI 的架構在成本、速度和可預測性上都存在明顯的瓶頸。於是,一個重要的轉變開始發生:開發者逐漸意識到,不是所有任務都需要 AI 的「智慧」

By Eric Lau
代理商務守門問題:平台如何成為新時代的聚合者

代理商務守門問題:平台如何成為新時代的聚合者

在電商與人工智慧交織的新時代,我們正見證一個前所未有的變革:代理商務協議的崛起。但這場變革背後,隱藏著一個值得深思的問題——那些曾經標榜開放、賦能商家的平台,正悄然轉變為控制流量與數據的聚合者。這不是陰謀論,而是商業邏輯演進的必然結果。當 Shopify、Stripe 這些我們熟悉的平台開始在 AI 購物表面扮演中介角色時,商家們需要清醒地認識到:你要麼掌握自己的命運,要麼成為別人棋盤上的棋子。 代理商務協議的新遊戲規則:開放但我先行 讓我們先理解一個基本事實:今天的代理商務協議與過去的網際網路標準有著根本性的不同。回想 TCP/IP 這個支撐整個網際網路通訊的核心協議,它經歷了委員會討論、RFC 文件、多年的審議過程。那個年代的開放標準是真正「民主」的,在公開透明的環境中發展。但在當今的 AI 場景中,協議的演進方式已經完全改變了。 無論是 OpenAI 的代理商務協議(ACP)還是 Google 的通用商務協議(UCP),它們從一開始就帶著完整的合作夥伴生態系統登場。OpenAI 與

By Eric Lau
當輸入為空時:探討系統邊界條件處理的藝術

當輸入為空時:探討系統邊界條件處理的藝術

在軟體開發的世界裡,我們經常專注於處理正常的業務邏輯和功能需求,卻容易忽略一個至關重要的問題:當系統接收到空值或無效輸入時,應該如何反應?這個看似簡單的問題,實際上揭示了軟體設計中最基本卻也最容易被忽視的一個面向。今天,讓我們深入探討當輸入為空時,技術系統應該如何優雅地處理這種邊界條件,以及這對整體系統設計的深遠影響。 理解空值的本質與意義 空值並不僅僅是「什麼都沒有」這麼簡單。在不同的程式語言和系統架構中,空值可能代表著截然不同的意義。在某些情況下,它可能表示資料尚未被初始化;在另一些場景中,它可能意味著使用者刻意選擇不提供任何資訊;還有時候,它可能是系統錯誤或網路中斷的結果。這種多重性使得空值處理成為一門需要細緻思考的藝術。從技術角度來看,空值可能以多種形式出現:null、undefined、空字串、空陣列、空物件等等。每一種形式都有其特定的使用場景和處理方式。優秀的開發者需要能夠區分這些不同類型的空值,並根據具體情況採取適當的處理策略。更重要的是,我們需要理解空值在業務邏輯中的含義,而不僅僅是從技術層面來看待它。例如,在電子商務系統中,購物車為空可能意味著新用戶剛進入網站,

By Eric Lau