9、
我做的第一款APP是2011年的“网易云相册”，除了网易相册移动端之外，还提供手机相册一键备份，以及私密的相片群服务，试图解决好友间的相片共享。
APP发布后不温不火，用户评价不错，但也并没有口口相传。要知道低频次工具做到“口口相传”是特别不容易的一件事，关键还是“低频次”。
商业模式
相册服务，本质上是低频次的存储服务，也是大众化的基础服务。基础服务就应该由大平台来提供，而不是独立品牌产品。移动端产生相片的便捷性，以及换手机的频繁性，让相片备份成为一个全民需求，但它和网页端相册的硬伤一模一样：访问频次低，付费意愿弱，存储成本高。单独做云相册一定是赔钱买卖，必须得放在一整个生态里去通盘考虑，用亏损换取生态圈的收益。
所以做云相册的多为手机OS，或是Google这样的独角兽。
回到2011年，网易在移动端既没有平台也没有战略，自然没有做大云相册的计划。它只是网易相册这个边沿部门，刷存在感刷经验值的小项目，小打小闹，不成气候。我作为部门老大当然不甘心，强行拓展了私密相片群服务——这是接下来产品架构要谈到的话题。
产品架构
从商业模式顺下来，云相册有三种场景。一是网易相册移动端，在手机上浏览相片，比如把相机拍摄的旅行相片展示给朋友。
二是手机相册的一键备份。通常先备份再删图，存储卡永远都是不够用的。换手机时更加需要转移相片。而一键备份带来的衍生需求是，如何更好地索引海量相片，通常通过“城市”与“人物”两个维度。前者需要一个城市数据库，后者需要图像识别技术。
三是私密群相册，憋提了，死得很惨。我的解决方案是快速建立一个共享相册，用密码进入，交互还算是轻盈，但最后得到的教训是，用一个低频应用去解决另一个相关联的低频需求，我脑子进水了吗？低频次需求或者靠专用APP解决，比如BUMP；或者靠高频应用的附属功能，比如QQ文件助手；才容易在记忆中建立关联，偶尔出现需求时能想得到你。
每一款产品都有自己的天然属性，云相册的天然属性就是相片存储，而不是相片共享。拓展产品边界也不是不可以，但低频应用就是不可以。
最后说到具体的设计，没什么难度，只要在架构上定义好核心场景与主要功能，再做好交互减法就行了。烂产品往往是因为臃肿，而臃肿又是因为产品设计不甘寂寞自作多情。
PS：昨天有人请我看看最新版本的Google Photos，在传统云相册的架构基础上，新增了图片处理工具。5年过去了，云相册还是玩不出多少新花样来，“产品边界”就是这么冷酷。
运营体系
存储类产品的运营主要是推广，抓住“一键备份，永不丢失”这个卖点，但我既没有推广经费，也没有推广团队，大公司体制也不允许我自建推广团队。本打算靠网易相册本身的用户完成冷启动，再口口相传出去，我显然高估了这个效果，半年才做到几十万激活量，对于网易来说可以忽略不计。
回想起来，当年如果猛攻一键备份，又有足够的资金推广，未尝不能做大体量。用户的回忆都存放在这里，使用时间越长则黏性越强。但体量越大则亏损越大，商业模式早就判了这个项目死刑，唯一的价值是给团队刷刷经验值，作为接下来我创业的铺垫。
