avatarNana Chiang

Free AI web copilot to create summaries, insights and extended knowledge, download it at here

2575

Abstract

引起他興趣的事情,</b>這和我上面提到的「因為無聊而想隨意看看」是類似的狀態。(我個人覺得現在用戶常有這樣的行為是因為大多數的產品首頁會不斷刷新推薦,用戶下意識會知道當他們回到首頁或探索頁面,通常會有新的內容讓他們繼續瀏覽下去。)</p><p id="9cde">也因此首頁特別適合拿來做幾件事:

  1. <b>Navigate</b>:引導需求明確的用戶盡快進入他要做的事的流程,完成任務
  2. <b>Browse & Inspire</b>:讓需求不夠明確的用戶透過瀏覽找到他想做的事,或者能夠不斷享受瀏覽本身的樂趣。 3.<b> Remind</b>:提醒用戶完成他還未完成的任務</p><p id="c288">但東西方的首頁也有很明顯的差異,歐美的 app 希望首頁越簡單直覺越好,所以像是 Google 首頁到現在每開一個 Chrome tab 還是簡簡單單的一個搜尋欄位,沒有塞一些其他東西進去。而亞洲的現在有更多 super app 的趨勢,常常會在首頁放很多不同的任務選單進去給用戶,所以兩邊處理首頁任務的價值觀與方式可能也會不太一樣。</p><p id="683c"><i>💡個人小見解:大部分的買賣平台首頁會以「購物」為主要內容,其實我認為並不是因為買家比賣家重要,可能只是因為買東西的門檻比較低,透過推薦內容能夠達成衝動消費的機率較高。賣家方面的話,雖然還是可以透過「這個東西很多人想買如果你拿出來賣可以賺很多錢」的這種訊息去鼓勵更多的用戶上架商品,但畢竟成為賣家的門檻就是相對來得更高。</i></p><h2 id="921e">制定產品首頁的設計與實驗準則</h2><p id="3374">有了定位之後,也可以建立一些相呼應的大原則協助大家更有效率的合作,目的是希望大家沒方向是可以直接向 Best practices 看齊抄作業,但有想法時,這些原則也該保留足夠的彈性讓產品持續突破與進步。</p><p id="a6da">這部分可以從產品本身的<b>設計原則</b><b>指標架構</b>兩方向去下手。</p><p id="259b">在設計原則方面,最基本的是將我們累積的經驗轉化成幾個 high-level Dos and Don’ts,例如內容必須要相關、呈現必須要多元用戶才不會麻痹,圖片不能太小、關鍵資訊不能少等等。除此之外,我設計師有打造一個小型的首頁 Design System,將研究與實驗的結果集結成通用元件,幫助大家分析什麼樣的 UI/UX 更容易達成他們所期待的結果。團隊也一致同意,像是誰佔最上方第一排、誰的內容要被往下推這樣子的優先級排序問題,我們不爭辯不討論,直接做假設之後去驗證,讓實驗數字與演算法模型說話、做決策。</p><p id="73b6">在指標架構上,我和分析師一起列出且測試出一系列通用且可觀察的指標,通常大方向上都會是整個頁面的參與度指標(engagement metrics)或轉換率(conversion metrics),在大家跑各自實驗讓不同指標消長的同時,確保整體體驗仍然是健康的。</p><p id="33a9">通用原則不是死的,有新的學習之後一樣可以迭代,重點是這些工具通常能讓大家更容易有效率有目的的迭代,而不需要每次都從零開始思考。There’s no need to reinvent the wheels every time when you run a new experiment!</p><h2 id="83d4">盡可能地在共識模糊前快速地推進進度</h2><p id="f276">最後一點維護共識的方法就是:Move fast。 網路產品世界一向都動得很快,而人們也很善於遺忘,除非你要穩定且持續的不斷維護這個共識,否則取得共識後就趕快行動吧!</p><h1 id="5a12">2. Continuous Collaboration ✨</h1><p id="2c87">在第一次做首頁的時候,我取得初步共識後,後面就回頭專注在自己團隊的目標,結果兩個月之後,因為公司步調太快,發現很多人根本已經忘記我們在做什麼,私底下開始有很多回饋湧入,變得很棘手。當時主管緊急叫我們準備一個投影片,從頭開始敘述首頁願景、策略與計畫,才重新找回共識。</p><p id="eb5e">所以第二次做首頁我學到了:經營一個產品領域總是一段長長的旅途,和夥伴們的合作就像是一起拼樂高一樣,每一步都還是要仔仔細細的確保元件們都在互相扶持、並且朝著同樣的完成品前進。</p><p id="7c62">以下是我這次捲土重來後,通常會進行的幾件事情協助合作與向上管理:</p><ul><li><b>Centralised master doc</b>:使用一個簡單的主文件連結所有相關的文件(負責人、長期願景、階段性目標、實驗結果、指標系統、設計元件、技術文件等等),讓大家知道如果想看最新的資訊,可以到這裡統一尋找。</li><li><b>Monthly sync</b>:每個月 30 分鐘就夠的交流會議,非常重要! <b>會議前半部我們通常是各自分享上個月在首頁進行過的實驗、獲得的學習</b>,像我們網頁版和 App 版有不同 PM、用戶端和 ML 端有不同 PM,同樣的假設就不用每個人都測一次,可以拿別人測過的失敗假設加以迭代、把成功的實驗擴大到不同產品領域獲得 Free impact。也可以帶入行銷團隊,讓驗證過的事情與 insights 發揮最大效用。 <b>會議後半部我們會互相分享彼此下個月的計畫</b>,除了讓與會者知道接下來可能發生的事並提早給 feedback 以外,更重要的是如果有相撞的實驗,也可以趁這個時間來互相協調。</li><li><b>Slack channel(optional)</b>:如果有比較多 Ad-hoc 的事情需要討論,也可以開群組更即時的交流。</li><li><b>Monthly newsletter(optional)</b>:如果想要升遷或增加向上管理能見度的朋友很推薦使用這方法,把每個月的進度統整和產品團隊分享,也讓 Senior Leadership 可以更容易追蹤 hig

