在年底阶段，作为不到11人的小团队，我们自己完成了垂直内容社区的移动端、小程序、和PC门户的重构和优化工作。

时光飞逝，做产品经理社区这件事我们已经坚持做了6年，而以创业者、产品经理的身份，我们把社区这件产品也做迭代做了6年。

回过头看来，我用：给“产品做减法”来总结我们这6年的产品工作。

即为什么我们都说做产品很难做减法？

我认为越优秀的产品经理有两种，第一是给产品持续做减法再做加法；第二是在一开始就不会做的很复杂，就是一个严格的MVP产品。

可是MVP中文的含义是一个最小化产品，仍然是一个产品设计的概念，但许多产品经理就算经过缜密的需求调研，产品产物仍然是一个非常臃肿的，不算MVP。

只是产品经理经验、能力限制下的最小化产品罢了。

结合自己的经验，我分享自己以CEO的身份做PMTalk这款产品和以前在大厂公司里做产品的区别，相信许多产品经理可以以此为鉴，避免踩坑。

产品经理出身，一定会经常在公司里提到“资源”，但是背后的逻辑其实关心的少。比如投入资源周期有多久？大概产出会有多少？

实际上几乎不可能在PPT里规划出来的，同时我相信很多公司都没有CFO出身，只能从产品规划的角度考虑。

而实际上，一个项目立项后就是实打实投入。比如现在团队的研发人员有10个人，那么每个月人力工资、硬件成本、办公成本是多少我们可以算得出来的。

无论多优秀的产品经理，项目研发计划和实际场景是肯定存在偏差的，一个系统建设可能包含若干个前端应用、或者后台系统，并不只是一个APP就完事了。

所以在大厂里上班，只要项目立项了，往往PM感受到团队资源是充沛的，做产品设计完全不会考虑到底要在几个月把这个系统务必建设完，只知道当前首先要做什么功能，满足领导或者客户需求，至于以后的功能有没有其实不重要，仅仅停留在规划纸面上

可是对于企业的老板，那就是每天都在烧钱，很多项目启动，完全是因为外部的风口契机被立项，下阶段效果不好就立马被解散，也是因为烧钱的原因。

即使有用户，不能收支平衡的功能一定不要。

02、产品基础功能的理解深度不够

每一个行业下的每一个业务，都会存在一个产品的基础功能。

比如打车软件用户端是发布需求、选择车型、支付，司机端是接任务、完成任务，收款。

如果基础功能理解不够，可能就把功能范围做大了，比如优惠券、营销这类功能可以放在主功能之后再提供。

▲图片来自网络

做产品经理一定要记住的：核心功能跑通了再做功能优化与细分场景补全。

虽然我知道很多产品经理把公司当做个人试炼场，但是却浪费了产品研发的时间。

03、一个产品至少需要2年以上的打磨

到底是呆在办公室坐了几年的产品经理，还是真的做了实际案例的产品经理其实完全是两码事，真正从0到1做一个产品或者从1到10，至少需要2年时间，版本至少发布10次版本以上，才能够逐渐贴合用户诉求、市场需求。

对于刚毕业的产品经理，其职业生涯在一家公司的时间不超过1年，刚刚上线或者内部测试就离职了，比较空闲的产品经理一年都做不出几个能落地的需求。

因为一个产品设计到UI设计再到研发测试上线，至少都要几个月时间。所以我们经常会看项目排期任务密密麻麻，就是这个原因。

要想拥有长时间打磨产品的机会，还得找到业务是正向发展的公司，公司能有正向营收，老板才舍得花钱养团队，我们才能有时间做数据分析、观察用户使用情况，决定减少什么功能，需要做什么功能。

04、PMTalk做了什么减法？

前面提到了，我们经过6年的运营，逐步清楚了垂直的内容社区里面用户的核心诉求是什么，做了4点改变

1.接受现实，遵守用户习惯

最近2年不尝试产品设计的创新，清楚认识现有资源在技术能力、实现的短板，找到在内容社区的核心场景就3点：

一个是写内容，一个是看内容、还有一个内容的交互。

2.数据差的功能模块全部砍掉

对于内容几乎没有新增、或者用户访问数据不高的功能板块全部砍掉，而不是迭代。

即使这个功能可能曾经花了很多精力投入，但数据效果差就仍然选择砍掉，并不是考虑如何去优化了。

3.让用户操作简单、快，选择少

之前过于臃肿的首页，给予用户太多选择，比如之前首页有用户加地区群，但实际上我们给的社群要超过6个地区，导致首页布局非常满。

▲改版前

现在改版后，只保留3个类型的社群，地区群入口仍然存在，只是用户没有那么多选择了。

▲改版后

4.核心路径的功能打磨

刚提到了用户的核心路径是发布文章、看文章，所以我们重构了编辑器，找到了市面上比较易用的编辑器，在基于编辑器开源下做了二次封装，虽然编辑器不是自研，但是通过前端交互和文案，增加了用户投稿的意愿。

▲PMTalk编辑器

增加了用户快捷导入、富媒体悬浮窗口hover效果，关闭了用户自定义话题，加快了用户话题选择。

另外一个稳定的编辑器是一个非常高成本的功能，如果产品不是内容创作为主，建议不要自研编辑器，会非常多的前端资源和测试时间投入。

5.UI还原和BUG修复

我曾经写过一篇文章，要是公司没有测试，那么产品上线后一定少不了修修补补。我们团队就是通过这样修修修补补来完成产品的迭代，还原了超过200个页面的UI，以及超过100个细小BUG，提升用户体验。

▲记录的优化池

比如下面提升用户操作体验，随时可以回到首页，增加跳转。

6.增加访问速度

对于互联网产品，速度是核心，用户不会等待，所以在文章和社区访问加载上我们都做了优化，让用户打开文章的速度尽可能在1.5秒内。

7.优化文案

这里的文案不仅是系统的文案，还有用户填写的展示文案做优化，比如摘要的显示长度、标题长度等，为了更好的阅读体验进行优化，在排版上更好看。

增加默认头像、默认文案，让即使数据不好看的页面，体验不差。

05、产品经理为什么很难做减法

第一是产品经理机会太少

▲生命周期

为什么产品经理很难做减法，因为很多产品经理还没有到做减法的时期就走了，产品减法至少要处于产品从探索期到增长期或者增长期到稳定期的跨度，有生命周期的跨度才会对产品进行改版。

而生命周期需要产品经理不断观察数据，日常数据环比和新版本数据环比，才能得到结果。

版本之间的间隔时间往往至少1个月或者2个月，那么自然能够有做减法的机会就特别少了。

第二是产品经理做YY需求非常多

比如同样是一个活动报名系统，有的产品经理设计的用户路径会如下

活动详情-活动支付-支付成功

其他的产品经理可能会如下

活动详情-门票购买-选择门票-支付成功-消息通知-线下签到

第二个方案的路径就会很长，虽然结果给业务方提供了：”活动创建的需求“，但是实现的时间并不一样，并且开发也会认为合理。

可是如果自己做老板，就会选择上者，因为省钱。