做產品真是哭夭難! — Marty Cagan 演講 Q&A 中文逐字翻譯

Jason HOU
Jason HOU
Jul 19, 2020 · 31 min read

上一篇文章,我們分享了 Marty Cagan 在台北 70 分鐘的逐字稿,但沒有提供演講後面 45 分鐘的 Q&A 問答逐字稿。文章最後一段只寫了「若文章超過 2 千拍手,就來寫 Q&A 互動的逐字紀錄」這樣一句話,因為實在不確定「數萬字的逐字稿」究竟有沒有人要看。

到今天,上一篇文章已經累積了 1 萬 1 千 1 百個拍手,實在出乎意料。

相信很多讀完文章的朋友,也會有很多疑惑。在當天活動的 Q&A 時段中,觀眾發問相當踴躍,每一個問題都被收錄在這篇文章中,而 Marty Cagan 本身也對這樣的發問互動很滿意。現在,就讓我們來看看 Q&A 互動的逐字紀錄吧。

如果你還不熟悉: Marty Cagan 是享譽全球的產品大師,【INSPIRED: 產品專案管理全書】的作者,擔任許多知名公司的產品教練與顧問,也是全球的產品社群中的思想領先者。透過 ProductTank Taipei 社群的籌備 (Facebook, Meetup),Marty Cagan 去年 11 月難得第一次來台灣演講,由我擔任本次活動的主辦人。

如果你還沒看過上一篇文章,建議你先回頭看看。如果你準備好了,接下來有 11 題 Q&A 互動,讓我們開始吧!

Q1: 那 4 大核心能力,沒有「對產品的深入知識」嗎?

(影片秒數: 76:49)

問: 前面提到產品經理的 4 大核心能力,但我也很好奇,你覺得「對產品深入的了解」也是必要的核心能力嗎,還是說這不夠重要?

Marty: 大家有聽到他的問題嗎:「你不是也必須深入了解你的產品嗎?」

其實當我坐下來訓練團隊的時候,我會列 5 個核心能力,而這就是第 5 個,所以你確實切中要點。我其實把這項視為必帶的基本條件,但我仍然加到第 5 點,是因為我仍會遇到產品人真的不太了解他們的產品,而這很荒謬。你能夠想像這樣的事嗎?當一個產品經理,居然不了解他負責的產品?

這在面向消費者的產品很罕見,因為這些產品通常很直白、很直觀。但對面向企業客戶的產品來說,有些產品真的很複雜。負責這些產品的產品經理,若不是該項產品的專家,他們就有很大的問題了。這其實是非常嚴重的問題,我不認為任何人,包含工程師,對這樣的產品經理還帶有任何尊重。

產品經理的 4 大核心能力

Q2: 工程師只想開發,不參與探索,怎麼辦?

(影片秒數: 78:27)

問: 關於「贏得信任的被授權團隊」,我們公司曾經嘗試要做到,但我也在想,你如何讓工程師和設計師也一起找到適合的方案?我的意思是說,如果他們不夠瞭解使用者、客戶,他們還沒有這樣的觀念,他們只想完成這個功能 (feature)、只想把任務搞定,他們只想完成他們的工作,那這樣的話,我們如何能夠促使他們一起找到更好的方案,而不僅是讓他們做完工程和設計的工作而已?

M: 好,又是一個好問題。對這個問題,其實有很多個層面。好吧那我只用兩個面向來講,因為這兩項都很重要。你的問題基本上是在說「如果你有個工程師,他就只想被告知要打造的功能,而不想幫大家一起找到更好的方案」,對吧?他們只想打造方案,不想探索方案?

問: 也許他們想幫助,但他們也需要知道更多 (顧客或市場的) 資訊?

M: 很好,如果他們有意願,我們就快要成功了。那麼,我們就來聊聊這 2 種狀況。

不想參與探索的工程師,需要資深的模範

如果是他們不想幫忙的情況,那我也要給你很務實的建議。其實你需要的不多,就只需要一個願意幫忙資深工程師,這樣你就可以成功了。如果你連一個願意幫忙的資深工程師都沒有,那你就有一個棘手的問題。這時你需要去找上技術長,告訴他你至少需要一位這樣的人。在大部分良好的產品公司裡面,你不可能從資深工程師晉身到技術主管,除非你展現了「幫助探索產品方案」的意願與能力。

換句話說,良好的工程師不會只想寫程式,他們想要發明與創造。這大概也因為和我一起工作的公司,特別是那些優秀的產品公司,幾乎所有的工程師都想參與產品探索。這些人都不想打造一些沒人要用的東西,這真的很讓人喪氣。

想參與探索工程師,是最佳的創新來源

另一個你提到的情況,假設他們願意幫忙,但你也知道他們主要的工作是開發軟體,他們很可能沒太多時間,或他們沒有相關的知識,這是個比較大的議題。這時候,你得體認一個產品的小秘密,一個沒講太多、但其實非常重要的小秘密: 只有一個創新的最佳來源,不是來自我們的顧客、不是高層主管、不是產品經理、不是設計師,而是來自工程師。你告訴我一個你喜愛的產品,我告訴你是哪個工程師實現的,這是個始終如一的現象。