Options

h-level 的進度。</li></ul><p id="bc3d">根據團隊的回饋, Monthly sync 的實驗結果交流是大家覺得最有幫助的,每個月在回顧近期學習的時候都可以加速每個人的知識量。</p><p id="898c">我也會視討論議題的多寡決定這個月要取消、延後還是增加成一小時,也不強迫大家參加,希望維持這個會議在 5–10 人以內,每次都可以輕鬆的討論,不需要太正式。所以後來除了首頁,我又開了商店頁面和產品卡片的 monthly sync 😂</p><p id="21b5">除了這些比較有系統的合作以外,<b>擔任一個共同領域的負責人最忌諱的就是「為了做而做」</b>,ownership 不只是跑跑流程,因為產品並不會因為有一群人每個月多開 30 分鐘會就變好。產品領域負責人必須時時刻刻的了解所有發生在首頁的大小事、維持文件更新、協調團隊之間的矛盾等等,都是身為一個 page owner 的責任,而這些常常是在自己團隊的 KPI 之外的。我會讓大家知道我隨時都願意幫助他們,有問題就 ping 我,<b>希望任何想利用這裡的特色達成目標的夥伴、在執行上有 micro decision 需要做的夥伴,都可以把我當成他們可以利用的資源,盡情地發光發熱。</b></p><p id="e8b7">當然這也不是我一個小 PM 能夠做到的事,也很感謝我的 Engineering Manager、Staff Engineer 和 Product Designer 也都一起共同擔任起這個責任,讓各方需要協助的人可以獲得全方位的諮詢服務❤️</p><h1 id="0ccc">3. Impact at scale 🙌</h1><p id="215d">我覺得做首頁最需要擁有的心態是:<b>不是我把首頁做好,是我讓產品首頁變成一個「大家都可以利用的工具」,來讓產品對於各種用戶區隔都能發揮最大的價值。</b></p><p id="5f0a">前面有提到我因為太專注買家的轉換率,而遺忘了其他 Verticals(租車、租房)團隊的需求,在菜鳥時期常常思慮欠佳,常常達成了 A 目標卻傷了 B 目標,最後都很苦惱到底要不要把對 A 好但對 B 沒那麼好的功能上線,除了同事們很苦惱,我也超苦惱的!</p><p id="e34f">而這其實都是因為首頁的特質很適合做 <b>Navigation</b>,前面有稍微提到,首頁功能常常是在引導需求明確的用戶盡快進入他要做的事的流程,完成任務。也因為首頁往往不是滿足一項用戶需求,而是多項。<b>也因此做首頁的時候有的時候要從開發者心態抽離,退一步思考如何 enable 其他人發揮更大的影響力。</b></p><p id="a569">所以在這次捲土重來做首頁開發的時候,雖然我是買家團隊,80% 的時間都專注在如何協助買家找到想要購買的商品並且購買,但我和團隊還是會花其他 20% 的時間(這裡的 80/20 只是個概念而已,其實沒有去計算每個小時😂)打造首頁的基礎建設,讓我們產品迭代更好做,也間接協助其他團隊成功,以免再度踩到各種我當年還是菜鳥 PM 的雷。</p><p id="2f12">這些基礎建設包括但不限於:</p><ul><li><b>Measurement</b>:和分析師或其他 PM 們一起討論好如何衡量成敗,也要有統一的健康指標(e.g. purchase conversion 永遠不能被傷害)來當作底線,讓大家只要不傷害指標,都有跑實驗 & 把功能上線的自由。<i>(以前第一次做首頁的時候,很怕別人把體驗破壞掉,常常在討論階段就想把其他人的點子擋掉,但事實上是不實驗我們都不知道結果!所以最好的方法就是把指標定義好,給大家實驗自由 👼 跑完實驗再來用數據講話)</i></li><li><b>Design system</b>:設計系統或原則,讓大家知道如果需要幫助用戶達成某項任務,可能可以用 A 元件做 A 方法,會比 B 元件做 B 方法還有效。</li><li><b>Tech foundation</b>:能夠在不干擾彼此之下去去開發與部署的開發環境、齊備的事件追蹤、Code review 的流程與方法,甚至 SLA 的定義等等,讓大家有清楚的 technial ownership 卻又能彼此合作。誰負責什麼、誰維護什麼,這些都需要仰賴團隊工程師們事先談好怎麼合作。</li></ul><p id="ccec">我在做了一年半的首頁迭代之後,<b>我也把一年半以來的所有學習和實驗結果統整成一個投影片,發到公司的公開產品群組,讓全公司都能看見我們一路的跌跌撞撞,知道我們試過什麼、有哪些成功與失敗</b>,也藉此告訴大家「首頁真的超讚!好適合讓你的功能被用戶看見!歡迎來用我們的框架成就你的 Impact ✨」,也感謝一路以來各種幫忙的夥伴們。發出這個投影片的時候真的超有成就感的 😭</p><p id="4d86">我們公司一直以來產品經理之間都有很強的合作風氣,也因為如此,我在做首頁的時候沒有遇到太大的困難,大家都把用戶放在第一位,願意看數據說話,相信彼此都是各自領域最棒的 Expert。謝謝我的 PM 同事們你們好棒!(雖然沒人看得懂中文所以其實沒人會來看這篇 😂)</p><p id="aee4">因為首頁被整理得越來越乾淨、越來越容易做實驗,<b>近半年公司大約有一半的團隊都來首頁做自己的實驗</b>,目前已經看到了好多成功案例,我真的是打從心底替他們開心,Pricing 團隊的成功、賣家團隊的成功、物流團隊的成功都是首頁的成功 👏</p><p id="b1f9">希望這篇分享能夠幫助到跟我一樣正在領導能見度很高的產品領域的朋友,如果有什麼跌跌撞撞心得,也歡迎留言跟我分享 💪</p><blockquote id="b96c"><p>謝謝你的閱讀! 有幫助的話,歡迎拍手與分享👏🏻 <a href="https://medium.com/3pm-lab">產品三眼怪實驗室</a>時不時會分享其他產品管理相關文章,追蹤起來!</p></blockquote></article></body>

