接下來的三篇文章我們把焦點轉向產品開發的執行面：『認知現況』、『設定目標』以及『擬定計畫』。前面幾篇心態面的文章如同團隊的後勤，可以為我們建構一個足夠能量的團隊，而執行面則進入團隊的作戰階段，要討論的是團隊要如何產生價值。
有閱讀前幾篇的讀者，應該會發現『事實／現況』這個字詞幾乎是每篇都會出現。因為現狀就是這麼重要的事情，現狀就像大樓的基石，有穩固的基石我們才有辦法建出一座高塔。建構產品過程中，常見的問題來源之一就是『現狀』與『認知』的落差[註1]，另一種則是突發狀況。處理兩種問題的第一個步驟其實沒什麼差別：搞清楚狀況。我們要認知的現狀有哪些呢？產品的現狀不外乎市場狀態、使用者需求、自家產品狀態、財務狀態、利害關係人等。[註2]接下來，我們試著從了解每個面向開始，去建構我們對於產品現狀的認知。
了解自己跟自己的團隊
we remain simply and necessarily strangers to ourselves, we do not understand ourselves, we must be confused about ourselves. For us this law holds for all eternity: “Each man is furthest from himself”—where we ourselves are concerned, we are not “knowledgeable people”
— Friedrich Nietzsche
講到理解／認知，首要的就是先知道自己的理解／認知能力程度。比如說我在前端／做產品的領域經驗比較豐富，那我在這領域可以設想得較他人而言來得全面，足以提供一些洞察；反之業務／行銷面就是我的弱項，在不熟悉的領域，就要靠其他人的協力幫助。誠實的面對自己優缺點，也才能誠實公平地看待自己以外的事情。
至於怎麼認識自己？把心思放在自己身上是一個好的開始，這裡不是要你自私自利，而是持續注意自己與周遭的狀態，並思考其中的關聯性。注意自己為什麼情緒起伏、注意自己的身體狀況、注意自己的思緒脈絡等。從他人眼中看自己也是一種方式，了解你在不同人的眼中是什麼樣子。最後，就是不斷地檢視，自己對自己的認知有什麼新發現，有沒有什麼矛盾衝突並解決它。認識自己的過程等同於提升認知能力的過程，對於下列各種面向的認知都會有幫助。
https://medium.com/@nifetuc/改變-從覺察開始-32f847ad0eb7
了解自己的同時也要了解自己的團隊，包含了團隊有誰、負責什麼範疇、協作方式、工作流程等等。越是了解團隊，就容易找到團隊的盲點弱點，進而提升未來產品開發的效率。
產品使用者
世界上兩件事最難：一是把別人的錢裝進自己的口袋，二是把自己的思想裝進別人的腦袋。
現今各種產品充斥市場，使用者其實掌握了非常大的主導權， 因此得到一個重點就是了解使用者、了解他們遇到了什麼困難、有什麼問題需要被解決。我們可以從兩個方面來了解產品的使用者， 一個方面是使用者研究，另一方面是 數據分析
- 使用者研究：透過使用者訪談或問卷去蒐集使用者遇到的問題，描繪出一個個使用者的輪廓。使用者研究可以獲得非常深入的洞察，通常用在產品初期不確定方向時。缺點是投入時間成本較高，無法規模化的執行。
- 數據分析：透過記錄使用者在系統的行為，進一步分析系統的使用狀態。Google Analytics 是最常用的工具。統計數據需要一定量才有意義，因此在使用者開始增長後會逐漸的提升數據分析的重要性。
兩種方法算是相輔相成，先透過使用者研究來找出需要解決的問題，或是初期功能上線後驗證這些問題是否被解決。待一定的使用人數之後用數據分析，從統計數字去了解使用者運用系統的狀況，也可以用統計數字去驗證功能是否如我們預期。當功能不如預期時，就再回到使用者研究去找出問題的根源。
使用者研究也好，數據分析也好，不要忘了我們最終的目標：透過了解使用者的狀況去做出能解決問題產生價值的產品。
所在的市場
想了解市場，做些市場調查是必須的。市場調查有很多種：包括競品分析、政策環境、市場規範、市場趨勢、市佔率分佈、現有和潛在用戶的人數及需求量、市場需求變化趨勢、商業模式與銷售途徑等。
這其中，與產品開發最為息息相關的是競品分析。關於競品分析個人的看法是這樣：理想情況下如果我們能夠百分百的了解使用者，那麼就沒有競品分析的必要，如果已經確保做出來的產品是使用者想要的，那又何必去管其他產品是什麼。但現實上我們只能知道一部分的事實，因此競品分析反而是讓我們透過不同角度去了解使用者需求的一種途徑。不同產品的不同設計有可能是他們做過許多使用者研究所獲得的結晶，因此我們要做的就是去研究，去思考為什麼這個功能會這樣子做、這樣子做的好處是什麼？缺點是什麼？有沒有符合我們的現況？能否幫助我們達成設定的目標？
競品分析另一個好處是，可以從別的產品功能來反思自己產品的優缺點。例如看到別家產品介面漂亮很吸引人，我們自己可以怎麼改善？但發現他們其實成交量很低，因為販售的產品內容品質不佳影響使用者購買意願，相比之下我們又可以如何保持產品品質。
產品狀態
前述各種面向對於建構產品的理解非常有幫助，但這樣龐雜的資訊對於決策來說卻過於累贅，我們的大腦是無法負荷這麼大量的訊息的。我們需要簡單卻有效的方式做決策的輔助，這種系統通稱商業智慧。必須先強調的是，商業智慧是了解產品狀態的好工具，但不要錯把工具當作產品本身，這工具跟其他所有資訊一樣，都只能反應產品的單一面向而已。商業智慧的資訊可以拿來『輔助』決策，我們還是需要理解資訊背後的意涵以做出可靠的決定。比如說最近口罩銷量突然很好，也許不是團隊銷售能力大增或是使用者滿意度提升，而是市場需求因為疫情關係暴增，而這樣的資訊在商業智慧上可能是看不出來的。
之所以放在最後，是因為產品就是團隊、使用者、市場交會的地方。因此得先好好掌握內部團隊狀況、外部使用者、市場的狀況，才能對產品狀態做出精確的判讀。
工程師們怎麼看產品
對產品開發團隊內的工程師來說，自家系統絕對是最核心，也最應該通透了解的部分。通過前面這些篇幅可以理解，這些系統行為其來有自，絕對不是工程師們自己定義就好。工程師除了打造堅實的系統之外，更重要的是與整個產品開發團隊一同討論，到底該打造什麼東西？畢竟我們的專業在於打造系統，但是系統該長得怎麼樣那又是另一個領域的事情了。
知識庫
如果希望團隊對產品有一致的理解，統一的知識庫是一種方法，知識庫扮演著多重的角色：幫助理解產品、定義功能規格、紀錄演變歷程。這一切有賴於知識庫詳實地體現產品的『現況』，也代表著團隊成員必須在系統行為變動時就主動的更新知識庫。沒有及時更新的知識庫會造成後續資訊的落差，產生溝通上的額外成本。
需求／反饋狀態
產品開發過程中會有各方進來的需求，處理方式如同知識庫一樣，只要是有發生過的就應該如實紀錄。此階段的重點在於詳實紀錄，以幫助後續的處理。基於專業分工的準則，建議各方(BD、客服、開發）都有個負責人來紀錄需求，以利後續執行階段處理。
開發狀態
功能開發有大有小、一堆有的沒有的細節、各種突發狀況。為了掌握開發進度，任務管理系統是個基本配備，有些團隊會更進一步把開發狀態實體化。實體化之後不僅一目瞭然，且成員也能就進度互相幫忙督促。
系統狀態
指的是產品運行的狀態，又稱作 monitoring，現在已經很多可用的服務，不管是線上要付錢的或想開源自幹都有。重點是透過監控系統狀態，我們可以及早發現系統問題並及早治療。
產品的全貌
透過上列幾個面向我們可以慢慢建構出一個產品的樣貌[註1]，涵蓋上述面向的粗略資訊，知道相關事務的負責單位／資訊在哪裡，當需要時我們就可以快速的主動取得。譬如說工程師的我較能掌握產品狀態，但對於市場相關資訊就相對薄弱，但如果知道市場問題的對應窗口，這樣在做相關功能時就能夠從那邊獲得相對精確的資訊。
套用資訊透明化的概念，許多產品團隊會把產品的核心流程圖像化的貼在公司牆上。這樣做的好處是所有人對於產品的核心有共同的認知，對於接下來的設定目標以及執行階段也非常有幫助。
摘要
- 心態面的文章如同團隊的後勤，可以為我們建構一個足夠能量的團隊，而執行面則是進入團隊的作戰階段，要討論的是團隊要如何產生價值
- 認知現狀從瞭解自己與瞭解團隊開始，減少認知上的盲點弱點逐步的進步
- 使用者研究與數據分析是相輔相成的，但我們最終的目標是透過了解使用者的狀況去做出能解決問題、產生價值的產品
- 競品分析是快速學習既有功能的捷徑，也是一個反思自家產品的好方法
- 商業智慧可以拿來『輔助』決策，但我們仍然需要理解資訊背後的意涵以做出比較可靠的決定
- 掌握產品的全貌不一定要什麼都知道，只需要知道相關資訊在哪裡，在有需要的時候即可取得
附註與參考
- 關於認知與現狀可以參考我的另一篇文章
- 其實還有兩個重要的面向分別是利害關係人跟財務狀況的資訊，但跟開發團隊距離相對遙遠因此不在本文探討。
