标签 产品 下的文章

在国内互联网公司的产品经理成长路径中,通常在对标阿里P7这个级别上,会出现一次P序列和M序列的分叉,一部分人走上了管理(M)之路,更多人走上了专业(P)之路。P序列的高级别,被称为"产品专家",或者是"产品架构师"。相对于能力更通用化,发展更成熟的研发线系统架构师,产品架构师的定位比较模糊,至少在实践中,工作内容与系统架构师有诸多重合之处。梳理产品架构师的内涵及外延,是一件有趣的事情,下面的内容都是我个人的理解,欢迎批判和探讨。

一、产品架构的一些问题

1、产品架构是什么

广义上,产品架构是业务结构的镜像,描述的是从实际业务中抽象出来的需求(子需求),和需求在如何通过在系统之中(子系统之间)进行交互,最终被满足的过程。

狭义上,产品架构是指需求和交付物之间的关系。

用下面一个表格来说明:

分层名称内容产出
业务交易(消费)结构客户表达并满足需求的过程和结果需求的定义
需求狭义产品架构需要什么交付物满足客户需求交付物的定义/配方
实现系统架构怎么在系统中生产交付物交付物生产工艺/流程

在实现层面,系统架构应该包括数据、业务/商务、运营、营销等整体业务流。

2、产品架构对组织架构的影响

组织架构变革在新零售话题中常常被提到很重要的位置,系统中台化趋势要求组织结构液态化,以响应商业环境和业务形态的快速转变;在产品架构话题中,组织架构和产品经理个人的成长却常常被忽视。

直接影响产品技术研发类组织架构,产品架构最后的交付物是系统架构,会切分好各子系统(子模块)之间的内容,PM和RD的工作内容和协作关系也随之确定。

间接影响整个业务流各参与角色的职责内容和协作关系,随着业务变化和系统改进,参与角色的工作内容甚至是角色本身,都可能改变或取消。

完成业务结构、产品/系统架构、个人成长三合一,是衡量产品架构是否优秀的一个重要视角。

3、产品架构的评判点

好的产品架构,应该是容器,提供空间(性能冗余/数据监控分析/损失管理等能力),容纳业务的不确定性(创新),是一种系统机制。

评判点也用一个表格来说明:

评判点内容
合理性需求(子需求)结构简洁,需求场景定义清楚;
子系统(子模块)高内聚松耦合,边界定义清晰,执行顺序可预知,系统交付物稳定。
前瞻性适应未来1-2年的业务发展,在业务变化快的情况下,至少适应1年的业务变化。
系统性结构上的横与纵:横-中台核心业务平台,纵-关键实施项目落地;警惕过度设计。

4、谁来评判产品架构

由于产品架构是需求间的关系和需求实现的过程,参与产品架构评估的角色,应包括具备业务抽象能力的业务方、产品、研发,以业务场景为基本维度。

5、产品架构设计实施的一般方法

产品架构与技术上的架构设计实施过程有一致性:

过程行为产出
商业诉求抽象产品需求
复杂系统分层基础通用能力和个性化作业
作业流程分治简单子任务工单
接口化中间层(中台实现)组合可演化的开放系统架构

乐高一般的开放系统架构应包括三个基本要素:

  • 组件/构件

    • 可复用的模块,尽量排除个性化的业务流程逻辑,排除过程。即是,内部信息流程不依赖外部模块处理,高内聚
    • 关注组件的输入输出,组件之间的信息流及媒介
  • 模式

    • 支持业务全流程的系统闭环的一组知识体系
    • 商业需求/客户需求被满足的生产交付过程
  • 规划

    • 对业务长期支持,设计未来整套行动方案

6、产品架构视角下的系统化创新

在业务发展的早期阶段,产品设计开发工作经常落后于业务创新,主要工作内容是响应和配合业务需求,产品经理及工程师,常常有疲于奔命的失控感,但这是一个基础设施建设的必要阶段。随着对业务理解加深及产品系统架构的完善,产品领先业务,进入系统化创新的阶段就会到来。

系统化创新常常以这样一种方式进行:

