Selected Work / HAPPY GO App

Full Case · Consumer Product / Loyalty

HAPPY GO App:從產品重構到長期會員產品演進

會員 App 並不是一次改版就完成的產品。真正的挑戰,是從早期重構出發,逐步建立可被持續營運、擴充與治理的產品能力,同時讓會員端維持簡單的使用體驗。

2018–2026Product Management / Product HeadConsumer ProductProduct Operations
HAPPY GO App 從產品重構到長期會員產品演進的視覺摘要

Executive Summary

不是做一次 App 改版,而是建立可以長期演進的產品能力。

Challenge

從舊產品重構出發,同時處理會員體驗、營運需求、系統限制與後續產品演進。

My Role

長期參與產品規劃、需求拆解、跨部門協作、系統與營運能力設計、UAT、Production 驗證與後續優化。

Approach

重建核心會員旅程,把前台體驗與後台營運能力一起規劃,並逐步導入 state / segment / rule / priority 的產品治理方式。

Outcome

支持產品從 2018 重構持續演進至 2026,從單一 Consumer UI 擴展成可持續營運、分眾與治理的會員產品。

Context

會員產品的生命週期,比一次專案長得多。

2018 的起點是產品重構,但真正需要處理的不是把既有頁面重新設計,而是重新建立會員在 App 裡的核心旅程與產品骨架。當產品進入長期營運後,問題也隨之改變:內容如何配置、不同會員狀態如何呈現、營運人員如何管理、不同需求如何共存,以及每次 Production 回饋如何轉成下一輪產品決策。

因此,HAPPY GO App 的產品工作逐步從「前台體驗重構」延伸到「營運能力」、「分眾與規則」以及後期的個人化治理。

Problem

真正的問題,不是頁面夠不夠漂亮,而是產品能不能持續被營運。

只修前台,會把複雜度留給人

如果內容、狀態與優先順序都靠人工協調,App 每增加一種使用情境,就會增加一次性的操作與溝通成本。

只做後台,又可能讓會員體驗變複雜

產品需要把規則、狀態與營運複雜度吸收在系統裡,最後只把會員真正需要理解的結果呈現在前台。

My Role

隨著產品成熟,產品管理的重心也持續移動。

我的角色並不是只負責某一次版本,而是長期參與產品規劃與演進:從早期需求拆解、核心旅程、跨部門協作與 UAT,到後續系統/營運能力、Production 驗證、規則治理與持續優化。

這也意味著產品經理需要同時理解 Consumer Experience、營運使用者、資料/系統限制與實際上線後的問題,而不是只在需求文件完成時結束工作。

Constraints

長期產品的限制,通常不是單一技術問題。

既有會員與服務不能被中斷

  • 產品重構必須兼顧既有會員使用習慣。
  • 既有點數與會員服務需要持續運作。
  • 版本演進不能只以理想新架構為前提。

需求來源與使用情境持續增加

  • 會員、營運、行銷與合作需求彼此交織。
  • 不同狀態與情境不能無限制寫死在前台。
  • 需要在速度、彈性與治理之間取平衡。

Key Decisions

四個決策,定義了這個產品後續的演進方向。

Product Rebuild,而不是持續 patch 舊產品

先重建核心會員旅程與產品骨架,避免新需求永遠被舊結構限制。

Product + Operations Platform

會員看到的是前台,但真正讓產品可以長期運作的,是後台配置、營運流程與治理能力。

用 state / segment / rule 處理差異

把不同會員與情境的差異放進可管理的產品邏輯,而不是不斷複製畫面與特殊條件。

把 Production feedback 變成 roadmap input

上線後的實際問題不是例外,而是驗證產品模型、調整優先順序與設計下一階段能力的重要證據。

Product / System Design

產品設計不只是一張 UI,而是一組可長期演進的能力。

HAPPY GO App 產品演進:2018 重構、2019 到 2024 營運平台、2025 到 2026 個人化與治理
HAPPY GO App 產品能力架構:會員體驗、體驗邏輯、營運能力與忠誠度資料基礎
會員狀態體驗:Identity 到 State、Rule 再到 Experience
Consumer Experience 與 Operational Capability 的產品關係

From Plan to Production

真正困難的工作,通常發生在產品開始被使用之後。

每一階段都需要把規劃轉成可以被驗證的產品:需求拆解後進入設計與開發,透過 UAT 確認流程與情境,再進入 Production。上線後則持續觀察實際操作、營運需求與系統限制,把出現的問題重新分類成產品模型、規則、操作流程或技術實作問題。

這種循環讓產品不是「專案完成」,而是逐步累積出更穩定的產品能力。

Impact

產品規模成長是背景證據,真正值得呈現的是產品能力如何跟著成熟。

從約 50 萬 App 會員的早期階段,走到數百萬會員規模的長期產品。

公開資料可支持 2018 約 50 萬、2021 約 200 萬、2026 約 400 萬 App 會員的規模脈絡。但這些成長不能被單一歸因於個人或某一項產品決策,因此這裡只把它當作「產品需要承載更大規模與更複雜營運情境」的背景證據。

我更重視的結果,是產品從一次性前台重構,逐步累積成可持續營運、分眾、規則治理與個人化演進的產品能力。

Evidence

用產品演進與系統能力證明工作,而不是只展示漂亮畫面。

2018 · PRODUCT REBUILD

Wireframe / prototype evidence

早期重構素材用來證明產品重新定義核心會員旅程與資訊架構的起點;公開版僅保留產品語意,不公開內部連結與敏感註記。

2026 · CURRENT PRODUCT

Current homepage / navigation evidence

現行產品素材用來呈現長期演進後的 Consumer Experience;會員資料、點數、券與交易相關資訊均以 mock / abstract 方式處理。

SYSTEM LOGIC

Member state / segment / rule

以抽象 diagram 呈現 identity、state、rule 與 experience 的關係,避免把 backend 欄位或內部規格直接公開。

OPERATIONS

Consumer × Operations

展示會員端的簡單體驗如何依賴後台營運能力支撐,說明產品工作不只停留在 UI。

Public safety:本案例不公開可識別會員資訊、內部 URL、後台欄位、設計工具私有連結,以及非必要的精細使用活躍數據;會員資訊與交易型內容皆以 mock / abstract 方式呈現。

What I’d Do Next

下一步不是增加更多功能,而是讓規則治理更透明、更可測量。

Rule Governance

讓 segment、state、priority 與 rule 的來源、影響範圍與變更紀錄更容易被產品與營運共同理解。

Decision Evidence

持續把行為資料、Production feedback 與營運結果連回產品假設,讓後續個人化不是只依賴需求直覺。

← 回到 Selected WorkNext Case · AI Social & News Intelligence →