兵家必爭之地:產品首頁管理術

產品首頁,顧名思義就是用戶打開你的產品所看到的第一個頁面,這裡有著最高的能見度和流量,也是用戶能否順利使用產品完成他們所想完成任務的關鍵頁面。負責首頁產品,常常要面臨來自不同觀點的意見、解決公司多個目標可能產生的的衝突,是一個需要把關係管理技能點滿的任務。

最近剛和團隊結束一段一年半的電商 app 產品首頁優化旅程,當初一開始的想像都測試的差不多,總算把產品從混亂的瀏覽架構中,帶到一個能夠繼續實驗迭代的新基礎上,接下來要重新思考下一個階段的願景,算是個很大的里程碑。

不敢說自己能夠掌握複雜產品的首頁管理,不過和多年前第一次負責首頁改造的菜鳥時期比起來,第二次做首頁時覺得順利許多!所以想把過去犯的錯誤,以及這次做的改進統整起來,看到這篇的朋友就可以提前避雷了。

現在的 Depop 首頁和兩年前長的超級不一樣了✨ 持續迭代中

在負責首頁產品管理時,你可能會遇到以下問題…

  • 團隊 A 希望自己的內容被放在能見度最高的地方,團隊 B 希望自己的內容可以有一塊獨立版面可以呈現,如何判斷誰更重要,更值得更多曝光?
  • 同時有多個團隊想跑實驗,開發上產品實驗時程互相打架,有些實驗可能有相依性,怎麼辦?只能等待嗎?
  • 雖然都是為了公司好,但團隊的商業目標都有些許不同。以電商平台為例,買家搜尋團隊希望更多人使用搜尋功能、買家結帳團隊希望用戶不要忘記他們放在購物車裡的商品、行銷團隊希望促銷特價的版面可以被看到、廣告團隊希望合作夥伴的活動可以被曝光。如何平衡不同的目標,以免顧此失彼?

