[心得] 產品人的坑-wireframe與產品流程

軟工

1252

產品人的路也走有一段時間了,分享當初剛到新創時遇到的震撼教育供大家參考~

--

Medium好讀版: https://reurl.cc/vWgAky

--

前言

在產品路上走久的人,一定遇過各種坑,不管是從被別人指著鼻子罵、或是規劃許久的產
品最後難產、又或是遇到各種設計陷害或是光怪陸離的事,只要你也是矢志於推動產品面
向的世界的人,那麼這種坑,對我們來說,初期遇到一定躲不掉,因為很多事情都超出了
認知邊界,只有經歷過並納入經驗庫後,才有能夠參考的邏輯框架。

因為在推動產品時,你可能沒注意環境的限制、文化的影響,或是產品在推動時剝奪到他
人的資源種種,當然我們做產品有時真的無法面面俱到,但在做好一個產品人的立場下,
把傷害減到最低,也是在組織架構內累積正向的信用循環的一個很重要的點,有時候產品
架構想法再好,只要身邊的人、事、物無法有效的協助,那產品的效益可能會大打折扣,
更嚴重可能危害到團隊氣氛或是自己的職涯。

所以整理過去踩過的坑分享給大家,一方面是有架構的彙整這些情況,看能否從中再挖掘
到讓自己成長的東西;另一方面是產品人的業務層面過廣,所以藉由自己拋磚引玉讓大家
收集不同的資訊,在某些決定上可以有不同面向的思考,盡量達到雙贏或是減少雙輸的情
況。



這次分享的是我第一次進新創,就給了自己一個巨大的當頭棒喝。


衝突


那時候是一個資深UI從頭diss到尾,起因在於以下幾個點:

wireframe畫的很爛,那時候還在用axure各種剪貼圖片,沒有理解到wireframe的更本質
的意義,一些對齊排版都不懂,也還不會做互動
對於產品的運作流程沒有很全面的認知,當時還不知道persona、roadmap、user jouney
等一些產品流程中的知識工具
交付產品求快次求嚴謹(這看產業別,不一定是壞事)
衝突最後越演越烈,後來UI不想和我合作,直接抹黑我不想溝通、沒有交付文件,後來主
管保了UI,而我最終的情況是黯然離開團隊。


人物背景


UI是從嚴謹的電商出來,對於團隊夥伴的能力又非常的要求、個性也比較苛刻,和她合作
的溝通成本非常的高。她對於產品UX的部分可能有片面的理解,但其實也不全面,但我也
因自己能力、經驗的不足,沒辦法有邏輯的跟她說,哪些階段並不適合做哪些事情,連吵
架怎麼跟別人吵都不知道(笑),所以很理所當然的她就會覺得我不配與她共事。

我的主管也不是做產品出身的,是某科技大廠的專案經理,所以也不知道如何做產品。他
掛的title是產品總監,之前在大廠內並沒有著墨IT產品的推動與運作,比較多的技能是
在大組織底下的政治生存,實際和產品比較相近的經驗只有聽過梁寧的產品思維30講,很
毛骨悚然吧…但其實這也是一般新創環境的日常,至於新創整體情況比較細節的探討,未
來會做一話特別跟大家分享~

我那時候的產品資歷大概只做一年多、待過一間公司,對於做產品的知識、經驗、架構所
知甚少,對於商業、組織該如何推動產品也是很有限的認知。

前公司雖然做產品的方式和流程有點胡來,卻是構築了獲利的商業模式與架構,所以在某
些產品的運作流程上是值得借鑑的。

而從那個架構出來的我,自然看新創很多事情會覺得不對勁,但又不夠厲害,無法條理的
說明階段性任務的運作,所以在團隊中做事情就處在很彆扭的狀態,知道某些環節不對,
但又說不上來。發生了衝突,卻沒有足夠經驗能說明化解,導致情況變得惡性循環。


狀況分析


我自己在做產品時,基本上還是以產品推進為最終目的,所以很多的溝通妥協在所難免,
但基本上不是一個跟別人對著幹的人。也許遇到過度偏激的設計師和自己能力不足是一種
極端處境,但還是會習慣反省從這樣的架構中,自己領悟到了什麼,盡量不要再犯同樣的
錯,或是避免這樣的處境。

