从PD、UED、产品本身和运营角度谈如何做产品

曾经，“非设计师谈设计”系列前两季得到了很多朋友的关注和认可，很多人特别期望看到新的一篇，时隔2年，征得胡斐同意，他携重磅文章再次出击，结合自己在淘宝积累出的经历和感悟，对产品方方面面有了更宏观的认识。本篇共分4个部分，从PD、UED、产品本身和运营角度谈起如何做产品，整个文章一气呵成，让我读起来有种畅快淋漓的感觉，希望读者您也能喜欢，欢迎评论。

（1）要栓在一起的PD

我在淘宝做了几年运营，观察大大小小的产品设计、活动策划，发现运营和PD*，和UED*在沟通上总是会出现各种问题。好的是，我们一直在不停改进这种沟通，双方都在不停做改变，力图走到一起。我试图从几个方面，思考这个问题。

做互联网产品和其他产品不一样，电视机生产出来卖掉就好了，顶多有个售后服务，互联网产品不同，做出来了要有人用，做的好才有人用，而且还要不停优化修改，产品做出来只是第一步，后面还有一大帮运营的人跟着呢。一直以来，有种矛盾的想法：

PD想做什么呢？PD总会们希望运营能提出一些大的长远一些的想法，这样通过一个大的产品、一个项目就彻底解决问题。PD希望产品都做成模块化， 到处可以重用，为每个活动设计不同的产品是很辛苦的事儿。PD希望开发资源足够，而这不可能，于是PD希望去排项目优先级。PD希望自己做一些有成就感的 东西。

而运营不这么想。运营希望产品做出来马上就可以用，想怎么用怎么用，不要每个小改动都要重新走流程立项开发。甚至，运营最不希望听到的词就是“立项”，因为一立项，就是一个月以上，要PRD评审要评估要开发要评估要测试要PK上线，上线了还要修bug……运营希望PD能告诉他“可以做”，告诉他 “怎么做优化能节约时间”，可是PD很少这么做。运营希望PD能跟项目捆在一起，和自己一样关注项目进度，可是大部分PD没有做好后续跟进。

甚至，很多时候运营会和个别好说话的工程师搞好关系，一些小改动就直接做掉了。这是没有办法的办法，但是不应该。

更可怕的事儿还不是这个。运营提出的需求是A，到PD写成PRD的时候变成了A’，开发的时候，开发的理解是B，开发过程有些变动，做出来是B’，甚至，产品同学会自作主张删掉一些细节需求，而有时候这正好是核心功能点。而运营从A’到B’的变化，根本不知道。

结果就是：设计 =》 上线 =》 改=》 改=》 设计二期 =》 上线=》 改…… PD被烦死，运营崩溃死。

这就是问题所在啦：大家没有拴在一起，大家目标不一样啊。

那天商户平台的同事给我讲起他们的做法，我觉得很可取。要知道，商户平台近年出的产品很多，大都也很靠谱，看来效果明显。

他们PD和运营业务线绑定，PD和运营背着同样的KPI，产品达到什么目标、什么时候上线大家一起商量。这样，PD和运营不再是“提需求”和“接需求”的甲方乙方关系，自然融洽很多。不好的是，PD和PD之间会因为资源等等问题发生争抢。

PD关注产品进度和效果。当产品成了自己的事儿之后，PD就不会觉得“这是他们运营的项目”，他就会很关注。并且，产品上线，PD会主动要求数据 监测，关注效果，因为这是证明自己成绩的方法，如果有问题，不用运营说，PD就会主动帮你做掉了。不好的是，如果这时候缺乏沟通，PD很可能会“自作主 张”。

要注意，PD和运营就算拴在一起，毕竟还是坐在不同位置上，思考的方向肯定不一样。PD要对产品做的修改，如果没有经过运营同意，很可能会做成“阉割版”。

最直接的例子，我们说过的“限时打折”产品，就是产品觉得“预告”功能做起来比较复杂，自作主张去掉了。上线了运营才知道。没有“预告”还“限时打折”什么啊，核心功能没有的产品就是阉割版。经过紧急沟通，“上线”到真正“能用”，推后了整整1个多月。所以解决办法很简单：

运营在提需求的时候，把核心功能，也就是删掉谁都不能删掉它的功能，标出来。

产品上线之前，一定要有运营验收。测试团队看的是“能不能用”，运营还要看“好不好用”，甚至，UED也应该加入到验收工作中来。

我想，做互联网产品，运营和PD之间一定会有矛盾，但是也一定有办法解决，只有大家同心协力，才能把产品做好。