06 | 如何做好产品立项

精选留言(15)

• 

  拾叔

  感谢二爷分享。我们现在业务主要对公业务，类似于BBC业务，所以几乎没有页面设计相关等相关直接toC的功能，更多的是偏后台的交互及流程设计方面，包括内部的以及外部的。目前立项的参与方比较多，我们名字叫信审会，包括风控，法务，资金，开发，测试，财务……都需要参加，而且都有一票否决权，信审委员会基本都是各条线总经理或者关键人，目前，基于金融监管目前的态势，CEO也加入了，可见信审会的严酷程度。为了能顺利通过信审会，我一般会提前将大部分东西准备好，比如上会PPT，业务推荐报告，协议框架，风险政策，运营操作手册等，PPT，推荐报告，风险政策等一定要精确，并且不能遗留关键环节的待定点，要不极有可能被一票否决，其他的，可以不用太详细，但是思路一定要清晰，随时准备被challenge。信审会后还可以有部分调整，但是不能有核心内容的大调整。
  信审会后，我们就成立相关的项目组，在进一步细化业务相关内容后，我们就可以开始做系统需求分析，然后技术沟通，需求评审等。
  

  2018-08-13

  

   15
• 

  laulend™

  首先，感谢二爷分享。
  这里想咨询二爷几个问题。
  先说下背景，现在我们公司所有的用户端的立项都是由我们运营发起的，比如：大活动立项、营销功能立项、用户端产品功能立项等等…
  现在比较苦恼的是：运营在花心思和精力在对内和对外的营销资源的时候，还得去跟进设计的样式、产品的流程和逻辑、页面的交互是否合理、研发功能实现的情况、当然，还有最终测试验收的环节等等，这里面除了精力以外，还有对各个模块的职能情况的了解不够深入，总有一种感觉自己在做运营的同时兼职着项目管理的岗位，但自己又不是一个合格的项目管理，甚至对项管没有什么经验，连一个菜鸟也算不上……
  现在的问题是：
  1、在产品太弱没想法的情况下，我该如何去协调这些资源并且运用好除了产品这个节点的人，或者我该不该自己上手解决一切，做个规范出来？如果我上手解决一切，我需要付出什么？
  2、我想用好研发、运营和设计团队，有没有什么好的建议可以让我把这一套流程打通？
  3、最重要的一个问题，我立项完之后，往往会忘记去跟进产品的东西，该如何去避免，目前我唯一能做的就是三个节点的把控，一是在设计稿完成后做最终确认，二是在需求评审的时候做把控（产品是没有prd文档的），三是在最终测试上线环境做把控。但是感觉这些还不够，还是无法将一个项目很好的推进下去，挺头疼的。我不知道我的把控是否合理？如果不合理，还需要增加哪些关键节点的把控？
  4、运营做立项人是否合适？
  5、如果合适的话，运营需要具备哪些技能和付出什么能扛得下这个活，把项目很好的推进下去，且尽量少问题的角度上线。
  问题有点多，期待二爷能看到并给予回答

  2018-08-13

  

   6
• 

  『婷半仙』

  二爷您好，在上期产品会客厅您解答我的疑惑时说“也可以等产品开发完再招运营”，但是这次项目立项提到一定要和运营，客服等等部门达成共识😨，所以其实项目期初就应该有运营对不对？？？！！！（可能上期的提问我也没有表达清楚，我们Boss对运营思路也是打算走一步算一步，等产品销售出去再打运营牌）

  2018-08-13

  

   3
• 

  高天泽

  总感觉产品经理是-权责利-岗位三元素不对等的职业

  作者回复: 其实大部分岗位都是，但自己是可以想办法去找平衡的，比如对产品来说，主动承担更多责任，利用非职务影响力去解决更多问题，都是好办法。

  2019-05-23

  

   2
