标签：
期待已久的《创业维艰》(The Hard Thing About Hard Things)昨天终于送到了，之所以说期待已久，是因为这是一本关于本·霍洛维茨失败经历的书——尤其是在这个充斥着鸡汤的时代，相比于「事非经过不知难」的经验教训，人们还是更愿意讲一些他们的英勇事迹。
前两天逛拉勾，看到一家企业要求随简历附上「你最成功的决策」，我当时就懵住了，一来「成功」和「决策」充满了某种宏大感，二来或许是太过微不足道，怎么也记不起那些「灵光乍现」的瞬间，反倒是一些教训，一直铭记在心：
深入思考 收获感觉
这是最让我印象深刻的。刚开始做产品时，总以为PRD写得足够细致，能考虑到各种极限条件和错误反馈就差不多了。但实际上这是不够的。
在许多小团队中，翔实的PRD并非必须品（况且再细致的PRD也会有疏漏），真正紧要的是当开发抛出一个问题时，你能以最快的速度分析问题，并给出解决方案，而不是回答说「等等，让我想一想！」，这只会让开发觉得你不靠谱。
犹记得自己最初也常厚着脸皮让开发干等，那种羞愧的滋味实在不好受。在我看来，这不仅意味着思维的懒惰，更意味着对自己所负责的产品缺乏足够的理解——本应花更多时间反复细致思考，但却随波逐流，怠于思考功能背后的使用场景，也从不对「惯常」发起质疑。
直到后来，有一次被女友问起网站导航的细节，发现我竟能对背后的逻辑脱口而出，尽管那是在我接手前就设计好了的，尽管我之前都没有深入思考过，这才令我释然而又兴奋。常听人说「产品感觉」，总觉得虚无缥缈，但其实这就是它触手可及的「初级表现」之一。
化整为零 模块思维
在设计如何在新网站中延续旧网站的某项商业功能时，遇到过这样一个例子。
背景：重做一个资讯类网站；功能：客户付费传讯的聚合页，但在呈现和交互上都区别于其他聚合页。
最初我并没有太当回事，觉得和原来一样：后台加个字段，前台再设计一个页面、加个入口，保证有曝光、能聚合就OK了。
但和产品总监讨论时，他的建议却是把这个相对特殊化的权益（功能）拆散成一组权益（功能），这组小的权益（功能）既可以组合起来成为一个和原来一样的Package，也可以单独售卖，如此一来可售资源更多了，同时又避免了单独为个别客户开发一套功能，此外对程序结构来说亦是好处多多。
这种模块化的思维令我受益良多，产品经理不应只看到眼前的一个功能，它更需要全局意识——如何在解决一时之困的同时，顺便也为今后可能出现的其他问题铺平道路。
面对需求 永不说不
这是一个艰难的事实，在一个不以产品为导向的公司中，你会发现更多时候自己像一把工具，做新功能的原因或许仅仅是因为一位销售或一个业务部门的Leader拍了拍脑袋说「别人有那个」/「那个看起来有戏」。
但这还不是最糟糕的，最糟糕的是自己曾为了强调某些需求「毫无价值」而与业务部门的同事争辩了起来，现在看来那更像是为了体现自己「产品经理价值」的无谓之举。
作为一个产品经理，跨部门协作是再普通不过的事了，因而「会做人」十分重要，尤其对于他人提出的「需求」，永远都不要说不，那样只会让对方觉得你否定了他本身，毕竟那也许是他引以为豪的创意。
告诉他「以后会做」，同时拆解他的需求，分析背后的价值，然后列入需求池中，最后，给它加上一个合理的优先级。这是我后来才学到的圆滑的做法。
做产品经理 而不是功能经理
鬼脚七曾写过类似的话，但我要说的，和他不一样。
不仅仅是用户的需求 还要满足客户的需求
这是对于平台型产品而言的。也许由于自己是运营出身，始终会站到用户的角度思考问题，因而容易忽略公司的商业需求、忽略如何满足客户的需求从而盈利。
这个产品在公司整体的产品线中的作用是什么？这个新功能对客户而言的卖点是什么？销售如何用最简单粗暴的方式说服客户使用这个新的功能？旧有的客户权益如何延续，在提升价格的同时又如何继续提升原先权益的价值？…
直到最近我才开始正视这些问题。
看过太多故事说先有用户才有客户、用户需求和客户需求发生冲突时优先满足用户，但这些都不意味着要客户不重要，客户的需求应当被同等的对待。
时常抬抬头 想想自己的目标是什么
网站开始公测的时候，产品总监问我公测的首要目的是什么，我不假思索「收反馈啊」，「那然后呢？」，「看看用户有什么反馈，改完了好上线」。
「公测的首要目的是亮相，其次是过渡，让更多的用户在新版上线前能够知道并看到，不至于让改版那一天来得太突然。」
尽管我至今仍然不完全同意他的观点（大概是我被精益思维荼毒太深了？），但他确实警醒了我：用户的感知固然重要，但上线日已定，反馈收得再多，也不可能再做大调整了，更重要的反而是在此期间你能改变的是什么——产品经理不应只是一个整天埋头于功能的经理，一个整天功能复功能的流水线零件，多抬抬头，时常想想自己该做什么、目标是什么、计划是什么。
标签：
原文地址：http://www.cnblogs.com/maiyacheng/p/4343997.html
