最近更新了下简历，简历上写了“有成熟的产品方法论”。昨天晚上吃饭那会来了个电话，就问到这个问题，有些懵，絮絮叨叨说了些有的没的，感觉面试官都尴尬了。
有没有什么所谓的产品方法论呢？其实应该是有的。就跟我第一个家公司推崇的产品设计方法论，从原始需求开始到功能总表共8个步骤，如同八股文一样，这个可以保证你做出的东西是一个中规中矩的产品。但是实际上更加细一些说，那么从需求分析开始到项目运营上线每个步骤也应该是有所谓方法论的，当然，也包括项目管理。
我记得好像问我是这么问的：你这有成熟的方法论，那么你觉得用什么方法保证能做一个好产品呢。我不知道是不是我经验的问题，我总觉得这个问题太抽象，不知道从什么地方切入。
没有一个产品一开始就能说是一个好产品。或者说这个一个好的想法，这是一个用户痛点，但是不一定对应做出的业务或者功能就是好。只能通过一些所谓的方法去尽量保证这些是好的。这些方法可能是固定的，也可能是个人习得的属于自己的。
回到需求分析，最常见的我们说用卡诺模型：基本、期望、兴奋3种需求归类，也可以用四象限分类简单处理，但是在归类以前我觉得似乎关键点是：我们到底要做什么？做成什么样？
举个例子，这边业务部门提出一个能够让用户在app提出述求，发到邮箱，我们线下屏幕播放的需求。他们要求很简单，提供一个规则说明页，资料提交页就ok，实际呢？围绕这个点，发散开做一个穷尽思考：提出诉求是否需要登录？提出后需要保留记录吗？提出后后台需要对述求管理审核吗？是否发布了有所反馈？是否鼓励分享？是否支持重复发布？...然后把这些列出来，这个是基本需求，这个是期望需求，这个是兴奋需求。
那是谁判断这些需求？所有项目成员。需求评审后，确定要做什么，做到哪个程度，基本上后续功能优先级也就定了。
每次迭代，优化和修复bug是最基本的，也得适当的有用户期望的新的东西出现，难免就不停做加法。
这样看与其说是个方法，不如说是如何运用这些方法的思维。其实没有人告诉过我这样处理是不是对，谁叫我是野生的呢。
接下来就是所谓原型设计和PRD，这块现有方法论或者模板就很多，整理一个合适自己的。比如我的标准是不要有色彩，简洁、看着干净，PRD标注在原型。
剩下的产品经理要做的就是项目管理方法了，无论是用excel甘特图还是协同工具，或者使用敏捷开发，结果导向即可。规定时间完成自己的事，及时沟通反馈。
说起来我还是用了挺多工具的，tower、tembition、jira、worktile、禅道，这个可以找个机会单独写一下感受。
至于灰度到运营这些，我经验不够。以已有经历来看，关注用户及时反馈，关注页面数据，跳出率或者漏斗模型，适当的回访用户。起码保证用户体验是舒服的吧。
最后小结：
1、知道我们要做什么，做成什么样。需求分析穷尽发散，多考虑情景和可能性
2、原型和PRD找到属于自己模板，简洁干净单一，可以的话自己做及组件库和规范
3、项目管理找个工具，多沟通，多沟通，多沟通
4、运营我经验水。数据（定量）与访谈（定性）结合，关注用户实际体验
5、【突然还有一点】压住临时变更需求，下次再做。所谓：小步快跑，持续迭代
最后最后一句，如果没有【执行力】上面的都是废话。
下次反省下自己从0到1做的东西~
