产品怎么与技术沟通

⑴ 运营人员如何与技术人员沟通

当设计师把页面设计出来之后，运营就需要拿着这个和技术人员把产品需求沟通到位。

和设计人员一眼，技术人员往往也是抢手的资源，所以一定要提前预约，把排期确定下来，对于需求文档里的内容要沟通到位。

有时候对于一个功能的实现，没有直观的感受，技术人员可能并不能理解要实现怎样的功能，或者是理解上出现偏差，所以要及时沟通，如果能有案例就展示案例，能自己利用一些软件作出动画效果，就用动画效果来展示，总之，文字描述不如图片，图片不如动画，一定要把需求传达到位。

再开发阶段，一般不再修改需求，因为技术人员开始写代码的时候，心里就有了对整个功能模块的框架，一旦修改，就可能推到重来，那你和技术人员之间友谊的小船，真的要说翻就翻了。

前段时间有个段子

你不能对一个程序员说：你的代码有bug。他的第一反应是：1，你的环境有问题吧；2，傻逼你会用吗。如果你委婉地说：你这个程序和预期的有点不一致，你看看是不是我的使用方法有问题。他本能地会想：操，是不是出bug了！

虽然有点好笑，但确实是应该要委婉地沟通。如果出现bug，就尽可能描述出出现bug的步骤，使用环境，已及这个bug的重要程度，方便技术人员排查bug和确定任务优先级。

运营和技术人员的良好沟通可以保障产品的顺利上线，所以别看技术人员只会写代码，人家可重要着呢。

⑵ 怎样让产品项目组进行有效的沟通

项目沟通管理是项目管理工作的核心，贯穿项目管理的始终。

项目沟通管理的目的是保证项目相关信息能够及时准确地采集、传递和保存。在项目的组织与实施过程中，如果缺乏有效的沟通，项目经理就难以做出正确的决策，此外还会出现项目运行效率低下、质量不佳等问题，无形中增加了项目的成本，甚至会导致项目的失败。

良好的沟通是团队协作的基础，只有做好项目沟通管理，才能充分调动所有项目干系人的工作积极性和创造性，通过有效的沟通获取足够的信息、发现潜在问题、把控项目各个方面，保障项目顺利进行。

要做好项目沟通管理工作，可以从以下几个方面入手：

1. 制定项目沟通管理计划

通过沟通管理计划对项目整个生命周期的沟通对象、沟通内容、沟通频率、沟通方法等各个方面进行计划与安排，并明确沟通责任，如由谁负责沟通，沟通的标准是什么，在沟通过程中出现问题及冲突时谁应该负责并进行补救等，为实现有效沟通提供依据。

项目沟通管理计划应依据条件变化及时进行修订，保证沟通管理计划的持续适用性。

2. 灵活运用各种沟通形式

在项目管理中，沟通形式是多样的。一般使用较多的是口头沟通和书面沟通。

口头沟通包括谈话、会议、语音、电话等。口头沟通过程应该明确、坦白，避免因用词不当或个人思想等因素隐瞒事实或造成理解上的差异。

书面沟通包括通知、文件、备忘录等，大多用来进行通知、确认和要求等活动，其优点是可以作为资料长期保存，反复查阅。

沟通的具体形式取决于工作领域和团队结构。

3. 建立有效透明的沟通机制

1）定期会议：通过日会、周会等定期会议及时共享项目进度和信息，减少因信息不透明导致的项目延误。

2）沟通内容标准化：对会议沟通内容进行标准化设定（如：周会须确认各小组的开发进度，遇到的风险，讨论解决方案等），减少无效会议，提高团队沟通效率。

⑶ 各位产品同学在和技术团队沟通时，有没有发现好的前端

好的前端，python和php现在发展的很不错，是个好的前端。

⑷ 产品经理怎样更好的和开发人员沟通