业务流程被抽象成为颗粒度非常细小的节点,通过四个方法(方法来自《简约至上:交互式设计四策略》)变成全新形态出现

  • 删除(自动化或智能化)非必要节点
  • 重组(有时是替换)为新模块
  • 隐藏支线节点
  • 转移节点到其他产品

二、产品架构师的一些问题

1、产品架构师是什么

产品架构师是产品团队内部的专业咨询顾问角色,深度参与到产品设计实施的全环节

  • 架构设计

    • 从业务诉求(商业诉求)中抽象需求,以结构合理的系统完成满足需求之交付物的生产,并使生产持续
  • 团队建设

    • 成为P序列产品成长的坐标和参考,为PM的专业序列制定能力模型阶梯及成长路径,提供产品专业相关的指导
    • 识别并培养具备产品架构师潜力的产品经理
    • 建立并维护适合架构师成长的规则及团队环境
  • 项目实施

    • 在实施层面的协调工作更多,平衡不同项目在方案上的投入产出
    • 分拆架构目标,落地到具体的项目实施中,确保架构目标/进度符合团队整体目标/进度

2、产品架构师职位要求

  • 对业务的理解

    • 理解业务全流程各环节,参与角色及其作业操作(包括管理)
    • 理解公司商业模式,所在业务线的商业模式及定位
    • 理解基础的技术实现
    • 行业趋势、产品方案趋势、竞争对手产品研究能力,关键是完成产品评价标准
    • plus-具备基本的财务/税务/法务知识
  • 对产品工作的理解

    • 具备探索并成功实施(规划/设计/运营/增长)创新方向的产品能力
    • 具备规划和部署产品矩阵,实现组织目标的能力
  • 对职级的要求

    • 应具备高级经理及以上的产品职级和能力,从内部培养效果更佳

3、产品架构师的工作方式

  • 产品架构师与产品执行负责人的协作

    • 架构师跨产品模块参与评审,为系统间交互提供符合架构设计的建议,尤其是在中台化项目中,重视流程;产品执行负责人确定具体设计及实施方案,重视细节;
    • 架构师对项目/系统目标负共同责任,以协商为基本前提,保留在对架构设计的最终决定权,同时承担最终责任;
    • 设置产品架构委员会,规避重大项目架构设计风险;
  • 产品架构师与技术负责人的协作

    • 产品架构师角色重需求抽象和场景定义;技术负责人重实现;
  • 产品架构师工作成果的评估

    • 落地项目的绩效
    • 产品、研发、业务团队的认同度调查
    • OKR及360度环评

4、产品构架师对PRD/MRD的影响

由于产品架构师重视中长期架构的规划实施,所以需要在PRD/MRD中强制增加以下内容

  • 数据流及模块I/O
  • 对不能严格控制的外部系统的依赖及交互,即是架构风险控制的内容
  • 系统目标的完成评估方法,重结果
  • 数据分析导向的监控和分析方法,重过程

5、产品架构师的晋级之路

下面的级别是从实施、变现、平台战略角度来说明,未必符合所有公司对架构师的晋级定位

级别核心定位
系统架构师设计实施符合业务流的系统间信息流
商业架构师结合财务税务法务知识,迭代和创新商业模式
生态架构师赋能行业生态的产品矩阵架构

在细分领域上,如电商、社交、工具、金融、人工智能等,都对产品架构师有非常高的专业要求,可以分别制定评分表来确定不同级别架构师的实际要求。

6、产品架构师的工作难点

  • 作为非管理角色,如何获知/参与业务目标规划
  • 作为规划型角色,如何平衡架构设计的长期收益与KPI的短期收益
  • 作为重咨询角色,如何平衡架构设计师与产品线负责人之间的产品方案及优先级冲突

三、市场中对产品架构师的描述

通过查看一些招聘网站,选择了两个case,来看看不同公司对产品架构师的不同描述,说明产品架构师这个角色,并没有整齐划一的刻板定义,对有志于在产品P序列向上发展的产品经理们,在自己特定的业务和组织场景中,都可以形成有特色的产品架构师成长路径。

百度中台产品架构师

职位说明:

- 负责百度知道内容tag模型和用户画像建设,支持多端产品的推荐工作

- 负责百度知道内容及用户反作弊工作,及内容审核工作

- 负责百度知道整体数据平台建设

- 负责百度知道相关的中台业务工作