這個現象的原因,是因為工程師每天都和技術為伍,這讓他們處於一個絕佳的位置,去看到「此刻的可能性」 (what’s just now possible),這就是卓越產品的來源。當然,他們不需要知道產品經理知道的每件事,正如他們也不需要知道設計師知道的每件事,這正好是我們需要跨專業、跨領域團隊的原因,因為這些是非常不一樣的技能組合。組成跨專業的團隊,就因為我們必須整合大家的技能。

我也要說,只有很少數的事情,可以比「產品經理與設計師,帶著工程師一起見客戶」來得更強大。對我來說很有趣的事情是,很多產品經理告訴我,他們懼怕做這件事,因為他們不想以「給你們見見這位不爽的顧客」來打擊工程師的士氣。我就會搖頭,告訴他們「你們把整個因果關係搞反了!對工程師最佳的心理動力,就是看見正在受苦的顧客!看他們多麽想要矯正這個情況!」他們真的想這個做,我沒在跟你開玩笑。這是很真實的情況,這是卓越創新的來源。所以說,「帶著工程師去見客戶」是神奇的魔法。當然,我們沒辦法拖著 8 位工程師,去見每一位顧客,但我們可以每次帶上一位,通常我會輪流帶上不同的工程師。

接觸用戶的最低要求

我剛剛沒講這件事,但其實我早該講清楚。如果你負責面向消費者的產品,你至少每週要有 3 次與用戶互動的時間,每次 1 小時,這是最低期待。如果你正在推動大改版,可能要提高成 5 到 10 小時。我們需要讓這樣的動能發生,我們也有很多的技巧可以做到。但這真的是偉大產品的來源,透過向工程師展示、分享各種問題,來啟發工程師的動力與靈感。產品經理提供問題的背景與情境,設計師瞭解用戶的心理模式、用戶期待的體驗,然後當然由工程師來瞭解哪些在技術上有可能性。當我們把這些人擺在一起,雖然沒保證,但理想上我們能獲得特別的成果。

這是個很棒的問題,因為這帶到了「我們必須怎樣做產品探索」的核心,而一個很常見的錯誤就是產品經理和設計師每週去和顧客互動,但他們沒有帶上工程師。你很難在這樣的情況下,獲得任何創新。

Q3: 為什麼多數的公司與老闆,都不採用產品團隊?

(影片秒數: 84:28)

問: 你提到我們有「功能團隊」 (Feature Team) 和「產品團隊」 (Product Team) ,那為什麼我們有那麼多的功能團隊?只因為他們沒有相關的知識嗎,還是只是不願意?

M: 我說有「功能團隊」和「產品團隊」,我也說大多數團隊是「功能團隊」。同時,雖然我沒明講,但你也聽得出來,「功能團隊」並不是太令人欽佩,所以我們寧可成為「產品團隊」。那為什麼沒有那麼多「產品團隊」呢?就是這個問題。

不信任產品團隊

當我和執行長 (CEO) 聊到「為什麼你們要 (像功能團隊) 這樣運作?」,最基本的答案就是-他們並不信任產品團隊。最主要是,他們並不信任產品經理。請不要誤會我,通常他們也是對的-不要信任產品經理-因為產品經理們還沒有做足功課,他們還沒做到我前面所說的。當然,當他們向我指出這點的時候,我就會問「那當初是誰聘請了這些產品經理?人不是我的啊,是你找的,對吧!所以也是你的錯。」所以,我就會進一步說「聽著,你得確保他們接受訓練。然後,你得給他們一個機會表現。」那真的就是我們所尋找的兩件事。

做好你的功課

如果你是一個功能團隊的產品經理,而你真的很想嘗試成為一個真正的產品經理,認真的找設計師和工程師一起做我們談到的事情,你可以做的、最重要的事情,就是我說的「做好你的功課」,也就是我列出來的「產品經理的 4 大核心能力」,你最重要的就是做好這些事。當你能夠做到這些,接著你就去找你的主管或執行長 (CEO) ,和他們說「可以給我們一個機會,嘗試用這樣的方式工作嗎?只要幾個月就好,讓我們嘗試。」這時候,他們很可能會測試你,因為他們想知道你是否真的了解顧客、了解事業嗎?如果他們認為你還沒有,他們當然不會信任你。同樣的,他們也不應該信任你。

能夠稍微放手

如果他們相信你懂,那真的是一大進步。從那一刻開始,當產品經理贏得了高管們 (executives) 的信任,是時候讓高管們展現他們「能夠稍微放手 (let go a little bit) 」,而不是掌控每件事。對某些人來說這很困難,比其他人困難,這毋庸置疑。不過,當他們看到「這就是優良公司運作的方式」,這是一個很有力的論點。