诚然，这些挑战可能是由于参与人员的能力问题，这无可避免。但我更愿意相信，沟通不畅、习惯不佳、缺乏换位思考等因素才是最常见的。知乎上的几个问题的讨论，可能会对各不同角色的人之间进行换位起到一定的帮助作用，无疑，这是一件对各方都有积极意义的事情。 产品经理作为贯通各环节的中心节点，避免一些让人讨厌的臭毛病显得尤为重要。从知乎的回答中，我将这些可能成为臭毛病的行为归纳为以下几种情况： 短时间内可以完全避免的：需求不清晰 ，当开发人员问PM需求的时候，发现PM也弄不清楚，这样的问题是一定要杜绝也完全可以杜绝的，如果PM自己都不清楚需求，的考虑这样的工作是否适合自己了。 干预纯技术问题 ，例如：这个code应该这么写。避免之道:对于纯技术的问题不要干预，如果他的技术实现真的有问题，自有相关的人去负责，产品只需关注他最终是否实现了预期的功能。 交付的方案不确定 ，开发人员讨厌其实这样也可以，要不就这样吧的言论，他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候，PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时，再将备选方说出来。 没有必要的预留时间 ,这个我们修改一下，明天提交新的版本，一看，列了一大堆增加的功能，并不是仅仅是修改。coder真的不是神，增加的功能是需要测试的。pm给自己留时间同时，可怜可怜攻城湿，留点时间思考吧。这是一位工程师的原话。Pm要对进度负责，压力很大，但是预留时间是一定要的。 不能完全避免但短期内可以改善的：需求变更 ，这是回答中出现平率最高的一个词汇。但是，要让开发人员失望的是，因为种种原因，这个问题并不能完全避免，PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到，使可能发生改变的需求讲到最少；另外一个就是要杜绝需求的往复性变更，不要让从方案A改为方案B之后觉得不行，又改回方案B。 口交次数太多 ：要避免口头交代，显然不现实，再完美的文档也无法代替口头上的直接交流。但频繁的口（头）交（流）可能会打断工程师的思路，延缓进度。PM可以做一是尽量完善你的文档，第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情，从而减少次数。 需要长期积累或锻炼才能改善的： 缺乏个人魅力 ：是的，缺乏个人魅力也成为工程师讨厌PM的一个原因了。但是个人魅力这个东西，确实很难在短期内得到改善。甚至，对于个人魅力的判断，不同的工程师会有不同的标准。 经验不足：或者说资历不深，要改变这样的现状，恐怕也非可立竿见影的。 以上 ，以自勉。

⑸ 产品经理要如何正确的和设计师沟通