簡單來說就是大家要的都不一樣,很難讓全部人都滿意啦😭 相信就算不是首頁,大家一定或多或少都有遇過這樣子的情況吧!!

那麼,我過去犯了哪些錯,這次又怎麼解決呢?

1. Alignment, alignment, alignment ✨

多年前第一次在旋轉拍賣做首頁的時候,我隸屬於公司唯一的買家體驗團隊,主管告訴我,首頁就是要讓買家更好的瀏覽商品,於是我和團隊馬上從用戶研究著手,訪談、規劃、開發、跑實驗。結果跑實驗的時候發現整體買家轉換率雖然提高,但同樣是購買商品,現在用戶改為購買平價的日常用品,去瀏覽高價的二手車的人反而減少了。

整體轉換率是好的,但平均消費單價減低,這是好事嗎? 這樣的情況之下,我們該將新版改動上線,還是改回舊版呢?

OK,產品經理最愛講的,it depends,我個人是覺得沒有標準答案啦。

你可以假設:當用戶知道這裡不只可以買日常用品,還可以買二手車,能夠滿足他更多面向的需求,那麽他對平台黏著度會更好。你也可以假設:用戶來到平台就是想逛日常用品,幫他們盡快找到想要的商品並購買,他們才會更容易有第二次購物。其實各種假設都可能會成立,但要看當下公司整體的 context 和大家的想法。

例如可能可以看產品的階段:平均單價下降不一定是壞事,有可能因為價格更便宜、更容易轉換、有更多人買得起東西因而讓用戶感受到產品價值,更願意留下,這對整體用戶增長可能有幫助。但如果用戶已經很黏著且穩定,你怎麼煩他他都不會離開你,這時候幫助用戶去探索更多種類的商品、增加 LTV(Life time value)的確是好事。

也可能要看公司的價值觀與狀態:如果新創公司募資的錢已經快燒完,那麼可能需要先賺錢再說,哪個錢多往哪個走,而如果這情況發生在財務穩定的公司,可能就會有更多餘韻去思考長期策略。

如果基礎建設更穩固的公司,更數據導向的方法是可以長期觀察 GMV (Gross merchandise value)的走向,了解轉換率、價格與總和收益的關係,知道維持怎樣的價格可以達成最適當的轉換率而達成高收益。

