《产品经理必懂的技术那点事儿》思维导图
【干货】产品经理从零到一技术进阶：不懂代码也能愉快地与开发相处
什么是前端？什么是后端？二者是如何配合运转的？前后端的划分，可以简单地理解为凡是运行在用户设备上的技术都可以称为前端技术（比如HT ML / CSS / JS，甚至移动设备的 Obj-C / Swift ）；而后端的作用就是负责将这些东西封装在HT T P 的数据包中然后通过网络传送到前端。
当然除了这些前端文件，后端还有一个更重要的职能，即保存和提供用户数据，比如移动端常见的 JSON 就是目前最流行的在后端和前端之间传输的一个文件格式。
前端与后端是如何配合的？如上图，以 Web 端为例，在浏览器输入一个网址后，浏览器向服务器发送了一个 HT T P 请求；服务器通过一个 HT T P 响应，把显示这个网页所需要的资源传回给了浏览器。
而需要在浏览器中执行的技术，HT ML / CSS / Javascript 等就叫做前端；需要在服务器端执行的、通常我们看不到技术就叫做后端。
Web 前端的运行逻辑假设我们要访问 Google，从我们在浏览器输入 到最后这个页面出现在眼前，这其中涉及许多前端的技术反应和代码组合，总体而言可以简化为两步：1/ 浏览器向 Google 的服务器发送了一个请求。
2/ 服务器收到了一个 HT T P 响应，这个响应中就包含了执行这个命令所需要的所有资源（注：可以通过 Chrome 浏览器的开发者工具来进一步观察 HT T P 协议的运行情况；下图为 Google 的HT T P 协议运行情况）。
上图这个界面看起来很复杂，但对于非程序员而言，HT T P 协议运行情况只要关注其中的几个关键部分：第一列，即资源的 URL；第四列是这个资源的类型。
在第一个请求和后续的请求之间有一根蓝线，即进度条。
而 HT T P 协议中运行的项目越少，浏览器加载的速度越快。
图中 Google 就处理得很好，只有 10 个左右的请求。
Web 前端技术语言介绍HT ML 和带样式的 HT MLHT ML 就是一组标签和文本的组合，是一个最基本的网页。
产品经理必懂的技术 产品经理技术要求
产品经理必懂的技术开篇产品经理必懂的技术术语类、对象、抽象和实例⼯程师⼝中的“打印”是什么意思⼯程师⼝中的“写死”是什么意思架构和框架控件和组件进程与线程什么是“脚本同步处理和异步处理原⽣开发（Native）和⽹⻚开发（H5）数据接⼝（API）及数据传输格式（XML、JSON）什么是SDK（软件开发包）产品经理为什么要懂技术产品思维与技术思维产品思维：从⽤户价值出发，在满⾜商业战略和业务⽬标的同时寻找产品路径满⾜⽤户需求技术思维：从功能和⼯程出发，在满⾜产品需求的同时寻求可复⽤技术架构和低开发成本从技术⻆度判断产品需求的⼏个参考原则做新需求⽐改⽼需求相对容易、对原有产品⽅案做需求变更，会涉及到新⽼版本数据兼容问题业务逻辑越复杂，对应的技术⽅案越复杂程序和功能的关系什么是编程语⾔定义：⼈与计算机进⾏通讯的指令集分类机器语⾔（0和1）：IP地址汇编语⾔（符号标记）：域名⾼级语⾔（语义表达）通常情况下，不同技能的⼯程师掌握不同类型的编程语⾔Android⼯程师和iOS⼯程师的语⾔不同什么是程序通过⼀系列计算机指令的组合来完成⽬标动作程序=数据结构＋算法数据类型是编程语⾔中⽤来区分数据格式的标记⽤来区分不同数据类型的符号叫关键字整数类型：int浮点型：float，double字符串型：string布尔型：Boolean（true，false）程序逻辑结构：判断及分⽀结构switch case：控制选择逻辑，根据选择项执⾏对应的操作if else：控制判断逻辑，根据判断条件选择执⾏对应的操作while/for循环：循环逻辑，处理⼀定条件下的循环重复操作程序职能模块——⽅法⽅法：通过数据类型和逻辑判断的组合完成某个特定任务⼯程师每天写的代码就是程序，程序由不同的变量、数据类型、逻辑结构、⽅法组成程序是如何组装成功能的程序的最⼩执⾏单元——程序块程序块:多种数据类型和逻辑结构的组合产品功能与程序块的关系程序块相互关联运作，打包后组成了⼀个⼀个的产品功能程序世界⾥，不同的程序块负责不同的职能，例如：专⻔负责⽹络请求的程序块专⻔负责数据库操作的程序块专⻔负责业务逻辑的程序块不同的程序块通过相互“调⽤”的⽅式来实现协同，从⽽组成了产品功能。
产品经理 流程图
产品经理流程图产品经理流程图。
产品经理是一个非常重要的职位，他们需要负责产品的规划、设计、开发、上线和运营等工作。
在整个产品的生命周期中，产品经理需要制定一系列的流程图来指导和管理产品的各个环节。
下面将介绍产品经理在不同阶段所需要制定的流程图。
首先，在产品规划阶段，产品经理需要制定产品需求流程图。
这个流程图主要包括市场调研、竞品分析、用户调研、需求分析等环节。
通过这个流程图，产品经理可以清晰地了解用户的需求，找到产品的定位和切入点，为产品的后续开发工作奠定基础。
接下来是产品设计阶段，产品经理需要制定产品设计流程图。
这个流程图包括产品原型设计、UI设计、交互设计、视觉设计等环节。
通过这个流程图，产品经理可以指导设计师们按照一定的流程进行设计工作，确保产品的设计符合用户的需求和公司的定位。
然后是产品开发阶段，产品经理需要制定产品开发流程图。
这个流程图包括需求评审、技术方案设计、开发编码、测试验收等环节。
通过这个流程图，产品经理可以协调开发人员、测试人员和其他相关人员，确保产品按照计划顺利开发上线。
接着是产品上线阶段，产品经理需要制定产品上线流程图。
这个流程图包括上线准备、灰度发布、版本回滚、数据监控等环节。
通过这个流程图，产品经理可以指导运营团队按照一定的流程进行产品上线工作，确保产品的上线顺利进行并保证产品的稳定性。
最后是产品运营阶段，产品经理需要制定产品运营流程图。
这个流程图包括数据分析、用户反馈、功能优化、推广营销等环节。
通过这个流程图，产品经理可以指导运营团队进行产品的日常运营工作，不断优化产品，提升用户体验，推动产品的持续发展。
总之，产品经理在产品的各个阶段都需要制定相应的流程图来指导和管理工作。
这些流程图可以帮助产品经理清晰地了解工作的流程和环节，提高工作效率，确保产品的质量和进度。
因此，产品经理需要具备制定流程图的能力，以便更好地完成产品管理工作。
产品经理需要学习的技术(产品经理需要懂技术吗)
产品经理需要学习的技术（产品经理需要懂技术吗）总的来说：不一定。
有很多类型的产品经理没有必要懂技术，懂技术对于工作也没啥帮助，不如多花时间去了解业务。
只是当下随着互联网和AI的发展，涌现出来的一些新产品经理岗位，这些岗位懂技术已经是必备。
具体要不要懂技术以及懂什么技术栈，取决于你从事的是哪一种类型的产品经理。
先放一张汇总的图，后续细细展开。
一、技术的分类技术本身是一个十分笼统的概念，我们先对技术进行分类，分为四个大类：1.工程通过Java、C语言等写脚本实现系统的其中一功能或者是通过数据结构的改变提升系统其中一性能。
2.算法理解业务需求，完成数据清洗构建正负样本，构建特征工程；再基于Python语言，调用库包现成模型如GBDT等完成模型训练和测试；最终对模型进行部署上线。
3.数据分析基于对业务的了解构建一整套的数据分析体系，然后通过SQL和Hive等数据分析语言完成数据分析。
4.大数据基于海量的数据源开发各类底层的数据表格和数仓，通过Hadoop、Spark等构建各种数据流任务。
二、产品经理分类我们基于产品经理的工作内容将市场上的产品经理分为6大类：下面我们根据每一类产品经理的工作内容进行实际分析需不需要懂技术，以及懂哪个技术栈。
1.交互产品经理工作内容：主要负责产品的交互样式和流转流程，通过研究用户习惯和系统之前的交互流程，设计流程更加顺畅，体验更加友好的产品。
常见的有APP交互产品经理、ERP系统产品经理、平台产品经理等。
技术要求：无。
交互产品经理其实不需要懂底层技术，只需要洞察用户即可。
2.业务产品经理工作内容：这类产品经理专门是做功能设计和对接业务需求的，尤其是在一些非互联网行业，比如金融信贷产品经理、金融理财产品经理等。
这一类的产品经理更需要懂的是业务知识，并不是技术能力。
技术要求：无。
业务产品经理需要对业务十分清晰，清晰地判断业务未来的发展方向和产品形态。
不要让需求朝令夕改，不要让技术人员做太多无用功，这就是一个优秀的业务产品经理了。
产品经理学习资料---产品思维-从新手到资深产品人(读书笔记)
产品思维-从新手到资深产品人（读书笔记）怎样探索用户心智锚定效应（anchoring effect） eg：1.外卖告诉用户预算30分钟到结果25分钟就到了，和告诉用户预算20分钟，结果25分钟送到心理反差很大2.新饮料哪怕价格高放在百事和可口可乐中间卖的快，但是放在便宜的饮料中间就不会买注意力偏差（attentional bias）"黑猩猩现象"，用户不会认真阅读小字，要么就是重要信息突出显示，要么就是更重要的信息阻断式显示。
设计原理:1.主线流程之外的信息和功能，要默认用户不了解2.大段的文字和小字，默认用户不会阅读3.有重要的流程步骤、信息传递，就需要更突出，或者阻断提醒有一部分用户不了解产品设计原理，会有很多的猜想，这些猜想是复核他们的“个性心智”的，受环境影响。
主观会倾向系统来思考问题，这个假设会偏向一种简单可以解决的逻辑。
用户在有了主观判断后，收集各种信息进行补充，加重和坐实这个判断。
这时会出现三个偏误：1.主观验证（subjective validation)找到其他无关信息来支持这个论据2.证实偏见（confirmations bias)偏好能够验证假设的信息，而不是否定假设的信息3.逆火效应（backfire effect)当假设被相反的信息否定后，反而更加相信自己的假设这些偏误会导致我们想扭转用户的固定心智时，传递信息非常的困难。
意识到这些困难，并且解决这些困难。
不可以假定用户会全盘接受所有信息或很容易说服。
概率思维与0/1思维我们做功能是概率思维，但是对于用户就是0/1的关系。
对于我们来说是产品功能有95%不会出现问题，对于用户来说，他不是从整个的平台视角理解产品，他只有0和1，只有正确和错误知识的诅咒（curse of knowledge）知道的越多，反而做不好。
产品决策需要避免这个现象峰终定律（peak-end rule）用户对产品的评价往往来源于高峰时的使用感和结束时的体验eg：冬天等车的时间过长，就会形成用户的固有印象间隔效应spacing effect和延时效应lag effect ：有间隔的重复接触会有更好的记忆和学习效果；比起短延迟时间的多次重复你，长延迟时间的少次接触有较好的记忆与学习效果关于用户心智的建议1.获取足够完善的用户画像和用户场景2.要对普遍存在的认知偏误有些了解3.要有极强的同理心，分析拆解用户表达的内容，对用户行为背后的心理决策逻辑做共情猜测4.要用科学论证的精神反复检验找到真实有效的需求点096-需求七原则需求是用户对解决现存问题的需要需求不是无边界的用户的诉求不是需求：国外的某成人网站在定义视频质量时，用的是播放该视频时离开网站的用户数量需求的主体是目标用户需求有其时空约束用户是需求的集合需求存在不同层次，深层的需求持之以恒产品设计者应该为用户价值和产品价值负责用户价值：用户使用产品时主管判断能否帮助自己解决特定问题用户价值是对用户对解决问题的主观判断——我们能够为客户创造的价值、用户对于我们的商业价值产品价值：从产品设计的视角关注的用户价值产品价值本质上也是用户价值：产品价值是由用户决定的；产品价值体现在功能和服务中用户体验：在实现用户价值过程中用户的主观感受两个致命错误：忽视旧体验，忽视迁移成本核心用户价值就是产品要实现的产品价值产品价值=（新体验-旧体验）-迁移成本产品价值=平均创造的用户价值*覆盖的用户数量用户体验=可用性+易用性+稳定性用户体验=可用性+易用性+稳定性可用性：任何场景下都要先确保可用性，这是用户体验的基础，比如双十一，各平台的服务器性能都要提升到前一年几倍的程度易用性：用户达成目的的成本降低、效率提升稳定性：降低不可用、不易用的概率超预期：让用户超过原本预期的感受可用性和易用性是由严格区分的，剩下的两点是由交叉的，某些时候用户会认为超预期也是在可用性、易用性的一部分优先满足可用性！！！基于体验差，酌情提升易用性；降低严重异常的概率以及发生异常后的用户成本；只考虑永久性的超预期体验！第九章深入场景，探索供给侧的价值用户的价值觉得了供给侧的价值，“你有一个好点子”不代表“你就是做这件事最合适的人”不管是创业时寻求合伙人，还是在企业的产品中完成一个重要模块，都需要判断你最需要的合作伙伴和资源。
产品经理需要学习的技术都在这里
产品经理需要学习的技术都在这里这是一篇写给没有技术背景的产品经理看的文章。
要深入学习的，请另外参照对应领域大神的指引。
本人计算机专业毕业，实习刚开始也做过一小段时间的开发，从前端到后台到数据库略有接触，所以对技术那点事儿比非计算机专业的童鞋要稍微懂得多点。
从开发角度讲，我一定是个不合格的程序猿；从产品的角度讲，我还能算懂70%技术的产品汪。
今天就来写写，作为产品经理，你需要懂哪些技术。
先问：产品经理为什么要懂技术？对技术了解不多的产品经理们，在日常工作中，会不会遇到以下问题：1）需求评审时，你说，一个星期应该能完成吧。
开发给你一个白眼，说，不行，一个星期你来写，这至少得三个星期，陷入尴尬……。
无法评估一个功能的技术实现难度。
2）测试提过来一个bug，比如收藏列表的价格显示和商详页不一致？你搞不清问题的根源，不知道该找客户端同事还是后台同事修复，只能先问前端再问后端。
不能快速定位反馈对象，无形中浪费了许多时间。
3）与开发沟通时，总是会听到接口，API，传参数返回等听起来很懵逼的技术专业词汇，云里雾里插不上话，感觉自己是个局外人。
需要花大量功夫去了解清楚，降低沟通效率。
因此，作为一名产品经理，懂技术是非常必要的。
这样才能和开发工程师有效沟通，对实际开展产品工作有非常大的益处。
但也不至于要去学一门编程语言，会写代码。
真正掌握一门编程语言需要大量的精力和时间，还容易陷入到各种技术细节。
懂前后端的数据交互和底层数据表结构设计，足矣。
专业的事情交给专业的人来做，写代码到底还是工程师该干的活儿。
再问：技术的底层架构？一个完整的项目由客户端（前端）和服务端（后端）组成。
1.前端前端分为网页前端（H5）和移动客户端前端（native)，移动客户端又分为Android、IOS或微信小程序等。
我们需要理解H5和Native这两种技术方案在实现难度、工作量、资源投入上的区别，以决定具体用哪种方案？H5的开发成本更低，且在工作量上只需要H5工程师开发一遍；如果是原生系统（native)开发，那至少需要Android和iOS工程师各自开发一遍，工作量和资源投入要高。
产品经理产品设计-AI产品经理入门手册(上)
AI产品经理入门手册（上）近两年来AI产业已然成为捷伊焦点和风口，各互联网巨头都在布局人工智能，因特网不少互联网产品经理也开始考虑转型AI产品经理，本文我也同样在转型中。
本篇文章是通过一段时间的学习归纳总结整理而成，力图通过这篇文章给各位考虑转型的产品经理们一个对AI的全局概括了解。
本文分为上下两篇，此为上篇。
全文思维导图如下：目录：1.1AI产业结构AI发展至今大致按照在上产业结构的分工不同产生了三种类型的公司，我们在转型时最好要先清晰明确先要自己的优势及兴趣，来判断自己适合着眼于哪个层面的教育工作，从而进行针对性的学习和提升。
（1）行业+AI这类公司重在“行业”，本身有着一定的行业积累，给用户提供AI赋能后的产品或服务。
例如：智能家居、智能车载等。
这类公司对产品经理的要求重点在对行业论述的表述上，以及需要对行业趋势有一定的insight。
目前此类公司的战略趋势是会越来越细分到具体的垂直场景上，所以这也对产品的场景分析能力有较高要求。
（2）AI+行业这类公司重在“AI”，是由AI催生出来的行业，客户可以通过使用这类公司提供的服务或解决方案来完善自己的，从而快速大幅提升自身产品的价值，例如：智能客服、智能外呼等。
此类公司目前商业模式主要以toB为主，所以需要产品经理品类具有较强的沟通能力，加速能快速挖掘理解客户的真实需求，并对项目兼具一定的把控管理能力。
（3）基础平台这类公司旨在为客户提供基础AI技术平台，主要包括一些计算平台、算法平台，或者提供各场景的一手数据，从而帮助化工企业快速对接AI技术，大幅缩短客户在人工智能研发上的投入成本和周期。
此类公司对产品经理的主管要求更侧重于对底层技术框架的理解。
如果你曾经从事过研发专事工作，那么在教育工作该类公司工作会很有优势。
1.2AI产品经理的分类AI产品经理，是直接嵌入式或间接涉及了AI技术，进而完成相关AI产品的设计、研发、推广、产品生命周期管理等副经理其他工作的产品经理。
产品经理必备的办公技能
产品经理必备的办公技能1、原型设计技能：有参照物的讲解会更有效率大家一定要意识到一点，信息传输有效性层面，视频>声音>图片>文字，辅助多媒体介质去传输信息要比文字效果好很多，所以到目前为止，大篇幅文字的PRD在逐渐减少，取而代之的是交互稿上的逻辑说明，直接在原型旁边标注相应的逻辑，这样对照着看也能节省很多操作的时间。
纸质原型在概念讨论初期会比较有效果，当脑海中浮现某种布局排版的效果时，先用纸和笔将其画出来，辅助以语言说明，比单纯的讲要效果好。
我们在日常沟通的过程中，应该经常会遇到这种讨论场景，当对方对现有的事物不满意的时候，会给出他自己的方案，这时候要么对方把所描述的内容具象化，要么你去把它总结定义出来，这时先在纸上或者白板上画出来，能极大的提升沟通效率。
通常意义上的原型，能用HTML访问的要比纯图片效果好，或者是现在很多原型工具类APP，支持图片原型做好之后，导入到手机里然后设置对应的热点跳转。
有页面或者单击跳转的操作，就好比静态的图片或者页面变成了动态的动画，接近于视频的传达效果。
本身原型的最大作用，就是作为参照物，辅助于演示和沟通，若演示的效果能接近于DEMO，或者接近于实际的产品，那自然效果是最好的。
只不过制作高保真原型的时间成本真的非常大，不建议大家在制作原型上花太多的时间。
像Axure这款工具倡导的都是“快速原型设计”。
2、思维导图：结构性的梳理会更清晰明了在没有思维导图这个概念之前，我们可能就直接开始画流程图了，但有了这个之后，能在画流程图之前先梳理一遍业务，这样画流程图的效率也会提升上来。
像我自己之前更多是先在本子上列示一下某个模块会涉及到哪些关键点，这样在设计的时候可以参照。
也有人会习惯于制作用例图，UML工具在传统软件行业用的挺普遍的，到了互联网行业，好像就用的少了，现在的新人，估计知道UML的人就很少了。
做思维导图绝不是记流水账，而是一次信息归类整理，要点梳理的过程。