對事業的深入知識

所以說,我相信他們通常想要這麼做,只是不知道如何做到。我會說,這當中有一個真的很常見的問題,我也對這個問題很敏銳,因為有好幾位執行長 (CEO) 明白的告訴我,這就是他們遭遇的問題。他們相信那些產品經理真心想為客戶做出厲害的產品,他們也知道做產品的人都想這麼做,但是他們說「這些人對我們的事業如何運作,卻毫無概念」。

我很常聽到這樣的說法,他們會説這人很天真,或這人對財務、對績效指標一無所知,這些對他們好像是外星語言。怎麼會這樣呢?我當然希望這些很簡單,我們只要打造顧客喜歡的產品就好了。但很不巧,產品也必須對我們的事業有益。所以說,做好功課當中的第 3 點,就是要有「對事業的深入知識」。對一個產品經理來說,要熟悉所有的 4 點功課,通常需要 3 個月,才能從新進人員到足以勝任的階段。花 3 月,其實不算太困難,但這同時需要 2 件事-願意做好功課的產品經理,以及願意幫助他們的主管。

Q4: 「做產品探索」和「做產品文件」有所衝突?

(影片秒數: 88:58)

問: 我們其實是一整個團隊一起運作,所以我有一個問題,和產品開發 (product development) 以及文件紀錄 (documentation) 有關。就是說,當我們的產品隨著時間發展,產品變得越來越大,你也知道,你擁有很多的功能、錯誤處理、邏輯驗證,等等等。不僅如此,追蹤你過去對產品做了些什麼,也變得越來越困難,因此你必須做很多文件紀錄。但是,這其實和原型製作的概念有衝突。因為,當我們製作文件紀錄,都需要時間。但原型製作,如果你僅是為了測試一些點子,其實你並不需要文件紀錄。所以,你怎麼應對這樣的衝突問題?

恩很好,這是個好問題。我打算把它拆分成 2 個問題,因為你描述的文件紀錄其實有 2 個目的。

溝通「該打造什麼、應測試什麼」

第一個目的,你必須和工程師和品質保證人員 (QA) 溝通「該打造什麼、應測試什麼」,
如果你有品質保證人員 (QA) 和你分工的話。這是第一個,要溝通商業邏輯是什麼、期待的結果是什麼。關於這部分的答案,其實很大程度地取決於這是個共處一地的團隊 (co-located team) 或遠端的團隊 (remote team)。

你也知道,共處一地的產品團隊 (co-located product team) 是大家的最愛,但不是每次都可能。只是在共處一地的產品團隊中,你有產品經理、設計師、技術主管、還有幾位工程師,通常都坐得很靠近,不然也沒隔多遠。如果這是你擁有的情況,坦白的說,產品原型就是他們彼此溝通的方式,你也就只需要非常少的文件紀錄。

如果你的工程師在遠端,這就困難很多了。如果他們不只在遠端,還講不同語言、有不同文化,那現在你就有非常多的(文件紀錄) 工作要做。如果是那樣的情況,你也看得出來,我不是那種模式的粉絲,我覺得那會讓前進速度變慢很多,而且同時你也不能取得工程師的高度參與,就是前面問題談到的、你急切需要的那種高度參與。所以,在那樣的模式之下,你會需要更多的文件紀錄,同時,有另一個我強烈努力讓公司執行的事情,就是至少保留一位資深工程師,坐在產品經理與設計師的旁邊。

當他們都在同一地的時候,我們還是有一些文件紀錄的工作,但沒有那麼多。不過你也沒錯,這在將來必定產生代價,等待償還。

至今不曾管用的「產品編年史」

第二種你談到的文件紀錄,就像我們繼承了一個產品,這產品大概有 5 年或 7 年那麼老了,已經存在好一段時間。而事實上,所有當初設計產品的人都走光了,所以你根本不知道這東西可以幹嘛,沒有人知道。從以前到現在,我指的差不多就是 30 年的長度,我們產業一直在找一個良好的方式,去紀錄我們做過的每一個 (產品設計或開發) 決策的背後思路。

經過 30 多年,你知道我們現在在哪裡嗎?任何人唯一信任的東西,就是原始程式碼,這是真的。多數的公司真的已經放棄了「文件紀錄我們為什麼這樣做」的目標,就算你真的嘗試去文件紀錄它,人們也不相信,因為他們連「確認這是最新資訊」的方法都沒有。所以說,這是一個非常非常困難的問題,所以這也是為什麼多數人會直接走向技術主管,然後跟他說「你可以看一下程式碼,並看看這裡現在實際上發生什麼事嗎?」

這就是為什麼,我不會擔心第二個問題,但專注在第一個問題,並非常努力的嘗試擁有共處一地的產品團隊,在任何你還可以的時候。

Q5: 「探索」與「交付」是分離的階段?

(影片秒數: 93:07)

問: 你提到要有一個探索團隊、一個交付團隊…