• 

  Novelty

  此前自己在立项的过程中，老是忘记通知业务支持部门，比如此前上线了一款分享即可一元秒杀的活动，却忘了把产品的规则通知客服和品质管理部，导致客服应对咨询没有任何准备，而品质管理部依然按照正常经营期间的质检标准进行出库，导致许多用户都收不到一元秒杀的产品，对我来说绝对是一次惨痛的经历。后来自己也养成习惯，在立项前我会把整个链路从开始到结尾仔细梳理一遍，看看都会涉及到哪些部门并且事先思考他们的业务诉求点。
  
  此外，正如二爷所言联合利益也很重要，我也遇到过因为项目对某些部门没有任何利益点只能增加他们的工作负担导致推进速度缓慢，所以作为产品人还要深入整个协作网络去理解涉及到的每个业务方的需求，这样才能形成一个稳定的项目共同体。
  

  2018-08-16

  

   2
• 

  Dylan

  作为一个新人，最近遇到的最大的坑就是没有平衡好各方利益，结果做出来的方案总会有某一方表示反对。经历过几次这样的事情后，我终于试着事先先问清各方的诉求和倾向，然后锤炼创意出方案后统一各方集中讲解，点到各方利益。
  入职一个月，终于开始试着理解一些产品经理的日常，继续带着脑子努力！

  2018-08-14

  

   2
• 

  刘祯

  立项这事和需求评审也是相辅相成的关系，我还记得上一季专栏聊到的如何做好需求评审，道理殊途同归，二爷也提到了产品规划，其实每一步都是紧密相关的。归根结底还是做事的责任心与做人的态度。
  
  上次二爷的建议是，自己要承担责任，统筹资源，做好表率，即便项目可能有各种情况，我们也要肩负起作为产品人的责任，这才是专业表现。
  
  从实战来看，我就经历过项目并未完全想清楚而后期撕逼的事件，的确很伤情绪，并且容易挫败团队凝聚力，最好的状态是大家每做一件事都能进步并且配合更好，显然，只有我们认真做事，才对得起自己。

  2018-08-13

  

   2
• 

  sylan215

  1. 二爷说的立项会，真的非常赞同，前期充分合理的撕逼，对项目后期的开展至关重要，但有时，大项目老板说了算，自然立项，小项目产品经理说了算，资源只是为了被调配。作为业务下游的测试，真希望所有产品经理都能看到这篇文章，能够重视立项，以及立项时对各个部门的信息同步。
  
  2. 配合时间长了，立项会就相对容易的多，因为哪个产品经理靠谱，哪个不靠谱大家心知肚明，只要是真正为项目考虑的人，很容易达成默契。对新人来说，前几个项目中的态度很重要哦。
  
  3. 目前参与的立项，有两个经常出现的问题建议关注：
  一个是立项的项目目标是什么，本次的阶段目标是什么，害怕那种没有轻重缓急一股脑堆需求的产品经理；
  另一个是需求涉及的各种场景请考虑清楚些，不要一被挑战就各种没考虑到，各种不耐烦，各种看看再说。
  
  以上，测试一枚，望沟通交流，公众号「sylan215」

  2018-08-13

  

   2
• 

  ecanfly

  『婷半仙』有点钻牛角尖啦，项目构成中，有运营人员的时候，你才需要在立项的时候和她/他达成共识，都没这人呢，直接忽略这个角色呀。

  2018-10-04

  

   1
• 

  v.

  感觉二爷写的这些都是教人怎么做事的，不只是在做产品的地方有用。当然，做产品就是做事，怎样做最好怎样收益最高，都是值得思考的；也就是说，产品经理不只是做一个产品，这也是高级初级PM的区别。

  2018-08-13

  

   1
• 

  EinBetterMan

  我理解的所谓立项就是粗略版的需求评审，不知准确不准确

  作者回复: 粗略的需求评审是立项的一部分，立项更重要的还是同步目标，锁定资源，公布计划。

  2019-08-16

  

  
• 

  和小胖

  利他心态。

  2018-12-26

  

  
• 

  幻想

  好文，这篇是我看得最认真的一篇了。

  2018-09-22

  

  
• 

  不知

  平衡利益是很有必要的，作为公司里有部分权限的人我拒绝过不少其他事业线的产品需求，主要是做了这个需求对我来说完全没好处的同时具有一定的风险。
  
  主要我负责的又是金融业务产品十分讲究稳定性，对方也没有能力说服我，所以就over咯。

  2018-08-15

  

  
• 

  Jerry

  立项和需求评审在我的理解中，本质并没有太大区分，不知道二爷怎么理解的。

  2018-08-14

   1

  