1.关于产品原型
有不少公司都要求出原型时要求高保真原型，在这里我对产品原型有几点建议：
首先，不要添加色彩元素。色彩的添加虽然更真实，但这对设计师来讲绝对是干扰，甚至是灾难。一份上了色的原型，交到设计师手里，从设计师的角度考虑，产品就是设计的需求方，那么产品给的原型是这样的配色，必然说明这是产品喜欢的颜色，那最安全的方法就是保留原型的配色，这样的设计稿更容易评审通过。如果你遇到一些有个性的设计师，可能还会因有颜色的原型而抱怨，因为这严重影响了设计师的工作。抛开设计师不说，有色彩的原型稿在做原型评审时，颜色也会抢了元素布局，排版，功能逻辑的注意力。所以，我是坚决反对有色彩的原型。
其次，产品原型的交互还是要尽量做到更接近真实，这样在与设计沟通时，一来利于更好的表达产品同学的想法，设计师在理解时画面感更强，第二其实也便于后续利用原型做用户测试。
2.产品经理首先要明确需求，知道自己想要什么
“产品经理明确需求”这似乎是一句废话，但就是这样一句废话，在很多研发项目中“需求不明确，需求摇摆”类似这样的问题和抱怨，往往是设计和技术同学最常挂在嘴边的，也是最容易产生杯具的。
很多产品经理在设计出产品后，对自己产品的设计多少都会有一些自己的想法。当然，这些想法在设计前期可以与设计师沟通，但你要确保的是你真的知道自己想要的是什么。很常见的一种情况是，产品人员对设计的要求是：大气一点，清新一点，热闹一点。而当设计师给出设计稿后，往往产品又觉得这不是我要的那种感觉。不得不说，这样的产品经理其实她娘的根本不知道自己想要的是什么，或者说无法很好的将自己的设计想法传达给设计师，如此，又怎么出来好东西呢？
产品经理在设计前一定要给设计师做详细的产品介绍，这个介绍不仅是要说明产品的特性，功能，文案，更重要的是要讲解清楚这个产品需求的重点以及希望设计表达的产品含义。虽然说UI设计师负责的是界面美化，但这个美化也是要有思想的。从另一个维度讲，产品经理向设计师解释自己思路的过程，也是产品经理确认自己提出需求有明确价值认识的过程。
产品经理需要关注重点应该在产品整体的风格、可用性、易用性、信息展示的效果如何。而设计的各种细节和用色，这些还是交给专业的设计师来做，在这一方面，产品经理应当充分信任设计师的专业能力。
3.产品也要懂一些基本的设计知识
产品经理本来就是一个杂家，不仅要对所触及的各个领域都略懂一二，还要对自己的领域精通。那么在产品流程各个环节中，你了解得越多，自然对自己工作越有利，自己也就越主动。

⑹ 产品经理如何与强势的技术沟通

从我的角度讲，绝大部分技术人员说实现不了。其实隐含的意思是：

1、当前没时间；

2、这个东西，尤其是已经迭代开发过几次的项目或者产品，其框架和技术选型其实已经制约了某功能的实现（不是功能做不了，而是做出来满足不了产品经理的要求）；

3、该技术人员目前还没掌握此需求所需的技术积淀。我也貌似某个大型软件产品的产品经理。

从我的从业经历来看，确实是有研发经验和基础的产品经理，跟我们的技术团队交流起来是要顺畅些。在这样的条件下，技术团队一般也会认为你是大半个自己人。而你也会从产品设计和产品实现两个角度考虑问题。但是透过现象看本质，其实这里面是沟通的力度和沟通的态度在其中做了怪。比如我来说，可以从两方面去考虑问题，这个是较顺畅和容易些。而一旦产品设计和产品实现的职责变成2个个体来碰撞的话，我们就开始防范和潜意识的抵制对方。技术嫌产品人员老改来改去，产品人员觉得技术老是拖拖拉拉，而且不按设计干活。我的做法是，在做产品设计的时候，我会邀请我们的技术骨干参与进来。当然前期他们是聆听，等他们理解我的想法和设计后，我们再来进行探讨。最后形成原型提交。然后后续的写文档啊，开发啊。这样一般要顺利些。我在我的团队里，提倡用下里巴人的语言讲高深的行业知识。树立“越是明白人，越能用白话把事情讲清楚。”的思想。

⑺ 产品经理如何有效沟通

一、凡事有回响

在职场沟通中，同事艾特你必须要回，哪怕忘了,也要事后回，并且给出解决方案，如果不是自己负责的事情，也要告诉对方谁负责。

如果答应对方的事情，就一定要做到，否则不轻易答应，最坏的情况下答应的事情解决不了，也要提前和对方沟通一起想解决办法，而不是等对方问的时候，才说出实情，这样印象分会大打折扣。

注意，这里要做到100%的回应。因为哪怕对方 问了10件事情，有一件事情没有回应，那么在对方心理你做事都不是很靠谱。

二、沟通技巧

在日常工作中，用star法则，能最准确最快的把问题说清楚，这招同时也适合面试的时候陈述自己的项目背景。

大家一定要重视沟通技巧，如何深入浅出把自己的想法传达给协作者，直接决定了自己方案的落地性。

