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

[abc5555 (前進)]

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

--

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
噓 hegemon: 然後勒，你這篇除了無病呻吟以外有什麼重點嗎？
推 f26724309: 呃 這是心得分享還是流水帳啊
→ loadingN: 重點就是文章發出來了
推 TAKADO: 謝謝從不同角度分享產品開發，但希望撰寫邏輯可以再清晰一
→ TAKADO: 點，讀下來有點隔靴搔癢，讓人get不到重點的感覺。
感謝反饋，因為PM比較多會遇到各種面向的情況，所以想說描述清楚一些
之後會試著文字再精煉些

→ brandy: 感覺是流水帳。
→ DrTech: 快速看了一下，一點MVP的精神都沒，當為了小事執著而忘了
→ DrTech: 商品的目的。
→ DrTech: 另外，工具與方法論真的不是工作的重點，達成目的才是重點
→ DrTech: 。
認同，但PM在做某些團隊溝通和產品探索時，沒有這些工具還是窒礙難行

同時我也認同MVP的精神，但我這幾年的產品路走下來，即使想MVP，但可能面對的情況是
組織內其他人根本還沒有這層意識，這些都需要PM去做溝通跟說明的橋樑，台灣的產品環
境並不如外國那麼成熟友善，所以才需要很多的溝通說明

→ exodus29: 真PM的價值也不是在做WF, 可能版主對PM應該有的價值有
→ exodus29: 誤解
→ lazarus1121: 這位的風格一直都這樣吧，高來高去，套任何產業都行
推 wulouise: 我只有一個問題，pm要負責wf?
推 a11062012: wireframe通常是UX designer 負責
邏輯上是UX，但台灣的環境、跟組織意識大部份(我遇過的互聯網公司)都由PM來負責QQ
※ 編輯: abc5555 (223.137.108.233 臺灣), 08/08/2022 12:01:21
※ 編輯: abc5555 (223.137.108.233 臺灣), 08/08/2022 12:04:50
推 lego1984: 推～也是 PM, 看完有感
噓 alongalone: Nothing important