起点课堂会员权益
职业体系课特权
线下行业大会特权
个人IP打造特权
30+门专项技能课
1300+专题课程
12场职场软技能直播
12场求职辅导直播
12场专业技能直播
会员专属社群
荣耀标识赠书福利｜产品经理需要懂技术吗？它可能是最适合你的答案
作为中国最大的产品经理社区，在我们发起的数百个产品经理交流群里，常常能看见大家在探讨一个话题：“产品经理需要懂技术吗？懂到什么程度？”
许多朋友给出的答案都是：要懂。
所谓“懂“技术，并不是说产品经理一定要学会自己写各种代码，而是尽可能全面地了解与自己的产品落地息息相关的各方面技术。了解它们是什么、位于哪一个层次、有什么作用，可能出现的技术难点一般会存在于哪些方面，如何在设计上进行调整应对等等。
虽然这些已经在业内达成了较为普遍的共识，但对于许多非技术出身的产品经理朋友来说，如何入手提升对于技术的了解与认知，依然是个难题。
为了帮助非技术出身的产品经理朋友提升对技术的认知，以更好地在工作中与技术人员沟通需求，从而更好地达成合作，做出好产品，2017年1月，我们就已经与技术转型产品经理的优秀代表、社区专栏作家唐韧老师，联合出品了《产品经理必懂的技术那点事儿》一书。在过去的半年里，我们也联合起点学院，与唐韧老师共同推出了《产品经理的技术必修课》系列课程，为非技术出身的产品新人科普基础技术知识。
第一版《产品经理必懂的技术那点事儿》一经推出，便获得了数万产品经理朋友们的认可与好评，当然也收到不少对内容的建议。
随着产品行业的变化以及对产品认知的加深，我们力邀唐韧老师推出本书的2.0版，经过7个月的精心打磨，这本书再次升级：《产品经理必懂的技术那点事儿——成为全栈产品经理》终于上市销售了。
可能，你会对如下2个问题比较关心：
- 这本书适合谁阅读？
- 书中包含了哪些主要内容？
在接下来的内容里，我们将为你解答这些疑惑，并赠送10本新书给一直关注着人人都是产品经理社区和唐韧老师的朋友们，赠书的方式请参考文末说明。
这本书的作者
唐韧（Ryan），《产品经理必懂的技术那点事儿》作者，人人都是产品经理专栏作家，微信公众号：唐韧，国内早期移动开发者，转型产品经理，目前在创业公司负责产品工作。
这本书适合谁阅读？
本书以帮助读者建立“技术思维”为目标，希望读者在阅读本书后，能具备基本的技术判断力，并且实现与技术人员的高效沟通。
所以，如果你是：
- 非技术背景产品经理
- 设计师或者运营同学
- 在校大学生或者想从事产品工作
那这本书适合你一读。
如果你已经读过老版本的书了，并且希望对技术以及产品和运营有更多的了解，可以选择本书。但如果你对技术知识的理解已经有一定的提升，那这本书在技术角度不会给你太大的帮助。
如果你还没看过本书，并且希望获得“产品+技术+运营”整体思维，这本书适合你一读。
书中包含了哪些主要内容？
全书以“产品+技术+运营”为主线构建内容，通过掌握产品思维、具备技术思维、使用运营能力成为“全栈产品经理”。
本书从基础到应用，梳理了一套适合非技术背景同学了解并学习技术的脉络。
在内容框架顺序上，以互联网技术发展历程开始，介绍了互联网技术的演化历史，然后过度到最基础的技术知识，也就是什么是程序、什么是编程语言，通过对基础技术知识的介绍，让读者对“技术思维”有整体的了解。
在完成基础技术知识内容的介绍后，就会展开技术应用层面的介绍，从客户端技术、后端技术、数据库技术以及产品数据收集统计等为读者逐一详述技术应用层面需要了解的技术知识。
同时，本书不是一本狭义的技术书籍，不仅仅从技术本身讲述，核心还是为非技术背景产品经理提供一种“技术思维”，所以在于技术人员的沟通、解决问题的方法上给出了一些参考建议，试图帮助非技术背景的产品经理能够在与技术人员合作的过程中更加顺畅。
此外，在新版书中，唐韧老师还结合了自己这几年的工作实践，将产品工作过程中与技术团队、运营团队和相关职能协作的一些收获也记录了下来，综合为“产品经理必懂的运营技术”。
赠书规则
1.在本文下方评论区留言（仅限在woshipm.com站内或产品经理app内留言有效），写下你在产品工作过程中，因为“不懂技术”踩过的坑，唐韧将在2月7日24:00前的所有评论中，挑选出最具代表性的10条走心评论，每人赠送1本新书《产品经理必懂的技术那点事儿：成为全栈产品经理》
2.所有参与评论的同学，都可以获得由人人都是产品经理社区、起点学院与唐韧老师联合推出、受到近千名学员好评的《产品经理的技术必修课》第7期课程限时3.3折超值预约购课优惠，扫描下方二维码，联系起点学院betty（微信/手机：18680310383），并备注“预约”可领取
中奖名单公布
懂技术带来的便利是相似的，不懂技术的产品经理却各有各的辛酸
在发出“你说故事，我送书”的活动后，我们共收到了200多条留言回复，大家纷纷分享了自己因为不懂技术而踩坑的经历。唐韧老师也仔细阅读了每一条留言，并从中选出了10位同学，赠送新书。这10位同学的社区昵称分别是：
- 赵传义
- Mango
- A_真爱无敌
- ◇◆◇·洋
- erma_feng
- 爱喝饮料
- Bili
- Mr.Z
- 晴暻
- 于快快
恭喜以上同学！每位同学都可获得唐韧老师新书《产品经理必懂的技术那点事儿：成为全栈产品经理》1本。请于2月8日晚20:00前联系起点学院betty（微信/手机：18680310383），备注“领奖”，领取奖励，过时视为自动放弃领奖资格。
这些同学的踩坑经历都在评论里有分享，大家都可以去看一下。希望每位同学都可以多懂点技术，少踩点坑。
（如果你已经迫不及待要看到唐韧老师的新书，也可以戳这里直接购买：http://item.jd.com/12296638.html）
嘻嘻，我不是做产品的，我是做向同事运营的小伙伴，但是对于技术也是小白，在工作中经常向同事提问，什么是前端，什么是后台，等等白痴问题。希望可以学会点技术
终于可以不被怼了
作为一个刚刚要从设计师转到产品的我，听到这个消息简直不甚欢喜！做设计师的时候想一些交互上的问题，也会被技术说这个不能做，吧啦吧啦吧啦～～～～（虽然不是很懂，但是也感觉被忽悠了）下定决心要好好了解技术！但是公司了解的不全面，只能遇到问题才去了解技术！遇到这本书简直太幸福了吧～虽然第一版没有读过，但是相信第二版会更加完善！希望能更好的提升自己，系统的学习产品。小编小编～看到我的小心心了嘛
1岁产品经理，工作中除了自身经验（眼界）不足挖了坑，日常挖坑就是因为不了解技术；了解技术其实是为了提高效率吧，毕竟产品整个开发效率从设计原型开始才是最佳的。团队中和开发配合的时间最多最长，他们平时忙，给你梳理开发难度显然不现实，只能靠自己多学习，把坑尽量挖小一点……加油！
坑1：开发周期时:长的一脸懵逼；
坑2：开发难度预计的一脸懵逼；
坑3：开发维护Bug难度的一脸懵逼；
坑4：产品技术架构的维度上的一脸懵逼；
坑5：需求评审的难度上的一脸懵逼……
和谐开发你我他，产品和程序员是好朋友，对吗？！（围笑）
做了半年多的产品助理，从互联网不搭边的专业转到本行业，由于不懂代码逻辑，和程序员闹矛盾是家常便饭，每当我和程序员闹矛盾过后，就想，为什么程序员不懂我的意思，和做这个功能的意图，就有一种孤芳自赏的感觉。开始我以为是自己的原因，就开始买书自学编程，学着学着发现思想受到程序逻辑的限制，思想变得很狭隘了，但是和程序员撕逼的次数变少了。希望能够通过本书找到未来规划，和跨过这个新人的坑~
目前做产品来说更专注于业务领域，更多对接客户和运营，因为是计算机专业，而且自己逻辑性比较强，在技术上、和开发对接上，基本没遇到特别大的困难，最多就是在技术细节上，把锅举高高，往上甩。说两个例子，一个是App开发，在业务设计上自认为逻辑清晰地表述清楚了，开发人员似乎嫌麻烦找了一堆关于cell的理由，然后我就找总监沟通确认了实现，开发只有乖乖去做了；一个是BI框架的设计，有三个方案：自己开发组件，运用第三方插件（百度echarts之类），购买服务（BI厂商），和开发讨论不休，最后直接找了上层拍板。其实觉得如果懂多点技术，比如实现方式、难易程度，应该会更有效合理地管控产品
正在转产品，每次让我们的技术小伙伴们做个功能或修改个功能都已之前的谁谁谁做的找不到、改不了为理由，至今死磕，能改过来的都改过来了，改不过来的就还那样，我心是忧桑的；死磕到底，与楼上的众位大神比起来感觉还是幸运的，死磕成功后最起码能给我改，虽然我技术的道理讲不过，但是我能讲歪理啊（此时我的技术小伙伴可能泪流满面的——因为确实有些东西更改不了） ➡ 就等着学完技术让我巴拉巴拉说完拿正经的他们的道理跟他们讲，就等着看他们张大嘴吃惊的样，小样这回该能给我改了吧 😀 言归正传，楼主我要求书求书
如果我中奖了，我看完之后会继续把书分享给更多的人:D
很走心的说，踩过比较多的技术坑，就不举例了，因为项目情况各不相同，并不能给大家比较好的参考，但针对技术方面得出三个对大家自身比较有用的建议：
1.的确如文中所说，不需要懂底层代码什么的，但是要了解再日常沟通中常用的技术词汇；以及再项目功能中要明白是否能够实现，实现的大概周期，有余力的童鞋可以了解是通过什么手段实现的
2.要多问为什么。和技术沟通中过程中通过话术要明白为什么不能实现，为什么要7天才能实现，为什么…（重点是话术，辅助必要得人情手段：吃饭喝酒之类）
3.再往上看一步，以现在互联网趋势来看，技术的门槛越来越低（大部分行业，AI/区块链等除外），运营变的越来越重要，就要考虑自身发展得重点，是向市场运营侧重还是偏技术因人而异，勉励之
最后，祝大家都能早日跳出技术坑，迈向更大的坑…☺
作为一个设计出身的产品经理，深知技术与策略并重的重要性，首先就是沟通，能正确的把自己想要呈现的效果传达给技术和设计，可以节省很多时间，其次，如果产品经理懂一些技术，在策划某个方案的时候可以尽量规避技术无法实现的难题，所以产品经理不一定会技术，但一定得懂一些常识，因为这样你可以提前知晓你所策划的案子是如何落地执行。
作为一个刚入行的小白，非常希望通过自己现有的特长在策划这条路上能走的长远，多方面学习一些知识，促进个人成长。
“不懂技术的时候就会说，这个东西不就是简单的特效么，你就是像谁谁谁那样做就够了，很简单的，这个做出来之后用户肯定会很喜欢；什么，你做不出来？做不出来就想办法，问问身边的一些其他大神吧，反正我再给你宽限两天，你就肯定可以做出来！我虽然不懂技术，但是我感觉这个就是很简单，你不要逃避问题嘛。这个就是要这样的做，你实现不了就花点时间专研一下，别人能搞出来，你也肯定可以搞出来的，加油吧!”
—–来自我的产品同事
所以我特别希望，能送他一本书，就是如何理解程序员说的难到底是真的难还是假的难，实现不了是真的实现不了，还是很难实现！恩，送给他！ 😀
每次与开发沟通，经常被说的体无完肤，说这个底层逻辑太复杂，搞不了，可是在我看来很简单呀，就两个东西，非说做不到，容易被忽悠，希望能够通过学习，能够更好的理解开发，项目能够顺利进行
我是去年中旬刚接触产品的，小公司你懂的，莫名被项目经理叫去当产品经理，项目经理是偏向技术这块的，以上为背景。然而产品小白不断学习中只能听项目经理的，每次开会是我主讲但其实都是项目经理在哔哩吧啦一大推，你写这个功能的时候有考虑到开发是怎么实现的吗？这个功能现阶段对开发来说实现有点难度，能不能换个更好的方式实现。这个功能先留到后期吧，前期实现难度有点大，害怕开发那边忙不过来的，赶不上工期。内心各种黑人问号，还能这样子砍需求的？无奈对于技术这块不是很懂没有发言权，只能默默地修改。。。
老板说：做一个商城平台，一个半月完成。
我理解，时间紧得快速开发，管他什么需求，老板说做那就做。按着淘宝一路全画原型图里了。
花两天，用户前端原型出来了，老板一看，说：不对，还少了上传商品，商家得查看订单呀对不对？
我了个去，这是要搞大事情啊！行，加，那就给加个商家管理后台！是的，确定要在用户的前端加个商家操作后台（捂脸）（捂脸）！
再经过两天，原型初版发群里了，跟着是老板的技术开发时间表。
其实说真的，我只是一个画原型图的，收入不高，技术没有，经验不够，想法不创新，但是我想学习，我想怎么做好一个产品，我想怎么利用产品帮到更多的人！
需要
“不懂技术”最大的坑莫过于在需求排期时经常被技术人员忽悠，明明就是一个很简单的需求，技术人员给你预估工时的时候随便给出个5人天，理由是你这个需求我需要新建一张表、还要增加一张映射表，还要修改底层代码，系统的代码逻辑也要做出修改等等，让你感觉很有道理一样，其实很有可能他所谓的5人天的需求前3天他们都在打酱油，最后两天稍微努把力就解决你的需求。如果懂一些技术知识，可能就很容易反驳他们，将工时压缩到3人天，提升整个项目进度。
从事产品经理工作，一直在创业公司。流程和体制不完备的情况下，产品容易独立出产品方案，没有需求评审，更没有技术参加，等prd做完之后，再对接技术，真的是坑事不断。基于对技术底层框架的不了解，或者兼容性不清晰时，设计的功能很难加入现有框架，这就导致重新更改产品设计，反反复复，心力疲惫，就很没有效率了。以上只是其中一点，还有很多被技术怼的无话可说的时候，还有时候其实功能可做，但是技术难度较大，技术人员自身水平不够的时候，会托辞说：不行啊，做不了，你这个设计的有问题，技术实现不了。此时如果懂点技术，就可以理直气壮的怼回去了，告诉技术可以通过哪些方式实现。（以上为本人亲身经历，并不代表全部创业公司产品经理 ➡ ）
1、提出一个在开发看来是反技术的需求，然而并不懂为啥时的懵逼；
2、一个简单需求评估需要几周的开发时间，开发大讲特讲需要做的技术准备，然而一句都反驳不了；
3、一遇到技术实现的问题，仿佛一个弱智。。。
我学的是营销专业，从事产品工作快5年了，有几处因为“不懂技术”踩过的坑列举如下；
1、2013年刚从事产品工作，领导要看一些数据（大概有5个），我把数据整理之后交给技术同事，结果他们把这个需求排期到2天之后（写个SQL都要排期，明摆着欺负小白！！！），我把结果跟领导反馈后，领导笑着跟我说，他们忽悠你呢，这个事情分分钟搞定，哪里还要排期，于是他自己打电话给那个同事，结果10分钟之后结果就出来了，事后我真想杀了那个同事，欺负我不懂技术！
2、有个项目需要和外部系统交互，接口文档由我整理，完成后交给开发小伙伴了；后来因为文档中有较多的字段命名不符合技术规范，好多字段需要重新命名，技术同事说这个修改是伤筋动骨的，数据库和实现程序都得改，巴拉巴拉。。。；最后工期增加了2天，而且还遭到开发同事的嫌弃。。。
3、参加某个需求讨论会，运营提了很多需求，由于技术知识缺乏好多需求能否实现不能当场给予回答，结果遭到运营同事的好多白眼和疑似嘲讽的微笑。。。
总结：产品还是要懂一些技术才好，这样需求实现难度、排期、后期的产品拓展心里才有谱，我在平时的工作中，通过向技术同事学习、网上查阅、购买书籍等方式不断学习着技术知识，现在工作起来有底气多了。
每次讨论需求：
程序猿：这个不能实现，这个逻辑有问题，这个babababa…..
我：这些都是很基本的功能啊，为什么不能实现，市面上那么多APP，人家不做的挺好的嘛….
程序猿：那你来呗…..
我：…..
每次都恨不得自己变身技术大牛，当研发说你来的时候，我立马当他的面敲出完美的代码。。。。 ➡
本人是新闻专业出生，后入互金产品坑，熟悉业务逻辑，但是对技术实现心中没谱。入坑初期负责一项运营支撑系统后台项目，其中主要功能模块是对包括线上、线下的不同渠道、平台的业务做订单管理及销售统计，开发评审时技术大神说有些统计字段只存在核心系统，有些在则业务系统，数据字段不统一没法做统计，当时就懵逼了…后来有心了解一些技术知识，网上查了下大多数教各种编程语言的，与产品不太相关。
半岁产品，负责一款新的B2B2C产品，经历过最大的坑就是，因为涉及到很多身份区分以及数据库结构等等的问题，在我的理解中很容易拆开或者分隔开的数据和页面，在开发逻辑上根本走不通，我一开始又没有清楚阐述这一个需求，现在挖出来的天坑已经快要把我埋了~
也算是深刻了解到一点，越是底层的东西，越是要反复思考反复琢磨，在产品最开始的时候就考虑好延展性，因为后面一动就基本等于重做了
我：程序员哥哥，这个功能您看一下能不能实现？
技术：哦，我看看
三分钟后…
技术：这个功能服务器*#￥……&，控件&……&*&……
我：那可以做吧
技术：我都说了服务器*#￥……&，控件&……&*&……，做不了
我：…
个人在技术方面比较保守，一般在产品的任何设计阶段都会先考虑这个功能我们公司目前的程序员实现起来容不容易，不容易的是不是还需要学习，会不会耽误工期，或者是不是这个技术在行业就是一个难点，这样的话学习起来就更加困难以至于不现实。
从易到难的思考，站在技术的角度去考虑功能的实现，这也让我经常低估了我们技术人员的水平，非常尴尬，希望能够更加了解技术，了解每个阶段的程序员应该具有的水平，了解产品的开发成本（人员成本、学习成本、时间成本）
从去年已经打算成为产品经理的我，已经关注咱们平台很久。只有自己对这些知识都懂，才不会被技术人员排斥。这本书我特别感兴趣，也觉得特别适合自己
我们公司是开发主导项目，但是产品推进，把控时间。经常会出现技术开发部门虚报开发时间的情况，客户火急火燎，技术还拖延时间，产品无法反驳，哎呦。。。
码农：你设计的这个是什么鬼，实现不了啊。 负责人：实现不了设计师就换一下页面吧 我;…………..好吧
我是想技术转型产品，作为技术人员，经常会遇到有想法但不懂技术的人，深知之间的那么一点鸿沟，需求想法与实现之间的距离，所以做产品对技术来说还是需要大概了解技术思路和实现大致方案。期待老师的新作品和指导！
那么我来做第一个，抛砖引玉好了。转行做产品不足一年，做分销系统时，开发同学为节约时间采用之前的货币体系，导致后期的拓展功能（老板根据市场战略提出的）无法很好的展现，那么这个锅谁来背？当然是不懂技术的我 😈 不能再被技术牵鼻子走，于是下定决心提升技术能力，更重要的是作者的技术思维很吸引我，谢谢
每次新方案出来之后，要和技术交流，他们就会以各种理由来说，这个东西实现起来有什么什么问题，或者是技术在以技术的角度讨论的时候，感觉自己就像个二傻子似的，什么都听不懂，这种感觉好痛苦，当技术讨论完以后，给到的结果，自己只能默默的承认，不管是否可以现实，或者以什么样的方式来实现。