Management
Product Management
經理人 [第184期]:產品經理的10堂課
反覆探索需求和想法, 確認需求後再鑽研技術及提高效能.
Part 1 產品經理的特質
要說服不同團隊去開法某項產品的功能, 必須理解組織的運作以找到及利用正確的資源.
需要做什麼? 對內與不同關係人合作, 對外定義產品價值
當團隊很大時,會把產品經理拉出來專門思考需求:
產品的一生由產品經理負責; 專案經理只負責到產品上線.
需要懂技術嗎? 技術背景替專業加分, 洞悉客戶需要四種軟實力
- 不斷學習 對所處的產業有熱情 不斷吸收新知並深入
- 同理心 親自體驗客戶面對的問題
- 溝通技巧 剛進入新團隊先花時間和相關人一對一聊聊 了解彼此的期待和溝通方式 定期分享及溝通狀態 避免模糊的需求
- 保持修正的特性 市場不等人, 沒有無瑕疵的產品, 集體確認需求
Part 2 構思產品
想替人們帶來什麼改變? 描繪產品願景, 改善了什麼, 訴求價值才能創造市場區隔
產品願景是用來激勵團隊以幫忙實現這個願景,
- 推出產品的原因 當某些群體因為侷限而產生動機時, 便有需求產生
- 推出產品後對客戶及公司造成的影響 一定要想出一個能解決客戶需求的主張, 才能試著推出產品
- 產品有什麼價值能創造市場區隔
如何辨識用戶需求? 描繪場景, 時間, 事件, 從客戶的痛點發想產品
產品的功能不等於客戶的需求, 需求是用戶對現實的不滿.
在汽車發明前, 急著趕路的人會需要一匹更快的馬 但背後的需求是更快的交通工具
客戶是花錢買你產品的人, 用戶是會反應問題的人.
當用戶非常想要而且要得起時才會產生需求.
Part 3 打造好產品
產品設計準則: 有困擾, 經常使用, 夠方便, 減法思考篩選功能規劃
好的產品有三個關鍵
- 使用者的基本需求
- 解決使用者的問題
- 使用者的使用頻率高
成本管理: 了解基本財務知識, 判斷每項資源的投報率
產品毛利 = 產品營收 - 產品成本 產品毛利率 = 產品毛利 / 產品營收 營業費用： 間接影響盈餘的費用(非製造過程的費用，例如員工薪資、租金等) 營業利益(Operating Profit Margin) = 毛利 － 營業費用 營業利益率 = 營業利益 / 營收 稅前淨利 = 營業利益 + 業外損益 稅後淨利 = 稅前淨利 * (1-所得稅率) 淨利率 = 稅後淨利 / 營收毛利率遠比競爭同業高，通常代表其產品擁有其他競爭對手沒有的優勢，有可能是單價較高，也有可能是取得成本較低
產品的最終定價必須依據產品的差異化及競爭者的反應
時程控管: 協商有共識的截止日, 設里程碑檢核工作內容
- 決定完成專案的時間點
- 把專案分成幾個子計畫
- 每隔幾週設定子計畫的截止日
- 子計畫期間必須每隔一週討論分享進度
測試回饋: 幫產品事先打預防針, 觀察用戶是否會使用, 想用
Part 4 產品行銷
產品上市後該做些什麼? 追蹤為何買, 什麼情況下買? 那一步驟讓客戶遲疑不買?
如何拉攏更多客群, 經營死忠客戶? 觀察KOL喜好, 社群活動, 用話題及回饋機制帶動銷量
Part 5 企業實戰
從0到1, 打造新產品的關鍵思維: 優先滿足核心客群, 遇變化要懂得見招拆招
溝通協調, 梳理資源分配的順序: 品質顧好再談開發新功能, 用戶體驗佳才能吸引新顧客
鑽研產業知識, 爭取認同: 找到關鍵玩家, 還要會說行話, 才能打進B2B市場
Scrum 30天學習日誌
Scrum
Scrum是一種敏捷軟體開發的方法學。Scrum在英語是橄欖球運動中列陣爭球的意思。
Scrum的核心就是"檢視"與"調整"
Scrum的目的，其實是為了要去對應需求難以在前期明確界定的專案類型。 所以Scrum將把管理重心放在需求澄清、以及需求控制上，並以時間限制的方式來做為管理的核心限制。
軟體開發的問題在於很多東西其實使用者並不完全清楚自己的需求為何，也往往不具備開發所需的專業知識。 往往得等實體出現後，認知才會更清楚。
既然使用者很可能無法一下子定義出自己的真實需求，很多東西也很難紙上靠流程圖或規格書來解釋清楚，那為何我們不盡快的做個Prototype？
這Prototype不用很完美，也不用一次就完整，只要能每次精進一些。 每次都讓使用者能多看到些東西、能按些按鈕、能有些反饋，這才會知道產品到底跟他想像的有沒有任何差異。 然後隨著逐次使用者的回饋，每次重新計畫，讓下一階段的Prototype能越來越朝向正確的方向。
Scrum的特性
Scrum是一個包括了一系列實踐和預定義角色的過程骨架。Scrum中的主要角色包括：- Scrum Master 是Scrum教練和團隊帶頭人，確保團隊合理的運作Scrum，並幫助團隊掃除實施中的障礙；
- 產品負責人(product owner) 確定產品的方向和願景，定義產品發布的內容、優先級及交付時間，為產品投資報酬率負責；
- 開發團隊 一個跨職能的小團隊，人數5-9人，團隊擁有交付可用軟體需要的各種技能。
Scrum會議
Scrum會議一共包含以下四種：
- 衝刺計劃會議
- 每日站立會議 每一天都會舉行項目狀況會議，被稱為「scrum」或「每日站立會議」。 在會議上，每個團隊成員需要回答三個問題：
- 昨天你完成了那些工作？
- 今天你打算做什麼？
- 完成你的目標是否存在什麼障礙？（Scrum主管需要記下這些障礙）
- 評審會議
- 回顧會議 每一個衝刺完成後，都會舉行一次衝刺回顧會議，在會議上所有團隊成員都要反思這個衝刺。舉行衝刺回顧會議是為了進行持續過程改進。會議的時間限制在4小時。
透過短的階段，盡快作需求上的驗證
先根據User模糊的需求，在很短的時間之內(如2周到4周間)，開發出一個可執行的版本。
而根據每次的版本，使用者(在Scrum中稱為Product Owner的人)將檢視目前版本，調整他手上的需求清單(稱為Product Backlog)。 看哪些需求要再加入，哪些需求的重要性是否要調整。 並據此在跟開發團隊討論，定出下階段要能實現或修改的功能。
每個循環都要先滿足「首要功能」。 若首要功能及早滿足，這產品甚至有可能可以提早上線。 至於次要功能，則是看時間來決定加入多少。 若開發時間到了，首要功能有達到、但次要功能有些沒完成的，也必須強制犧牲。
時間主導 無法做完的就放棄
每個周期中，必須根據Product Owner定義的需求優先順序開發，沒完成的需求就往後推移。
所以這方法的重點在於盡一切力量在時限前，提供一個符合「主要價值」的產出。
提供更多的成員自主性，但也仰賴團隊的成熟度
強調Empowerment這個字。
團隊根據每個周期的需求，自己來做工作規劃。 (也就是Scrum Backlog)
意味著工作團隊除了本業工作外，還得了解其他的專業，並得做大量的溝通與合作。
團隊整合必須很緊密
先解決最核心的需求，行有餘力慢慢把其次的需要加入。
每個周期的開始與結束，可是強制要團隊必須根據Product Owner新的需求清單檢視，檢討、重新開會，並做出下一周期的計畫。
而每次計畫都需要安排一到兩個完整工作天。 除了這以外，每天也必須有段時間做Daily Scrum的日回報與日計畫。
留言