首页 » 划重点 » 干货精华集锦梳理产品经理工作流

干货精华集锦梳理产品经理工作流

2019-09-26 1255736f015b8ad0 划重点
公众号从3月份开笔到现在,已经写了65篇文章了,每篇平均四千字,其中还有一些随笔感想也不适合放在公众号上,已发布和没有发布一起也差不多40W字。
于是这篇文章想要做一个汇总。
做汇总前,想先放几张公众号没有写到的内容罗列下,仅供知识碎片点参考。

1.【用户体验反馈清单】敲定优先级方法


为了保证具备可量化且统一的操作,针对问题需要进行三步拆解,即“问题还原→问题拆解→判断具象”。
可以保障【用户体验反馈清单】进行对应问题评定标准。

通过这三步拆解,能有效的处理对应三个问题:

  • 用户提出的问题核心点是什么?
  • 通过问题点拆解到功能点是什么?
  • 排定【用户体验反馈清单】优先级制定迭代计划。

此方法同样也适用于需求全链路收集,可以去试试。
轻易上手……

2.产品设计做好减法

产品设计并不是一股脑把功能堆砌在原型上,重点强调让用户聚焦点,而不至于分散用户的注意力。
少即是多,少即是精。


3.产品框架MVC模型

我们来讨论一个更深层次的东西,我谓之为“产品层次感”。
所谓 产品层次感,是说在产品的设计中,除了功能的设计与叠加,还有在产品垂直逻辑分层中拥有分层的特性。
这种分层,是一种自下而上的,这种分层的理解对产品经理提出了一种新的要求,你需要懂得产品的架构逻辑。

产品经理并不需要懂得什么编程的细节,而是需要懂得产品的逻辑设计,这种逻辑设计比较抽象,我在这里进行了一个分层的描述。

基于软件工程理论,产品本来就是至少要分为三层的,即典型的MVC(Model、View、Controller),这种描述对产品经理理解产品分层帮助极大。


4.用户分层

用户在产品中,基础可以分为这几个层面:
专家型、资深型、普通型和路人。
电商中有一个模型挺适合的用户分层。


以上是四个模型,当然还有很多模型可以自己去梳理。
下面John依托于产品经理工作流将公众号文章汇总下。
产品经理工作流无非就是:

业务需求→功能模块→功能需求池→功能流程图→页面原型→功能逻辑→产品需求文档(PRD)→产品评审→测试用例→数据分析→产品迭代
”。

1.业务需求

针对于业务需求来说,业务方明确的就是:
“做这个业务希望什么用户在哪些场景中会用到,目的是什么?
”那么匹配对应的需要梳理出业务需求池。
其中需要注意的是,一定要去深挖业务需求,因为往往业务方的需求都是很模糊的,也许你有更好的方案去替代它。
当然在做业务需求,是否已经针对业务需求契合本身的产品定位做了足够的拆解?
是否针对于用户画像有了足够的清晰?
在John的公众号历史文章中,这三篇可能会帮到你:

产品经理规划产品之了解业务

一文弄懂用户画像以及如何召回用户

产品经理们,好好琢磨产品定位吧……

2.功能模块(产品架构)

很多产品经理往往只在于如何做好单一功能,而没有去全局思考产品架构。
那真的只是变成了执行者了,理清产品规划能有效的俯瞰产品全局,针对后续迭代避免功能的冗余有很大的作用。
产品经理在产品架构设计阶段能很快的提升能力,同时你就是真正的产品leader了。
在John的公众号历史文章中,这四篇可能会帮到你:

产品经理如何设计产品架构

产品经理天天提MVP,到底该怎么用?

A/B测试的那些事儿

一文理清产品规划究竟怎么做(内附案例剖析)

3.功能需求池

功能需求作为一个中间件,负责将业务需求和原型串联起来,其重要性就不言而喻了。
然而很多小伙伴仅仅只是把功能需求收集整理。
而不去针对功能需求做版本规划和真伪鉴别,那最终上线的产品可想而知。
功能需求清单不仅仅是产品经理日常笔记,更是判断产品经理最基础的素质之一。
在John的公众号历史文章中,这三篇可能会帮到你:

产品经理如何输出完整的需求池?

如何将用户需求转化为产品需求?

产品经理必须清楚的【产品需求设计五步法】

4.功能流程图

每个功能都可以通过流程图去承载,流程图无非就是按照用户操作的场景来输出。
同时也是产品经理做功能埋点指标的查漏补缺。
好的流程图能减少很多的沟通成本。
做好场景的区分(模块)也许能为交互和技术节省不少时间。
所以,John在历史公众号文章写了一篇:

流程图,产品经理必备的技能包之一

5.页面原型

原型重不重要?
那太重要了。
但是似乎没弄到最重要的地步吧。
画的更清晰当然能让团队的人更清晰理解。
但是如果在没有弄清楚功能和流程的情况下,去花大力气画原型,似乎好像本末倒置了。

