人人都是产品经理 如何做好产品经理实习?( 二 )


所以,用户的真实需求是能让我更快地到达某地 。 看到这里肯定会有人说,做产品难道不考虑实现难易程度,时间成本的吗?当然是要考虑的,但是也要考虑用户体验的,在用户体验和各种成本之间去做一个平衡 。
第二步,梳理框架梳理框架的目的在于将需求转化为功能,怎么样去设计对应的功能满足对应的需求,用户的需求A可能对应着很多的现实方式ABCD,最终会用哪种方式还需要做市场调研,to B产品很少有去做用户研究的,可能目前这个阶段我所在的团队还没有或者我不知道做了 。
其实,在做框架梳理之前会有一个需求拆分,这个是我们老大去做的,把一个产品拆分成几个小的模块,比如微信的“聊天”“通讯录”“发现”还有一个“我”,这里面可能涉及到需求优先级讨论 。 目前我只是一个产品新人,还不能做产品需求的优先级决策,现阶段的工作主要还是以执行落地为主 。
老人兴趣社区app功能架构(来源个人作品)
第三步,分析业务流程分析业务流程里有很多方法论,内容太专业复杂,我也很难讲清楚,所以不班门弄斧了 。 那怎么样去分析业务流程呢?我并没有像书上网上讲的去构建数据模型,而是先搞清楚我们的业务需求是什么,想要达到一个什么样的业务目标 。
因为我前面也讲了我现在的工作偏执行,更多的思考老大都想到了,比你想的更全面,而我需要做的就是根据框架画出满足业务需求的流程图 。
说到这里我感觉画流程图是最费脑力的工作,你需要考虑用户在不同场景下的体验路径(用户体验路径三要素:用户,场景以及行为),做的过程挺折磨人的 。
不过当你跑通了整个任务流程,回头跟同事交流的时候还是很有意思的;这个过程中他们会有很多疑问,可能是你穷举的场景不够全面,也有可能是你穷举的场景不合理;进而再次引发你的思考,你又再次补充或修改你的流程图,就这样一步步完善业务流程图 。
我们产品团队每个人的分工都很明确,在需求文档交给项目组和研发评估之前会有一次内部评审 。
早餐习惯养成APP提醒及登录注册流程(来源个人作品)
第四步,撰写需求说明文档(PRD)写PRD也是挺折磨人的工作哈哈哈,第一次写一个PRD用了一天,原因是什么呢?
原因是框架和任务流程还不清晰,要把一个自己还没理解透的东西写出来并让别人看懂是很难的 。
工作不是和学校做作业一样,每次到了要交作业的前一天晚上抓紧做一下就可以过了,60分万事大吉 。
工作不是这么回事,你的认真程度直接反映的是最后这个产品好不好用,好不好卖 。 也直接反映了你在这一阶段是否有所成长,最终体现在你的薪资待遇上,所以真的不要把学生时代那种不认真的态度带到工作中 。
PRD写得好不好直接反映了一个产品经理的基本功是否扎实,写PRD的目的是什么?给谁看呢?
主要目的:一方面是用来产品交流的,既然是用来交流的,那么就分交流的对象——内部交流和外部交流 。
内部就是产品部门,项目部门,设计部门,测试部门以及研发团队,每个公司内部人员架构会有所差异,我是以自己目前所在的公司架构分的部门 。 为了方便不同的部门间进行交流,就需要有这么一个规范的产品需求文档,图文结合的形式,让大家都能明白我们要做的是一个什么样的产品,每个功能它在什么样的场景下可以完成什么样的任务 。
另一方面是用来外部交流的,外部交流的我还没有写过,不知道会不会有所差异 。 外部交流的叫产品需求说明书,主要是给客户看的,类似于操作手册这样的一个东西,一般在产品交付的时候会写这样的一个说明文档 。
这里想说明的一点,PRD内外部交流和评审的内外部有所差异 。
评审的内外部,内部是自己的产品团队内部评审,内部评审过了才会拿出去进行外部的评审 。
内部评审的内容主要是需求和功能的合理性,逻辑性是否完整,也会考虑经验范围内的可行性问题 。
外部评审就是指前面提到的项目、设计、测试、研发以及市场、运营、财务等部门的评审 。 外部评审主要是对产品的可行性进行评估 。 对技术而言就是是否可实现,以及实现成本是怎样的;对市场而言就是产品是否好卖,卖点是什么;对运营而言就是我想加的活动入口有没有突出;对财务而言就是公司要投入多少钱,最终可以获得多少回报做风险评估 。

推荐阅读