M: 一個產品團隊,兩種活動。

問: 好,兩種活動。(探索與交付) 依循不同的流程,假設有不同的目標,那你怎麼轉變加入團隊的人?你實際上會保持某些人一直都在探索活動中嗎?還是說,你會讓探索團隊同時也扮演交付團隊?

M: 好的,這又是一個很好的問題。我要回到前面那張圖,所以可以展示給你看看。

每天持續的「探索與交付」

大家都有聽到他說的話嗎?

首先,我想要強調,這是同一個產品團隊,我在這邊展示的只是兩種不同的活動。因為,如果這是不同的團隊,你會遇到一些很難看的問題。我大可以展示,編寫程式碼和品保測試是兩種不同的活動,在一個團隊中總有非常多種的活動,但我展示的是「探索」和「交付」這兩種活動。

現在,我們來談談第二件我想指出的事情。你沒有使用這樣的字詞,但很多人傾向於把「探索」想成一個階段 (phase)、把「交付」也想成一個階段。你不會想把它想成一個階段,就好比你知道有哪一個階段,他們完全不用編寫程式、不用處理交付產品的事情嗎?其實就好比我們每一天、每一週,持續地做這些事。對探索也是一樣的,有時候你產生幾個產品待辦事項 (Product Backlog Items),有時候你產生一大堆,這些不是許多階段,而是持續發生。事實上,我喜歡完整的描述為「持續探索」 (continuous discovery) 和「持續交付」 (continuous delivery),這是第二點。

再來下一個重點,如果我們現在看待成有兩種活動正在發生,在你觀察的和提問的核心,其實是關於工作崗位的本質。產品經理和產品設計師的工作,和工程師的工作,是有那麼一點不同。工程師主要的工作是完成交付、打造正式產品品質的程式碼,而產品經理和設計師主要的工作是搞清楚應該要打造什麼產品。

接下來,我用一個比較長的方式,來描述我們如何管理這一切。就是我們會請工程師每天空出 30 分鐘,去參與探索活動。這真正的內涵是指「每天都要試用、把玩產品原型」,然後要尋找 2 件事:第一,你可以想出達成目標的更好方式嗎?第二,在這個產品原型中,有任何事情使你感到緊張嗎?我們很想知道這些,對吧!?如果答案是肯定的,就表示我們有很多種方式可以達成目標。

事實上,你知道什麼是來自工程師最常見的單一抱怨嗎?不是我沒有時間參與探索,而是完全相反的,他們的抱怨是「若產品經理曾在這點子最初產生的時候,就先和我聊聊,就算只花 2 分鐘也好,我們搞不好早就省下了好幾個月的工作!」不騙你,特別是跟技術債或系統遺跡有關的議題、或決定,這些可能非常的昂貴。

事實上,我喜歡把這情況,轉變成對團隊很具體的描述-如果你的工程師第一次看到一個產品點子的時機,就是衝刺規劃會議 (Sprint Planning) ,那你就完全搞砸了。這正是多數公司採取的方式,因為他們不是用今天講的模式運作(沒有分成兩類活動-探索與交付)。在這樣的模式中,衝刺規劃會議只不過是個「選擇的時機」,因為工程師他們早就一路看著事情發展,所以這個會議只是關於「我們在下段衝刺要做什麼」的選擇而已。

好,所以一部分就是我們需要工程師每天的 30 分鐘。同時,另一部分,產品經理與產品設計師最主要的工作是探索,但我們仍要求他們每天花 1 小時,來回答交付過程中出現的問題。因為,不管你多麼在行,當工程師開始編寫程式時,永遠會冒出問題。就好像是「任何你沒想透徹的事情」,在這時候就會變得很明顯,而工程師現在就需要一個答案。

所以說,每天 1 小時,對他們來說通常很足夠,這些就是團隊合作的動態。如果你夠幸運,能夠被設定在我前面提到的團隊,真正共處一地的產品團隊 (co-located product team) ,有一個很不錯的事情會發生,就是每天 30 分鐘的互動會自動的發生,因為大家都在那裡,你就在我旁邊,你是工程師、我是設計師,你就成天看著我的產品原型,這不是個難題。但如果我們不是坐在一起,那麼我們就需要那樣特定的時間,但那真的是關鍵。

這是個好問題!

Q6: 「企業級軟體」如何快速探索、迭代?

(影片秒數: 98:40)

問: Marty 謝謝你的分享,我的確很欣賞迭代和產品原型的想法。不過,在企業商用產品 (B2B Product) 的情境中,這有點難進行,因為我們得要維持對客戶的系統穩定性。而且,我們每幾天就釋出一個新版,也有可能會嚇到我們的客戶。所以,我很想獲得你這方面的建議。

