1000字范文,内容丰富有趣,学习的好帮手!
1000字范文 > 圈子 | 苏宁易购产品经理:平台支撑型产品的思维方式

圈子 | 苏宁易购产品经理:平台支撑型产品的思维方式

时间:2021-04-16 11:44:09

相关推荐

圈子 | 苏宁易购产品经理:平台支撑型产品的思维方式

入群规则请看文章底部

分享者:阿卓,苏宁易购产品经理

群组:PMcaff互联网金融圈

加入方法:请联系管理员:37°C 微信号:erhuoyimei

今天和亲们分享的主题:平台型产品的需求分析,也是自己的一些笔记和思考,和大家一起学习。我用pc端发,本来准备用脑图,但还是文字看起来工整些。

最近在做平台型的产品工作,相对于垂直类产品的小而美特点(追求极致体验、制造运营感、数据驱动、快速迭代)不同,平台型产品更加注重生态建设,根据公司自身特色,依托现有平台资源,瞄准服务对象,从而推出一整套的解决方案。相对于以前做运营商的产品规划不同,互联网平台型产品规划侧重竞品分析,业务讨论,主动规划。没有人告诉你需求是什么,BOSS定一个方向,产品经理负责基于大方向开展一系列如调研、分析、头脑风暴、评审、汇报工作,最终在规定的时间产出业务和产品需求。结合自己实际工作中的一些经历和体会,分下面5个部分谈谈对产品需求分析思路的理解,附上指导自己开展需求分析工作的一些方法。感谢PMcaff产品互联网金融群。

1、使用场景调研

调研竞品的使用场景、产品使用流程

备注:关注竞品有什么、此阶段不要被自身产品现状束缚。

输出:产品调研报告

1.梳理产品的会员体系

2.梳理产品的账户体系

3.梳理出产品使用过程中的涉及功能

4.梳理不同用户的产品使用权限区分

5.梳理产品提供的服务的生命周期管理

6.梳理产品的支付/计费/结算体系

2、渐进明细定位

根据公司的业务方向和业务目标定义平台该承担什么职责、不该承担什么职责

备注:高层给的是大方向,到产品定位落地是一个渐进明细的过程,需要结合公司业务目标、组织机构、业务范围、假设及依赖,产品团队多轮讨论才会逐渐明晰。

输出:产品上下文场景图

1.通过调研设计产品的总体使用流程,只抽象到产品的二级模块。

2.以用户为视角绘制用户使用产品时自身产品和外部产品之间的业务交互、自身产品内部组件之间的业务交互。

备注:该阶段可以先抽象出产品的内部组件,回答产品是做什么的?为什么要和周边产品这样划分?为什么要抽象出这些内部组件?

3、明确产品逻辑

明确平台的使用对象是谁、使用产品的流程是怎样的

备注:根据使用对象设计产品权限、产品使用流程

输出:产品流程图

1.根据产品上下文场景图,将产品场景进一步细分。

2.根据每一个细分场景,以用户为视角绘制用户使用产品时自身产品和外部产品之间的业务交互。

备注:该阶段回答产品有哪些使用场景?这些场景都经过哪些平台?平台间的交互顺序是怎样的?为什么是这样的交互顺序?

4、抽象平台组件

依据产品上下文场景图,结合架构原则,细化管理组件。

依据产品上下文场景图,结合架构原则,细化执行组件。

1.对外提供的接口

设计哪些接口该提供、哪些接口不该提供。

设计哪些接口字段该提供、哪些字段不该提供。

备注:

字段的提供与否需结合平台定位、业务流程合理性、数据延时问题、技术实现代价综合考虑。

根据业务场景设计区分查询接口、推送接口等

2.依赖外部的接口

设计哪些接口该提供、哪些接口不该提供。

设计哪些接口字段该提供、哪些字段不该提供。

备注:

字段的提供与否需结合平台定位、业务流程合理性、数据延时问题、技术实现代价综合考虑。

根据业务场景设计区分查询接口、推送接口等

输出:产品功能结构图

根据抽象出来的组件组合成产品的功能结构图,区分管理组件和执行组件。

备注:功能结构图只描述自身产品有哪些功能模块,可以增加有交互的外部产品。

5、梳理依赖关系

1.内部组件间的关系

根据功能结构图,以用户为视角,结合细分场景,梳理组件之间的业务关系。

2.与外部组件的关系

根据功能结构图,以用户为视角,结合细分场景,梳理与外部组件之间的业务关系。

输出:泳道图、时序图

泳道图用于描述用户在使用产品时,产品组件与外部组件之间的交互顺序和交互结果。

时序图可以作为泳道图的补充,描述组件之间同步/异步交互时的交互顺序和交互结果。