三、精确输出

在工作中我们有输出的文档，比如日报、周报、月报、各个时间段的计划以及prd等。

要写的东西是如此之多，以至于很多人在输出时忽视了相应的标准。

比如日报和周报中，计划没有写，连下周做什么都不知道;

比如prd 中界面是过来的，还存在其它历史界面，存在误导开发的后果;

比如在做产品规划时候，措辞不准确，甚至用几个字就代替负责的方案，也不做具体的解释，让别人看不懂;

比如画流程图，线条过于复杂，没有做拆分，给相关人演示时把自己都绕晕了……

以上都是精确输出的反面案例，产品经理如果输出要么不做，要么就有一些标准，一定要做好。

⑻ 产品经理如何和开发有效沟通

现实中对开发的沟通能力普遍让人们给弱化了，其实并不是沟通能力的问题，而是逻辑角度的问题，产品经理考虑的问题更宏观更贴近于用户，而开发的角度则是针对某一需求怎么去好实现，所以造成了产品与开发的无效沟通比较多，
有效避免的话就是转变思维，引导他们在你的角度考虑问题。

⑼ 甲方要求公司产品进行小改动，但是公司技术人员觉得没必要，不想改，这时候我要怎么跟双方沟通

客户至上啊，首先应该劝技术人员进行修改。告诉他维护客户利益就是维护自己的饭碗。
技术人员如果坚持不修改，让他讲出修改后可能产生的不利因素，然后说给客户听。
个人观点，仅供参考。

⑽ 产品经理如何与RD（研发）沟通

导读 

上节课，我们提到，作为团队枢纽的产品经理，优秀的沟通能力，是必要的能力与品质。

之所以用“必要的能力与品质”的定义，是因为产品经理只要稍不留心（特别是产品新人），就容易与其它同事产生沟通障碍，发生沟通矛盾；特别是与RD（研发/工程师）之间的沟通，“沟”了没“通”几乎会成为常态。而因此引发的一切严重后果，都将由团队陪同产品经理一起买单。

1、产品经理和工程师有哪些沟通问题？

2、产品经理为什么会被工程师嫌弃？

3、产品经理应该如何与工程师沟通？

正文

作为产品经理，特别是产品新人，肯定/绝对/100%会遇到各种各样的沟通问题；与此同时，我们也更加需要学会找到导致问题的本质原因，根本解决问题并更好推动产品工作。

接下来，我们会对X小姐文章里7处具有典型代表的内容，进行解读，方便大家更好的理解。

一、产品经理和工程师有哪些沟通问题？

原文引用1：

最近有位刚做PM（产品经理）的小伙跑来跟我控诉，说公司技术部的RD们（工程师）个个不给力。需求过了千百遍还是理解错，或者就是简单回一句“做不了”，表情如死灰。

解读思考：

这是所有产品新人都会遇到的问题（我过去做产品，有时候也恨不得把工程师们给**），但本质原因不外乎有两个：

1、需求并没有按照工程师们的思维模式来表达，他们理解不了自然也就回复做不了（所以大部分时候他们说做不了真的不是在推诿骗你，而是他们真的没有理解清楚你在说什么）；

2、需求没有优先级，工程师们无法明确研发节奏；大部分时候一股脑无定级的瀑布式需求，自然会遭遇一股脑的无视（就像有时候同事找你做事，一股脑的给你提了很多需求，也不说轻重缓紧，你也会瞬间懵圈）。

原文引用2：

这位PM血气方刚，张牙舞爪，脑子里总有一千万个新产品需求的想法扑腾着。

解读思考：

这里需要打击一下，“脑子里想法创意万马奔腾，实际中能落地的几乎为零”，这是几乎是所有产品新人的通病。

