[心得] PM做產品背後的折騰
Hi,大家好~
想拋磚引玉分享一些產品相關的經驗,如果有大神也再懇請指教!
--
medium好讀版
https://reurl.cc/V5Ymmn
--
這篇主要想分享的則是我們產品人在產品路上的過程,和這中間的愛恨交織……
如果你問一個產品經理喜不喜歡做產品,大概會有三種答案:喜歡、不喜歡、愛恨交織。
能說出喜歡的只有兩種人,一種是大師級、另一種是Jr.PM。
大師級可能是早已 "行至水窮處,坐看雲起時"。知道公司戰略與市場需求怎麼找一個平
衡點然後試著推進;心中對於用戶心理的琢磨也有很好的直覺,有較高的機率在規劃與設
計出產品架構時,能夠較精準的切合需求。也知道產品該迭代的方向;同時累積足夠的產
品經驗 與 知識框架結合,溝通並說服有資源支持的管理者。因為幾乎已了解所有可知的
方向、接受不可知的情況,然後以自己的生命力不斷的推動產品生長,能夠真正的發揮自
己,而這樣的情況下,產品就是自己生命力的展現,誰能不愛自己呢?
而Jr.PM的喜歡,可能是剛進去的幾個月內還沒有遭受到產品形成的折騰。只看到大家溝
通討論然後形成產品,還未能感知裡面規畫的細節;或是還在做一些執行層面的事情,只
看到產品與用戶互動的情形,還未能感受到找尋產品方向的迷惘;也可能是已經做了一些
時間的PM,但是公司的戰略網鋪的太安穩順遂,高層的注意力並不在該區塊上,所以可以
一定程度的創造,且屏除產品形成的初期給的充滿衝突與未知的不安感。
喊不喜歡的,基本上過不了多久大概就會自動被洗刷掉,或是繼續做著不怎麼樣的產品,
然後在公司的保護傘下過活,而這樣的PM基本上是做不出任何好的產品的,因為好產品需
要不斷的琢磨與迭代,必須要很大量的心思在產品路上探索。只要不喜歡就無法聚焦,不
能聚焦就無法用合理的邏輯來建構規劃,沒有合理的規劃那產品就只會是一團糨糊。
接下來就來聊聊,會說出愛恨交織的產品人們,實際在運作產品上的情況吧。
正常一個產品大概可以用底下幾個流程來區分:規劃、提案、畫面UX、設計、工程、上線
後迭代,這幾個階段來進行,不過不同公司的運作模式和實際情況會有些出入,就參考用
即可。
規劃、提案:
通常這件事還可以再分成商業分析、競品分析、老闆拍腦袋、既有的商模下推出換湯不換
藥的新產品等等。然後這件事通常是一個產品人的崩潰起始點XDD,因為通常一件事情總
會有正反兩面,隨著複雜度提升它可以分裂成更多面向,例如說一個人看書的習慣,有些
人習慣一口氣看完,有些人習慣一個章節一個章節看,有些人就是散漫著看,當這樣的習
慣你要鎖定什麼人群做出App,這時候老闆、其他協作部門可能可以提出不同面向的問題
來挑戰你,然後如果你沒能提出相對合理或是明確的邏輯來針對你的規劃來做解釋,如果
是細節還可以說回去想想,如果是主架構那就是打包回去繼續想。
不過大部分的公司,應該會偏向於老闆是優秀的戰略者,提出一個方向的概念然後由產品
PM去做Survey,然後老闆再根據你提出的資訊來做判斷跟評估,不過即使這樣,洗臉還是
很輕鬆寫意並自在的喔^.<。
然後主架構如果在被摧枯拉朽幾週訂下來之後,接下來會是使用者流程的定義,這時候你
會遇到UX部門、業務部門、設計同仁的確認,我的實際情況是這樣,簡單畫了幾個
wireframe之後,cue業務相關同仁來看,
—
我:欸,你看這樣設計OK嗎?
業務同仁:嗯...好像還可以,不過這邊比較不清楚
我:好,那我再去調整一下流程…(一段時間過去後)
我:那如果根據某元素,然後我再帶畫面到這裡,再如此如此的…
(然後討論過一段時間之後…)
我們:嗯…不過這邊可能會讓一部分的小白用戶不知道怎麼用、資深用戶看了也會疑惑。
我:好…那我再去調整過。
—
通常我們都很希望自己可以第一次就帶出無懈可擊的邏輯和脈絡,來讓產品直接上線,不
過通常牽涉到感知經驗、接觸業務、甚至是公司模式的侷限下,我們只能根據片段的合理
邏輯,往更大的一塊來探索。然後這時候我們只能當個發動點,不斷的往合理的邏輯方向
產出畫面、架構,來讓大家討論與延伸。很多時候,我們可能做了數天的邏輯推演、架構
思考,只是為了在下一個會議的時候,給業務同仁靈感 或是 跟相關同仁討論後自己的靈
感,不過通常這些探索過的方向不會白費啦,它沒有消失,只是變成事實上合理的形狀
(?),這也是產品人又愛又恨的地方,因為有時候規劃方向總是不容易一步到位,但這其
實也是迷人的地方,你在開始規劃之前,總無法想像到真正成形的樣貌是什麼,因為我們
典當思想脈絡,喚出某群用戶需求的未來。
接著在規劃方向定案之後,如果你想要讓產品變得更好,那就是繼續下一場吵架或是崩潰
修正。因為接下來是充滿優秀的用戶感觸 與 情懷的設計師,你必須和他們針對畫面上某
個東西收進下一層與否,或是用折疊或是展開的形式,進行討論與吵架(無誤),雖然有時
候會吵的心很累,不過通常設計師提出的UI/UX的想法和論點,總是會讓我驚覺到,咦?這
個用法真的有可能,我倒是沒想過。然後有些會是"X(心裡講,消音),我就覺得你這個流
程不合理"。不過越好的設計師,越願意捍衛他們的想法,而這時就要從用戶場景與邏輯
上,有時甚至拉業務單位來扛一下,在使用流程上去說服設計師,然後後續用數據來佐證
你們彼此的想法與做法,以此養成與設計師相愛相殺的關係!
接下來下一個環節,經過一開始規劃:老闆的摧殘、相關業務部門的探討。設計:與設計獅
的產品頁面搶糧(?),接下來…怎麼可以缺少產品產出環節最核心的人:工程師。
通常工程師會比較偏向於邏輯性、循規蹈矩的個性,至少在看著你的文件在進行工程時會
是這個屬性。通常會有的是,我們在寫一件事情時的邏輯如果不夠扎實,通常會被打回來
重練。例如說:一個使用場景有A情況、B情況、C情況,然後你終於明確寫好邏輯,然後給
工程師了!工程師開始實作之後,突然就反饋給了你D邏輯,然後這件事顯現後,你可能會
反思欸幹我怎麼沒有想到這麼顯而易見的情況,輕則文件補個邏輯,30分鐘就好。重則欸
你們可不可以先跳過這部分,然後你就邊崩潰邊加班把缺失的架構跟邏輯補上。
另外,可能有些拐瓜劣棗的PM太多,我有遇過RD一開始是抱著嘲諷的態度在對PM的,不過
他們卻也是很可愛的生物(?),因為只要你描述的事況,與說明的邏輯合理,他們就會開
始正常的尊重你。不會像職場政治上,有些人只是因為某些點,就diss你到底。所以好的
PM帶RD上天堂,壞的產品人RD就會讓你去搶狗糧,好像合情合理?
產品在跋山涉水、千辛萬苦終於可以上線後,產品在市況的反饋後有些功能要做調整,或
是要再迭代不同的主題,那…
我們就再把上述的流程再走過一次吧^^~
產品人讓人又愛又恨的地方,就在於你會是一個產品方向的發動點,如果你有神一般的邏
輯(正神),那你可以提著明確、弱點少的邏輯來創造出一個能存在於這社會上的服務模式
。但我們知識、認知、感受都有一定程度的侷限下,我們就只能把每一次被產品洗的灰頭
土臉的經驗內化,然後不斷的讓自己成長,隨著每個產品、每個迭代運作之後,我們建立
更多團隊的信任感、建立更多對用戶真切的感知、建立更多好的知識架構,讓我們在產出
產品的脈絡可以相對更合理,不被天生的主觀所侷限。然後由此來產出更好的產品,更多
的結合企業資源和自己天馬行空又合理的想像力,來造出一個匠心獨運的優秀產品。
在相對合理的企業環境下,當一個產品歷經千辛萬苦上線時,你看到用戶實際的運用,不
管有人對你的產品愛與恨的分享後,你就會覺得這一切真的都值得了!
願還沒成為產品大神的產品人們,共勉之~
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.161.58.7 (臺灣)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1635070206.A.E22.html
→
10/24 18:28,
2年前
, 1F
10/24 18:28, 1F
→
10/24 18:29,
2年前
, 2F
10/24 18:29, 2F
→
10/24 18:32,
2年前
, 3F
10/24 18:32, 3F
推
10/24 18:50,
2年前
, 4F
10/24 18:50, 4F
推
10/24 20:09,
2年前
, 5F
10/24 20:09, 5F
推
10/24 20:44,
2年前
, 6F
10/24 20:44, 6F
推
10/24 23:23,
2年前
, 7F
10/24 23:23, 7F
→
10/24 23:23,
2年前
, 8F
10/24 23:23, 8F
→
10/24 23:23,
2年前
, 9F
10/24 23:23, 9F
→
10/24 23:23,
2年前
, 10F
10/24 23:23, 10F
→
10/24 23:23,
2年前
, 11F
10/24 23:23, 11F
→
10/25 00:23,
2年前
, 12F
10/25 00:23, 12F
推
10/25 09:47,
2年前
, 13F
10/25 09:47, 13F