M: 我也喜歡這個問題。在這問題背後的真實對比是,在 B2C 的環境中,你知道的,這些顧客也沒付錢使用這產品。這是個免費的服務,我們常常弄壞它,反正他們也沒付錢,我們修好它就是了。當然這是個誇飾,不是真實的,但就是類似這樣的看法。對於 B2B 產品,我們必須對改動更加敏感。關於這個,其實有一個叫做「衝擊分析」 (Impact Analysis) 的主題,以及一個 Gentle Deployment Technique。

不過,關於這個問題真正的困難在於,當我們需要做產品更動,而如果你們做的是需要內部部署的方案 (On-Premise Solution),要在客戶那邊安裝伺服器與軟體,這大概是此問題最極端的型態。你可能希望每季釋出某些新東西,而你客戶的反應卻是「喔天啊,又是一個新版發佈!我們又給去驗證它、安裝它,我們還要確認所有東西都能動,還要重新訓練。」經過了一年,他們可能會說「我們受夠這些了,我們每年只接收一次新版本。」就算你可以每季釋出新版,這對你和你的客戶都不好,更別說一年一次。

客戶們的疑慮也是真實存在的,如果你跟隨良好的做法,我們最主要的挑戰是「客戶們不應該重新測試、重新訓練,這些都不需要」。事實上,Firefox 和 Chrome 都這麼做,這些都是部署在你的手機和筆電上的軟體,也是內部部署的軟體 (On-Premise Software),但他們無時無刻在更新,你只是不知道而已,這叫做靜默更新 (Silent Update)。

他們知道,如果所有人每次都要為了瀏覽器而重新訓練,誰會願意這樣做啊?沒有人想要這樣!所以他們知道要自動地更新,這就是 Gentle Deployment Technique 的例子。但如果你仔細看任何一個你喜歡的軟體,這些正在發生,他們正在每天更新好幾次。我指的是高端的 B2B 軟體,他們持續的在更新,但他們刻意設計這些更動,所以使用者不用重新訓練。

有一整個關於這些的主題,如果你有興趣,只要 google 搜尋 Gentle Deployment Technique 就可以了。那包含了各種類型的軟體變更,有些很細微、有些很重大,如果這是一個重大變更,你會看到一個叫做 Parallel Deployment,讓用戶可以依照自己的步調,選擇何時從舊版升級到新版。所以,我們有非常多的方式可以做到,但對一個現代公司,我最關注的要求就是「不應強制顧客重頭驗證」,他們正在這樣做,只因為你做為一個供應商,還沒做到你該做的事情。

Q7: 如何設定「產品團隊的目標」?

(影片秒數: 103:14)

問: 可以請你多談談目標 (Objectives) 嗎?在一個面對消費者個事業,我們如何知道這是一個比較重要的目標,我們想要解決它?在產品團隊之外,我們如何分解目標,然後設定成產品團隊的目標?

M: 好,這是個很大的問題。

針對你的問題,如果我可以全然的重述這個問題: 為何 OKR (Objectives and Key Results 目標和關鍵成果) 是這麼大的痛苦?

「功能團隊」並不適用 OKR

這真的是個痛苦,真實發生的情況是,很多實施 OKR 的公司,他們擁有的只是「功能團隊」 (Feature Team) ,但在功能團隊上實施 OKR,概念上本身就很荒謬。因為,一邊我們告訴你「這裡有個等待被解決的問題」,然後又說「喔不過,順帶一提,這是你的功能路線圖」,那種情況根本不合理。當然,這不是你確切的問題,不過某種程度上這在問題的背後。

不過這也是個很大的主題,如果你已經是被授權團隊的模式 (Empowered Team Model),那 OKR 本身並不是困難的事情,但如果你不是被授權的產品團隊,我根本不會推薦使用 OKR,他們互相不適合。這也是為什麼,有那麼多公司在 OKR 上遇到了那麼多混亂。

「設定目標」是管理者的工作

你同時也問到了,目標 (Objectives) 從哪裡來?這也是個很常見的誤會,我很高興你提出這個問題,因為我告訴你們「被授權團隊的模式」,這只是事情的一半,我並沒有提到另一半。當我提到被授權的產品團隊 (Empowered Product Team),這個團隊會被賦予一個目標 (Objective),而這個團隊有能力產生解決問題的最佳方式,但我沒說的就是「目標從哪來」,這也是你為什麼問我這個問題。這矛盾的來由,其實是因為「目標不應該來自團隊」,這其實是管理者的工作。

還記得我們談到,如何從功能團隊轉型,從功能路線圖轉變成目標?當我們請求主管們給團隊一個機會,試試看那樣的工作方法,你並不是從他們身上拿走所有的事情,你仍然要讓他們告訴你「哪些是現在最重要、最需被解決的問題」,這就是折衷。主管們說「最重要、需被解決的問題是留存率,這現在很糟糕,我們必須解決」,這是他們的工作,就是告訴你「什麼是最重要的問題」。然後,找出最好的解決辦法,就是我們身為團隊的工作。