任职要求:

- 5年以上产品经验,有搜索、推荐、内容等平台型用户产品经验优先

- 逻辑分析能力强,计算机、数据分析等理工科相关专业优先考虑

- 工作积极主动,抗压能力强,快速学习,踏实认真,有责任,具有优秀的理解、沟通与协调能力

京东金融解决方案产品架构师

职位说明:

- 从事部门创新产品的产品管理和产品经理团队管理;

- 负责核心产品的产品创新、设计、规划和运营;

- 组织内部、外部资源完成产品开发和推广;

- 指导产品经理团队完善产品分析和设计;

- 对内外宣传产品特性和价值;

- 培养产品团队成员能力;

- 横向沟通项目相关的产品、售前以及商务部门。

任职要求:

- 本科及以上学历,计算机或相关专业;

- 5年以上to B的计算机服务类产品运营经验,有互联网、金融等行业经验优先;

- 具有产品设计、组织研发和运营的能力;

- 良好的沟通能力,具有对外客户产品售前支持能力;

- 具有团队管理和提升的能力;

- 具有创新精神和创新意愿者优先。

四、结语

如果觉得我写得还有一点道理,欢迎留言沟通或邮件沟通sluke[at]qq.com,说不定有机会在互联网产品工作上合作,一起成为更好的产品经理。

业务符合需求,组织适应业务,系统镜像业务

从用标签区分客户到用户微粒数据镜像客户,需求越来越细节和个性化,要求组织、系统、产品都要相应变革

PM的工作有新目标:

  1. 信达雅翻译业务,用系统镜像业务
  2. 用成本低的系统试验变化,反哺业务创新和组织变革

mid-stage-position-1

系统分层,强化中台,业务也是一个操作系统

Google 的实验性操作系统 Fuchsia OS,设计了一个四层结构,可以用来帮助理解业务系统的前中后台划分。

中台,是通过信息流、资金流、物流来反映商业全生命周期的枢纽

强化中台,可以理解成强化对业务变化的反应能力,要求组织柔性化液态化,系统功能粒度更小,应用方案更丰富(类似应用市场中的 APP 更多)

中台系统PM重点关注:

  1. 客户最后获得的交付物是商品+服务,是一个漫长过程,结束不在商品交割的一刹那
  2. 中台有所有数据的最终版本,需要保持一致和完整

mid-stage-position-2

变化发生在用户第一线,就像是果实和种子

一线的业务细节变化良莠不齐,中后台的感知经常滞后,中台化在加强感知能力,面对不同的业务驱动模式,PM的定位也有不同

资源驱动阶段:面向新兴市场,向外求增量
管理驱动阶段:面向饱和市场,向内求优势
创新驱动阶段:创造新物种

mid-stage-position-3

做系统的股东

组织里的各种角色都在为业务服务,接近客户的还有销售和运营,接近系统的还有研发,PM是组织里的中台。

销售、运营、研发的工作相对于PM,容易评估,他们是系统的债主,先拿走确定收益率的回报。PM是系统的股东,拿走剩余的收益,要求PM的主人翁意识要强于其他角色,因为有潜在的超高回报收益。

决策引擎是什么?

决策是思维过程和行动过程结合的复杂过程,包括三个阶段:

  1. 抽象出对象特征,识别对象
  2. 通过规则或模型,诊断对象
  3. 根据诊断的结果,选择行动

决策引擎应当是承载业务思维过程和行动过程通用化工具集。在实际业务场景中,通常指支持第二阶段的工具,输入是一组对象及抽象出来的对象特征(即是变量),输出是针对对象的决策、标注、排序,被业务系统与映射到具体的业务行动中。

举例:

决策引擎基本模型说明

申请信用卡时候碰到的决策过程就符合这个结构:

  1. 将客户的基本信息输入,抽象出各中变量,如年龄、职业、收入、社交等
  2. 通过规则及模型,给出批准或不批准,批准多少额度的结果
  3. 选择后续行为,通过制卡/拒绝/需要补充资料的行动

什么样的业务需要决策引擎?

业务复杂性带来高决策成本和决策风险,需要决策引擎工具(本质上是效率工具)支持。符合以下特点:

  1. 业务链条长

    • 决策场景多样化
    • 参与角色多样化
  2. 业务对象多样化