以上的例子說明了產品決策是多面向且複雜的,在沒有標準答案的情況下,很容易流為政治角力或爭論。如果想避免這樣不健康的討論,我的經驗告訴我,在做任何改動前要先取得共識,討論出可衡量的標準,再進行實驗。

讓大家對產品首頁的定位與用途有共識

首頁的最大特色就是:這是所有人進來看到的第一個頁面。同時這也很容易創造一個誤區:團隊很容易以為首頁可以拿來做所有事!而當一個產品要服務所有人所有需求的時候,很常變成最後它服務不好任何人。

所以在開始做改動之前,先退一步定義:產品首頁的最大用途是什麼? 用戶到首頁的時候通常有哪些意圖(intent)? 哪些事情最適合用首頁來完成?哪些事情不適合或不需要使用首頁來完成?

以電商或雙邊平台來說,用戶到首頁通常是在這兩個狀態其中之一: 狀態一:用戶有某件明確的需求需要被滿足,開啟產品來到首頁。可能是在 Instagram 上被貼文燒到想購入某樣特定商品、可能是最近入秋變冷覺得可以找找看保暖衣物,也可能他的需求是殺時間,因為無聊而想隨意看看是不是有新商品上架等等。

狀態二:他結束了他在產品上需要完成的任務,沒事做了,下意識回到剛開始的地方看看還有沒有什麼可以引起他興趣的事情,這和我上面提到的「因為無聊而想隨意看看」是類似的狀態。(我個人覺得現在用戶常有這樣的行為是因為大多數的產品首頁會不斷刷新推薦,用戶下意識會知道當他們回到首頁或探索頁面,通常會有新的內容讓他們繼續瀏覽下去。)

也因此首頁特別適合拿來做幾件事: 1. Navigate:引導需求明確的用戶盡快進入他要做的事的流程,完成任務 2. Browse & Inspire:讓需求不夠明確的用戶透過瀏覽找到他想做的事,或者能夠不斷享受瀏覽本身的樂趣。 3. Remind:提醒用戶完成他還未完成的任務

但東西方的首頁也有很明顯的差異,歐美的 app 希望首頁越簡單直覺越好,所以像是 Google 首頁到現在每開一個 Chrome tab 還是簡簡單單的一個搜尋欄位,沒有塞一些其他東西進去。而亞洲的現在有更多 super app 的趨勢,常常會在首頁放很多不同的任務選單進去給用戶,所以兩邊處理首頁任務的價值觀與方式可能也會不太一樣。

💡個人小見解:大部分的買賣平台首頁會以「購物」為主要內容,其實我認為並不是因為買家比賣家重要,可能只是因為買東西的門檻比較低,透過推薦內容能夠達成衝動消費的機率較高。賣家方面的話,雖然還是可以透過「這個東西很多人想買如果你拿出來賣可以賺很多錢」的這種訊息去鼓勵更多的用戶上架商品,但畢竟成為賣家的門檻就是相對來得更高。

制定產品首頁的設計與實驗準則

有了定位之後,也可以建立一些相呼應的大原則協助大家更有效率的合作,目的是希望大家沒方向是可以直接向 Best practices 看齊抄作業,但有想法時,這些原則也該保留足夠的彈性讓產品持續突破與進步。

這部分可以從產品本身的設計原則指標架構兩方向去下手。

在設計原則方面,最基本的是將我們累積的經驗轉化成幾個 high-level Dos and Don’ts,例如內容必須要相關、呈現必須要多元用戶才不會麻痹,圖片不能太小、關鍵資訊不能少等等。除此之外,我設計師有打造一個小型的首頁 Design System,將研究與實驗的結果集結成通用元件,幫助大家分析什麼樣的 UI/UX 更容易達成他們所期待的結果。團隊也一致同意,像是誰佔最上方第一排、誰的內容要被往下推這樣子的優先級排序問題,我們不爭辯不討論,直接做假設之後去驗證,讓實驗數字與演算法模型說話、做決策。

在指標架構上,我和分析師一起列出且測試出一系列通用且可觀察的指標,通常大方向上都會是整個頁面的參與度指標(engagement metrics)或轉換率(conversion metrics),在大家跑各自實驗讓不同指標消長的同時,確保整體體驗仍然是健康的。

