我以前是这么做产品的...

大学期间，在代码方面，学习一些开源模板，改改discuz、wp，开发过一两个专题/活动网站（php+mysql），包括前后台的搭建。我不是一个特别聪明的人，但是至少在那几年，我是一个肯花时间去学习的人。
　　除此之外，最多的时间应该就是构思产品了吧，下面聊聊我在大学期间所主导的两个产品。

1、校内活动平台

---

很明显，这是一个提供给大学生查看校内活动的产品。萌发这样一个想法其实很自然，就是经常会有一些同学宅在宿舍不愿出去，没有好的途径了解到外面有什么适合自己的活动。虽然学校还有一些很传统的宣传方式，比如活动方线下摆摊宣传、教学楼LED轮播宣传。
　　所以当时就很迅速地把设计图做了出来，并且想着做一些结合学校特色的功能（当然这些在第一个版本的时候没有上），而且还做了一些自认为很酷的营销手段。然后就在当年的11月份上线了（这个时候正好是学期中，校园活动比较多的时期）
上线之后，不断留意数据，吓了我一跳，这个页面的PV普遍在几百上下，好的时候去到了一两千。而我们原本的资源网每天的PV都普遍有4w左右，在资源网不断引流、以及微博不断宣传的情况下，数据却还是如此惨不忍睹。
　　后面因为临近毕业以及社团换届的事，这个产品也就没怎么更新迭代了。后来想想，其实这是一个很低频的需求（当初意淫般的觉得大学生嘛，随时都有兴趣去了解学校都有些什么活动的啦）；而且本身我们网站的主要功能是提供各种电影综艺学习资源给学载，享受校内网的高速下载。所以在用户触达层面上，虽然学校有80%以上的用户知道我们的资源网，但是知道活动平台的不及5%。以一个班集体为单位，也就是说只有2/3个人知道。而且对于这部分学生，如果是本身对专业性活动、比赛感兴趣的，他们获取这些信息的途径想必更快，比如老师的告知。

2、校内订餐平台

---

记得饿了么，美团外卖这些产品在广州的流行，还是在13年底。
　　在12年底的时候，就萌生过类似这样一个产品的想法，主要是学生经常在下课走路10~15分钟去到学校饭堂的时候，在某一些档口还要再排队10分钟才能点餐。同时也有一些人不愿排队而选择去其他地方消费。所以为了解决学生能吃到自己心仪的饭菜，饭堂也能尽可能地售卖更多的商品。我就设想过这样一个场景：顾客在APP上点餐，拿到号码牌，会提示当前还有多少个人点餐，还需要等待多久。这样用户就能根据自己的时间，到达档口取得商品。而商家就需要有一个后台查看用户的订单，并为顾客配好菜，等待顾客前来取货。当然这里所有的交易行为都是在APP上实现。
　　后来，这个想法就始终只是一个想法，在召集一些朋友讨论后，发现了不少不问：
1、商家愿不愿意在现有模式下，去接受这种新颖的方式，就算你告诉他这样或许能增加订单数，但是这种改变也有可能会使得他要多招一两个人，支付更多的薪资。所以这种冒险的行为，在没有强而有力的补贴之前是很难推动的（这个之后在饿了么、美团外卖上体现得淋漓尽致，甚至是在打车届的UBER、滴滴快的也一样）
2、如果仅仅是针对校内餐厅，是否真的有这个必要性，当时学校是禁止外面的商家送餐进来的，记得当时我有一次开摩托车帮外面的商家送餐进学校时，还要表现得十分淡定。所以由于当时学校的规定，这方面的拓展性就十分有限了。（后来，饿了么美团外卖这些的兴起，学校也开放起来了！！！！！）
3、当然，学生才是这个产品的主要用户，从目前的饿了么/美团外卖的情况来说，已经验证了这个需求是切实存在的。
4、交易，当时想过用户在APP上就可以充值到校园一卡通上，然后我们的系统可以跟学校的校园一卡通系统对接，进行扣费。为了了解这个可能性，我还专门跑去一些硬件的Q群里去请求一些前辈，实现的可能性有多大。当时的结论就是：完全不可能！因为这些数据信息是记录在硬件芯片上的。但是直到后来.................支付宝支持校园一卡通充值（有的可以直冲，也有一些学校由于芯片等各种原因，还要到线下的设备自助处理一下）
　　后来这个想法也就搁置在一旁了。
　　大学时期为之努力过的两个产品，虽然最后都没能活下来。但是却带给了我一些启发：

1、需求要反复推敲，带入场景一起思考，不要想当然

2、有些产品注定只能服务一些产品，比如纯银提到他以前做过的网易相册，也比如我提到的活动平台，单纯的提供活动信息是无法使得产品活下去的。所以产品模型在一开始就是有问题的

3、你没发现，不代表他们不存在

4、就算你发现了，而且当时也还没有成熟的产品，但或许你当时的资源远远无法去推动这件事