售前人员有多种称呼，如售前工程师、解决方案专家、售前咨询工程师、技术顾问、售前技术支持工程师等等。
实际上，售前正是对售前阶段参与人员广义上的称呼。
一个IT项目的生命周期，可以大体分为售前、售中、售后3个阶段。
售前，是指与客户签合同前的阶段。大致包括线索获取、客户交流、提供技术方案、应标、签合同等流程。
售中，是指与客户签单后的阶段。大致包括需求评审、设计、开发、实施等流程。
售后，是指项目交付后的阶段。大致包括维护、使用培训、技术支撑等内容。
售前人员，主要是做售前阶段的技术支撑，但一个IT项目，通常都要考虑延续性，所以售前人员，也会参与到售中、售后工作中。
售前与其他IT人员的关系售前vs销售
销售（客户经理）为公司承揽业务，需要从事寻找线索、拜访客户、维护客情等商务活动。
但在一个项目的签单过程中，需要很多技术性和文档工作。比如与客户进行技术交流，编写技术文档等工作。这些工作，通常由售前人员去做。
所以有人说：客户经理是商务型销售，售前工程师是技术型销售。
售前vs研发
为什么不让研发来支撑销售呢？因为，研发虽然懂技术，但是不懂业务。
拿软件开发人员来说，他也许懂java语言、C语言、Oracle数据库、Hadoop架构，但不一定了解客户的业务，比如金融业务、医疗业务，甚至货币理论、医疗技术。这些就是业务，技术是要建立在业务基础上的。
售前，就是IT公司中，最懂客户业务的那群人。售前把客户的业务需求转化为技术人员能理解的语言。
售前vs产品经理
听上去，售前和互联网公司中的产品经理概念很相似。实际上，在IT公司中，也有产品经理的角色。那售前与产品经理有什么区别呢？
共同点是：二者都要与客户交流、调研需求、写需求文档。
区别是：售前的使命是签单，产品经理的使命是打造产品。售前想的更多的是如何开拓市场，签更多的项目。产品经理想的更多的是如何打造更好的、更有市场的产品。
售前的类型在回答售前具体做些什么之前，有必要先了解下售前类型。根据有无产品、归属总部还是区域，可将售前分为4个种类。
产品型售前&方案型售前
产品型售前是最容易理解的，即公司有了产品以后，协助销售将产品推销给客户的售前。硬件公司，如服务器、交换机厂商中，主要是产品型售前。
很多企事业客户想要的产品，市面上并没有，厂商要做的，就是提供解决方案。这种售前就是方案型售前，如在集成厂商中，主要就是方案型售前。
产品线售前&区域售前
很多大型IT厂商有多条研发产品线，同时，在全国各地有很多区域中心。于是出现了产品线售前和区域售前的分类。
产品线售前通常专注于某一行业甚至某一类业务，对产品有前瞻性的考虑和布局，面对全国市场。
区域售前更贴近客户，更了解客户需求。区域售前需面对本区域的多个客户甚至多个行业，对业务了解的深度不如产品线售前，但广度要超过后者。
在这类公司中，产品型售前与区域售前，往往需要相互取长补短，同时出马。
售前的岗位职责售前的基本职责是协助销售完成项目签单，售前的工作主要围绕项目生命周期开展。
售前阶段
解决方案规划：售前需发掘行业诉求、问题和痛点，整理行业解决方案和最佳实践，进行解决方案规划、设计；
技术交流：协助销售同目标客户进行技术交流，讲解公司现有的解决方案和案例，并在交流中了解客户的需求；
编制解决方案：基于客户需求编写解决方案。
方案讲解：负责为客户讲解、演示方案，并引导用户认同技术方案；
编写技术文档：如方案被用户接纳，在投标之前，还有很多环节需要提供技术文档，如：技术规范书、可研材料、工作量评估材料等等；
投标支撑：负责协助销售完成投标工作，主要负责技术分册、商务分册的编制，并到投标现场进行述标、答辩等工作。
售中阶段
需求调研：项目签单后（经常在签单前），首先要进行需求调研、分析，并编制顶层设计、需求规格说明书，并对需求进行管理；
需求交底：负责项目从售前到售中的需求交底，协助交付团队做好需求确认工作，提供项目实施相关的文档资料和知识转移；
配合交付：配合交付经理完成整体项目的交付；由于在公司中，售前擅长编写材料，所以经常要帮助交付人经理或客户编写工作汇报、工作总结、技术创新等材料；
售后阶段
售后服务：如产品技术培训、材料支撑工作；
需求收集：在售后阶段（经常在售中），售前需要收集用户新的需求，当需求较多时，要争取促成客户再立一期项目；
对于大型IT公司来说，这些职责通常会分散到不同类别的售前身上，如解决方案专家、售前负责人、产品线售前、区域售前。
售前的职业规划售前本位路线图
售前本位路线（上）——售前技术路线
售前是介于技术与销售间的岗位，严格的说，售前提升的不是技术，而是技能，既包含技术、业务等技术能力的提升，也包含商务等市场能力的提升。笔者将这些技能概括为：懂产品、懂商务、懂业务、懂技术、懂需求、懂趋势、能写、会说。（可参见“IT售前圈”文章《售前是做什么的》）
初级售前
岗位：需求工程师、售前助理
掌握技能：
懂需求：需求调研、需求分析 、需求方案编制、需求评审、需求交底等
懂产品：所负责项目或产品的基本了解；
懂商务：了解基本的签单流程；
懂业务：对客户业务有大概了解；了解客户的需求、客户业务的发展趋势；
懂技术：简单了解软件开发、数据库、硬件、网络等技术知识，学习云计算等行业相关的新技术；
能写：各种文档要过一遍手，如技术规范书、解决方案PPT、可研材料、预算表、投标材料、创新材料等等；
关键能力：学习能力、抗压能力
成长时间：1~3年
平均工资：约85K
（注：工资数据来源于职友集2020年4月售前工程师平均工资，下同。有兴趣的读者可参考“IT售前圈”文章《售前工程师工资高吗》）
售前的门槛较低，介于销售与研发之间，高于销售、低于研发。只要具备专业学历或背景，本科学历即可。但在售前打怪升级的路上，要掌握的知识、技能要远高于二者。所以，售前通常要两年时间，才能接触完这些技能。售前要学习的专业知识、新技术，更是无止境的。
售前在初入行时，一般是协助老售前做一些力所能及的事，比如需求调研、需求编写、标书检查等，和销售、老售前一块见客户、参加方案交流等工作；在学习一段时间后，一般会安排小项目给新售前。在经过中小项目历练，可以负责公司主要项目，被领导、销售、客户认可，并能够独当一面后，售前就完成了初级到中级的进化。
中级售前
岗位：售前工程师、解决方案工程师、咨询工程师
关键技能：
懂需求：提升需求工作的准确性，提升需求工作效率；
懂产品：对所负责项目或产品深入了解，如项目的来龙去脉，产品的每个功能和需求；
懂商务：熟悉签单、招投标流程；了解客户单位的组织架构、决策流程、关键人等情况；
懂业务：对客户业务非常熟悉；对客户行业比较了解；
懂技术：不断学习新技术：如云计算、区块链、AI、AR、5G等；
知趋势：了解业界最新进展和发展方向，了解行业痛点和诉求；
能写：各种文档要非常熟悉，提升文档编写效率；能够针对用户需求编写解决方案；
会说：会讲方案，能与客户、团队有效沟通；
关键能力：学习能力、抗压能力、协调能力
成长时间：3~5年
平均工资：约115K
中级售前需要在各种技能上精进，如对需求工作、产品、商务、业务、技术进行总结、深入了解。
重点能够根据客户的需求提供解决方案，并讲解，在技术上被客户认可；配合销售不断达成签单。
这个阶段的售前，要对行业趋势、客户需求、竞对产品有全景掌握。能够做出提升产品竞争力的有益建议；能够从业务角度发现或创造销售机会。
高级售前
岗位：解决方案专家、咨询专家、售前顾问
关键技能：
懂业务：从更高的视角了解客户业务；
知趋势：了解行业趋势、具备前瞻性；
能写：PPT大师
会说：讲方案大师
关键能力：学习能力、抗压能力、应变能力
成长时间：5~10年
平均工资：约145K
售前的技术发展目标，是成为行业专家。
IT行业的圈子不大，有的业务只有两三个竞争对手，这几个厂商就代表了这个领域的最高水平。高级售前要对自家产品和解决方案非常熟悉、具备丰富的案例和实战经验、对竞争对手的产品和情况了如指掌、对专注行业的IT发展历史、未来发展趋势了然于胸。只有这样，才能紧跟客户发展脚步，不断为客户提供前瞻性解决方案，不断创造合作机会。
售前管理路线
高级售前再向上发展，就是售前管理。
以下分别对产品线售前和区域售前的管理路线作简单介绍。
产品线售前&区域售前区别（来源“IT售前圈”文章《售前是做什么的》）：
很多大型IT厂商有多条研发产品线，同时，在全国各地有很多区域中心。于是出现了产品线售前和区域售前的分类。
产品线售前通常专注于某一行业甚至某一类业务，对产品有前瞻性的考虑和布局，面对全国市场。
区域售前更贴近客户，更了解客户需求。区域售前需面对本区域的多个客户甚至多个行业，对业务了解的深度不如产品线售前，但广度要超过后者。
在这类公司中，产品型售前与区域售前，往往需要相互取长补短，同时出马。
产品线售前管理路线
一般IT厂商每条产品线都配有售前部门，由售前经理负责。
售前经理有以下基本职能：
管理职能：负责部门售前人员管理，业绩任务制定、分配等工作，对整体业绩负责；
规划职能：负责产品规划；
售前职能：负责重点项目的售前工作；
若产品线有多层架构，产品线售前经理还可以逐级晋升。
若业绩、能力特别突出，还可以依靠不断转岗向上晋升。
区域售前管理路线
区域售前经理与产品线售前经理相比，不需要产品规划职能。不过，区域售前经理通常在负责业务的广度上超过产线售前经理。
若公司有多级区域划分，区域售前经理还可以逐级晋升。
若继续晋升，区域售前经理比产品线售前经理多一个转回总部的步骤。
售前转身之路
并不是每个售前都能从初级售前晋升到公司总经理。任何一个级别的售前，都会遇到发展瓶颈。此时，既可以选择继续在各自岗位精进，也可来个转身。
无论哪个职业，转身通常有5种主要选择，即跳槽、转岗、转行、做副业、创业。
跳槽
主要是两种选择：
一是跳槽到同行业其他厂商做售前：如果对公司的发展前景不看好，或待遇等不满意，可以考虑此选项。售前的价值体现在其专业水平，选择同行业公司容易进去，也容易提升待遇；
二是跳槽到其他行业做售前：如果对自身行业的发展前景不看好，可以跳槽到其他行业。但重新起步，一般难以提升待遇，还要学习很多新行业的专业知识。
转岗
IT行业不管哪个工种，都对其他行业抱有憧憬。
售前通常有以下5种转岗选择：
区域/产品线售前转换：区域售前离家近、出差少，产品线售前更具成长空间、可以到各地出差；二者可各取所需，内部转岗；
转销售：销售可以和客户建立更好的关系，不需要学习那么多技术和知识，不需要总是写文档；但是销售业绩压力更大，工作也不如其他岗位稳定；
转产品经理：售前与产品经理的岗位非常相近，只是一个偏向于签单，一个偏向于规划产品；
转项目经理：项目经理管的事情多，交付压力大，需要很强的协调能力、项目管理能力；如果喜欢这种挑战、或迫不得已，也可以转项目经理；
转研发：如果喜欢相对稳定的工作内容，又不擅长写材料、交流，并且具备技术能力，可以考虑转研发。
转行
IT行业是平均工资最高的行业，除非有更好的出路，不建议转行。
表：2018年规模以上企业各行业平均工资做副业
售前工程师通常时间不够用，因此靠利用空余时间做副业，很难。如果有积攒的资本，可以考虑投资、理财、入股等不需要花费太多时间的项目。
创业
售前很难像有些行业一样，炒了老东家自己在本行业创业。如果还是跃跃欲试，这里有两个建议：
不要因为售前工作不好做而去创业，因为创业更难；
有触手可及的机会，路径很清晰，能看到盈利时，再去创业；凭空而起的创业成功率很低。
我们将商品社会的基本行为抽象为服务的消费者和服务的提供者模式，在这个模式下几乎可以涵盖所有的商业行为。但是，问题来了，到底谁是服务的所有者(owner)北京电脑培训发现大多数人会认为提供者是服务的所有者，所以在传统的企业中，IT应用系统对服务的生命周期负责，应用系统的产品经理来定义应用系统对外的服务接口。这带来一个问题，同样的一类应用，由于实现的厂商不一样，所以各自的产品对外提供的服务千差万别，这就造成了服务的消费系统无所适从。
于是，我怀疑服务的提供者作为服务的owner来决定服务的生命周期甚至服务的定义是否具有合理性。首先，我认为服务的消费者真正决定了服务的内涵，也就是需求决定服务，从这个意义上讲服务是消费者定义的，提供者只是根据消费者对服务的定义通过技术手段实现了服务，只是服务的外延。这样看来，消费者是服务的理论上的定义者，而提供者是服务事实上的定义者，这两者在定义权上是有冲突的。
我认为，商业社会中解决冲突的最有效方法就是订立契约。假如有一个虚拟的服务提供者从大量消费者的需求中抽象出共同的行为模式，这个行为模式因为能涵盖消费者某些消费需求，就能隐式的和消费者签订提供服务的契约了。所谓隐式意思是说，虽然没有和消费者正式的签订合约，但是服务的合约内涵已经满足甚至超过任何一个消费者对此类服务的需求。可以将这个单方面定义合约的角色称为服务产品经理，服务产品经理在一个企业中的角色更像一个真正的产品经理，他们对自己的产品(服务)负责，他们定义并描述服务在各个维度上的属性，并不断寻找合适的服务提供者提供更优质的服务水平。
我们有理由相信，在后SOA时代，随着社会分工的进一步精细化，企业内部的IT系统将逐步的减少，取而代之的是更专业化的外部专业系统。而企业内部将会出现专职的服务产品经理来定义企业所需的服务，这些服务通过灵活的接口与外部专业系统对接，从而低成本、灵活高效的为企业提供高质量的IT服务。
分工不同。系统架构师主要着眼全局的技术实现方案，侧重系统的功能和性能实现。比如数据如何传输、数据如何存储以及数据如何读取等，子系统之间数据对接与分工，数据表结构字段设置等等。
产品经理着重从用户需求，产品定位到产品规划，原型设计，用户体验，系统商业模式等等。
项目经理着重负责整个项目的时间进度、成本和产品质量、需求范围等整体上进行管理。软考名师薛大龙课程免费试学
考软考，选择51CTO学堂，51CTO学堂聘请网络安全、服务器、Android、iOS、开发技术、云计算、大数据、HTML5、SQLServer、Oracle、数据库等各IT领域、具有丰富实战经验的行业专家，设计包括思科认证、软考、Linux认证、微软认证、H3C认证等各类精品IT课程体系，打造顶尖IT培训讲师、网络技术精品培训课程、培训自测题三位一体的网络教育特色，是国内最完善、最专业的IT在线教育平台。学员可免费在线观看，下载培训课件，并与培训讲师互动交流，参加课程评测。全书分为5个章节：
第1章介绍了SaaS的基本内容，第2章阐述了SaaS产品经理的6大素养，第3章介绍了SaaS产品经理的5大技能，第4章结合案例介绍了如何从0到1规划一款SaaS标准化产品，案例的加入使读者在阅读过程中很有代入感，第5章是SaaS产品经理进阶内容，包括战略分析、策略分析，SaaS护城河及未来发展展望等。
可以说是由浅入深，由点到面，为大家解析了SaaS产品经理的素质技能，以及作者对SaaS领域的洞悉。叙述风格通俗易懂，后面几个章节值得多读两遍。
SaaS的前世是传统ERP软件， 传统ERP商业模式存在以下缺陷 ：“取悦”企业决策层，忽视一线用户；昂贵的交付成本；一次性买断，收入难以持续。并且，它已经落后于时代，基于PC端设计的ERP难以适应移动互联网时代的移动化、社交化特点，重构的工作量不压于重新开发。
SaaS软件商业模式的诞生，使 客户不需要购买软件所有权，只根据使用量（使用时长、账号数等）付费 。大部分SaaS软件都通过互联网直接访问，客户也主要使用标准功能。
对于SaaS软件厂商，刨去实施服务的收入，每年的收入是比较平衡的。 如果客户对软件和服务感到满意，理论上会永久续费。 对于客户来说，省去了服务器、运维等成本，避免了二次开发费用，一次性支出成本大大降低 ，虽然每年都有支付租赁费用，但只要对软件不满意，第二年就可以停止付费。 SaaS软件对于标准化产品的能力提出了非常高的要求。
Salesforce在国外的成功，引起了中国企业的注意，中国SaaS软件于2004年萌芽 。但国内的SaaS软件萌芽并不顺利，主要原因是：国内创业SaaS公司相对于价格低廉的小软件公司没有价格上的优势；没有理念上的优势；没有功能上的优势，14年以前中国SaaS都以PC端功能为主，和传统软件区别不大。
随着4G网络与智能手机的普及，移动互联网时代到来，SaaS迎来崛起。 2015年被称为中国SaaS元年 ，融资消息频出，同年阿里巴巴发布钉钉10版本，进入SaaS市场。 2020年疫情的发生，使SaaS迎来了重要机遇， 大家意识到数字化转型是未来的趋势。
（1）热情： 对产品倾注热情，把产品当作自己的小孩。
（2）究竟精神： 对工作要刨根问底，寻求真相。追求极致的工作结果，做到自己能力范围内最好。
（3）自以为非： 日常工作中，发现问题或矛盾时，能够下意识反问自己是不是哪里做的不好，多反思自己的问题，主动担责，积极推进问题解决。
（4）学习能力： 学习习惯伴随一身。正确的学习方式包括 系统学习、知行合一、保持质疑、克服惰性 。实用的学习方法包括 阅读、研究成熟系统（标准化设计能力）、客户调研、复盘 。
（5）结构化思维： 产品经理面对一个需求时，需要具备快速梳理、精准定位并解决问题的能力，而结构化思维是其中必不可少的一个要素。 如果说解决问题的线索像一颗颗珍珠，那么结构化思维就是“把珍珠串成项链”的棉线。 提升结构化思维的方法包括阅读经典管理书籍、掌握经典思维模型、使用辅助思考工具、日常多实践。
（6）沟通能力： 对于B端产品，高效沟通的能力非常重要。培养沟通能力的重点在于培养人与人之间的信任关系，要重视他人的利益，注意维护日常人际关系。
（1）竞品分析： 正确的竞品分析方法一定要关注产品背后的东西。深入分析一款SaaS产品，可以从 战略层 （产品定位） 、资源层 （产品背后的资源） 、能力层 （产品背后的能力） 、场景层 （满足客户需求的具体功能） 、感受层 （包括 *** 作效率、界面布局等）五方面着手。
（2）业务调研： 高质量的业务调研才能梳理清楚业务需求，进而设计出优秀的SaaS产品。业务调研的三个要点是全面、清晰和重点突出。业务调研内容包括 企业组织架构和岗位、业务概况、业务详情情况、管理报表 （管理层重点关注的内容） 、现有系统、用户期望 （执行层/管理层/决策层有不同期望）等。
（3）产品方案编写： 方案编写要点包括聚焦重点、保持究竟精神、长远规划。方案结构包括 整体方案、详细方案 。
整体方案 包括方案概要说明、整体方案流程图、系统架构图、多组织架构设计。 产品功能范围的圈定要做好未来扩展性和当前版本复杂度之间的平衡关系。系统架构设计重点要做到低耦合、高复用。
详细方案 包括需求合理性分析、明确成功指标、方案要点说明、详细方案流程图、原型图。 个性化需求往往是产品能力不足造成的， 对于个性化需求，短期需要做好低耦合设计，即将个性化功能做成可配置项；长期来说，需要完善产品的PaaS能力。对于SaaS产品，真正打动客户的，往往是为数不多的几个功能特性，因此方案中要重点突出。原型图的页面设计和注释要尽可能详细，便于梳理思路、与其他同事协作。
（4）产品规划： 一个可落地的产品规划至少包括 机会分析、目标、策略、执行计划 四部分。 策略是落地的关键，制定策略的秘诀在于通过分析找到“ 影响最大且有机会改善的环节 ”。推进计划的重点在于分解出关键步骤，并落实到责任人。
（5）团队管理：团队管理是和人打交道的艺术。 要做好管理需要处理好和自己的关系、和下属的关系、和上级的关系、和其他部门的关系。
书中通过一个案例，从需求筛选、需求梳理、整体方案、详细方案四个方面讲述了从0到1规划一款SaaS产品的过程及中间的思考决策逻辑，很有代入感，感兴趣的可以阅读原书。
相对于内部B端产品经理，SaaS产品经理需要具备更多商业思维。 因此产品经理需要提升战略分析、策略分析能力，关注产品业绩提升，明确SaaS产品的护城河在哪里、有哪些陷阱、未来可能的发展方向等。
该部分重点内容如下：
战略分析 包括 市场战略 （产品/客户两个维度）、 产品战略 （工具型/管理型/业务型/平台型四种）与 运营战略 （费用/服务两个维度）。
策略分析 包括 产品策略 （ 寻找传统软件的薄弱点来切入，设计标准化，单点突破，着眼长远，与用户共创，做好需求管理，谨慎扩张）， 增长策略 （从完整的客户旅程看待增长，从而发现薄弱点，找到最大的增长机会。客户旅程包括需求萌生、深入认知、选择产品、上线使用、用户存活、产生粘性、续约增购。市场、销售、客户成功部门均为增长部门，需要协同帮助客户完成整个旅程。增长策略包括 营销策略、销售策略与服务策略 三部分）， 盈利策略 （ SaaS公司的盈利逻辑在于追求最大化的客户生命周期价值CLV 。 SaaS收入包括一次性收入、增值收入与订阅收入， 订阅收入是SaaS公司的底盘，是支撑起SaaS公司较高估值的核心逻辑。 SaaS成本包括获客成本与服务成本， 降低服务成本的关键是产品化 ）。
SaaS的7种护城河： 产品优势，客户成功，数据沉淀，品牌效应 （行业顶尖企业案例） ，C端粘性，创新与体系优势 （行业能力体系化）。
SaaS创业的6大陷阱： 远大的目标，丰富的传统软件经验，大客户订单 （个性需求） ，完整解决方案 （早期急于实现完整的解决方案，容易分散资源，对核心竞争力打造不利） ，强大的销售能力 （误导创业者，让团队在错误的方向上走得又快又远） ，热心的投资人 。
SaaS的未来： 产品创新 （ 关注AI等新科技）， PaaS平台 ， 一站式解决方案 （未来10年是企业整体数字化转型的高峰期）， 新的客户成功 （用更大的变革帮助客户成功）。
SaaS行业是未来的趋势，只是目前国内发展程度不足，不少SaaS公司做着做着就变成了定制化产品，很多公司成立了产品部门，却没有打造出真正的满足需求的标准化产品。
SaaS对产品经理要求很高，尤其是产品架构规划能力和商业化能力，市面上缺少高水平SaaS产品经理。另外，SaaS产品经理一定不是只做在办公室就能设计出好产品的，要和客户做朋友，进行现场调研。
理论结合实践，继续加油吧！很多同行的朋友围绕这个话题争论不休，争论往往分为三派。 正方：产品经理不需要特别精通技术，但需要懂技术，知道一些技术实现的方法，防止技术同学打模糊眼说功能实现的问题。 反方：产品经理不需要懂技术，技术会让你陷入技术的思维，在思考产品创意的时刻陷入平庸。 中庸：看团队的特点，如果团队人员配置完整且目标高度统一，那你就专注于产品创意本身，如果团队配置不完整或者技术人员并不是专注于技术实现那么最好懂技术，保证最终结果可以实现。 围绕这三个观点，产品经理经常吵的不可开交，也造成了很多产品初学者陷入误解，觉得人人都是产品经理或者产品经理特别高端，在选择职业发展方向时陷入了迷茫。一名合格的产品经理到底需不需要懂技术？公说公有理婆说婆有理，总之每个产品经理都会根据自己的职业经验给出不同的答案，那么围绕这个话题，我想先从我的成长经历谈一下技术在产品经理职业生涯中的作用。 我大学学的是软件工程，可是学艺不精整个大学时代只限于专业课不挂科那种，也只是了解基本的软件工程语言c语言，java语言等。07年大学毕业后，实在学艺不精也没有技术团队要我，于是就是干了网站编辑，那时候很多互联网公司还没有互联网产品经理的职位，很多用户体验，网站细节的改进往往都是网站编辑提出的，在那时候有了用户体验优化的思维但也只限于 *** 控体验还没有整体的产品概念。做了一年多的网站编辑到09年的时候各大互联网公司开始引入了产品经理的职位，我则跟风开始学了互联网产品经理所需要的技能工具诸如入axure，visio，ppt之类的，在使用这些工具的时候常常考虑的是产品创意的事情，如何把创意的东西通过工具呈现出来描绘给公司高层，技术童鞋让他们知道我的网站是什么样，有什么好玩的东西可以满足用户的哪些需求等，因此当时的我也认为我作为产品经理只需要把大家心中所希望的产品形态传达给技术，最终拿出来给大家用。至于用哪种开发语言，如何提高访问速度，加载速度，如何解决高并发状态下的性能问题等等的技术问题，完全不考虑，心里认为那不是我的事儿，是技术的事儿。可产品出来后，问题出现了，网站访问速度慢，加载速度慢，50的并发就报404了，这时候我才意识到你可以不懂技术，但你一定要知道哪些问题你得替技术考虑到。 因为前期不知道这些技术的细节，也没有一个有经验的技术大牛 *** 控
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）