产品新人在自身的能力还没有系统丰富的时候，对于需求的理解和认知，大部分时间都局限在一个点上，很难以点思面的思考问题（这并不是产品新人的错，事实上每一位优秀的产品经理，都需要这个成长的过程；要解决这个问题需要一定时间的业务经验与思维拓展历练，稳定心态很重要）；所以，在产品新人的大多数时期，不提需求比提需求更重要，执行好任务比天马行空更务实。

同时，发生这种情况的还有一个重要原因就是：被碎片化的文章或言论误导了，对产品经理没有系统客观的认识和理解。

过于理想化和抱怨，真心是产品经理沟通中的硬伤。

原文引用3：

面对他，我的心突然惆怅起来。几年前的自己也差不多是这个模样，懵懂如白纸……

身为一位女性PM，我至今为止并肩合作过的RD团队超过8组共200多人（动荡曲折的职业生涯啊）……

所谓人艰不拆，希望大家看完后能更理解彼此“都不容易”的立场。

解读思考：

产品经理是应该有个性的，但类似：自以为是、以自我为中心、随意放大自我感受……的“个性”，一定要尽早去掉，除非你不想做一个优秀的产品经理。

作为产品经理，一定要避免将自己陷入认识与情绪的局限里；包容与理解，会让你“产品经理“人设的人格魅力MAX！

毕竟不是人人都可以是乔布斯、张小龙……在生命的很长一段时间，我们与并肩奋斗的工程师、运营、设计等小伙伴们都一样是平凡人，我们都要一起面对生活与工作的不易；彼此真的“都不容易”，所以，理解万岁：）

原文引用4：

PM眼里的RD分成两种：能沟通的，和不能沟通的。后者占90％。

解读思考：

我也遇到过这种情况，当我踌躇满志，把一个产品勾勒得很美好的时候，突然发觉，为什么工程师们在用那种木讷的、毫无光亮的眼睛（眼神）看着我？他们不仅一点都不兴奋，还会问我：

1、这个功能为什么这么做？

2、你确定这样做没问题吗？

3、这个东西不是刚改过吗？

所以最开始，我也认为工程师是没法做朋友的（大致原因参考引用2的解读思考）。

原文引用5：

曾经有一个RD总监，在Kickoff会议上把我所有的需求都推翻了，让我差点在十几个老男人面前哭鼻子。

话说人在经历苦难后，要么变乖，要么变坏……于是我学会了通过非正规途径收买RD的心－－

比如请他们吃KFC啦，陪他们聊黄色笑话啦，穿低胸装秀黑丝大腿啦。

解读思考：

Kickoff（启动会议），基本可以理解成打仗前的誓师大会。已经要出征了，RD总监直接把X小姐的产品掰翻。

遭到打击后，X小姐的态度也很鲜明，强烈且迫切的心情想要让RD听命与她，于是决定通过非正规途径来搞定RD。

我觉得女生做产品经理一定要有掌控的欲望，要有一颗当女王的心；男生就更不用说了。

我最开始为了和工程师打成一片，也是什么事干：请人吃饭、帮人泡面、陪人加班、接人上下班（这个不要轻易效仿，毕竟一个成年男人每天刻意的去接另外一个成年男人上下班，而且时不时还要换不同的人，画面的确有些尴尬，也比较容易引起敏感话题 - -！）……通过不懈努力，我和工程师们的关系终于也改善了许多。

原文引用6：

正当我沾沾自喜，认为自己靠美胸美腿赢得了这场战役时，一个Ruby工程师幽幽的跟我说 “我好喜欢你的门牙” 。（鸦。。。你们果然是无法沟通的生物。。。）

解读思考：

真的是这样，我们可能永远也不了解工程师们的心，即使彼此的关系得以改善之后。

大多是时候，特别是产品新人们看工程师，总觉得别人傻傻的；与此同时，在工程师的眼里，我们可能更傻。

在我看来，发生这样的情况，大多数时候的本质原因，仅仅只是工程师们表达情感的方式质朴直白的表现；不能因为工程师们不会说话、不尽表达、不够“情商”就忽视了，大多数工程师的脑袋里，都有一个神奇美妙的世界，只是我们不懂的探索而已。

