导图社区 猎头招聘-电商产品经理
- 56
- 2
- 2
- 举报
猎头招聘-电商产品经理
猎头招聘用的电商产品经理的思维导图，主要内容有1.与普通人所谓的产品2.互联网行业的产品概念3.互联网产品的细分领域等。
编辑于2022-09-18 14:04:46 广东- 猎头
- 相似推荐
- 大纲
猎头-招聘- 电商产品经理
I. 什么是产品大概念
1. 与普通人所谓的产品
市场营销学认为，广义的产品是指：人们通过购买而获得的能够满足某种需求和欲望的物品的总和，它既包括具有物质形态的产品实体，又包括非物质形态的利益。
2. 互联网行业的产品概念
全局产品
互联网产品的概念是从传统意义上的“产品”延伸而来的，是在互联网领域中产出而用于经营的商品，它是满足互联网用户需求和欲望的无形载体。简单来说，互联网产品就是为用户解决问题而产生，它是网站功能与服务的集成。
功能产品
“产品经理”的简称
3. 互联网产品的细分领域
1. TO C
文化/娱乐类
书影音 虎牙直播，bilibili，微信读书，酷狗音乐
游戏类
王者荣耀，部落战争
社交类
QQ/微信，微博，小红书
资讯类
今日头条，凤凰新闻
工具类产品
猎豹清理大师，随手记，大姨吗
本地服务/O2O
美团/饿了么，货拉拉，链家
智能硬件
水滴摄像头，天猫精灵
电商产品
淘宝，京东，亚马逊，PDD
2. TO B
拉勾招聘，shopify，金蝶，用友，飞书，企业微信，salesforce
II. 产品经理这份工作
1. “产品经理”的本质
定义
产品从想法构思到用户实际使用的负责人。
所需能力
多领域的知识
产品经理要让设计领域的设计师，理解技术领域的工程师，在实作中会遇上哪些困难，进而说服设计师调整设计稿。
产品的系统文案由产品经理撰写。原因是团队缺乏专职的UX Writer（或称为Copy Writer，文案写手），所以由最懂产品的产品经理来撰写系统文案。
在没有下辖权力的情况下， 还能够影响多个利益相关方的能力
所以说不是经理
沟通能力
PUSH能力
职责
把抽象需求，化为具体方案
所以说需要跨领域的知识，最好啥都懂一点
推动进度
项目管理
2. 产品经理的工作流程
需求调研与分析
产品设计
跟进研发
测试
上线
产品培训与推广
数据分析
产品迭代
工作包括
画原型图、思维导图、写文档（BRD/MRD/PRD）
作者：THE TAO 链接：https://www.zhihu.com/question/19655491/answer/49122402 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 Ctrl+C&Ctrl+v BRD 商业需求文档 Business Requirement Document MRD 市场需求文档 Market Requirement Document PRD 产品需求文档 Product Requirement Document 好了，最好的记忆就一个单词 Business商业、Market市场、Product产品；那么这三个是什么关系呢？BRD是产品的head、MRD是产品的body、PRD是产品的Heart，有了Head、Body、Heart这就是一个完整的产品了！ 一、BRD是针对谁看的呢？一般都是针对老版或CEO或者项目总负责人，那么他们需要了解的是什么呢？ 1、要做什么样的产品； 这就包含了项目定义，描述项目并且让老版感觉到产品的竞争优势； 2、需要什么样的资源 要什么资源就必须知道产品的市场位置，通过多少人、多长时间、多少Money、多少关系等等能够实现这样的市场位置，并且还需要有利且有力的商业说明，需要有一定的高度！ 3、最终做成什么样； 要怎么做或者说怎么安排，老板们很少关心，更多的是关心产品的结果展示及盈利，这个产品能带来什么样的收入情况； 最终BRD就浓缩为 商业模式、盈利模式、资源投入、市场优势等；哦！对了！还有重要的一点就是“战略壁垒”，为什么呢？这一点主要是针对被Copy和产品包括来做的，这一点或许决定着整个产品的成败，但是如果说有些公司有特殊的资源那就另一码事！ 二、MRD是针对谁看的呢？一般都是商务、运营、市场人员，那么他们需要了解的是什么呢？整个文档对于他们的重要性？ 1、我们要找什么样的客户，进行资源合作 一般公司资源合作的都是商务和市场人员，或者加上运营人员，那么他们是资源拓展者，对于产品保驾护航，正如船要出海，就必须有在海里或者有水的地方，海的大小决定了船的大小，所以他们就是船的载体，不可能产品开发完介入吧？要是真是这样，那就当这里我没有说！商务、市场及运营人员在产品之前必须对于产品进行资源拓展，且快速评估产品的实现情况，MRD就是给他们一个清楚的方向，我该找什么样的客户，在这里或许有的朋友就问题了?n你没有产品这些人员不可能空说吧，看到客户该怎们沟通，这一块就是项目与运营之间一种Demo沟通了，在这里暂时不说了！ 2、找到客户后，我们该怎么和他们说 上面说了MRD指引着商务、市场和运营往前走，那么找到客户该怎么和他们说呢？除了文档描述一个清晰的蓝图，或者说从红海中挖出新的路子，这里边就是MRD中的业务模式了，通过业务模式，可以看到清晰的产品，且客户可以看到他们在中间的位置，甚至说他们怎么赢利；一般给客户看到的都是PPT+Demo的方式，这样对于客户更直观更易于理解，所以MRD的文档就是给团队和客户一个说明； 3、产品针对什么样的用户群体 商务是资源拓展的关键、市场是产品保障的关键、则运营就是产品的推手，那么市场和运营就需要了解产品是针对什么用户群体的，毕竟最终的是使用人群是用户，MRD基本需要明确产品的用户人群，这样市场才能更好的进行分析，通过分析这个人群，给运营提供很好的参考资料，这样运营在推广这部分人群的时候也能够制定出很好的方案，资源优化及减少资源消耗，这就是MRD对于商务、市场、运营的关键作用； 最终MRD就浓缩为产品模式、业务模式、运营模式、市场模式等，明确客户及市场方向！ 三、PRD是针对谁看的呢？一般都是项目组、开发组、测试组、策划组、体验组人员； 1、产品具体是什么样的呢？ 对于与产品相关的人员，就必须有一个清楚的产品概念，这个产品到底是干嘛的？插句话说，公司对于人员有一个硬管理文化，这就是公司的管理制度，而产品则是公司的软文化，让每一个参与产品的人都有一个“产品梦”，变成一群有产品信仰的人，无形中就会增加团队的战斗力。话扯回来了！要了解到底是什么产品，那就需要详细而简单的进行说明，但是这个只能是描述，还需要有与策划、开发、测试等另一种沟通语言，那就是UI、UE、原型图、流程图等，这样方便策划及开发人员的工作进展! 2、我们该怎么实现呢？ 该怎么实现，那就是规划了，包括时间、人力、资源等，什么时间完成什么事了！在前进的路上设立一些里程碑！这就对于产品经理来说就是一个挑战了？为什么呢？因为产品经理与商务、市场、运营沟通的方式和开发人员方式不一样，有什么不一样呢？商务、市场、运营更多的是发散型思维，而开发则更多是紧密型思维，对于开发人员的沟通则不能用“基本”“差不多”“还好”等这样的词来进行沟通，否则开发人员会开始发散，如果发散的和你一致的话，你就烧高香吧，如果不一致，对于程序来说推导再来，就不是那么容易的了！甚至出现了大量的BUG，有时候过多的BUG会让一个产品死掉！ 所以就需要有详细的功能说明，细化到什么程度了，用YN原则来说明，VISIO是甚好的工具，不能出现模凌两可的语句，甚至需要通过语句进行if else描述，对了还有default，这个很关键，当程序运行正确了那固然好，如果程序出现BUG，则你不能让程序没有出口吧，那就是default了，给程序的BUG找一个合理的理由！ 3、什么样的产品才能投入到市场？ 产品开发人员更多的是站在产品角度思考问题，以实现产品而完成产品，那么产品最终开发完后，是不是能够满足运营需求呢？这时候产品经理就需要进行产品审核！怎么审核呢？简单的依据于之前的详细功能说明来进行需求审核，但是需求审核只是测试走完了第一步，第二步就是黑盒、白盒、甚至灰盒测试，走完第二部还有第三步，那就是需求优化，怎么优化呢，依据于市场人员及运营人员提供的用户数据来进行，再让产品设计人员进行UI优化，立足站在用户的角度；第三步完成了，就是最终的步骤了，体验师就起了关键性的作用，AB原则就出来了，将产品上线，体验师们就开始采集用户信息进行分析了，这个阶段对于产品的整个战略规划很关键，因为用户对于产品的第一感觉非常重要，如果是互联网产品则你可以换个网站，反正用户没法删除你的网站，但是对于移动互联网的产品APP来说，就是一个挑战了，看着不顺眼就直接给删除了，你说你的产品还有第二次机会进入用户的手机吗？除非你搞特殊！ PRD最终浓缩下就是产品界面、产品流程、功能需求、测试需求、体验需求等，保证产品有效率有节奏的进行！关系到整个产品的发展方向！
插入图片
开会
3. 产品经理与运营MM与开发GG与设计师的关系
运营
所谓运营，就是拉新、促活、留存、付费。 1 基本上，所有的互联网产品都会涉及到活动运营，而且活动运营也是一种非常好的运营手段，每个活动都有明确的目的，围绕对应的目标，而活动运营人员要做的事情就是为了达成这个目标。 2 而纯交易或工具产品涉及内容运营则较少，如淘宝天猫、美图秀秀、墨迹天气、美团外卖，这样的产品即使有内容运营的分工，也不会很重要。 3 用户运营 用户运营是每个产品的核心工作，因为其他所有的运营最后的指标都会落实到产品的运营效益上来，而这个产品效益则基本上就是用户数或者是用户产生的交易额、利润等。 4 其他运营，如新媒体运营、社群运营、渠道运营、品牌运营等等 5、冷启动 那么，产品经理在日常工作中，应该如何和运营人员进行沟通呢？ 1、明确产品定位和产品价值 很多时候产品和运营进行的争吵，就在于对产品定位和产品价值的理解上有分歧，比如说产品经理反对运营人员做某一个活动，是因为产品经理觉得这项运营活动是违背了产品的定位和相关价值的，而运营人员则不觉得如此。 所以，很多问题的原点可以回到产品定位，如果一个需求或者活动、内容与产品的定位不符，则大家可以回到产品定位去继续思考、讨论，以避免更多无意义的争吵。产品经理如果想让运营更好理解产品和用户，可以把产品介绍文档、需求文档、竞品分析报告等相关的文件给到运营去学习了解。 2、运营流程需要明确 运营人员经常会在线上做一些运营活动，那么对于这个活动来说，就有自己的活动规则和活动流程，好的运营是能够将规则和流程用非常清晰的文档展现出来的，这个时候的产品经理则省事很多，仅仅需要对其文档进行相关解读就好了；而碰到不是那么靠谱的运营，光是活动的流程、规则文档都没有，而且还动不动常常临时修改活动流程和规则，这个时候，就给产品团队及开发团队造成了很大的干扰。 所以，产品经理务必与运营人员沟通清楚活动流程和相关规则，否则不靠谱的名头就会落在产品经理自己身上。 3、产品需求决策权需明确 产品经理作为产品整体功能设计的负责人，决策权是必须有的，也无可厚非，当然这里可以指产品部门。如果你的公司不是一家纯粹的互联网公司，而是传统行业转型过来的，会有这样的问题：运营人员经常随意提需求，要求你务必完成，你又没办法拒绝，又担心被人投诉。 这些涉及到跨部门权责的，应该由部门主管进行领导推进，确立产品经理在需求决策权的地位。注意，这个时候，运营人员往往会认为你在剥夺权利，所以应该在老板的认同下，与对方进行有理有据的沟通，明确让运营知道：你的需求可以提，但是需要经过产品经理的调查研究确定是否需要做。
开发
技术思维与产品思维
1. 电商产品经理 以目前我所在的电商领域为例，电商类产品的特点是重业务流，从商品信息流、物流、资金流闭环角度去进行产品设计。 例如用户下单后，系统会根据商品归属的商家、所在仓库、配送方式等不同维度对订单进行拆分，俗称“拆单”。 在直观感受上，大家平时下单支付完成后，在订单详情里会看到，之前一起结算的商品被拆分成了几个子订单，俗称“子单”，而被拆分以前的订单统一叫“父单”。 以京东为例，京东目前经营的商品分为自营和第三方经营，如果按是否自营商品进行拆单，拆单后，自营商品由京东自有仓发货，而第三方商家的商品由第三方自主发货。 从技术角度去理解上述拆单的过程，首先得从商品维度去理解系统是如何对自营商品和第三方商品进行划分的。 这里就引出了数据结构的概念。 在电商产品的数据结构设计中，商品数据是其中一个主体，包括了商品编号、名称、型号、颜色等各种属性，这些都可以被称为商品的数据字段；在这些字段中，我们需要为商品增加一个字段，这个字段就专门用来标记是自营还是第三方。 同理，商品有数据结构，订单也有自己的数据结构，例如订单编号、配送信息、商品信息等。 注意：订单数据里是包括了商品基本信息的，但不会包括完整的商品信息。 例如订单里我们能看到商品编号、名称等，但其他的完整信息是在商品数据里存储的——这里就引出了数据库表和表之间关联结构的概念。 产品经理需要对什么是数据结构、数据库表、表与表之间的关联关系进行理解，从技术角度理解原理后，再回到业务和产品角度来看问题，很多底层理解就和工程师基本一致了。 至于究竟如何建立数据结构以及如何操作数据库，就不在产品经理应该关注的范围内——前者叫技术思维，后者是技术能力。 在电商产品中，产品经理对各种业务流的理解以及从技术角度去拆解这些业务流是做好产品的基础。
设计师
UI/UX（也称产品设计师）
UI（User Interface）使用者介面，主要专业是设计页面上的功能、顾及使用的便利性与整个设计的美学，网站的美观性和他息息相关；UX（User Experience）使用者体验，则是根据使用者的习惯，安排整个网站页面的内容规划，像是哪些区块的内容要先在网站上出现，行动呼吁按钮（Call to Action, CTA）的位置应该摆在哪里。
与设计师的互动
告诉我为什么？
不重复造轮子
可用性第一
完整的用户流
4. 产品工作的几个名词解释
BRD
MRD
PRD
III. 电商行业与电商产品详解
淘宝，京东，亚马逊，PDD
1. 电商行业发展史
C2C
B2C
O2O
S2B2C
2. 电商行业盈利模式
下面为大家介绍几种最简单的盈利模式： 实物商品盈利模式 1、自己生产、自己销售 自己直接生产、直接销售给用户。 2、外包生产、自己销售 把生产环节外包出去，自己负责直接销售给用户。 3、只生产、不销售 自己负责生产，交给分销商销售。 4、只销售、不生产 自己作为分销商，或者提供销售商品的交易市场。 广告盈利模式 1、展示广告 一般形式是文字、banner 图片、通栏横幅、文本链接、弹窗等，通常是按照展示的位置和时间收费，这是目前最常见的模式了。 2、广告联盟 相当于互联网形式的广告代理商，广告主要在广告联盟上发布广告，广告联盟再把广告推送到各个网站或APP里去，一般是按广告的点击次数收费。 3、电商广告 一般是按销售额提成付费。 4、软文 把广告内容和文章内容完美结合在一起，让用户在阅读文章时，既到了他需要的内容，也了解了广告的内容。 5、虚拟产品换广告效果 可以为用户提供免费虚拟产品，但是代价是接受一定的广告，如看完一段广告、注册某个网站的用户、下载某个APP等。 6、用户行为数据 通过分析用户在网站或APP上的操作方式，可以分析用户的习惯和心理，从而有利于在产品设计和商业规划上做出正确的决策。 交易平台盈利模式 1、实物交易平台 用户在平台上进行商品交易，通过平台支付，平台从中收取佣金。（天猫） 2、服务交易平台 用户在平台上提供和接受服务，通过平台支付，平台从中收取佣金。（滴滴打车） 3、沉淀资金模式 用户在平台上留存有资金，平台可以用这些沉淀的资金赚取投资收益回报。传统零售业用账期压供应商的货款，就是为了用沉淀的资金赚钱，现在这个套路也应用到互联网行业了，很多互联网金融行业、O2O企业也是寄希望于这个模式。 直接收费盈利模式 1、定期付费模式 这种商业模式类似于手机话费的月套餐，定期付钱获得一定期限内的服务。相当于一次性消费直接买软件，定期付费的单笔付费金额比较小，所以用户付费的门槛比较低。 2、按需付费 是用户实际购买服务时才需要支付相应的费用。 3、打印机模式 先以一个很便宜的价格卖给消费者一个基础性设备，但用户如果要使用这个设备，就必须以另一高价继续购买这个设备的其他配件进行使用。 免费增值盈利模式 1、限定次数免费使用 2、限定人数免费使用 3、限定免费用户可以使用的功能 4、应用内购买 5、试用期免费 6、核心功能免费，其他功能收费 7、核心功能免费，同时导流到其他付费服务 8、组织活动 通过免费服务聚集人气，然后组织各种线下活动，这些活动可以获得广告或赞助，或者在活动中销售商品或服务。 总之，互联网的世界里从来不缺少盈利的方法，还有很多更加复杂、巧妙的盈利模式，所以要想通过互联网盈利模式，商家应该做的回归本质，做好产品、获取用户的口碑，不要在根基不稳的时候过于担心未来如何赚钱的问题。
实物商品盈利
生产或销售的排列组合
广告盈利
注：用户数据也有用
交易平台盈利
实物交易抽佣
服务交易抽佣
沉淀资金压账期投资盈利
直接付费盈利
定期付费
按需付费
打印机模式付费
3. 跨境电商行业特质
模式
做平台
做外贸
做第三方平台卖家
做独立站
难点
语言文化
时差
仓储物流
售后
获客
4. 电商产品概念讲解
作者：Vuder 链接：https://www.zhihu.com/question/27136892/answer/160739465 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 作为一个基本啥都做过的产品经理来稍微说一下后端产品的事情。 后端产品是什么？ 产品经理这个词，可以以很多种形式进行分类。个人的观点是对产品的设计规划到具体实施的整个生命周期和价值的实现负责的人就是产品经理。一个完善庞大体系下的产品的产品经理就是CEO本身；而互联网上单独一个可独立运转的模块其实也构成一个产品，其背后的产品经理可能是产品人员、运营人员、技术人员或设计人员。 无论如何，体系中总会有一个人主导完成工作并明确整个工作需要达到的关键方法和成果，同时起到了开发者和使用者沟通的桥梁作用，我一般就把他叫做产品。 今天要说的不是被大家用各种场景思维、用户体验、用户价值、运营转化各种轰炸已经概念泛滥的前端产品经理（先为前端产品经理经常被当作UI默哀三分钟），而是一般默默躲在服务器后端，每次都拿出一堆别说用户不理解，老板也很少细看的文档的后端产品经理（为后端产品经理和项目经理经常混为一谈默哀三分钟）。嗯，有些时候由于To B业务一般都是后端产品经理的范围，很多人也会把后端产品称为B端产品。 前端产品经理的关键词在于：用户、场景、体验、转化、价值挖掘。在根据用户和市场挖掘需求。 后端产品经理的关键词在于：业务、逻辑、跨越、结构、控制、数据。在根据业务和发展规划需求。 后端产品经理的价值在于什么呢？举个例子。像京东天猫这样的电子商务网站，我们看到的商品背后涉及一整套的类目配置、商品录入、上架、审核的各个业务流转业务；每次搜索涉及整套的商品排序和展示策略；购买下单时涉及背后的库存锁定、抵用券的计算、支付接口的调用；而交易后的数据会同时统计到商家后台的数据已各种视图显示出来等等等...在用户看来完成一个简单的”购买“过程，在用户互联网上极致的交互操作背后，为保障其背后支撑的复杂的业务逻辑和业务结构顺利运转，还需要优秀的后端技术人员和产品经理的辛勤工作。 后端产品经理是整个后端业务需求的整理者，需要串起整个业务的前中后所有流程。后端业务往往并不像前端需求那样简单易于理解，而且会涉及信息输入者、信息处理者、信息接收者、信息管理者出现完全不同的情况，这 要求后端产品经理的首要目标就是理解业务的全貌，能够让业务正确的运转并对效果进行评估，能将充满个性化理解与执行的业务过程通过与业务各端人员进行平衡和协调以确定标准化方案。 后端产品的一般特征？ 后端产品一般会具备下述一个或者几个点需要进行设计与考虑： 1.业务流转 - 多节点效率配合 业务会需要在不同的操作者、模块、系统中流转，复杂的业务流转的梳理是产品经理一个最基础也是最重要的工作之一。产品经理需要认真考虑如何将业务拆分为必要的节点，并正确设计好节点之间的关系。保障不好业务流转，后台运营人员要骂娘加班，HR天天面临人力压力，技术天天手工写数据库。很多时候，除了技术之外，各角色之间的实际关系与作用也需要考虑在内。 2.管理配置 - 信息管理操作 后台对数据的标准化录入、导入、状态管理、数据修改等，核心在于通过后台操作影响前端的生成、展示、功能、活动、资源信息等。前端包括文字详情、活动页面、展示列表、价格参数等都是后台配置管理的范围。配置后台在初期往往是交由开发者处理即可，但随着系统关联度的上升，功能之间的相关影响，运营操作效率对业务的影响，以及后台可能的开放过程，管理配置功能往往复杂类似矩阵化结构，需要一个优秀产品经理的把控。当然有些时候产品的修改反而会造成不利影响，因为主要操作者“已经习惯了”原有产品。 3.系统对接 - 内外数据交换 对接内部外部的不同系统，以各种形式包括爬取、导入、接口或服务形式传输数据。产品经理需要认真考虑系统与系统之间的关系，以及数据之间的同步和调用方式。与外部合作盘活生态是开放的互联网必不可少的一部分。如果产品涉及业务够复杂或是老板谈下的合作项目越大，就有越多的精力花在对接的梳理上，所以经常会在各种奇怪的对接会议上看到产品经理的角色存在。 4.算法策略 - 数据转化输出 将数据重新进行处理输出，常说的人工智能、大数据也是其中一种应用方式。可应用范围从滴滴的车单派送、百度的搜索引擎、qq每天的弹框广告到信用征信、人脸识别、垃圾邮件过滤都属于计算机算法的研究范围。属于互联网产品中最讲究技术的部门。如何能够将前沿技术和实际的商业应用做结合，如何来评估算法策略的在实际应用中目标和效果，如何利用技术优势保持行业领先，是这个领域的程序员和产品经理最关注的事宜。 5.统计分析 - 业务价值挖掘 简单来讲就是将业务复杂的过程进行数据化的监控。可以是操作的数据日志，可以是购物车每一层的转化率，可以是某类目产品的订单变化情况...需要将数据重新进行一些列的数据埋点、数据收集、数据清洗、数据挖掘、数据建模、数据可视化，以通过数据对业务进行分析、理解，并影响业务和工作的进展。最终的产物可能是一个excel，一个dashboard也可能是一个改变公司的数字。人员众多的大型商业公司的可能会需要成立专门的BI部门负责，如果公司不大，很多时候还是需要一个产品经理结合业务来把控需求。 6.安全管控 - 数据保护 对整个后台系统进行管理，保障合适的人接触和使用到合适的功能及数据，同时保证不要被一些弱智的设计导致数据错乱、误操作及安全泄露。包括账号管理、权限设计、流程控制、操作留痕、防呆设计、备份同步都属于从安全可控角度考虑的范围。有些时候业务会涉及很多资质类 哪些是后端产品 CRM、ERP、DSP、DMP、订单、支付、爬虫、搜索、精准化、活动、财务...... 后端产品的核心关键词 业务——后端产品经理推进的是整个业务环节的完成，不完成整个业务环节永远得不到及格分数。 逻辑——复杂多方如何经过产品经理层层梳理找到最优化的标准化解决手段，需要处理纷繁错杂的逻辑关系不出错。 跨越——跨项目沟通、跨部门协调、跨公司交流、跨行业学习。 结构——系统结构，运营人员关系，各种复杂度、稳定性、扩展性都需要有序的模块化的考虑进去，以达到最大效率的设计结果。 控制——开发周期可控、业务风险可控、实现手段可控、权限可控、数据可控、流程可控、错误可控。 数据——后端的核心输出围绕就是数据 后端产品的项目工作流 认知->关联->重构->执行->修正 认知——通过文档、沟通、学习等各种方式了解业务、了解业务背后的逻辑、了解业务执行的人的痛点和利益点、了解原有系统关系和关键点、了解项目的资源和时间期望等，收集项目资料与行业知识。 关联——将资料进行重新整理，勾画出各条关系结构与流程，整理关键的要素与信息，获取相关的资源支持，掌控可控资源。 重构——将信息、要素、资源进行重新整合，设计出系统架构并拆分填充细节，确认核心功能点与迭代计划。 执行——推进项目的立项、方案的确立与资源的到位，进行项目的开发。 修正——对项目结果进行评估，将执行结果要素重新整合进入下一期工作流。 后端产品经理的核心能力 业务把控能力/全局把控 沟通交流能力/资源整合 技术知识经验/可行判断 逻辑整合能力/思考设计 项目管理能力/执行推动 后端产品的常用工具 VISIO——用例图、流程图、泳道图、时序图......在让别人弄清楚之前，先让自己弄清楚复杂的关系吧。 Xmind（其他脑图亦可）——发散一下脑洞，把需要关联的事务都放上去重新整理好。 EXCEL——真的需要把细项像矩阵一样样列出来，你看数据也经常要用的。 WORD——嗯，你需要写的各种PRD、功能说明、接口关系、图都在这边。 数据库查询——你都能查的出来的东西技术就只有开发量没有难度。 PPT——和你的嘴一样是对老板神器 AXURE（其他原型工具亦可）——让操作符合人性 邮件、微信、QQ——找人学习、找人对接、找人交流、找人干活、找人开会。 产品系列（五）- 产品的前端 、后端和管理后台是什么关系 做产品经理的工作，经常能听到前端，后端，管理后台，这几个词在耳边绕来绕去，今天我们捋一捋他们是什么及彼此间的关系。 应用或者网站，对于一个普通用户而言，可以感知到的只是产品的前端，直观上是由一系列页面组成的。产品前端作为传感器，负责上传、下载数据及响应用户需求。尤其在前后端分离的趋势下，前端获取页面模板和接口数据，完成渲染（拼装页面），与用户交互，简言之：前端负责展现逻辑。 从用户角度来看，完全感知不到的产品后端的存在，它在整个产品中扮演什么样的角色？一言以蔽之：后端负责业务逻辑，提供技术支持，接口实现。接口是什么呢，接口是一组能力，一种承诺。和前端约好调用方法参数标准以后，前端在交互中响应用户需求，来调用指定接口，此时后端程序负责功能具体实现（总的来说就是对数据库得读和写），完成后将结果通过约好的方式传回前端，称为接口回调。 整个调用过程可以打个不恰当的比方，拿餐馆来讲：前端相当于店小二，负责招呼客人，和客人交流，听取客人需求（点什么菜，有什么忌口，不吃辣，速度要快），之后把需求传递给厨房（后端接口），厨师根据传递的信息负责拿菜洗菜做菜（对数据操作，实现具体功能），做好之后，再由店小二呈现给用户，自始至终用户只能感知到店小二（产品前端），和他交流自己的要吃什么饭，有什么要求（通过前端交互）。 互联网产品，交互基本就是在不同的页面之间跳转，或者在页面内点击某些按钮，填写部分内容，之后得到自己想要的结果，所以有句话说得好：看得见的前端，看不见的后端。后端作为实际功能的实现者（厨师完成做菜，小二负责呈现），深藏功与名，让我们一起为无名英雄点赞！其实还远不止如此，实际情况下，后端为了保证产品的扩展性和稳定性，要做大量的工作：负载均衡，各种缓存策略，高可用，CDN，业务分层，读写分离，网络传输，架构迭代等等一系列工作。 至此，大家以为整个产品OK了么？没有，还少了一个角色：老板，是的，这个角色很关键。做了一天生意，忙活辛苦了一天，是赚了还是赔了，如果赚了，赚了多少。管理后台差不多就是解答类似问题的角色了。 对于业务型管理后台而言，核心功能主要包含以下几个模块：资源管理，任务管理，效果管理，用户管理。其中资源管理主要负责资源的提交发布，拿餐馆来说，就是提供哪些菜品，什么价位，酸甜苦辣什么味，这些属性是由管理后台的资源管理来定；任务管理主要处理审核前端用户的行为，比如用户觉得这个菜不好吃，要退或者其他找茬，小二搞不定，厨师做不了主，只好汇报老板，老板做决策处理；效果管理主要指产品整体的效果，对数据整理分析：今天餐馆来了多少用户，点了多少菜，卖了多少钱，赚了多少钱，哪道菜被点的多，用户客单价是多少，有多少用户点了菜等不及退单了，所有这些都要通过后台数据监测分析，之后基于数据优化调整，才能让餐馆的体验更好，用户更多，以上基本就是管理后台的作用了，挺重要吧，老铁。 简单总结下：前端负责响应用户，获取需求后传给后端，后端负责具体实现，通过接口回传，然后前端呈现结果，管理后台负责资源提供，任务处理及效果分析，三者相互配合，保证整个产品的正常运转。 店小二（前端），厨师（后端）和老板（管理后台）一起将餐馆开的红红火火，前几年还是不满十人的小店，现在已经是全国连锁，听说过不久要美股上市，老板带着伙计们一起去纳斯达克敲钟呢。
要加入示意图片
前台产品
商品展示
站内搜索
导航
着陆页
内容展示
公告
帮助中心
品牌价值
等等.............
交易过程
购物车
订单提交与结算
支付
用户中心
登录注册
订单中心
服务中心
信息管理
等等........
后台产品
商品
商品管理
基础数据
会员
登录注册
用户数据
用户运营
订单
系统服务
订单流转
查询服务
售后
渠道支持
线上
线下
交易流水（记录支付信息）
运营
CMS
营销系统（优惠、活动）
风控
工单（客服）
评价系统
店铺管理
财务
用户退款
供应商结算
销售渠道结算
其他结算
数据
商品数据
用户数据
订单数据
埋点数据
WMS
入库管理
出库管理
库存同步
中台产品
中台的概念
业务中台
在有些人眼里：中台就是微服务业务平台，像最常见的什么用户中心，订单中心，各种微服务集散地，人们都叫它“业务中台”
组织中台
在有些人眼里：中台应该是组织的事情，在释放潜能：类似于企业内部资源调度中心和内部创新孵化组织，人们叫它“组织中台”。
技术中台
在有些人眼里：中台就是技术平台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的，人们都叫它“技术中台”。
前端与后端
关于前后端产品-有价值的回答
作者：Vuder 链接：https://www.zhihu.com/question/27136892/answer/160739465 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。 作为一个基本啥都做过的产品经理来稍微说一下后端产品的事情。 后端产品是什么？ 产品经理这个词，可以以很多种形式进行分类。个人的观点是对产品的设计规划到具体实施的整个生命周期和价值的实现负责的人就是产品经理。一个完善庞大体系下的产品的产品经理就是CEO本身；而互联网上单独一个可独立运转的模块其实也构成一个产品，其背后的产品经理可能是产品人员、运营人员、技术人员或设计人员。 无论如何，体系中总会有一个人主导完成工作并明确整个工作需要达到的关键方法和成果，同时起到了开发者和使用者沟通的桥梁作用，我一般就把他叫做产品。 今天要说的不是被大家用各种场景思维、用户体验、用户价值、运营转化各种轰炸已经概念泛滥的前端产品经理（先为前端产品经理经常被当作UI默哀三分钟），而是一般默默躲在服务器后端，每次都拿出一堆别说用户不理解，老板也很少细看的文档的后端产品经理（为后端产品经理和项目经理经常混为一谈默哀三分钟）。嗯，有些时候由于To B业务一般都是后端产品经理的范围，很多人也会把后端产品称为B端产品。 前端产品经理的关键词在于：用户、场景、体验、转化、价值挖掘。在根据用户和市场挖掘需求。 后端产品经理的关键词在于：业务、逻辑、跨越、结构、控制、数据。在根据业务和发展规划需求。 后端产品经理的价值在于什么呢？举个例子。像京东天猫这样的电子商务网站，我们看到的商品背后涉及一整套的类目配置、商品录入、上架、审核的各个业务流转业务；每次搜索涉及整套的商品排序和展示策略；购买下单时涉及背后的库存锁定、抵用券的计算、支付接口的调用；而交易后的数据会同时统计到商家后台的数据已各种视图显示出来等等等...在用户看来完成一个简单的”购买“过程，在用户互联网上极致的交互操作背后，为保障其背后支撑的复杂的业务逻辑和业务结构顺利运转，还需要优秀的后端技术人员和产品经理的辛勤工作。 后端产品经理是整个后端业务需求的整理者，需要串起整个业务的前中后所有流程。后端业务往往并不像前端需求那样简单易于理解，而且会涉及信息输入者、信息处理者、信息接收者、信息管理者出现完全不同的情况，这 要求后端产品经理的首要目标就是理解业务的全貌，能够让业务正确的运转并对效果进行评估，能将充满个性化理解与执行的业务过程通过与业务各端人员进行平衡和协调以确定标准化方案。 后端产品的一般特征？ 后端产品一般会具备下述一个或者几个点需要进行设计与考虑： 1.业务流转 - 多节点效率配合 业务会需要在不同的操作者、模块、系统中流转，复杂的业务流转的梳理是产品经理一个最基础也是最重要的工作之一。产品经理需要认真考虑如何将业务拆分为必要的节点，并正确设计好节点之间的关系。保障不好业务流转，后台运营人员要骂娘加班，HR天天面临人力压力，技术天天手工写数据库。很多时候，除了技术之外，各角色之间的实际关系与作用也需要考虑在内。 2.管理配置 - 信息管理操作 后台对数据的标准化录入、导入、状态管理、数据修改等，核心在于通过后台操作影响前端的生成、展示、功能、活动、资源信息等。前端包括文字详情、活动页面、展示列表、价格参数等都是后台配置管理的范围。配置后台在初期往往是交由开发者处理即可，但随着系统关联度的上升，功能之间的相关影响，运营操作效率对业务的影响，以及后台可能的开放过程，管理配置功能往往复杂类似矩阵化结构，需要一个优秀产品经理的把控。当然有些时候产品的修改反而会造成不利影响，因为主要操作者“已经习惯了”原有产品。 3.系统对接 - 内外数据交换 对接内部外部的不同系统，以各种形式包括爬取、导入、接口或服务形式传输数据。产品经理需要认真考虑系统与系统之间的关系，以及数据之间的同步和调用方式。与外部合作盘活生态是开放的互联网必不可少的一部分。如果产品涉及业务够复杂或是老板谈下的合作项目越大，就有越多的精力花在对接的梳理上，所以经常会在各种奇怪的对接会议上看到产品经理的角色存在。 4.算法策略 - 数据转化输出 将数据重新进行处理输出，常说的人工智能、大数据也是其中一种应用方式。可应用范围从滴滴的车单派送、百度的搜索引擎、qq每天的弹框广告到信用征信、人脸识别、垃圾邮件过滤都属于计算机算法的研究范围。属于互联网产品中最讲究技术的部门。如何能够将前沿技术和实际的商业应用做结合，如何来评估算法策略的在实际应用中目标和效果，如何利用技术优势保持行业领先，是这个领域的程序员和产品经理最关注的事宜。 5.统计分析 - 业务价值挖掘 简单来讲就是将业务复杂的过程进行数据化的监控。可以是操作的数据日志，可以是购物车每一层的转化率，可以是某类目产品的订单变化情况...需要将数据重新进行一些列的数据埋点、数据收集、数据清洗、数据挖掘、数据建模、数据可视化，以通过数据对业务进行分析、理解，并影响业务和工作的进展。最终的产物可能是一个excel，一个dashboard也可能是一个改变公司的数字。人员众多的大型商业公司的可能会需要成立专门的BI部门负责，如果公司不大，很多时候还是需要一个产品经理结合业务来把控需求。 6.安全管控 - 数据保护 对整个后台系统进行管理，保障合适的人接触和使用到合适的功能及数据，同时保证不要被一些弱智的设计导致数据错乱、误操作及安全泄露。包括账号管理、权限设计、流程控制、操作留痕、防呆设计、备份同步都属于从安全可控角度考虑的范围。有些时候业务会涉及很多资质类 哪些是后端产品 CRM、ERP、DSP、DMP、订单、支付、爬虫、搜索、精准化、活动、财务...... 后端产品的核心关键词 业务——后端产品经理推进的是整个业务环节的完成，不完成整个业务环节永远得不到及格分数。 逻辑——复杂多方如何经过产品经理层层梳理找到最优化的标准化解决手段，需要处理纷繁错杂的逻辑关系不出错。 跨越——跨项目沟通、跨部门协调、跨公司交流、跨行业学习。 结构——系统结构，运营人员关系，各种复杂度、稳定性、扩展性都需要有序的模块化的考虑进去，以达到最大效率的设计结果。 控制——开发周期可控、业务风险可控、实现手段可控、权限可控、数据可控、流程可控、错误可控。 数据——后端的核心输出围绕就是数据 后端产品的项目工作流 认知->关联->重构->执行->修正 认知——通过文档、沟通、学习等各种方式了解业务、了解业务背后的逻辑、了解业务执行的人的痛点和利益点、了解原有系统关系和关键点、了解项目的资源和时间期望等，收集项目资料与行业知识。 关联——将资料进行重新整理，勾画出各条关系结构与流程，整理关键的要素与信息，获取相关的资源支持，掌控可控资源。 重构——将信息、要素、资源进行重新整合，设计出系统架构并拆分填充细节，确认核心功能点与迭代计划。 执行——推进项目的立项、方案的确立与资源的到位，进行项目的开发。 修正——对项目结果进行评估，将执行结果要素重新整合进入下一期工作流。 后端产品经理的核心能力 业务把控能力/全局把控 沟通交流能力/资源整合 技术知识经验/可行判断 逻辑整合能力/思考设计 项目管理能力/执行推动 后端产品的常用工具 VISIO——用例图、流程图、泳道图、时序图......在让别人弄清楚之前，先让自己弄清楚复杂的关系吧。 Xmind（其他脑图亦可）——发散一下脑洞，把需要关联的事务都放上去重新整理好。 EXCEL——真的需要把细项像矩阵一样样列出来，你看数据也经常要用的。 WORD——嗯，你需要写的各种PRD、功能说明、接口关系、图都在这边。 数据库查询——你都能查的出来的东西技术就只有开发量没有难度。 PPT——和你的嘴一样是对老板神器 AXURE（其他原型工具亦可）——让操作符合人性 邮件、微信、QQ——找人学习、找人对接、找人交流、找人干活、找人开会。 产品系列（五）- 产品的前端 、后端和管理后台是什么关系 做产品经理的工作，经常能听到前端，后端，管理后台，这几个词在耳边绕来绕去，今天我们捋一捋他们是什么及彼此间的关系。 应用或者网站，对于一个普通用户而言，可以感知到的只是产品的前端，直观上是由一系列页面组成的。产品前端作为传感器，负责上传、下载数据及响应用户需求。尤其在前后端分离的趋势下，前端获取页面模板和接口数据，完成渲染（拼装页面），与用户交互，简言之：前端负责展现逻辑。 从用户角度来看，完全感知不到的产品后端的存在，它在整个产品中扮演什么样的角色？一言以蔽之：后端负责业务逻辑，提供技术支持，接口实现。接口是什么呢，接口是一组能力，一种承诺。和前端约好调用方法参数标准以后，前端在交互中响应用户需求，来调用指定接口，此时后端程序负责功能具体实现（总的来说就是对数据库得读和写），完成后将结果通过约好的方式传回前端，称为接口回调。 整个调用过程可以打个不恰当的比方，拿餐馆来讲：前端相当于店小二，负责招呼客人，和客人交流，听取客人需求（点什么菜，有什么忌口，不吃辣，速度要快），之后把需求传递给厨房（后端接口），厨师根据传递的信息负责拿菜洗菜做菜（对数据操作，实现具体功能），做好之后，再由店小二呈现给用户，自始至终用户只能感知到店小二（产品前端），和他交流自己的要吃什么饭，有什么要求（通过前端交互）。 互联网产品，交互基本就是在不同的页面之间跳转，或者在页面内点击某些按钮，填写部分内容，之后得到自己想要的结果，所以有句话说得好：看得见的前端，看不见的后端。后端作为实际功能的实现者（厨师完成做菜，小二负责呈现），深藏功与名，让我们一起为无名英雄点赞！其实还远不止如此，实际情况下，后端为了保证产品的扩展性和稳定性，要做大量的工作：负载均衡，各种缓存策略，高可用，CDN，业务分层，读写分离，网络传输，架构迭代等等一系列工作。 至此，大家以为整个产品OK了么？没有，还少了一个角色：老板，是的，这个角色很关键。做了一天生意，忙活辛苦了一天，是赚了还是赔了，如果赚了，赚了多少。管理后台差不多就是解答类似问题的角色了。 对于业务型管理后台而言，核心功能主要包含以下几个模块：资源管理，任务管理，效果管理，用户管理。其中资源管理主要负责资源的提交发布，拿餐馆来说，就是提供哪些菜品，什么价位，酸甜苦辣什么味，这些属性是由管理后台的资源管理来定；任务管理主要处理审核前端用户的行为，比如用户觉得这个菜不好吃，要退或者其他找茬，小二搞不定，厨师做不了主，只好汇报老板，老板做决策处理；效果管理主要指产品整体的效果，对数据整理分析：今天餐馆来了多少用户，点了多少菜，卖了多少钱，赚了多少钱，哪道菜被点的多，用户客单价是多少，有多少用户点了菜等不及退单了，所有这些都要通过后台数据监测分析，之后基于数据优化调整，才能让餐馆的体验更好，用户更多，以上基本就是管理后台的作用了，挺重要吧，老铁。 简单总结下：前端负责响应用户，获取需求后传给后端，后端负责具体实现，通过接口回传，然后前端呈现结果，管理后台负责资源提供，任务处理及效果分析，三者相互配合，保证整个产品的正常运转。 店小二（前端），厨师（后端）和老板（管理后台）一起将餐馆开的红红火火，前几年还是不满十人的小店，现在已经是全国连锁，听说过不久要美股上市，老板带着伙计们一起去纳斯达克敲钟呢。
附带的文件和图片