請不要誤會我,每個我認識的好主管,都希望聽到一個團隊說「我們知道留存是個問題,而且我們想要處理它」,他們很愛聽到這些,因為這是個有動力團隊,想要解決重大的商業問題。他們不想聽到的是每個團隊說「喔,我們想要做這個,我們將要做些有趣的事情」。你懂嗎,這就像是一團混亂,每個人都朝自己喜歡的方向前進。

所以說,當一間公司想轉換成 OKR 時,一個很常見的錯誤就是,他們讓每個團隊自己決定 OKR。這樣事情該如何結束,每季或每年結束時,該如何達成商業目標?應該是目標來自主管們,而關鍵成果來自團隊,這是 OKR 背後的基本想法,但很多人並不了解。不過,再說一次,真正搗亂這些的因素,是很多公司只是運作功能團隊 (Feature Team),所以總之他們並不真的有導入 OKR 的環境。希望這些聽起來合理,關於 OKR 我也寫了很多,也有很多和 OKR 有關的書。

Q8: 「共用人力」的團隊,怎麼辦?

(影片秒數: 107:38)

問: 在很多談話中,會假定足夠的工程資源就在那邊。那如果一個產品經理沒有足夠的資源,會發生什麼事?我想舉例來說,以我的狀況,我要和另一個專案共享同一個工程師,你會如何應對這樣的情況?

M: 恩,是有其他團隊運作的模式。我在這邊談到的產品團隊,或小隊 (Squads),這些都是專責的團隊。事實上,有些人稱呼它為「專責的產品團隊」 (Dedicated Product Teams),有些人在精實創業中稱呼它為「持續的產品團隊」 (Durable Product Teams),而核心想法就是這些團隊不會被共享,不會被共用。

如果你和許多產品經理共用工程師,這叫做共享池模式 (Pool Model),有一池子共享的工程師,同時間處理不同的事情。我甚至很難再看到這樣的模式,我並不是質疑你,我偶爾還是會看到。這是個很糟糕的模式,我知道有些老牌的技術長、資訊長會認為這比較有效率,但當然這其實更加沒效率,因為這些工程師並不是棋盤上的棋子,可以隨時被移動到不同的遊戲中,這些是需要花時間深入事情並創新的人。所以,這是個不同的模式。

我們先假設你不是這樣運作,且你有專責團隊,但你可能會遇到一個普遍的情況,就是一個產品經理身邊沒有產品設計師。如果你是做面對大眾的產品,你沒有設計師,這會是一個很困難的挑戰。通常會發生的一個不太好的現象,就是產品經理嘗試著扮演設計師。這是其中一個相當棘手的事情,因為事實上學習使用設計工具非常簡單,但這不會讓你成為一個設計師,所以你會獲得很多可預期的糟糕設計。

如果這個情況發生了,我常常必須和執行長有這樣的對話,和他說「如果你有這麼多工程師,你正在浪費很多錢,除非你有足夠數量的設計師」。如果你有 50 位工程師,你不需要 50 位設計師,但你很可能需要 5 位。如果你沒有這 5 位,就從工程那邊釋出 5 個位子,轉移到設計上,你將會完成更多事情,而且是更好的成果。

所以,我們必須調整,才能確保每個團隊都在做他們必須做的事情。最低的限度,如果你做的是面對消費者的產品,至少是 1 位產品經理和 1 位設計師,搭配至少 2 位工程師,最多 10 到 12 位工程師,大概就是這個區間,取決於這個軟體產品的性質。

Q9: 如何溝通產品長期的方向?

(影片秒數: 110:54)

問: 你經常談到原型製作,我想知道原型製作如何搭配產品路線圖?因為我的一些團隊成員很想考慮一致性和可擴展性,有時候我們運用敏捷的方法,他們會感到不自在,因為我們會不知道在下一個衝刺迭代 (Sprint) 將要做些什麼。

M: 好,這裡面有幾個議題。有一件很重要的事情,就是產品團隊上的每一個人,從產品經理開始,以及所有優良的工程師,他們不只是必須知道這個衝刺迭代 (Sprint) 正要做什麼,還要知道未來好幾個月正準備做些什麼。事實上,如果你是資深架構工程師、或技術主管,你必須要知道未來好幾年可能發生什麼事情。

這是什麼意思,提出一整年的路線圖嗎?當然不是,但這確實表示要提出產品願景。說到產品願景,要澄清這是另一個常見的問題,就是每個團隊都提出自己的產品願景,這和每個團隊提出自己的目標一樣瘋狂。產品願景的重點,就是那些我們所有團隊的共通點。不過,產品願景是大約介於 3 年到 10 年之後的未來。工程師那麼迫切的需要它的原因,附帶一提,設計師也同樣需要,就是因為他們必須確保他們擁有一個到位的架構,可以滿足事業上的需求。如果你只給他們一兩個衝刺迭代 (Sprint) 的能見度,他們沒有辦法做好他們的工作。所以說,那樣的能見度非常重要。

