POC 陷阱:努力解決一個錯誤的假設
在產品開發過程中,POC(Proof of Concept)可以說是產品的基礎,沒有基本技術,有沒有產品,那新產品的技術是什麼呢 ? 這篇文章分享我們如何透過實體模擬,驗證我們是否有能力做出潛力達成體驗與財務目標的產品,以及過程中學到的事。
當空間多塞 20%,就能多賺 20%?
如果一個 100 坪的空間能容納 120 位工作者,相較於只能容納 100 人的空間,就等於提升了超過 20% 的坪效。
「坪效」對以租金收入為導向的產品來說,是最關鍵的指標。一個場域能創造多少收入,基本上可以拆解成三個變因:單位數量 × 翻桌率 × 價格。
我們的商業模式,是讓彈性工作者租一個位子來工作,因此空間能容納多少人,就會直接決定營收的上限。
但問題來了,空間內的人越多、座位越密集,體驗就越差,甚至可能讓使用者卻步。即使座位數增加,若使用率下降,實際的坪效反而不升反降。這就是我們在做這項 POC 時,最核心要解決的問題:
如何找到一個「體驗不會明顯下降」的最小空間單位?
低成本 POC 的方法
為了解這個問題,我們開始研究空間中每一個可能影響體驗的細節,包含走道寬度、分區設計、座位排列、桌子大小。這些看似微小的差距,累積起來會造成極大的影響。
例如,一張 60x100 cm 的桌子與一張 50x90 cm 的桌子,單看一兩張差異不大,但放大到整個場館規模,就可能影響到每月數千甚至數萬的收入。
初期的測試方式很簡單,我們用一張大桌子配合隔板,模擬不同尺寸的桌面,並找來不同身高與體型的人試坐,模擬各種使用情境,例如:邊吃飯邊工作、桌上擺著筆電、咖啡、水壺等,看在不同空間條件下,體驗上有什麼差異。
這就是一個低成本、高靈活度的 POC 測試方式,先快速收集回饋、掌握極限邊界,避免過早投入硬體開發。
為何要在這麼早就定義規格?
這麼早投入硬體規格的細節,是因為我們知道,硬體一旦做下去,修改成本非常高,也很花時間。與其等到做出正式產品後再調整,不如在 POC 階段就先定義清楚能接受的極限範圍,對未來產品的穩定性與效率都有幫助。
因此,在技術研究階段的目標很明確:
先在實體環境中建出一個空間模型,設定空間內所有重要元素的長寬高、距離關係與排列邏輯,並確認它們是否能創造「最低可接受的體驗」。
而這些建模測試,都還只是基礎,後續還要加上裝飾物、顏色..等,來證明我們有能力設計出一個空間,它能在體驗與坪效之間找到適當的平衡點。
多餘的技術,來自於假設的執著
在過程中,我們其實也出現過一些爭論,例如:是否還能再把桌子縮小 10%,進一步提升坪效?
但隨著測試進行,我們發現某些規格一旦縮小,體驗就會滑落,但如果不縮小,坪效似乎又不太足夠。這讓我們重新回到一個根本問題:
我們到底在消除什麼樣的不確定性?
我們一開始假設:「產品的成功,取決於是否能同時做到高坪效與好體驗」,並以此推演出極限壓縮空間的需求。但事後回頭看,我們發現這個假設忽略了同樣重要的「翻桌率、定價」。
如果翻桌率、定價結果能比預期的再好一點,那麼可租借的單位數,就不需要這麼多,一樣可以達到財務目標,甚至能創造更好的體驗,也就是說:
我們可能投入了大量精力,在解決一個「不一定會發生的事」。
這就是產品開發中的 POC 盲區,在產品還沒上市之前,我們過度擔心某些假設成立後可能帶來的風險,進而在 POC 階段就試圖「一勞永逸」解決它。
但實際上,這個假設不一定會成立、也不一定需要這麼早被處理,產品本身也許就能承受那樣的風險。
為了避免一個風險,反而過度優化了沒那麼重要的東西。
POC 的目的不是完美,而是釐清假設
總之,為了打造出符合我們期待的空間體驗,我們逐步驗證各種細節、釐清每一個設計背後的假設,避免再次掉入技術陷阱,這次的經驗也再次提醒我:
POC 的目的不是設計出完美產品,而是排除問題的不確定性