所以，有时候放下所谓的“说话艺术”、“情商”、“温柔”等定标性偏见，用最质朴直白的方式去理解工程师的表达，彼此都会轻松高效很多。

原文引用7：

RD眼里的PM也分成两种：有脑子的，和没脑子的；后者占90％。

没脑子的PM，RD们是打心底森森嫌弃你的。

解读思考：

其实，沟通更深层次的条件是相互的信任。

产品经理和工程师之间，如果没有建立好一种信任的关系，那彼此之间的合作就会不协调，也就会经常出问题。

但在大多数情况下，产品经理是很难获得工程师信任的，甚至被嫌弃。

为什么？

二、产品经理被工程师嫌弃的3个原因

现在我们来解读，X小姐从她的血泪史中总结的，产品经理被工程师嫌弃的3个原因。

1、没有自己的想法

解读思考：

如果我们经常说，“这个东西是老板说的”、“老板要这么做”，好像这个事情和你没关系，那工程师们在心里是不服你的。所以产品经理一定要有自己的主张，你可以这么说：“老板要求这么做，我觉得还是有一定道理，不如咱们试试吧。”

或者：“这个确实是老板要求做的，我感觉还是有点问题，怎么办？我们再沟通沟通，还是怎么着？”

我们要有自己的主张和独立的思考。这样，工程师们才会相信，你犯错的几率更少，把事情做成的几率更大。他们也才愿意协助你，助你更好地推动产品，对吧？

2、风花雪月没有逻辑

产品经理很讲究“感受度”；这也是我一直强调的，优秀的产品经理一定要通人性，感情丰富。

我们也说，产品经理要有理性的思考和感性的表达；理性的思考在背后，感性的表达在前面。

感性的表达简单理解就是：尽可能的用对方更容易接受和舒服的方式去传达自己的意思。

工程师们大多是逻辑思考能力很强的理科人才，在与他们的沟通协同时，如果思维不缜密严谨，或是呈现的事物缺乏逻辑经不起推敲，就可能被嫌弃。

3、不信任工程师的能力

如果我们不信任工程师，他们是能感觉到的；或者有时候我们问工程师研发一个功能大概需要多少时间，他们回复可能三五天；但最后你发现，其实只要半天或者两个小时。

这些问题，也会使大家平时的沟通产生障碍。所以X小姐提到：要让工程师觉得你很优秀（一定要让工程师觉得你很优秀）。而实现这种状态的前提是，我们先要学会去信任和肯定工程师们的能力。

所以，要做到良好的沟通，背后有很多需要我们去推进的事情，而不仅仅是所谓的沟通技巧和表达能力。

三、产品经理如何与工程师良性沟通？

文章最后，X小姐给出了7个建议，很有启发价值。

1、眼观四路，耳听八方。

“知识渊博，掌握行业内的各种动态，分析市场趋势……”要让工程师们觉得你是一个靠谱的人，什么都知道。

2、混对圈子，积攒几个牛逼人脉。

关于这点，我在后面的课程里会与大家讲到的：产品新人们一定要去混圈子。

拥有更多牛逼的人脉，既可以帮助产品有获得更多露脸的机会，也可以帮助招聘到更多优秀的工程师，也就能更好推动产品工作。

3、无论是口述的需求还是撰写的文档，文字和原型图的呈现都要有逻辑。

这是最重要的。

很多产品新人找到我说：“刘老师我觉得写文档很痛苦，我可以口述么？”。其实我接触的很多的产品团队，有很多也是不写文档直接口述的，但同时这对语言表达能力也有更好的要求。

其实无论是着重于文档的文字表达，还是着重口述的语言表达，本质上最重要的还是表达核心思想的逻辑。