决策引擎产品设计的原则?

  1. 通用工具适应个性业务

    • 多样化决定个性化

      • 决策场景多样化

        • 人工干预 / 规则 / 模型 是个性的
        • 外部限制条件是个性且动态的
      • 参与角色多样化

        • 决策标准和行动是有差异的
      • 业务对象多样化

        • 特征是复杂多变的
        • 抽象成特征的方法多样的
    • 工具属性决定通用化

      • 本质上,决策引擎实现的是对业务对象的决策、标准、分类
      • 结构上,工具可简化为规则、模型、人工干预三大模块(统计可作为附属模块)
  2. 角色化

    • 决策过程中,不同角色权限、决策点、决策成本和收益、行为不同,输出结果应可回溯、可解释(机器学习模型有难度)、可修正救济
    • 不同角色在不同决策场景下,需要获得的信息和使用的规则或模型也不同
  3. 服务化

    • 提供接口层方便嵌入复杂业务流
    • 不同决策的内容不同,可根据输出结果包装为不同小工具,作为服务输出

如何评估决策引擎产品的质量?

工具的质量评估:

  • 服务稳定可靠
  • 基础工具可灵活装配
  • 方便部署
  • 面向不同用户

决策引擎的实际应用?

金融风控决策引擎简明示例

营销阶段贷前管理 贷后管理
服务客户意向分析服务申请反欺诈服务信审服务授信额度管理服务贷后风险管理服务
规则 反欺诈规则组风险预审规则增信规则风险规则
自动化审批规则
业务模型客户识别模型反欺诈模型信审评分模型行为分析模型逾期预警模型
收益预估模型收入模型失联预警模型

决策引擎里的规则工具元素

实际业务中,规则引擎服务是决策引擎的核心之一,规则引擎包括一系列工具元素,像乐高一样组合成不同的规则服务:

  • 规则/规则集
  • 决策表
  • 决策树
  • 评分卡

    • A卡(Application scorecard),常用于用于信贷审批
    • B卡(Behavior scorecard),常用于贷后管理
    • C卡(Collection scorecard),常用于催收管理
  • 决策图
  • 自定义函数与方法

怎么理解决策引擎里的模型

给模型一个简单的定义:

模型 = 算法 + 数据结构 + 参数值

针对模型的主要工作就可以分类如下:

  • 调整算法
  • 调整数据结构
  • 调整参数,要求有良好的反馈机制,让业务结果反馈回模型

优秀参考资料:斯坦福大学的机器学习技巧和秘诀速查表

使用权和所有权的关系

先定义出行,是指将人从出发地送达目的地。满足用户需求的关键是车辆的使用权,用户也是在为占用使用权付费。

打车,付出打车费,司机和出租车会将我们送达目的地;租车,付出租车费,自驾旅游,我们自己和被租车辆会将我们送达目的地;公交车、地铁、高铁甚至是共享单车,都是如此。我们可以看到一个不同于自己买车的逻辑:

车辆的使用权和所有权是可以分离,不属于同一个人的

在过去的常识里,使用权和所有权分离常常伴随着一个“集中”,那就是车辆的所有权,比如出租车公司、类似安飞士租车和神州租车这样的租车公司,大量车辆的所有权是属于一个集中的组织的。共享经济展示给市场另一种可能性,车辆的所有权也可以呈现出“分离”的状态,比如PP租车和滴滴打车。

我们用一个四象限图在总结市场上的各种出行领域企业:

innovation-of-travel-market.png

使用权和所有权的关系,可以转化为“虚拟车”和“实体车”的关系。使用权是车辆的功能性部分,是满足用户需求的关键;所有权是车辆的实体部分,使用权附着在所有权上;使用权的转移容易实现,因此非常容易碎片化,这是出租车和共享出现的基础逻辑;所有权受到登记制度的限制,转移的成本比较高,不容易碎片化,是比较容易控制的资产,因此,传统汽车金融都是以车辆所有权为基础的。

出行领域的模式创新,本质上都是打碎和重组使用权的模式。人人都需要一辆“车”,但是需要的是“虚拟车”,这辆“虚拟车”实际上可以由不同粒度和不同车辆的碎片化使用权重组而成。

