在產品開發過程中，為了有效和不同角色溝通，軟體PM經常需要準備各種形式的資料，例如簡報、範例圖、流程圖、表格....，林林總總的資訊，目的就是要確保每個人對同一件事、同一個產品規格有足夠且具體的了解。資料準備越齊全，即便日後經過人員交替、任務交接，也能遵循相同的規則繼續前進，讓影響降到最小。
一個產品從發想到形成規格，勢必經過一段演進的過程，嚴謹一點來說，應該會有User Story、 Functional Map、Flow Chart、Wireframe、Prototype ...等產出，最後彙整成一份完整的產品規格書，而本篇文章將依據我過去的工作經驗，以及收集各方資訊後，分享一些製作Flow Chart(流程圖)的心得。
職棒場上有一句名言 : 贏球治百病。意思是說球隊若是能贏球，很多缺點都可以被忽略，相反的，一旦球隊處於戰績低迷狀態，團隊向心力(也就是所謂的休息室氣氛)就會成為重要的檢討項目。
團隊建立的過程大約會歷經幾個階段 :
在產品的生命週期中，必須先歷經新創期、成長期後，才能進入穩定發展的成熟期，但多數新創產品在進入成熟期之前，就紛紛失敗退出市場，這些失敗的寶貴經驗，都是下一個新產品茁壯發展的養分。我曾經待過兩家新創公司，過去的職涯也參與多次大大小小的新產品、新服務開發，這裡列出幾個我認為導致產品失敗的關鍵，一方面讓自己作為警惕，另一方面也提供給大家當參考，避免重蹈覆轍。
雖然產品失敗的原因很多，且環環相扣，我還是依自己的經驗，盡量將之歸納為三個關鍵，分別為市場認知、團隊認同、執行力，這篇文章就先來談談新產品在導入前，對市場的掌握程度，產品人或多或少知道，或聽過STP理論，我想從中來進行一些簡單的剖析。
身為產品經理，經常需要製作product roadmap來說明產品的相關資訊，但到底一個好的product roadmap需要包含哪些資訊呢? 工作多年以來，我發現一直很難找到一個明確的定義，似乎每一個主管要求的都不太一樣，大家所繪製出來的roadmap形式也各有不同，直到最近在國外網站上看到一篇相關文章，原文標題為Product Roadmap: Key Features, Types, Building Tips, and Roadmap Examples，看完後覺得心有戚戚焉，決定分享一下我的心得。
首先，什麼叫做product roadmap? 顧名思義，它叫做產品地圖，目的是指出產品所在位置的一份地圖，而它要勾勒的相對位置，是產品願景和公司業務目標之間的距離，因此我們通常會用一條時間軸，再加上幾個重要的產品要素來組成。
由於我自己對於新產品的未知挑戰十分感興趣，因此曾經待過兩家新創公司，PM的職涯過程中也曾負責不少新產品開發案，當然，失敗的經驗不在少數。產品開發的過程中，經常會有一個通病，就是想做的事情太多，能運用的資源太少。
Slcak是目前當紅的辦公室通訊軟體，當時它選擇深入開發三件最重要的功能：搜尋、同步和檔案共享，順利切入商用領域。它的共同創辦人 Stewart Butterfield 曾引用 Gmail 發明人 Paul Buchheit 的話「If your product is Great, it doesn’t need to be Good」，說明產品必須專注將某些重要的事情做到極致，解決用戶的核心問題，讓使用者彷彿登山一樣，感受到山巒的起伏變化，留下深刻的印象，至於其他核心以外的功能，則暫時不需要太在意，因為更多並不等於更好。