現在的我來看過去衝突中的幾個點:

1.wireframe
2.產品運作流程
3.產品交付

然後從這些點中,試著從更廣的視角來看這些很基礎的產品概念。


wireframe


因為也經歷了不少組織,我遇過這幾種做wireframe的情況:

1.我的Jr.PM時期,很少在用Axure原生的線框,大部分都用截圖的方式在拼貼,整體來說費
時費力,因為那些拼貼的調整不像axure本身的元件調整這麼方便。

2.老闆說用ppt做也沒差,設計師接的做APP或網頁文件是ppt…這某種程度上是驚世駭俗的
,因為ppt無法呈現Figma 或是 Axure的靈活性,基本上是做線圖的人痛苦、做圖的人也
痛苦、做工程的人也痛苦。

3.當開會工具、設計文件、工程文件,全部混在一起,這種做法會有點混亂。

4.和主管開會時,就要把所有的互動完全做出來,但是沒有先確認過流程和架構,所以主管
只要更動需求,一個小小的功能你可能就要花幾個小時修正…

5.交付的互動性、相關的元件尺寸比例都要有,包括對於欄位的限制、狀態等等。

wireframe其實只是一個交付想法的過程,怎麼做對我來說是一種進到組織內嫁雞隨雞的
概念,因為wireframe背後對市場的觀察、產品的戰略、組織的協調,這些才是產品人的
重點,而如果在討論過程中,你大量的精力都是花在調整wireframe,那真的很浪費產品
人的才智,與其調整線圖的邊邊角角,或是哪邊沒對稱到,哪邊互動沒做好,不如思考這
個功能要運作的本質是否真的切合用戶的需求了。

我遇過很要求wireframe的公司,要做成幾乎是高仿真原型,但是這樣PM交付的時間卻是
一般時間的4~5倍(也許更多),而且這不是為了客戶端需要先進行驗證,只是那個產品總
監個人的堅持。我現在還是不能理解。因為市場上類似的競品,開發功能數量已經比該公
司多了好幾倍了,但公司做產品的速度還是上不來;另一部分,人員離職後交接成本很高
,因為新進的PM大部分沒有這種原型功力,平均PM在位時間可能不到半年,所以才能符合
原型需求,人就又要離職了,後來就繼續無限循環;我從商業跟組織角度真的無法理解這
種高仿真的意義在哪,還是我太弱了還不能意識到這件事的高深(怕)。

而在當時新創的情況下,被要求做互動式的wireframe在那個時空背景下其實是沒有必要
的,因為整體產品架構甚至是公司自己本身的商業模式都還沒有建立,在這種產品末端的
地方做細節的刻鑿確實有點過頭了。


產品運作流程


在那時候另外一個被diss的點在於沒有其他的產品知識工具,後來意識到這件事情其實頗
重要的,因為產品人是一個產品戰略、框架、用戶體驗的發動點,我們必須有條理地說明
產品想要走到哪,為什麼。

通常在已經有商業模式營利狀態下的中大型公司,對於產品人來說會比較有運作空間,因
為組織的權利比較有機會下放給你去運作,如果公司的產品有一定的生態系的話,那對於
要跨出Jr階段的產品人比較有機會看到不同產品間的串連,還有公司在產品上的戰略布局
與運作,但這種位置有時候看求職的緣分、另外一種是自己的緣分,因為自己如果沒有拉
高層次看產品,也可能永遠只是一個功能型的產品人。

而在有辦法挖掘、探討的情況下,我通常會用數據說明目前產品的情況,因為數據在某些
程度上是神聖的第三方,避免產品被大家的主觀拉扯而無法進行。接著再用路線圖去定義
我們可能要前進的方向,讓大家可以比較明確知道產品要前進的方向,要討論或定義戰略
也能夠有錨點可以討論,不會讓討論偏掉。

如果產品比較穩定,但求發展出新的機會,我會用user journey或是更深度了解和相關業
務同仁的單位討論,覺得怎麼樣的發展方式可能會比較好,取得某些程度上的共識之後,
再進行產品推動,這樣有時候產品運作會順利很多。


產品交付


