产品新人第一次独立负责新功能的上线,如何才能hold住？.pdf

产品新人第一次独立负责新功能的上线 ，如何才能hold住 ？ 之前在一篇文章中看到 互联网公司给实习生做的是比较不费脑或繁琐的工作 ，竞品分析和收集用 户反馈已经算高级的了。如果这种观点成立的话 ，那我做的事情应该算是略高级的了 ，我一般都是 进行竞品分析、收集用户反馈 ，并且给出方案 ，能被评审通过的方案就采纳执行。 前几天和部门的产品leader一起吃饭 ，谈论了不少产品相关的话题。他 我对产品的理解是比较到 位的 ，理论知识也比较扎实 ，但是缺少项目实践经验 ， 回去让我自己自己考虑一个方案 ，并且自 己负责跟进方案的落实。于是我这个产品新人便有机会自己负责一个小的功能的上线全流程 ，功能 上线后还是很有成就感的 ，也反思总结了下功能从0到1的全流程 ，望各位前辈不要见笑。 一.需求调研 需求的来源一般有产品本身、数据分析、竞品、用户反馈、PM自发、来自BO SS这几类 ，但并不是 所有的需求都要进行满足 ，首先应该去分析辨别是真的需求还是只是伪需求 ，是否为刚需 ，需求 频次如何 ，需求的用户基数有多大。然后也需要结合产品的定位 ，公司的资源 ，开发实现的难易 程度 ，优先级 ，性价比去将合理的需求转化为产品需求。 我们这个产品的需求来源于用户反馈 ，通过用户反馈的数据发现确实是有此需求 ，并且根据数据来 看需求的人数较多。于是我便又去调研了几个直接竞品(与我们产品的业务模式重叠性较大 ，目标用 户相同)的处理方式 ，根据分析调研后的数据得出这个需求应该需要满足的结论 ，于是我针对两种典 型的用户采用了两种不同的处理方案 ，考虑到类型二用户的特殊性 ，我又将类型二的用户细分为两 种方案 （暂定为方案a与方案b ），方案初步定下来之后我便去找ment o r初步评审去了。 二 ．产品评审 方案评审前一定要自己想清楚方案的细节 ，以及作出此方案决定的缘由 ，最好是有数据支撑或者其 他支持。切勿拍脑袋下定论 ，这样评审的时候会死的很难看 ，别问我怎么知道的。还有在定方案的 时候如果牵扯到技术的问题 ，请提前找技术确认 ，提前找技术确认 ，提前找技术确认 ，不要等方案 定下来之后 ，然后技术 实现不了。Ment o r 理论上来讲一般的需求都是能够实现的 ，只是实现成 本大小的问题 ，当然还有和技术的熟识程度。不停的请吃饭、请吃饭、请吃饭 ，陪加班、陪加班、 陪加班就能快速和技术们打成一片了…… 方案一初审就通过了 ，没有什么问题 ，Ment o r关于方案二的两种情况细致的问了几个问题 ，便问我 为什么不采用另外的一种处理方式 ，我 考虑到可能需要对接A PI的问题 ，然后Ment o r 这个不需 要对接A PI ，碰到这样的技术问题你应该去找技术确认。我 知道了 ，便回去重新修改了一下方案 二中的两个方案。Ment o r确认之后让我就方案二中的a方案和b方案去找技术评审确认下采用哪种 方案。 三 ．技术评审 最开始我是在RT X和技术Leader沟通的 ，Ment o r问我打算什么时候和技术沟通的时候 ，我 正在 沟通啊 ，然后Ment o r告诉我这种复杂的问题应该是提前和技术预约好时间段 ，进行当面沟通 ，在评 审前做好准备工作 ，尽可能的将需要问到的问题提前列举出来 ，提升沟通的效率 ，在沟通完成之后 需要就会议内容进行整理总结。 于是我在整理好方案 ，并做好准备工作之后便提前和技术Leader预约了个时间点 ，我把需求和方案 拿给他的时候 ，他 :“方案一没什么问题 ，方案二需要改动的东西太多 ，实现不了”。我的内心几乎 是崩溃的 ，于是我就和他 需求已经定下来了 ，一定需要做。技术Leader确认后问到“已经确定要做 了是吧 ？”我 “是的。” 然后我们就方案a和方案b进行了讨论 ，技术Leader问了好多边界问题 ，有的我考虑到了 ，有的边界 问题我根本没有想到。虽然我被虐的惨无人道 ，还是要 技术的思维严谨程度真是太赞了。最后得 出的结论是方案a要优于方案b ，但是…还是采用方案b吧。我问技术Leader“以后应该还是要使用方 案a的啊” ，技术Leader “方案a是比较合理的 ，估计以后也会使用方案a的。但是方案a需要改动的 东西太多了 ，就先采用方案b吧。”我 “那以后需要用到方案a的时候怎么办 ？”技术Leader “那到时 候再改吧。”我…… 然后就决定采用方案b了 ，后来我默默地去问技术的同事“你们是不是通常都是这么处理 ？”技术 “ 对啊对啊 ，都是哪种实现方式最容