通用原則不是死的,有新的學習之後一樣可以迭代,重點是這些工具通常能讓大家更容易有效率有目的的迭代,而不需要每次都從零開始思考。There’s no need to reinvent the wheels every time when you run a new experiment!

盡可能地在共識模糊前快速地推進進度

最後一點維護共識的方法就是:Move fast。 網路產品世界一向都動得很快,而人們也很善於遺忘,除非你要穩定且持續的不斷維護這個共識,否則取得共識後就趕快行動吧!

2. Continuous Collaboration ✨

在第一次做首頁的時候,我取得初步共識後,後面就回頭專注在自己團隊的目標,結果兩個月之後,因為公司步調太快,發現很多人根本已經忘記我們在做什麼,私底下開始有很多回饋湧入,變得很棘手。當時主管緊急叫我們準備一個投影片,從頭開始敘述首頁願景、策略與計畫,才重新找回共識。

所以第二次做首頁我學到了:經營一個產品領域總是一段長長的旅途,和夥伴們的合作就像是一起拼樂高一樣,每一步都還是要仔仔細細的確保元件們都在互相扶持、並且朝著同樣的完成品前進。

以下是我這次捲土重來後,通常會進行的幾件事情協助合作與向上管理:

  • Centralised master doc:使用一個簡單的主文件連結所有相關的文件(負責人、長期願景、階段性目標、實驗結果、指標系統、設計元件、技術文件等等),讓大家知道如果想看最新的資訊,可以到這裡統一尋找。
  • Monthly sync:每個月 30 分鐘就夠的交流會議,非常重要! 會議前半部我們通常是各自分享上個月在首頁進行過的實驗、獲得的學習,像我們網頁版和 App 版有不同 PM、用戶端和 ML 端有不同 PM,同樣的假設就不用每個人都測一次,可以拿別人測過的失敗假設加以迭代、把成功的實驗擴大到不同產品領域獲得 Free impact。也可以帶入行銷團隊,讓驗證過的事情與 insights 發揮最大效用。 會議後半部我們會互相分享彼此下個月的計畫,除了讓與會者知道接下來可能發生的事並提早給 feedback 以外,更重要的是如果有相撞的實驗,也可以趁這個時間來互相協調。
  • Slack channel(optional):如果有比較多 Ad-hoc 的事情需要討論,也可以開群組更即時的交流。
  • Monthly newsletter(optional):如果想要升遷或增加向上管理能見度的朋友很推薦使用這方法,把每個月的進度統整和產品團隊分享,也讓 Senior Leadership 可以更容易追蹤 high-level 的進度。

根據團隊的回饋, Monthly sync 的實驗結果交流是大家覺得最有幫助的,每個月在回顧近期學習的時候都可以加速每個人的知識量。

我也會視討論議題的多寡決定這個月要取消、延後還是增加成一小時,也不強迫大家參加,希望維持這個會議在 5–10 人以內,每次都可以輕鬆的討論,不需要太正式。所以後來除了首頁,我又開了商店頁面和產品卡片的 monthly sync 😂

除了這些比較有系統的合作以外,擔任一個共同領域的負責人最忌諱的就是「為了做而做」,ownership 不只是跑跑流程,因為產品並不會因為有一群人每個月多開 30 分鐘會就變好。產品領域負責人必須時時刻刻的了解所有發生在首頁的大小事、維持文件更新、協調團隊之間的矛盾等等,都是身為一個 page owner 的責任,而這些常常是在自己團隊的 KPI 之外的。我會讓大家知道我隨時都願意幫助他們,有問題就 ping 我,希望任何想利用這裡的特色達成目標的夥伴、在執行上有 micro decision 需要做的夥伴,都可以把我當成他們可以利用的資源,盡情地發光發熱。

當然這也不是我一個小 PM 能夠做到的事,也很感謝我的 Engineering Manager、Staff Engineer 和 Product Designer 也都一起共同擔任起這個責任,讓各方需要協助的人可以獲得全方位的諮詢服務❤️

3. Impact at scale 🙌

