Ⅰ 在IT和互联网行业，产品经理是前端还是后端为什么
我理解为：客服经理为前端！设计为后端支撑！说错不喷！
产品经理既不属于后端，也不属于前端。
如果你的问题是指：产品经理是属于前端研发人员，还是后端研发人员，那么两者都不是。因为严格来说，产品经理是属于运营人员，在很多公司都归属于运营部门。
如果你的问题是指：产品经理是属于前端销售人员，还是后端研发人员，那么答案也是同样的：两者都不是。
因为产品经理是沟通前端销售人员，和后端研发人员的渠道。所以，你可以认为产品经理是前端和后端的中枢。
这个岗位需要把前端销售人员接收到的用户需求，转换成具体的功能，在产品上实现。也需要把后端研发人员的能力，转换成文档或者其他材料，供前端销售人员使用。
所以，产品经理既不属于前端，也不属于后端，而是两者之间的中枢。
你好，谢谢你的邀请。产品经理，在互联网行业，我感觉应该即使后端客户经理，有事前端。产品经理负责从设计规划到具体实施落地的整个生命周期和价值的。在一个物联网企业一个产品经理其实就是企业的CEO；而互联网方面一个可独立运转的子系统也可能构成一个产品，那么她的产品经理可能是研发人员、销售运营或者其他设计相关的人员。前端的工作主要在根据用户和市场挖掘需求。后端的工作主要是根据业务和发展规划需求。
当然在互联网企业里有侧重点，后端主要特点：梳理复杂的业务流转、管理配置复杂类似矩阵化结构的功能、进行接内部外部的不同系统数据的对接、保持企业的产品技术优势、对业务数据进行监与保护。
前端客户经理主要特点：需求分析，完成产品设计、编写产品需求文档、和各方进行有效沟通、从初期的概念设计到上线后的数据分析和用户反馈收集，不断优化产品品质、推动项目开发进度、合理分配资源、有高效的时间管理策略和经验等等
所以具体产品经理属于前端还是后端，需要你个人的分析和公司需求策略决定！
这个前端、后端，如果是公司角度：
IT行业产品经理有可能属于前端。类似售前的工作。
如果是技术角度：
产品经理分：前端、中台、后端、业务条线、全栈
产品经理要区分前端或后端，我们先从产品形态本身去看，传统行业的产品偏于整套解决方案或软件集成为多，要求产品经理技能倾向于解决行业问题，其中要参与较多产品方案中的技术方案的理解、研究与设计。而互联网产品经理，独立的商业模式，更多的to C 业务，导致产品形态区别于传统行业，它更面向用户与要实现的商业模式，产品的展现层需要更多的交互设计，虽然有很多产品经理配备了交互设计师，但交互仍是产品经理不可逾越的技能。
以上并非绝对，因为互联网下一个时代也是向产业端发展，逐渐也形成了大量的解决方案，而另一方面传统行业也在互联网化，本身也孵化了大量的to C业务，所以传统行业与互联网行业在其软件产品的结构是相互交织的。
前端与后端的定义也看公司怎么定，不同公司有区别。
在我看来，此问题还是要回到产品经理的职能与工作职责，就是分析市场、定义产品、设计产品、迭代产品，趋向越来越好，实现产品的价值所在。所以，产品经理的深度应该是一个全栈产品经理，或者广度理解是产品线产品负责人，就是前后都会。
1. 产品经理需要理解客户的需求，需要不定期去和客户交流，获取对产品的意见和建议。需求调研和获取阶段，产品经理的角色属于前端客户沟通和落实需求的角色。
2.需求明确后，产品经理需要在研发组内部，进行需求讲解，对开发和测试，UI设计等同事的问题进行解答。产品经理此阶段的工作，偏向与后端沟通需求和细化需求的角色。
总结: 产品经理是链接前端客户和后端研发的纽带，沟通需求和协调研发资源实现需求。
产品经理：
第一、产品经理既不属于前端也不属于后端；
第二、产品经理的工作内容：
1、熟悉产品的需求，与需求方沟通产品的需求，或者根据现在市面上的功能，推导出产品出来；
2、根据收集的产品需求写出产品稿；
3、与前端、后端的技术人员评审产品稿，核对产品稿的可行性；
4、当前端、后端的开发人员根据产品稿把项目开发出来后，产品人员还要初步验收项目，产品人员验收完项目后，才有测试人员介入去验收。
所以说产品经理更像一个设计师的性质，但是又没设计师的范围大，因为前端、后端的很多实现方式，产品人员是不负责的，只是效果方面的范围管控。
你好，很高兴可以回答你的这个问题，希望我的回答对你有帮助，我认为产品经理是一个项目的交接人，和项目开发关系不太大。这是我个人的想法，说错了别怪我哦。
都不属于。算是技术开发、运营、设计的统筹与粘合岗位。
首先需要明确 产品经理的概念是什么。
网络对产品经理的定位是 企业中专门用来负责产品管理的岗位，负责市场调查并根据产品、市场及用户等的需求，确定开发什么产品，选择什么业务模式，商业模式等。并推动相应产品的开发组织，还要根据产品的生命周期协调开发营销运营等。
第二点，产品经理在不同的公司的定位是不一样的。根据从属部门不同会有不同的定位。有些小公司，产品经理的权限很小。他们只需要根据上级提出的需求画出原型，然后理顺逻辑，负责最后功能把关，有些还兼任着测试等各种奇葩的任务。
大公司的产品经理，对整个产品的生命周期负责，从竞品分析市场调研，到需求分析流程梳理，研发流程测试进度等等都会进行参与协调。
在IT或者互联网行业，如果从这个业务或者整个公司的角度去看前端和后端，那么产品经理其实应该属于后端，因为站在业务或者公司这个宏观角度，和客户直接接触的职位才应该算作前端，比如销售，售前、售后咨询等等。作为产品和业务的设计和规划者，应该作为后端，比如产品，设计师，工程师等等。
但是，在IT和互联网行业，通常不会以这样一种宏观角度去区分前后端，而是会细化到部门或者职位，而前端和后端通常会指技术岗位中的前端和后端，即前端工程师和后端工程师。而这两个职位都不包括产品经理。
前端工程师是指做用户端产品的工程师，主要包括用户界面，用户交互等。后端工程师主要是指做服务端业务开发，中间件、基础设施等开发。
而产品经理主要是负责产品设计，包括功能设计，流程设计，产品交互设计等等。
综上，前后端的区分主要是看在什么角度上区分。而不是单纯的某个职位属于哪一端。
Ⅱ 前端和后端产品经理的区别在哪
一、前端产品经理：
也叫2C产品经理或C端产品经理或客户端产品经理。主要面向普通用户或被服务者。比如**点评客户端，团购客户端，打车客户端等等。这类产品的特点是：
1、区分客户端和商户端，并且功能差异很大，一个提供服务，一个享受服务；
2、客户端具有操作、购买、下单功能；
3、商户端具有开启、关闭服务，更新、上下架商品等功能；
4、客户端产品前期靠运营、推广获得用户，商户端产品前期靠商务拓展人员去寻找合作商户；
重前端产品代表：
比如手机QQ、微信、微博、知乎、网络搜索等，这类产品属于是纯前端产品，一般没有后端界面或只有简单的后端统计界面，前端产品完全不依赖于后端，每个版本都可以独立运行。
二、后端产品经理：
也叫2B产品经理或B端产品经理或商户端产品经理，主要面向的是商家或服务的提供者，开发商户的商铺或商品管理平台。
重后端产品代表：
比如某基金管理公司开发的股票交易系统、量化交易系统、面向企业数据安全的风险评估系统等，这类产品一般是纯后端产品或者只有简单的几个前端界面，操作按钮等。
Ⅲ 前端和后端哪个更适合转产品经理
前端。前端相比于后端，更加适合转岗产品经理，前端更加了解页面设计的规则，慎巧也更接近用饥尺户。
1、前端开发工程师是Web前端开发工程师的简称，2007年才真正开始受到重视的一个新兴职业。
2、后端工程师隶属于软件研发工程师，是从事软件开发相关工作的人员，其主要职责是平台设计、烂孝高接口设计和功能实现。
Ⅳ 产品经理必懂的前端技术
前端技术是指用来开发和实现客户端产品的技术
Android、iOS、Windows Phone
Html、Css、JavaScript
Windows、MacOS、Linux
1、移动开发工程师（Android、iOS）
2、web前端开发工程师（H5）
3、桌面客户端开发工程师（Windows、Mac）
布局原理应用与产品设计：
1、产品设计时考虑每一个控件的边界属性（文本的最长展示范围，不同屏幕尺寸的适配）
2、内容型控件需指明内容对齐方式（文本展示框内容的对齐方式，图片拉伸方式）
UI控件三要素：
1、大小
2、位置
布局：线性布局、相对布局
3、外观（内容）
所有的显示问题，最终都归结为适配问题，适配问题为移动开发的一大难题之一，产品经理需要了解适配原理，通过适配方案反向推出能降低适配难度的原型设计。
1、界面布局适配（相对布局）
2、应用素材适配
（1）Android：点9图
（2）iOS：@2x、@3x
3、功能适配
Html页面是 骨架 ，CSS是给Html页面装饰的 衣服 ，同一个Html页面根据不同的CSS可实现不同的展示效果
Web页面可实现对PC浏览器和手机浏览器的 适配 ，一套网页可在不同的设备上呈现不同的展示效果
修改网页内容不需要重新发布客户端产品，只需要网页重新更新，可进行 热更新
Html：超文本标记语言
以 标签 的形式表示网页组成元素，通过浏览器解析还原成视觉页面
CSS：层叠样式表
定义统一 样式风格 ，给Html页面元素进行展示样式渲染
Html5应用： 通过网页 web技术 实现的客户端产品，具备 轻量化、易维护 的特点
Native应用： 通过各移动平台技术实现的客户端产品，具备 体验好、功能丰富 的特点
混合应用： 结合Html5和Native应用混合实现，在Native中嵌套H5页面代替部分功能，具备 动态扩展，高灵活性 的特点
1、设计产品原型时，结合产品思维与实现思维
2、组件化设计思路，从开发角度思考问题，设计可复用产品模块
3、明确技术边界，基于现有技术设计产品原型
Ⅳ 写给产品经理之前端是如何展示后端数据的
移动互联网的迅猛发展让移动APP呈现出爆发之势，这两年更是移动开发程序员的春天。
今天的互联网上充斥着产品与技术的撕逼。也许你会问产品经理到底要不要懂技术？由此引申出，产品经理到底要不要懂设计？产品经理到底要不要懂运营？产品经理到底要不要懂市场？产品经理到底要不要懂业务？这所有问题的来源都是大家对于产品经理的工作认识不一致。
每个人心中都有一个产品经理的定义，产品经理在技术方面更多的是去统筹和规划。不是画画图写写文档就可以了。这里面更多的需要的是对逻辑的梳理和拆分。
例如很简单的一个app内嵌发红包的活动，产品经理需要确定整个活动的流程。从用户进入页面的那一瞬间就应该被产品经理掌控。他的每一个步骤，每一个操作会带来什么结果，有哪些变量会导致活动进程失败，这些都要产品去考虑。等到活动逻辑和过程全部梳理完成，下面就要进行拆分了。还是以发红包为例，红包中金额是客户端写死还是服务端进行计算，红包领取资格需要服务端返回几种结果，每种结果对应客户端的提示是什么，用户领取红包以后服务端需要记录那些信息（帐号，uid，领取时间，金额，是否使用等），客户端哪些地方需要加入计数器进行数据统计。总结起来其实就是，产品经理需要根据开发的每一个环节，将所有内容分类整理，并分发给不同部分的开发进行研发。最后，还需要给测试准备好check list，当测试按照check list测试完成以后，才可以上线。
以上种种都需要产品对前端如何显示后端数据有一个清晰的认识才能规划好数据如何展示。是APP写死呢还是后台返回，在用户任务进行的时候有哪些可能case。只有搞清楚这些，产品才能在实际的开发中掌握好整个项目的流程与进展，才能不被开发给糊弄。
简单的说，前端仅仅将后端返回的数据展示在页面上，不做过多的逻辑处理。前端需要关心的是，数据如何更好的展示出来，页面效果如何做出来，以及其性能问题。
而后端就是负责对这些数据进行处理，提供给前端展示。
前端一般有H5、android、ios等多端界面。数据不要轻易写死在前端里面，不然到时候三端都要修改，费时费力。而将这些变化多数据让后端进行处理，前端将这个数据取出来显示出来就行了。
举个例子吧，下图是一个美团app首页团购的展示效果
上方美食等8个icon一般为固定展示栏目，非特殊情况不会修改。那么前端一般是写死在app中，等到需要更新的时候更新app即可。
而下方猜你喜欢是一个列表，该列表数据经常变化，数据写在服务端维护，app取出数据进行展示即可。
首先，前段对页面的展示是分两步走的。
第一、在本地绘制好界面，当然此时未连api会填充一些假数据，或写一些默认值。
第二、连api进行数据获取，将数据填充进界面。
既然如此，咱们简单看下前端拿到的数据到底长什么样的吧。
现在前端获取到的数据基本是json数据。
不需要特别懂里面每一个的含义，只需要知道，前端通过"title"这个键名(key)就可以拿到"合辑护甲"这个值(value)。 "title": "合辑护甲" 这一整个就是俗称的一个字段。通过该字段前端就可以获取到列表的标题了。当然这个列表只是简单的展示用，还有诸如图片地址、优惠信息、已售份额等信息没有提供，这就是缺少字段的情况。
前后端就是通过这样的一个定义获取/传递数据的。
考虑到后期拓展、需求变更等，一般来说，涉及到计算的、可能有变动的，一律不要让前端来弄。
还是刚才那个例子，在刚才那个列表中有一个“立减5元”的橙黄色tag。
这个tag信息，如果考虑不充分，比如说，后端只提供一个数字5，然后前端在其页面写死“立减x元”，x为填入后端提供的数字，颜色固定为橙黄色。这个如果需求不修改还好，如果后期需要新增一个“满20减5元”的红色tag不傻眼了吗？
到时候只能通过升级app来解决，而且不升级的老用户将永远看不到这个红色的tag。
所以说，考虑到程序的可复用和拓展性，需要产品将后期可能新增或变更的需求考虑好，和前后端进行沟通，让前后端设计好实现，尽量降低程序的耦合和硬编码。这才能使一个产品更加健壮以及让苦逼的程序猿少加班的关键。
那么刚才那个tag的需求如何设计才合理呢？
首先是tag显示文字，全权由后端提供，可以是多个字段，由前端进行拼接。然后是tag的颜色，提供几种样式让前端判断是一种可行的办法，但是直接提供tag的色值给前端的这种方式无疑给前端展示增加了无限的可能。
是不是也要增加一个tag形状的字段呢？
俗话说，过犹不及。tag形状这种东西真的很少变更，字段太多无疑会增加开发的时间成本，而且会让人有一种舍本逐末之感。
前端获取到后端数据后，如果前端不主动刷新重新请求数据的话，这个页面的数据在该页面销毁前会一直保持不变。
如何理解？
首先，第一次进入一个页面，该页面数据为空或默认数据。此时前端会链接api请求数据。数据请求完成后，填充进页面。那么本次联网请求就完成了，在前端不进行二次数据请求之前，该页面会一直保持本次请求的数据。也就是说，就算服务端修改了数据，前端此时是不能事实的进行更新的，因为我前端不知道你数据更新了。
那么在这个需要实时更新页面数据的时候和前端讲这种需求会被前端直接回绝：“做不了”。这个时候产品咋办，怪怪妥协？最后背锅的还是自己，而且自己也不知道是真做不了还是假做不了。
实时刷新也不是不能做，只是做的成本略高，需要和后端进行配合，像微信聊天一样和后端进行长连接(socket)，这样服务端数据变更前端就知道数据变更了。
当然如果稍懂页面刷新机制的话，可以要求前端在适当的时机进行页面刷新，如在页面可见的时候进行刷新，这样用户每次看到的都是最新的数据。也可以让用户主动刷新，如新增刷新功能。
产品懂技术这件事情，不仅会降低和开发同学沟通时的难度和被歧视风险，还会提升在面对开发同学意见时的判断力，会降低被技术团队忽悠的几率。同时，在需要向上级解释技术原因导致变更的情况下，也会有助于说服老板。
“闻道有先后，术业有专攻”，要相信自己所接触的开发团队是专业的，靠谱的，相信开发团队为实现需求所做出的技术方案是合理的，最优的。如果有质疑，可以加深沟通，以合适的方式提出自己的质疑。这里要补充一句的是，这个信任过程是需要建立的，也是会根据团队的表现不断变化的；同理，其实团队对于产品经理的信任度也是一样的情况。
吐槽是没有意义的，关键还是要解决问题。如果觉得产品经理不靠谱，那么有没有进行过深入的沟通？如果觉得开发不好沟通，那么有没有进行过了解，不好沟通的原因在哪里？如果当事人本身确实不可沟通，那么有没有考虑和对方的老板沟通，或者通过自己的老板如实反映情况？吐槽是最容易的，解决问题反而会很难。