我做的第一款APP是2011年的“網易云相冊”，除了網易相冊移動端之外，還提供手機相冊一鍵備份，以及私密的相片群服務，試圖解決好友間的相片共享。

APP發布后不溫不火，用戶評價不錯，但也并沒有口口相傳。要知道低頻次工具做到“口口相傳”是特別不容易的一件事，關鍵還是“低頻次”。

商業模式

相冊服務，本質上是低頻次的存儲服務，也是大眾化的基礎服務?；A服務就應該由大平臺來提供，而不是獨立品牌產品。移動端產生相片的便捷性，以及換手機的頻繁性，讓相片備份成為一個全民需求，但它和網頁端相冊的硬傷一模一樣：訪問頻次低，付費意愿弱，存儲成本高。單獨做云相冊一定是賠錢買賣，必須得放在一整個生態里去通盤考慮，用虧損換取生態圈的收益。

所以做云相冊的多為手機OS，或是Google這樣的獨角獸。

回到2011年，網易在移動端既沒有平臺也沒有戰略，自然沒有做大云相冊的計劃。它只是網易相冊這個邊沿部門，刷存在感刷經驗值的小項目，小打小鬧，不成氣候。我作為部門老大當然不甘心，強行拓展了私密相片群服務——這是接下來產品架構要談到的話題。

產品架構

從商業模式順下來，云相冊有三種場景。一是網易相冊移動端，在手機上瀏覽相片，比如把相機拍攝的旅行相片展示給朋友。

二是手機相冊的一鍵備份。通常先備份再刪圖，存儲卡永遠都是不夠用的。換手機時更加需要轉移相片。而一鍵備份帶來的衍生需求是，如何更好地索引海量相片，通常通過“城市”與“人物”兩個維度。前者需要一個城市數據庫，后者需要圖像識別技術。

三是私密群相冊，憋提了，死得很慘。我的解決方案是快速建立一個共享相冊，用密碼進入，交互還算是輕盈，但最后得到的教訓是，用一個低頻應用去解決另一個相關聯的低頻需求，我腦子進水了嗎？低頻次需求或者靠專用APP解決，比如BUMP；或者靠高頻應用的附屬功能，比如QQ文件助手；才容易在記憶中建立關聯，偶爾出現需求時能想得到你。

每一款產品都有自己的天然屬性，云相冊的天然屬性就是相片存儲，而不是相片共享。拓展產品邊界也不是不可以，但低頻應用就是不可以。

最后說到具體的設計，沒什么難度，只要在架構上定義好核心場景與主要功能，再做好交互減法就行了。爛產品往往是因為臃腫，而臃腫又是因為產品設計不甘寂寞自作多情。

PS：昨天有人請我看看最新版本的Google Photos，在傳統云相冊的架構基礎上，新增了圖片處理工具。5年過去了，云相冊還是玩不出多少新花樣來，“產品邊界”就是這么冷酷。

運營體系

存儲類產品的運營主要是推廣，抓住“一鍵備份，永不丟失”這個賣點，但我既沒有推廣經費，也沒有推廣團隊，大公司體制也不允許我自建推廣團隊。本打算靠網易相冊本身的用戶完成冷啟動，再口口相傳出去，我顯然高估了這個效果，半年才做到幾十萬激活量，對于網易來說可以忽略不計。

回想起來，當年如果猛攻一鍵備份，又有足夠的資金推廣，未嘗不能做大體量。用戶的回憶都存放在這里，使用時間越長則黏性越強。但體量越大則虧損越大，商業模式早就判了這個項目死刑，唯一的價值是給團隊刷刷經驗值，作為接下來我創業的鋪墊。

#專欄作家#

純銀V，蟬游記創始人，人人都是產品經理專欄作家。前網易網站產品部總監。一個文藝加文筆好的產品經理。

本文原創發布于人人都是產品經理，未經許可，不得轉載。