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

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

--

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能交付很完整且鉅細靡遺的文件，這時有賴於產品人能和自己的團隊明確溝通，做產品這件事情的本質和我們要前往的大方向，而不要讓團隊成員糾結在你哪個小邏輯怎麼沒寫好，那邊怎麼漏了。基本上是以快速進行、互相信任包容的方式在推動產品，這樣讓做產品的過程中阻力降到最低，大家在一個又一個產品或功能上線後，就能夠越來越有默契，團隊關係也能越來越好。

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

小結

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

--

感謝反饋，因為PM比較多會遇到各種面向的情況，所以想說描述清楚一些 之後會試著文字再精煉些

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

邏輯上是UX，但台灣的環境、跟組織意識大部份(我遇過的互聯網公司)都由PM來負責QQ