上面5个方面是自己日常产品规划与设计中的基本思路。最后,分享一些指导自己开展需求分析的一些方法论。

1.发现真正的问题

1、解释:解释利益相关者说所的内容,揭示本质。

2、分离:从所提的解决方案中分离出问题本质,无论技术如何实现,本质总是存在的。

3、抽象:对于任何技术,都必须从技术中抽象出来,看到它背后的本质目的。不要问技术能为你做什么,而要问技术在做什么。

4、端到端:查看端到端的过程,忽略当前工作在部门间的划分。

最重要的工具:头脑、眼睛和耳朵。

2.寻找最佳解决方案

1.影响解决方案的因素

组织机构和项目目标、限制条件、创新、包含的功能、非功能需求、用户体验、技术可行性、开发成本、差异化

2.开发解决方案的方法

1)确定产品范围,业务用例中那些部分要自动化。

2)考虑用户,研究群体如何行为和思考。

3)设计用户体验,专注于用户对产品的感觉而非功能(业务分析师在这里的任务是提出建议,为业务辩护,设计由体验设计师完成)。

4)创新

1.方便,达到产品使用起来方便,节省用户时间,让生活更方便。

2.联系,让产品与顾客或用户的联系更紧。

3.信息,让产品提供所有需要的信息,让顾客执行事务更容易。

4.感觉,让用户用产品时感觉安全、有竞争力、产品体验快、用户服务响应快。

5.接口草图,快速打造解决方案,快速汲取意见、快速修改。

6.分析业务事件的真正起源(通常在组织机构之外),将产品边界扩展到相邻系统的思维深处。

7.相邻系统和外部技术,将产品边界扩展到相邻系统之前,考虑它的本质和技术,可能会决定你设计的产品。

8.权衡成本、收益和风险

9.用文档记录设计决定(产品为什么是这样)

10.使用产品用例场景,解决需求规格说明书的枯燥乏味不可读的问题。

------------------------------------------------------------------------------

问答环节:

1、核心干系人主要在哪一步体现呢?

平台型产品需要产品经理把控产品方向,协调业务、技术、测试、运营,但是对于ued的合作,可以在产品研发后期参与进来。

2、现实情况我遇到的比如boss要求的跟另外的核心干系人会有一些冲突,平台类产品后期可能会接入其他公司的,这个您是怎么解决的呢?还是说自己决策?那自己决策的主要依据在?

我觉得还是求同存异吧,如果对业务发展有好处,梳理清楚思路和boss以及核心干系人沟通汇报。业务问题决策权不在产品经理。产品规划与设计由产品经理主导,是基于公司的业务方向和业务框架 。

3、对于2渐进明细定位中的不该承担责任这个很有感触,会出现很多雷区,这个您是怎么解决的?可以教一教吗?我的理解是需要经常直接找业务负责人谈心吗?还有就是4抽象平台组件这个问题上,决策权在产品还是业务呢?因为其实产品和业务都会有调研,最后提出建议,可能公司选谁都行。这时您是怎么处理的呢?

平台产品的定位初期其实大家都是在摸索,业务要回答:我们要卖什么?为什么要卖?,而产品要回答:我们提供什么产品来卖?如何更好的提供支撑?抽象平台组件,业务作为输入,产品组件划分如果涉及多个子系统,一般会由应用架构师和各个产品经理一起参与。渐进明细一般是通过竞品调研+头脑风暴梳理出来的,然后结合自身的业务方向,抽象出自身的业务需求和产品需求。

想更多参与讨论的同学可以点击查看原文,进入原帖讨论。

注意:本文为PMcaff产品经理社区原创,转载请标明来自PMcaff产品经理社区

入群规则:

1、入群需组织一次群分享。(内容不限,可以是一本书、一个产品体验、需求分析方法分享)

2、需要加群,请联系每个群的管理员。敲门装:PMcaff+行业+分享主题

3、各群中管理员均为小二班同学,大家可以通过他们来了解小二班的课程

社交产品经理圈—— 管理员:沙龙 微信号:alfa-jaychou

视频产品经理圈子——管理员:贺铮 微信号:EsDark_guiga

电商产品经理圈子——管理员:马莉 微信号:happylifemary

O2O产品经理圈子——管理员:郭爽 微信号:Gs_cool

硬件产品经理圈子——管理员:Johnson 微信号:Johnson727543

互联网金融产品经理圈子——管理员:李汉强 微信号:erhuoyimei

旅游产品经理圈子——管理员:喻萌萌 微信号:yumm_i

工具产品经理圈子——管理员:胡亚龙 微信号:zero_factorial

其他产品经理圈子——小助理建设中 微信号:pmcaffzs

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。