就像X小姐说的，无论是口述，还是写文档，一定要有逻辑。“功能细节上的逻辑处理得无一遗漏，实乃RD们的心头好。”

4、在老板责问为什么还没上线的时候，冲上前去说，“都是我的错，前几天又改了个需求”。

当工程师们真的很努力去做了，却被老板指责的时候，如果你能主动帮他们挡刀，他们会觉得你是一个有担当的产品经理。

5、在RD们被各种部门的需求同时袭击的时候，为他们安排最合理的优先级，并承诺担起一切后果（包括被某部门主管批斗责骂等）。

6、招到漂亮的实习生妹子给RD们养眼（请一定投其所好）。

7、给他们加薪，给他们加薪，给他们加薪。

本课小结：

产品经理在推进日常工作时，经常会和工程师发生沟通问题，着其实是普遍存在想象。

遇到问题，我们不要一来就想改变工程师，而是要学会先分析和总结自己的问题。

除了学习沟通技巧和表达能力，更重要的是要深刻理解并协助团队小伙伴。产品经理要有自己的主张，有同理心，有理性的思考和感性的表达；这样，才能获得工程师的信任，更好推动产品工作。

当然，沟通问题只是抛砖引玉，沟通只是产品经理工作中常遇见的问题之一，产品经理在工作中还会遇到各种问题，譬如：长期被加班、顶雷专业户等。

所以，下一节课，我们就来全面解读一下作为一名产品经理，我们将会遇见怎样苦逼又有趣的工作与生活状态。 

备注鸣谢：

推荐文章：《如何与RD沟通，写给那些血气方刚的产品经理》

链接地址：http://36kr.com/p/212020.html

特别说明：

因为我与团队在日常工作中，更习惯喜欢称呼RD为工程师，所以为保障阅读体验，引用X小姐《如何与RD沟通，写给那些血气方刚的产品经理》原文内容中出现的“程序员”均替换为“工程师”。

 

关于《产品经理入门指南》精译版

《产品经理入门指南》原本是刘文智老师于2014年发布的，国内第一套系统的互联网产品经理入门方法论视频课程。课程历时9个月精心准备，收集了上千名产品新人的真实需求，参考了近百家产品团队的用人标准，汇聚了数十位产品大咖的专业意见。旨在：

1、教会：产品新人评估自己是否适合做产品；

2、帮助：产品新人找到契合的入门学习方法；

3、引导：产品新人走出入门困境和学习误区；

4、启发：产品新人化解学习难题与高效成长。

应众多同学的需求，现由刘文智老师携课司机团队，重新编译为图文版，限免发布。

关于作者刘文智老师

刘文智 Jason

连续成功创业者，天使投资人，创业投资顾问

80后，爱足球、爱电影、爱较真。

知名产品经理社群“产品壹佰”、IT在线职业教育品牌“美好学院”创始人兼CEO

互联网社群+IT职业教育成功商业模式的创新开拓者；

于2016年接受慧科教育科技集团全资并购邀约出任集团合伙人、开课吧CEO；

2017年末转做天使投资人，创业投资顾问。

中国首位发布系统互联网产品经理职业教育体系的老师

2012年起先后着有《产品经理入门指南》、《产品经理深入浅出》、《手把手教你做产品》等互联网产品经理线上、线下实战教学体系；课程全网学习频次超千万次，影响了包括美国、加拿大、澳大利亚、丹麦、新加坡等超过38个国家和地区，帮助13万互联网人获益；

中国最早推出以就业为导向的产品经理职业教育服务的老师，数万名学员广泛入职中国各大互联网企业以及知名互联网企业核心产品团队。

15年互联网、10年教育一线坚守与沉淀

曾任搜房、新浪两家上市企业产品与营销策划相关工作；

曾任电子科技大学千星计划互联网应用专业负责人。

温馨提示：

若需获得更多产品经理学习帮助，推荐关注刘文智老师的微信公众号（微信号：iamliuwen）。