还有些小伙伴认为,不会我就抄袭优秀竞品的呗。
你问可不可行?
当然可行哇。
他们经常这么多用户的体验实践,当然值得可参考性,但是你似乎需要弄清楚为什么这个阶段可以借鉴?
为什么借鉴他们的,不借鉴别人的?
他们为什么要这么做?
在John的公众号历史文章中,这九篇可能会帮到你:

一文详解产品经理如何理解并应用策略

电商系统之——促销体系

产品原型真的只是产品经理敲门砖

电商产品之购物车里面的“大世界”

为什么说产品设计要有简洁性?

产品设计的思考和套路

产品经理如何规划信息的设计与展示?

购物车里的小秘密

以交互设计师的角度来看,B端和C端设计价值有什么差异?

6.功能逻辑

逻辑的梳理一定需要遵循用户正常操作习惯和异常情况。
可能大多数产品经理都会考虑到正常情况而忽略了异常。
比如你还记得你的朋友圈没有动态的情况么?
你还记得你朋友圈没有封面是什么样么?
无网络弱网情况下怎么提示?
等等。
在John的公众号历史文章中,这六篇可能会帮到你:

产品经理之电商订单逻辑

一文搞懂电商中的搜索和关联策略

协同推荐算法没有这么复杂,真的

不吹不擂,产品自查表看完这篇就够了。

从几个常见异常聊聊用户友好性

产品经理,你真的清楚产品逻辑吗?

7.产品需求文档

John在需求文档没有文章输出,需求文档主要是为了沉淀处理。
前面六步的汇总就可以形成了产品需求文档。

8.产品评审

产品评审是团队内澄清需求的会议。
所以产品经理必须前期一定要做好足够的准备工作,将前面七步全部整理出来,否则一旦思维发散,评审会也没有结论且时间是想象的漫长。
经历过需求研讨会的产品经理应该会懂得。
所以,John在历史公众号文章写了一篇:

产品经理如何避免需求评审会背锅?

9.测试用例

测试在写测试用例的时候,产品经理最好参与进来。
在测试用例完成之后,最好做一个测试用例评审会。
技术也会更加清晰测试需要的边界值。

10.数据分析

数据分析在John看来,如果团队有专业的数据分析师,那么可以写清楚产品经理埋点中的数据指标和埋点行为。
如果没有,则产品经理只能亲力亲为的从数据整理到数据报表以及计算的维度一一去做分析了。
在John的公众号历史文章中,这三篇可能会帮到你:

数据分析之产品经理要熟知的数据维度

产品生命周期中,产品人员关注的哪些数据?

产品经理工作流之数据分析全阶段(附电商统计)

11.产品迭代

产品迭代需要把前面十步重新走一遍。
但是此时第十步的数据需求很重要。
产品经理发起版本迭代的时候,一定要思考下场景,因为此时你们已经有了用户行为数据。
所以,John在历史公众号文章写了一篇:

产品设计前,四个需要思考的点,你是怎么做的?

12.其它文章

其它文章John也从产品经理方法论和运营策略上去写了一些感受。
相比于思考,john更喜欢落地。
经常说产品经理跟好一个项目就够了。
剩下的这些文章也希望你们看下:

单纯的聊聊产品生命中的AARRR模型和小方案

对于产品经理而言,前端产品是不是比后端产品难?

相对于APP,我为什么希望你做小程序?

请问你凭什么能做产品经理?

产品方法论真的有那么一点用……真的!

万字长文重新解剖产品经理

张一鸣的大招已经开启了?

产品经理的阿克琉斯之踵是产品思维

会员体系电商平台的三原色

产品经理十四问,你沉淀了几条?

产品成长的秘密:
从做一粒“种子”开始

中台到底是个什么鬼?

幕后产品这本书,真的很不错

裂变一定得依靠社交平台

你什么都不会,做产品经理挺好的!

产品经理们,读完这些书就够了……

向经典致敬,张小龙关于产品的68句话,你值得收藏

2019年度6月份app排行榜

一文详聊产品经理必须要具备的技术思维

产品经理跳槽面试大揭秘

关于产品的19条随笔,建议看一看

腾讯八节产品课——教你产品从0到1的思考

产品经理做好产品的几个关键点。
(文末有行业地图下载)

产品经理快速积累经验的八条铁律

一文详解产品经理工作流程

微博绿洲“截胡”小红书?

后台权限管理,看这篇就够了!

拆解微信,拆解的是生活岁月……

唠唠叨叨又写了这些多字,John原来也写过一个公众号,因为某些原因没有运营了。
但是这个公众号作为工作的输出,会经常更下去的。
承蒙各位的抬爱。
工作再忙也不会让质量打折……John在朋友圈做了一个调研,说想把历史文章整理成册子,让大家更方便的读。
其实没必要哈。
你们打印出来出来就好了。

顺祝国庆节快乐……预计国庆节会有一个有意思的事情,正在思考怎么弄?

写文不易,转发点赞下吧。
应该算干货了。

说点什么
头像
沙发还空着,发表你的看法吧ヾ(≧▽≦*)o
Loading...
上一篇 下一篇
已跳转到上次阅读的位置,从头阅读?