路線圖則是另一個問題,路線圖使我們陷入困境。因為,現在那邊有了各種細節,而這些細節將會改變。有一句亞馬遜 (Amazon) 執行長 Jeff Bezos 的名言,我覺得他完全抓到這個要點,他說「對願景要固執,對細節要彈性」。意思是説不要放棄你的願景,通常亞馬遜會提出一個 7 年的願景。路線圖就是細節,所以你最不想做的事情,就是提出一個好幾個月的路線圖,告訴大家這是我們即將打造的東西。

如果路線圖只是你們的點子清單,那不會有什麼問題,但路線圖從來不是這樣。我們之所以會陷入困境的原因,如果你還沒搞懂,你之後也會懂,就是一旦你放了某些東西到一個稱之為「路線圖」的文件上,我跟你保證,你的高管們 (executives) 將會把它視為一個承諾。到了那個時刻,你就被困住了,那些不再是點子,是承諾。而且那就是我們陷入困境的地方,因為正如微軟所承認,90% 的那些東西其實都不會管用,那麼你為什麼還要承諾 100 多件事情,而其中 90 幾件會失敗?那就只是浪費。

所以你可以發現這裡有很多主題,但他們都能拼湊在一起。好,這是個很問題。

Q10: 如何有效的進行「產品探索」?

(影片秒數: 114:23)

Marty,非常感謝你的演講。只是想知道,有沒有什麼探索上好用的技巧?因為我們團隊花大多數的時間做產品優化 (optimization),而就像你說過的,優化可以看到比較能預期的結果,探索有時候是很多的風險。所以,當我們有個目標,為了這個月或這一季的目標,我們容易傾向花更多時間做優化,而不是探索。當我們偶爾做探索的時候,例如跟我們的用戶對話,這很像是個抽樣。我們是面相消費大眾的產品,或許我們只挑選 10 個顧客,有時候這麽小的樣本會讓人感到不安。你可以告訴我們全貌嗎,或者是更好的技巧?

好,所以這個問題是,有沒有探索的一些技巧?事實上,我為此撰寫了一本書,剛好最近被翻譯,我想應該有些印刷本在那邊!(傳送門: 【INSPIRED: 產品專案管理全書】)

任何人都能辦到

我並沒有誇飾,我的意思是說,當我和一個產品團隊坐下來討論時,光要涵蓋最核心的技巧就需要兩天。那裡有非常多的技巧,而且沒有哪一個是火箭科學,沒有哪一個是你無法辦到的技巧。那些是任何人都可以執行的技巧,只要他們受過訓練。我也要說清楚,我沒有發明任何一個技巧,我所做過的事情,就是和很多很棒的團隊合作。當他們用一個技巧時,我通常就會分享給其他團隊,而如果這個技巧在另一個團隊也管用,我就再分享給更多人。所以,在所有技巧中,那本書有的只不過是我目前最喜愛的一組罷了。

不去冒險才最危險

就像你說的,探索就關於風險,全部都和冒險有關。你很可能也知道,最危險的事情就是不去冒險、不承擔任何風險,這就是我們事業的特性。那也是為什麼我說,當我發現很多團隊只做產品優化時,我就覺得你們即將陷入困境。所以,你應該做產品優化,但那些是簡單的事情。而事實上,如果這些就是你全部的工作,你的公司很可能可以省下非常多的錢,就憑它不需要有那麼多產品設計的人,甚至是工程師。

所以你需要做探索,你需要那些技巧,任何人都可以做,這只需要一些教育。探索就是很多的「製作原型」 (prototyping) ,正如我說的有 4 種原型,而我們有 4 種風險:價值 (Value)、易用性 (Usability) 、實行性 (Feasibility)、商業可行性 (Viability)。所以,我們有不同的方式,去測試每一個風險,然後我們有質性的和量化的方法來做測試。這不是一個簡單的答案,但當然有真實的答案在那裡,我當然強烈的鼓勵你這麼做。

Q11: 當高管要求你「下一件大事」的時候,怎辦?

(影片秒數: 117:25)

問: Marty 很謝謝你的分享,我想問的是,當高管們 (executives) 給出的要求,實在是非常巨大的時候,產品團隊可以採取哪些途徑?可不可以提供你的建議?譬如說,要產品團隊為這家公司找到「下一件大事」 (the next big thing): 找到下一個重大的產品、下一個新客群、下一個用戶會喜愛的產品、會賺錢的產品?

M: 好,你知道的,其實我正在寫一篇文章,我的下一篇文章其實是關於「如何為了誠信而輔導」 (How to Coach for Integrity)?因為這正是你要面對的情況,特別是產品經理,很多時候會被要求一些他們完全不知道自己能不能辦到的事情。如果你給了承諾,但沒有做到,你大概很可能會傷害到你先前對主管們建立的信任。同時,附帶的,如果你的工程師和設計師認為你瘋了,他們也將會對你失去信心。所以,「你如何應對這樣的情況」是個很常見的問題。

高誠信的承諾