我覺得做首頁最需要擁有的心態是:不是我把首頁做好,是我讓產品首頁變成一個「大家都可以利用的工具」,來讓產品對於各種用戶區隔都能發揮最大的價值。

前面有提到我因為太專注買家的轉換率,而遺忘了其他 Verticals(租車、租房)團隊的需求,在菜鳥時期常常思慮欠佳,常常達成了 A 目標卻傷了 B 目標,最後都很苦惱到底要不要把對 A 好但對 B 沒那麼好的功能上線,除了同事們很苦惱,我也超苦惱的!

而這其實都是因為首頁的特質很適合做 Navigation,前面有稍微提到,首頁功能常常是在引導需求明確的用戶盡快進入他要做的事的流程,完成任務。也因為首頁往往不是滿足一項用戶需求,而是多項。也因此做首頁的時候有的時候要從開發者心態抽離,退一步思考如何 enable 其他人發揮更大的影響力。

所以在這次捲土重來做首頁開發的時候,雖然我是買家團隊,80% 的時間都專注在如何協助買家找到想要購買的商品並且購買,但我和團隊還是會花其他 20% 的時間(這裡的 80/20 只是個概念而已,其實沒有去計算每個小時😂)打造首頁的基礎建設,讓我們產品迭代更好做,也間接協助其他團隊成功,以免再度踩到各種我當年還是菜鳥 PM 的雷。

這些基礎建設包括但不限於:

  • Measurement:和分析師或其他 PM 們一起討論好如何衡量成敗,也要有統一的健康指標(e.g. purchase conversion 永遠不能被傷害)來當作底線,讓大家只要不傷害指標,都有跑實驗 & 把功能上線的自由。(以前第一次做首頁的時候,很怕別人把體驗破壞掉,常常在討論階段就想把其他人的點子擋掉,但事實上是不實驗我們都不知道結果!所以最好的方法就是把指標定義好,給大家實驗自由 👼 跑完實驗再來用數據講話)
  • Design system:設計系統或原則,讓大家知道如果需要幫助用戶達成某項任務,可能可以用 A 元件做 A 方法,會比 B 元件做 B 方法還有效。
  • Tech foundation:能夠在不干擾彼此之下去去開發與部署的開發環境、齊備的事件追蹤、Code review 的流程與方法,甚至 SLA 的定義等等,讓大家有清楚的 technial ownership 卻又能彼此合作。誰負責什麼、誰維護什麼,這些都需要仰賴團隊工程師們事先談好怎麼合作。

我在做了一年半的首頁迭代之後,我也把一年半以來的所有學習和實驗結果統整成一個投影片,發到公司的公開產品群組,讓全公司都能看見我們一路的跌跌撞撞,知道我們試過什麼、有哪些成功與失敗,也藉此告訴大家「首頁真的超讚!好適合讓你的功能被用戶看見!歡迎來用我們的框架成就你的 Impact ✨」,也感謝一路以來各種幫忙的夥伴們。發出這個投影片的時候真的超有成就感的 😭

我們公司一直以來產品經理之間都有很強的合作風氣,也因為如此,我在做首頁的時候沒有遇到太大的困難,大家都把用戶放在第一位,願意看數據說話,相信彼此都是各自領域最棒的 Expert。謝謝我的 PM 同事們你們好棒!(雖然沒人看得懂中文所以其實沒人會來看這篇 😂)

因為首頁被整理得越來越乾淨、越來越容易做實驗,近半年公司大約有一半的團隊都來首頁做自己的實驗,目前已經看到了好多成功案例,我真的是打從心底替他們開心,Pricing 團隊的成功、賣家團隊的成功、物流團隊的成功都是首頁的成功 👏

希望這篇分享能夠幫助到跟我一樣正在領導能見度很高的產品領域的朋友,如果有什麼跌跌撞撞心得,也歡迎留言跟我分享 💪

謝謝你的閱讀! 有幫助的話,歡迎拍手與分享👏🏻 產品三眼怪實驗室時不時會分享其他產品管理相關文章,追蹤起來!

產品管理
產品經理
電商
產品心法
產業觀察
Recommended from ReadMedium