PTT評價

[心得] PM做產品背後的折騰

看板Soft_Job標題[心得] PM做產品背後的折騰作者
abc5555
(前進)
時間推噓 6 推:6 噓:0 →:10

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 留言評論
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.161.58.7 (臺灣)
PTT 網址

MoonCode10/24 18:28你說工程師偏向邏輯性、循規蹈矩 這什麼刻板印象

MoonCode10/24 18:29要做好一個產品 團隊哪個人是可以沒有邏輯的在做事?

MoonCode10/24 18:32把某個職位做些特殊的形容(可愛生物?)完全沒有意義

abccbaandy10/24 18:50樓上,老闆/PM阿,很多時候聽到他們的想法真的想跑...

j095832208010/24 20:09真的這麼不爽 pm 建議 rd 自己兼 pm

BignoZe10/24 20:44滿多PM過得滿開心的呀

carzong10/24 23:23不好說吧,如果比起很多奇奇怪怪的 ops/mkt/pm,工程師真

carzong10/24 23:23的是平均起來比較有邏輯的。

carzong10/24 23:23“要做好一個產品,團隊內哪個人是可以沒有邏輯的”,問

carzong10/24 23:23題是一間公司裡面,沒有邏輯的人,比你想的還多… 只是

carzong10/24 23:23因為工程師都只碰到工程師跟PM而已..

MoonCode10/25 00:23當你懷疑別人沒有邏輯的時候 先確定自己不是那個魚

MDay5610/25 09:47辛苦啊!!

fanatics556611/01 01:09會補文件跟Skip的PM還是給推。看過 PM Lead 不補文

fanatics556611/01 01:09件,叫RD直接改Code,事後還裝失憶,讓RD改規格重

fanatics556611/01 01:09工的廢渣PM