回到新創公司擔任產品經理，幾乎是在資源有限下進行一場精密的資源配置策略，比起大企業擁有充裕預算、寬裕時間、完整團隊，新創環境下的每個決策都要能影響公司生存或客戶，這篇會記錄近期打造從 0.5 到 1 產品的實戰心得。
一、如何做資源效益的最大化
⠀⠀
▍思考哪些是必要的事項產品經理不論在哪個環境，都是在處理：
在有限資源、需求無限的情況下，做出對公司最有價值的產品判斷。
而這件事對於新創公司更有感覺，新創公司的特點是「客戶少」，因此業務團隊為了搶下客戶，幾乎會將需求被標記為緊急，因此身為產品經理最重要的技能是建立自己的優先級框架。
優先級框架我最常使用的是「Must have」vs「nice to have」。
⠀⠀
▍劃出明確的權責線
當業務提了一堆需求，並說明他們在前線遇到了一些困難，這時我會先問「這 10 項當中，哪幾項是不做客戶就不會簽約的？」，把那條「產品能解決的線」畫出來，剩下的就是靠業務說法去談判。
這也是我在各種 PM Coffee Chat 學到的技能，明確告訴業務「10 項需求當中，有 2 項是 Must have 是簽約必要條件，我可以排入開發，至於其他 8 項既然不是 Deal-breaker，就先向客戶說暫時不會安排，但我可以協助你準備一套說法」。
資源配置一直是產品經理的課題。
資源包含工程師、設計師、測試人員、產品經理等產品團隊的時間，每一個功能都會經歷前期研究、可行性評估、效益拆解、流程規劃等，因此對於新創公司來說要不要投入資源就變成非常重要。
⠀⠀
▍符合客戶的最小可行性產品
投入後，接著另一個題目是：要做多深？
一個功能可以花 2 天做得超級簡易，也可以花 2 週做得很完善，因此對於產品經理來說要決定規劃到多麼細節以及為什麼。
這時就不得不提到 MVP 這個概念，a.k.a. Minimum Viable Product（最小可行性產品），在新創公司規劃產品時，我的產品想法包含：
- 我手上還有哪些重要功能正在評估，現在這個是最重要的嗎
- 如果我要最快滿足眼前的潛在客戶的場景，我至少要做哪些功能
- 如果我現在規劃得很陽春，會不會在可見的未來又要重改一版
- 如果下一間客戶提一個相反的場景，能不能也滿足其他人
- 如果現在投入做這個，我可能會犧牲了哪些機會
快速驗證與完美規劃的取捨，是新創很常遇到的決策，因此對於產品經理來說與其花 2 週打造一個完整的功能，不如先用短時間做出一個基礎版讓客戶使用，畢竟沒有人能 100% 把握客戶對於完整功能的想像跟自己是否一致。
⠀⠀
二、如何平衡業務和產品的平衡點
⠀⠀
▍持續和業務走在第一線
業務簽約壓力對於 B 端產品經理是很常遇到的難題，如何在滿足短期業務需求時，又不造成產品長期的技術債，是一個需要長遠眼光的思考。
我發現關鍵仍在於能否更近距離觀察客戶的真實痛點和使用場景，過程中在於提問方式，當客戶說他們需要「更詳細的報表功能」，深入詢問後發現真正的痛點是「無法及時掌握庫存狀況」，這種從表面需求挖掘到核心痛點的能力，會很直接影響產品決策的品質，也許客戶要的不一定是報表，是一個儀表版，但礙於開發時間，做一個報表也許速度最快，到這裡就會有初步的需求脈絡。
而要做到上述的事情需要仰賴和業務密切溝通，透過頻繁的交流客戶想法，才能挖出客戶到底在意什麼。
⠀⠀
▍用長期迭代的角度思考現在行為
在追求快速交付的同時，產品技術債的風險管理同樣重要，因此當業務說「能不能為 OO 客戶客製化一個 XX 功能」時，內心的產品思維就會浮起：「我能不能把這個需求做成盡可能滿足多數情境的功能」。
過往在不同公司做客製化功能的經驗，客製化有時候是向未來借債，這些技術債在未來的某天可能都要償還。
因此現在在規劃產品功能時，第一個想的都是：
長遠來看這個功能最理想是什麼樣態，假設會有 phase 1 ~ 5，那我現在 phase 1 應該要做哪些事，才會讓我未來可以做 phase 2 ~ 5
這個提前性的思考能夠大幅降低短期為了符合業務所造成的技術債，也可以更好說服工程師說現在產品在哪條路上，我發現這件事很關鍵是因為將產品長期願景描述清楚後，工程師也比較不會質疑為什麼你現在要做這個，因為他們可以理解長期產品要去哪裡。
⠀⠀
▍累積長期的產品視角
但要能夠時時想到產品的長期發展也是一件不簡單的事，代表我需要對每個功能掌握度極高，同時也要對於市場、競品擁有更多的認識，因此這也是我現在每週的工作：(1) 持續調查競品的發展動態、(2) 持續收集客戶的談判意向。
在新創公司還有一個難點是數據量不多，因此不容易做出「因為 OO 數據指標，因此我決定要做 XX」的判斷，更多是「根據 BD / AM / CS 的資訊，做這件事的效益比較高」，因此在和這些商務端同事的日常互動中，透過非正式會議可以收集到許多細微但重要的信號。
⠀⠀
三、如何維繫跨部門合作默契
⠀⠀
▍讓 BD/AM/CS 成為產品的最佳夥伴
BD/AM/CS 是產品與客戶之間的橋樑，能夠協助產品經理更好傳遞產品資訊，因此產品經理某種程度也算是一個 CS（Colleague Success），協助同事可以更好服務客戶。
我通常會做兩件事 (1) 每個新功能都會有教學手冊、(2) 每個新功能都會有 FAQ。
在教學手冊內容除非操作流程之外，也會提到「支援什麼 & 不支援什麼 & 長期會迭代什麼」，確認閱讀的人可以知道為什麼產品的限制，以及對於產品可以有哪些正確期待。
⠀⠀
▍適度滿足小幅度交付
與商務團隊合作的過程，不定時交付「小需求」也是一個維繫關係的方式，比起一昧說「這不重要我不做、這個很小我不想做」，若可以做到「小需求我可以抽空安排」會讓雙方合作更順暢。
特別是 BD / AM / CS 有時會帶一些需求進來，這些需求不一定是簽約重點，也不是 Deal-breaker，但有些是客戶覺得很擾人的小抱怨，可能每一陣子就會提一次，因此若能適度地將這些內容優化掉，也可以減少前線人員的負擔。
同時也因為產品經理展現出願意解決小需求的問題，就會讓商務端團隊更願意分享一些前線才會知道的客戶細節，像是客戶都在抱怨什麼就會仰賴 CS 協助統整，這些可以讓客戶的資訊交換維持一個正向循環。
⠀⠀
▍了解產品是一個不完美的組合
在與前線人員溝通時，有時會收到的反饋是：
- 我以為他可以支援 OO 情境，結果好像能做到的事很少
- 客戶雖然有使用，但他有提到其他延伸需求
- 有些特殊場景好像沒辦法做到，能一起補起來嗎
如何說服利害關係人接受「不完美」的產品是一個溝通藝術，我過往會用「開發時程 / 機會成本」來說服，像是：
- 我知道 A 客戶想要做到 5 件事，但我們無法保證這幾個情境其他客戶都會遇到，我們有把握的是其中 2 個場景。
- 我知道 B 功能理想要支援 3 個流程，但因為時間壓力，我們收集完各使用需求，只要先做 1 個流程就可以滿足 80% 客戶。
一樣是用 MVP 的方式，承認我知道現在不完美，但長期我們都想打造完美的產品，只是現階段的時間或人力不允許。
⠀⠀
四、總結
⠀⠀
在新創公司是一個檢視產品決策的機會，像是：
- 功能堆砌陷阱：以為功能越多越有競爭力，但其實客戶只在意某幾個重點功能就願意簽約。
- 過度完美陷阱：以為功能越齊全越好，但其實只要能達到目標，就算初期會有一些人工作業也還可以接受。
- 時間充裕陷阱：以為有很多時間慢慢打磨產品，但其實客戶一錯過有時就不回頭，因此持續和第一線保持互動，不要埋頭做產品。
產品經理的核心能力不在於擁有無限資源時能做出什麼，而在於在極度約束的條件下，如何創造最大價值。
正是因為資源有限，才被迫思考更具備 MVP 的解決方案，也才能更清楚知道什麼是當下最重要的事。
⠀⠀
如對這系列文章有興趣可以再觀看：