出行领域的金融创新,着眼点则是使用权和所有权的分离,将车辆从消费品变成可增值资产。车辆作为实体的财产,在使用中不断贬值,但是使用权却可以不断变现,当车辆使用时间可以被切割时,车辆闲置时间就可以减少且变现,使得车辆残值加上使用权变现总价值高于过去。用金融做杠杆,撬动更多使用权与所有权分离的车,进入出行的市场供求关系中。

供求关系

回到出行的定义,满足用户出行需求的必要条件有:车辆使用权、司机、道路使用权,这是出行的供给侧;用户到达目的地的诉求,是出行的需求侧。供求关系可以用来解释很多企业的跨界投入。

  • 滴滴投资人人车,获得一个相对稳定的二手车渠道,带来了两个好处

    • 大量二手车可以进入滴滴的出行供求关系,在供给侧提供了更多的低价车辆使用权
    • 存量的滴滴车主得到了销售二手车,更换为品质更好车辆的机会,有利于提供体验更好的车辆使用权
  • 大搜车推出弹个车,自建了一个新车销售渠道,以融资租赁的方式销售新车,同时也是可控的二手车车源,加大了低价车源供给

从供求关系上去理解出行领域创新有三个思考角度:

  • 如何增加供给和需求

    • 顺风车就是挖掘碎片化的车辆使用权,投入了供求关系,降低使用费用门槛,激发了更多的需求
    • 共享单车则是挖掘了碎片化的车辆使用需求
    • Uber在快递或者送餐服务,本质上也是增加了对车辆使用权的需求
  • 如何提高供给与需求的匹配效率

    • 滴滴的车站就是将原本散乱的上下车点聚合起来,使供求撮合效率提高
  • 如何革新车辆使用权的获取方式

    • 用户原本是通过支付一定费用来获取使用权,我们可以设计一种会员制的用户模型,会员投入一辆车或者一笔资金,用车辆资产的使用权收益或者资金的孳息还交换其他车辆的使用权

春节假期结束,又是人员流动的高峰期,时常能听到有人说:“XXX离职了,真是该走的没走,不该走的走了”,为什么企业发展了,优秀的员工反而要离开呢?“柠檬市场”模型可以用来解释这个优秀员工被平庸员工挤出企业的现象。

“柠檬市场”是乔治·阿克尔洛夫(George A.Akerlof)在《柠檬市场:质量不确定和市场机制》这篇论文中提到了一个虚拟的市场,说明了信息经济学中的逆向选择。柠檬一词在美国俚语中意思为“次品”或不中用的东西,柠檬市场指的就是次品市场或是二手市场,用二手车市场的例子来说明:

假设在一个二手车市场里存在质量高低不同的二手车,只有卖家才完全了解这些车的真实质量,买家只对二手车的平均质量有了解,也就是说这个市场里信息是不对称的。买家为了保证自身的利益不受损失,在购买时会倾向于压价,最高不会高于市场的平均价格,因此,二手车质量低于平均线的卖家会获利。随着市场交易的进行,卖家为追求利益最大化,不再入手质量高于平均线的车,转而入手低于平均线的车,高质量二手车就被低质量二手车排挤出了市场。

企业同员工的关系实质也是买卖家的关系,企业通过签订合同,购买员工的劳动力。然而员工的个人能力只有员工自身清楚,企业是不了解的,为保证雇佣的性价比,倾向于至多付出行业平均水平的薪酬。能力高于平均值或是说付出多于平均值的员工在这样的条件下收入受损,会产生怠工,拉低付出水平到平均线,不甘于自我降低的员工就会离职。而从企业一方看,人才市场上是难以判断的,即使遇到高价格的优秀员工,也会保持怀疑,最后很可能选择了低价低质的员工,这样从性价比上看是合理的,企业里平庸的员工越来越多,优秀的员工越来越少,集体杯具了……

有时候会看到企业招聘时要求211工程或是985工程学校毕业,或是有各种苛刻的要求,其实企业只是想借用著名高校的认证,拉高择人的平均线,以获取高质的员工而已。

规避企业里的柠檬市场,只能说一句大而空的话:“社会诚信”,老实讲,我觉得天朝很缺。