其實,這樣的情況和「設定期待」很有關係。我會建議,有一個技巧叫做「高誠信的承諾」 (high-integrity commitment),這就好比「你如何給一個承諾,當這是一個超困難的問題,而且我們今天並不知道答案」。有一個良好的方式去應對這樣的情況,會多花掉一點時間,但結果是一個有更高信心度的承諾。我會上 Google 去搜尋這個關鍵詞,「高誠信的承諾」 (high-integrity commitment),這將會對你有幫助,不過我也覺得我正在寫的那邊文章,也能對此有所幫助。不過,這很困難。

我完全不知道,這個在台灣有沒有人分享過,不過有任何人聽過「內褲侏儒」 (The Underpants Gnomes) 嗎?這來自於南方四賤客 (南方公園) 的卡通,你應該 Google 一下,因為就在講這種情境。我其實跟很多執行長分享這個卡通,為了跟他們指出「什麼才是他們在要求的事情」 (what they’re really asking)。當然,如果你沒看過,這就不代表什麼。這是個很真實的問題,很困難的問題。順帶一提,很多很棒的團隊,這是他們想要努力的問題。所以,不要誤會我,這是很值得努力的問題,但設定期待很關鍵。

兩種 OKR:承諾 vs 進取

這也和 OKR 的討論有關,因為其實有兩種目標、兩種關鍵成果。其中一種叫做進取型、挑戰型 (aspirational) ,這就是執行長説「聽著,對你的團隊,我們不是要求你小改善,去獲得 5% 或 10% 改進。我們要求的是,對我們的事業有 10 倍的進步」的時候。想想看,10 倍,多麼的巨大,當他們說這些的時候,他們也會説「我們也知道這並不簡單,獲得 10 倍改善的機會並不高,但你知道的,我們想要請求我們的團隊去真的試試看。」

有些人把這些比喻成「射月」 (Moonshot) 和「射屋」 (Roofshot)。射向屋頂並不困難,就好像丟個東西上屋頂,射向月亮就相當困難。但如果你射向月亮,就算沒有真的抵達月亮,仍然遠遠超出房子的範圍,就是這樣的想法。所以,這些被稱為挑戰型的關鍵成果 (aspirational key results),而且團隊要被明確的告知,你們要追逐下一個大事件,你們不應該那邊做優化,所以「射月」才是我們希望你們追逐的目標。這是風險很高的事情,大家都知道,所以對挑戰型的關鍵成果,這些並沒有「高誠信的承諾」。

另一方面,還有另一種關鍵成果。就是說,不要給我一個 10 倍的數字,告訴我「什麼是你很確定這一季絕對能夠交付的事情」?這才叫做高誠信的承諾,你也可以把那當做「射屋」,是你知道你做得到的事情。

這是一個很大的主題,但不一定是不好的事情,很多團隊喜歡處理這樣的事情。事實上,很多人會抱怨他們不被允許做這些的事情,只能處理相同的產品,做了 4 年。

ProductTank Taipei #19

這些就是 Marty Cagan 去年 11 月,在台灣演講後的 Q&A 互動內容,感謝各位的耐心等待,以及拍手鼓勵!感謝 4 位贊助夥伴,分別是 PicCollagearc() x codementorMozilla TaiwanPinkoi,讓 200 多位觀眾近距離和 Marty Cagan 互動。

特別感謝 3PM 產品三眼怪,以及當天支援活動的超多夥伴,才能讓更多人接觸這樣的內容。

謝謝你讀到這裏,相信你(跟我們一樣)有很強的學習動機,才讀完上萬字!我們很想集結熱衷學習的台灣產品人,在私密社群的環境下交流、學習。 💭 💬 💡

🙋🏽‍♀️ 🙋🏽‍♂️ 如果你願意,請幫我們填寫問卷:

http://bit.ly/product-people-survey-medium

再次感謝!🙏🏽

3PM LAB 產品三眼怪實驗室

來自網路圈的三位產品經理,透過【Medium 文章】與【Podcast】和大家分享各種網路產品經理的 #產品心法 #職場合作 #數據思維 #產業觀察 #職涯學習等等。歡迎追蹤三眼怪加入我們的實驗室!

3PM LAB 產品三眼怪實驗室

來自網路圈的三位產品經理,透過【Medium 文章】與【Podcast】和大家分享各種網路產品經理的 #產品心法 #職場合作 #數據思維 #產業觀察 #職涯學習等等。歡迎追蹤三眼怪加入我們的實驗室,ooohh!👀💡

Jason HOU

Written by

Jason HOU

從 Developer 變成 Growth Hacker,然後又變成 Product Manager。 https://www.linkedin.com/in/jason-tc-hou/

3PM LAB 產品三眼怪實驗室

來自網路圈的三位產品經理,透過【Medium 文章】與【Podcast】和大家分享各種網路產品經理的 #產品心法 #職場合作 #數據思維 #產業觀察 #職涯學習等等。歡迎追蹤三眼怪加入我們的實驗室,ooohh!👀💡