※ 為遵守 NDA，文中敏感資訊（產品、品牌、市場、客戶等...）均已抽象化處理。
那時我主責一款 IoT 消費性硬體相關 APP，作為唯一的 APP 產品經理，負責從市場與產品分析、Roadmap、PRD、功能設計、埋點規劃、未來迭代計劃，到推動 iOS 與 Android 版本從 0 到 1 上線。過程中，我帶領 UX UI 設計團隊與 RD 團隊跨職能合作。
一開始，這是一款配合硬體的「工具型 APP」。
用戶會打開 APP，大多是因為要透過 APP 完成控制設備的任務、查看數據等。因此這類產品有一個很現實的限制：用戶通常不常打開它，且用戶的新增也高度依賴硬體銷量。所以我很早就意識到，它的成長天花板會很明顯。
我不希望自己負責的 APP 只是硬體的附屬品，因此主動提出 APP 的近中長期發展方向，規劃可獨立運作的功能，讓 APP 有能力反過來擴展硬體的使用場景，為用戶創造持續回來的理由。
然而產品上線後，隨著公司商業模式與產品方向轉變，APP 後續也需要支援更多合作方與多品牌使用情境。原本以單一品牌為主的 APP，必須逐步具備平台化能力。這時真正的挑戰就不是「做功能」，而是：
「當一個工具型 APP 要從 0 到 1 走向 N，原本的產品架構還能不能支撐下一個階段的商業與產品需求？」
以下是這段轉型中，我遇到的三個關鍵挑戰與處理方式。
挑戰一：商業模式改變，不急著改功能，先重劃架構
APP 從單一品牌產品走向多合作方情境，表面看起來只是支援更多品牌或更多使用需求，但實際上整個產品的底層邏輯都變了。原本只需要服務一個品牌、一套設備、一種主要使用情境。但當產品開始支援更多合作方、更多市場、更多設備與不同功能權限時，系統就必須開始具備更高的彈性。
1. 先確認可行性，比較不同合作與交付模式
在正式向高層提出方向前，我沒有直接拿著想像去提案，而是先從商業需求開始拆解，釐清這類需求可能對應到哪些合作與交付模式。我需要先釐清更多問題，例如：
- 這些需求是單一合作方的客製需求，還是未來平台可以複用的共用能力？
- 新合作方陸續接入時，能否透過配置與模組化支援，還是每次都需要重新開發？
- 短期交付速度、長期系統彈性與後續商業擴展之間，該如何取捨？
- 開發與維運成本是否能被對應的收費模式覆蓋？後續維護責任又該由誰承擔？
- ...等等。
而後，我先將可能的發展路徑整理為三種模式：
1. 通用平台
2. 客製化＋我方託管
3. 客製化＋客戶自管
接著與架構師共同評估各方案的技術可行性，並逐一拆解在系統架構、資料權限、版本管理與擴展性上的差異，同時估算所需的人力與時程。
在技術面釐清後，我再補齊商業面分析，包含開發成本、維運複雜度、擴展能力與長期風險，讓不同方案能被放在同一基準下比較。
當商業與技術條件都有初步共識後，高層便能依據更完整的決策資訊做判斷，最終選擇「通用平台」作為發展方向。
也因為前期先把商業需求、合作模式與技術可行性都對齊過，後續方向確立後，團隊進入討論與執行時，沒有出現太大的認知落差。過程也讓我更明確地感受到，很多產品問題表面上是功能問題，實際上是商業模式、架構邊界與責任歸屬沒有先對齊。
而當方向確立後，下一個關鍵也不是立刻進入開發，而是先把平台邊界定義清楚。例如：
- 哪些能力應該收斂成共用基礎？
- 哪些差異化需求應該模組化，而不是寫死在主流程？
- 哪些功能可以被配置，哪些功能不應該被任意客製？
- 不同合作方的資料與權限邊界又該如何管理？
- ...等等。
這些問題如果一開始沒有想清楚，後面每一個新增需求都可能變成又一次的重工。 因此，我接著建立了一份全局功能權限矩陣表，把這些原本容易散落在會議、PRD 或個人理解裡的判斷，整理成團隊可以共同對齊的規則。
2. 建立全局功能權限矩陣，把混亂先寫成規則
因為平台產品最怕的不是功能多，而是每個人腦中想像的版本都不一樣，最後就會變成一個很豐富的產品災難。所以當產品開始支援多品牌、多合作方、多市場時，我做的第一件事，是建立一份全局功能權限矩陣表。
這份表不是單純列功能，而是把系統模組、不同合作情境、不同市場設定狀態放在一起看，明確定義，例如：
- 哪些功能是全局共用？
- 哪些功能屬於特定合作方需求？
- 哪些功能會依市場規範或產品階段動態開關？
- 哪些資料與設定必須被隔離？
- 哪些模組未來可以被配置與擴展？還是只屬於某個市場或階段的配置？
- ...等等。
有了全局矩陣後，每次有新需求進來，就可以先用同一套標準進行初步判斷。這份文件不僅成為產品、設計與研發跨團隊溝通的共同語言，更是日後評估新客戶新需求接入時的重要討論依據。
3. 導入共用層與模組化設計，避免每次都重做一套
平台化最核心的架構調整，是把 APP 的能力拆成兩層：
1. 必備 / 共用基礎層：包含帳號體系、資料管理、設備連線等基礎能力。這些能力不應該跟著每個合作方重做，而是要收斂成可複用的。
2. 差異化模組層：包含品牌視覺、特定使用情境、進階功能、不同功能入口等。這些是可以依照不同需求進行組合與配置的。
這個拆法讓平台後續更像一套「可組合的產品系統」，你可以把它想像成樂高，而不是每多一個需求就另外搞出一套新邏輯。
這次調整雖然在初期增加了開發成本，但長期來看，它讓系統具備更高的複用性，也降低後續維護成本。團隊不用一直重複造輪子，可以把精力放在更高價值的新模組開發上。
4. 重新梳理資料來源與權限邊界，讓多品牌可以共存但不互相干擾
平台化後，數據也不能再用單一品牌 APP 的思維處理。原本的數據只需要對應一套品牌與設備情境。但當多個合作方、多種設備與不同市場同時存在時，如果沒有先定義清楚資料來源與權限邊界，後面很容易出現兩種問題：
1. 不同的合作方的資料邊界不清楚，影響彼此信任與管理。
2. 用戶跨設備使用時，體驗被切得太碎，無法形成完整紀錄。
因此我重新梳理資料來源、使用權限與隔離原則，確保不同合作方的數據邊界夠清楚，同時保留用戶跨設備使用的延展性。
這些問題越早想清楚，後面就越不會補破定義補到懷疑人生。
挑戰二：原始場景與跨界應用的衝突
平台化初期，因為部分合作情境與原本產品相近，所以設計與開發端沒有出現太大混亂。前期規劃好的平台架構，也順利支援了後續擴展。但後來我們遇到與原始使用情境差異較大的合作需求。
新的設備應用場景、使用邏輯與原本產品不同。如果直接把新功能塞進原本流程，會造成數據互斥、UI 呈現混亂，也會影響原本用戶的使用體驗。這時遇到的問題不是「能不能做」，而是： 「要怎麼同時滿足特定合作需求，又不破壞平台的通用性與擴展性？」
1. 依照設備狀態與使用情境，呈現對應介面
同一位用戶可能同時擁有不同品牌、不同類型的設備。如果所有設備資料都混在同一套介面裡，用戶很快就會搞不清楚自己現在看到的是哪一台設備的紀錄。
因此我規劃讓 APP 根據當下的設備狀態與使用情境，呈現對應的功能入口、使用紀錄與操作內容。也就是說，APP 背後的帳號與基礎能力可以共用，但用戶在畫面上看到的情境需要被清楚區分。
這個設計解決了一個關鍵問題：
「底層可以共用，但前台情境不能混用。」
對平台來說，共用是成本與效率。
對用戶來說，情境分開才不會造成使用與理解負擔。
2. 數據頁以分頁方式呈現，讓多設備紀錄可切換、不混雜
除了當下使用設備的情境外，用戶也可能想在沒有連線設備時查看過去的使用紀錄。
因此在數據統計頁上，我規劃以分頁方式區分不同品牌或設備情境。用戶不需要時刻連線設備，也能自由切換查看不同設備的歷史紀錄。這樣做的好處是，用戶可以在同一個帳號底下管理不同設備，但不同設備的數據不會混在一起。
這裡身為曾是 UX 設計師的我會這樣判斷：
「當用戶腦中認為它們是不同情境，產品就不應該硬把它們塞進同一個畫面邏輯裡。」
因為很多時候，平台方會因為想追求共用性，把所有東西都統一在一起。但對用戶來說，過度統一反而會變成混亂。
3. 規劃出合作方可選的品牌專區，讓商業內容不干擾主流程
對合作方來說，他們需要品牌展示與商業轉換。對用戶來說，他們只想在需要時看到有幫助的內容，不想一打開 APP 就被推銷到懷疑人生。
如果直接把這些內容放進主流程，會影響用戶的使用體驗。更麻煩的是，不同合作內容混在一起，也會讓產品主線變得不清楚。
因此我規劃了合作方的品牌專區。當用戶進入特定品牌的設備時，可以看到與該合作方相關的商品、內容或服務。合作方也能在當中展示自己的內容，而不會干擾 APP 原本的核心體驗。這讓廠商與用戶間有了比較好的平衡。
4. 面對認知落差，讓客戶在實測中發現問題
在合作過程中，也曾遇到雙方對使用情境理解不一致的情況。
當時我判斷，如果直接用文件或會議強硬說服，成本會很高，效果也未必好。因為有些想法不是聽不懂，而是還沒親手用過，所以很難感受到其中問題。
於是我選擇另一種方式：先用低成本 MVP 驗證假設，讓純口頭討論轉到實際操作與體驗。等合作方在實際操作中了解到想像與現實的落差後，我再拿出事先準備好的調整方案與客戶溝通。後來，雙方更快對齊了較合理的產品方向，也省下大量來回說服的成本。平台架構也因為這次經驗變得更有彈性。
這件事給我的提醒是：
面對很難用口頭說清楚的產品分歧，不一定要急著證明誰對誰錯。有時候，讓大家用最低成本看到問題，比講幾十頁 PPT 更有效。
當然，前提是這個 MVP 的成本必須可控範圍內，否則就不是驗證，是自掘坑洞，還附贈免費開發團隊。
挑戰三：多版本、多市場並行時的「組合爆炸」
IoT 產品還有一個常見的情況：用戶更新了APP ，不一定會跟著更新設備；設備更新了，APP 也不一定就會同步更新。
更麻煩的是，硬體端一旦進入量產規格鎖死、韌體已燒錄、供應鏈排程改不起的生產交付階段，很多東西就不容易再調整。這時 APP 往往會變成比較有彈性的那一方，也就必須扛下更多相容性的責任。
因為當 APP 使用情境越多、覆蓋市場越廣，版本管理的複雜度就會快速上升。
再加上不同地區市場的合規差異，例如註冊登入方式、第三方登入、隱私政策、用戶條款，甚至部分功能的審查標準都可能不同。這些看似細節的事情，最後都可能會變成版本管理的一個坑。
1. 先把每種版本組合的行為寫清楚
我先定義各種版本組合下的行為規則，例如：
- 新 APP 遇到舊設備時，哪些功能要顯示？哪些要隱藏？
- 舊 APP 遇到新設備時，要如何提示？
- 某些功能在特定市場不能開時，替代流程是什麼？
- 用戶同時擁有多種設備時，數據如何切換？
- ...等等。
這些問題沒有捷徑，只能一個一個釐清並寫清楚，與團隊對齊。聽起來很瑣碎，但這份文件後來成為每次改版前的重要依據。每次要新增功能、修改設備邏輯或支援新情境時，我們都可以回到這份版本行為表確認影響範圍。
如果沒有這一層，團隊運作會很痛苦，用戶使用過程也會一起陷入這個痛苦的豪華套餐...！
2. 把合規確認前置，而不是開發完才補
多市場產品還有一個容易被低估的問題：合規性。
註冊登入方式、第三方登入、隱私政策、用戶條款、應用商店審查規範，每個市場都可能不同。尤其當產品同時支援硬體、設備連線、數據紀錄與智慧化功能時，提交審查前要確認的項目會更多。
所以我把「合規性確認」放到功能規劃的第一步，而不是等開發完成後才補文件、補條款、補說明。同時，我也為不同應用商店與市場維護上架素材 checklist，提交前逐項檢查，例如：
- 上架文案是否符合市場規範。
- 隱私政策與用戶條款是否對應該地區版本。
- 第三方登入與註冊方式是否符合當地要求。
- 功能截圖是否與實際版本一致。
- 需要揭露的設備、數據或智慧化功能說明是否完整。
- ...等等。
這些事情看起來不有趣又繁瑣。但只要漏掉一項，被應用商店退件一次，就可能延後上架，尤其 APP 又是與 IoT 設備綁定的，進而影響後續合作方的交付與商業承諾。
因此把合規確認前置後，原本會不斷膨脹的版本複雜度，才有機會被整理成比較能掌控的管理節奏。
我後來也把這件事當成一個產品重要原則：
「凡是會影響上市時間、合作承諾或法規風險的事情，都不應該被放在開發尾端處理。
不然最後它一定會在最緊急的時候回來找你！」
回頭看
這段經歷，這款 APP 從一個被硬體牽著走的工具型產品，逐步轉變成能支援更多合作情境的平台型產品。
而我自己的角色，也從一開始專注在單一產品的功能規劃與使用體驗，逐漸走到需要參與商業模式討論、把控產品發展方向，並與合作方共同推進產品落地的位置。
對我來說，從 0 到 1 再到 N 的過程中，最深的體會是：工具型 APP 要平台化，最難的從來不是多做幾個入口、幾張頁面，或換上幾套不同的品牌皮膚。真正難的是，當產品開始承接更多合作方、更多市場、更多設備與更多商業期待時，PM 能不能把原本混亂、分散、一次性的需求，整理成清楚的規則與可複用的系統；同時也要能把這些判斷轉化成高層能決策、團隊能理解、開發能落地的方案。
這兩種產品型態需要動用到的能力很不一樣，也讓我意識到 PM 的工作沒有固定樣貌，它會隨著產品所在的階段、商業定位與組織需求不斷變形。而重要的是能在每一次變形中重新判斷產品該往哪裡走，以及團隊該如何一起走到那裡。