在當時的新創公司,被要求什麼東西都交付的很嚴謹。但自己經過大大小小的公司後,且
思考過產品與商業的本質,我的看法是:絕大多時候,交付的邏輯要嚴謹,但文件就盡量
清楚明瞭,有模糊點就口頭溝通,除非已經合作的很熟悉,不然別指望PM能交付很完整且
鉅細靡遺的文件,這時有賴於產品人能和自己的團隊明確溝通,做產品這件事情的本質和
我們要前往的大方向,而不要讓團隊成員糾結在你哪個小邏輯怎麼沒寫好,那邊怎麼漏了
。基本上是以快速進行、互相信任包容的方式在推動產品,這樣讓做產品的過程中阻力降
到最低,大家在一個又一個產品或功能上線後,就能夠越來越有默契,團隊關係也能越來
越好。

我要加個但書,在現有的產品環境下,有時候確實公司策略或文化下,不一定好達成,但
我們還是要清楚並知覺地與產品團隊溝通,才能即使不在這樣的環境下,漸漸地推往我們
想要的處境與方向。


小結

當時那樣的情況,心情上確實是很巨大的打擊。一方面覺得遇到了神經病,另一方面也深
感自己在產品路上還欠缺了很多很多的能力,也因為當時的情況不斷地去思考各種不同的
工具、運作模式在產品路上該怎麼執行,漸漸地會發現自己可以在不同的團隊組織下去溝
通,也可以在不同的產品階段採取相對應的手段去幫助組織推動產品,而且也能凝聚團隊
討論該進行的方向。現在即使換環境、或是換團隊還是會不斷地去思考怎麼在這些流程上
達到最大效益,這是一個需要不斷調整和思考的概念,希望有幫助看到這些議題的大家。

--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 223.137.108.233 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1659878472.A.E18.html
hegemon1樓然後勒,你這篇除了無病呻吟以外有什麼重點嗎? 08/07 21:58
f267243092樓呃 這是心得分享還是流水帳啊 08/07 22:19
loadingN3樓重點就是文章發出來了 08/07 22:21
TAKADO4樓謝謝從不同角度分享產品開發,但希望撰寫邏輯可以再清晰一 08/07 23:09
TAKADO5樓點,讀下來有點隔靴搔癢,讓人get不到重點的感覺。 08/07 23:09
感謝反饋,因為PM比較多會遇到各種面向的情況,所以想說描述清楚一些 之後會試著文字再精煉些
brandy6樓感覺是流水帳。 08/07 23:12
DrTech7樓快速看了一下,一點MVP的精神都沒,當為了小事執著而忘了 08/08 00:31
DrTech8樓商品的目的。 08/08 00:31
DrTech9樓另外,工具與方法論真的不是工作的重點,達成目的才是重點 08/08 00:32
DrTech10樓 08/08 00:32
認同,但PM在做某些團隊溝通和產品探索時,沒有這些工具還是窒礙難行 同時我也認同MVP的精神,但我這幾年的產品路走下來,即使想MVP,但可能面對的情況是 組織內其他人根本還沒有這層意識,這些都需要PM去做溝通跟說明的橋樑,台灣的產品環 境並不如外國那麼成熟友善,所以才需要很多的溝通說明
exodus2911樓真PM的價值也不是在做WF, 可能版主對PM應該有的價值有 08/08 08:00
exodus2912樓誤解 08/08 08:00
lazarus112113樓這位的風格一直都這樣吧,高來高去,套任何產業都行 08/08 08:32
wulouise14樓我只有一個問題,pm要負責wf? 08/08 08:51
a1106201215樓wireframe通常是UX designer 負責 08/08 10:01
邏輯上是UX,但台灣的環境、跟組織意識大部份(我遇過的互聯網公司)都由PM來負責QQ
lego198416樓推~也是 PM, 看完有感 08/09 09:47
alongalone17樓Nothing important 08/09 21:22
更多心得
[心得] (代po)2022軟體工程師面試心得
[心得] 2022年初面試心得
[心得]軟體職缺面試準備
[心得] CloudMosa/Google/Kronos/Netskope/其他
[心得] 朋友一個有點好笑的面試經驗
[心得] 2022 後端面試心得
[心得] Google TW SWE 面試心得
[心得] 2022 面試心得