曾经，“非设计师谈设计”系列前两季得到了很多朋友的关注和认可，很多人特别期望看到新的一篇，时隔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之间一定会有矛盾，但是也一定有办法处理，只要大家同心协力，才能把产品做好。