起点课堂会员权益
职业体系课特权
线下行业大会特权
个人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）
终于可以怼技术了？！
懂点产品思维，用户思维，设计思维，就差工程思维一窍不通 🙁
别问懂不懂，就问你愿不愿意学习。我们产品部门技术业务都要会，没技术，你有什么本事和开发沟通
接上一条，起运地搜索框的搜索和查询问题，最近我又得出了一个开发认同的方案
使用【搜索联想】解决问题：
发货地和目的地，是一个地理位置，我理解是城市啊
中国行政区划有四个级，省市自治区直辖市，地级市自治区，县级市/区县，乡镇街道
一个城市包含，中文名字，汉语拼音，区号（地区级别），邮政编码（乡镇街道级别）
所以，用户可以输入区号/邮编，中文，汉语拼音，拼音首字母进行城市选择
如果输入了一个中文，联想不到，提示可以新建保存一个地理位置（虽然该用户可以用，但需要管理员审核之后，才放给其他用户公用）
就说最近遇到的一个事情，一个面对特定行业人群的产品；起运地的搜索框，开发决定以单击搜索，双击查询来区分两者，为此我和开发争执起来，为何不用模糊搜索来结合两者？我们开发给的解释是,用户查询的时候,需要输入地址,然后看后台数据库有没有相关的代码数据,如果没有的话,手动输入的地址,就无法使用。还有数据量庞大，做显性排查会增加负担后来我又给出了planB，如果我输入一个目的地，数据库中有这个地址，那么，我输入框旁边就可以出现个勾，来表示输入正确，如果不存在，可以出一句提示的话语“此目的地不存在”这样的方案，再次被开发驳回。后来第一个方案被客户采用了。
最近在知乎看到某个产品负责人身份的用户说了这样一句话，让我印象深刻，大意是“比起计算机出身的pm，我更喜欢非技术背景但是做产品后开始学习技术知识的pm”。
这句话给了我一些鼓舞，倒不是说科班出身有什么劣势，反而我认识的几个计算机出身的pm照样用户体验、运营、技术样样风生水起，超崇拜。但除此之外，其实也听过很多技术转产品后，代码那种思维方式还是一时间转换不过来，产品设计的会比较“僵硬”。所以当时看到这句话，我自我安慰地觉得，不懂技术就入行也未必是坏事，比如说运营、实施、设计等同学转产品前都会根据职位的不同，无意识地培养出一些产品感，等接触产品后，再在实际工作过程中有的放矢地学习技术知识，其实也是比较高效的方式，毕竟对于很多类型的产品来说技术是打辅助，不是主力。而先技术后产品，则意识和思维容易被技术框住，后期彻底解放比较难。
而前面说了这么多，主要是給非技术出身的pm打打气。接下来再说说我体会到的产品需要懂点技术的重要性：
1.最物质的就是招聘网站几乎每个jd上都会写着“会一门编程语言的优先”“懂数据分析优先”等等，会点技术仿佛已经是必须的装备，否则上战场都心虚。
2.实际工作中，设计原型、逻辑流程中，知道某些功能细节，乍一看貌似设计详尽了，但是其实缺了开发需要的值。这其实是思维的深入，从用户思维到开发思维，你站在两种思维中间，都要满足。
3.很多小伙伴提到了，就是和开发撕逼。尽管我们组的开发小伙伴都很耐撕，但也会遇到有些功能給到他们，直接撂下一句话“做不出来”。后面了解到，其实这句话的意思有时不仅仅是因为懒得做，而是目前的系统中，你功能的一个小改动，却触及了核心的底层框架，做起来费时费力，但是开发哥哥们不想跟你解释这么多内心戏，所以被直接回绝。这就需要产品对你目前的系统框架有些了解，因为某些情况下，却是换一种实现方式来满足功能需求，不仅无伤大雅，反而免除很多开发无用功。（这点我说的好听，至今也在犯此类毛病orz）
4.设计方案的权衡。在快速迭代并且复杂的系统中，开发中难免突发问题，例如产品逻辑的缺漏、开发实现出现未预料到的难度（这些可能来自于负责人员的不成熟），需要在短时间内找出替代产品方案，此时需要兼顾产品功能的立场和开发难度。这种情况说起来抽象，但是本周我就遇到了，一开始我理直气壮地站在用户立场怼着后端美眉，但是后来确实了解到我觉得逻辑看似一直的两种方案，其中一种开发难度小了很多很多，于是在上线时间紧迫的情况下，选择了次方案。
最后，个人觉得倒不是说学会技术就能完全解决上面的问题，但是至少会潜移默化地在设计产品方案和开发沟通中一天比一天更顺手一点。就算无法窥见全貌，但就算“牙牙学语”的程度都比用“手语沟通”解决更多问题。
入行一年半的小产品一不小心啰嗦的太多了。。捂脸跑路。。。（默默地点开学习python的pdf教程。。）
恭喜你被唐韧老师翻牌啦！你可获得唐韧老师新书《产品经理必懂的技术那点事儿：成为全栈产品经理》1本。请于2月8日晚20:00前联系起点学院betty（微信/手机：18680310383），备注“领奖”，领取奖励，过时视为自动放弃领奖资格，快抓紧时间勾搭betty吧
刚当产品经理的时候，不懂技术。想要在APP里加个搜索框，能搜索到用户即可。想当然以为这是个很小的改动，只需要一天。
提给研发的时候，被研发一顿喷：“是怎么搜索用户，用户昵称？昵称的限制字段有多长？是否可以模糊搜索？可以用用户ID搜索吗？展现形式怎么样？搜不到有怎么处理”
把这些想好后提给技术，技术又说这个模糊搜索不好弄，要花很长时间，我又是一脸懵逼，怎么不好搞完全不懂。
遥想当年刚刚开始做产品的时候 , 连前端都不知道指的是什么 🙂 🙂
在和客户沟通需求时，会遇到一些功能技术上实现的问题，没有相关技术方面的知识基本上答不上来，要向开发同事求救
第二版跟第一版没啥区别😂有第一版的同学就没必要买第二版了！
我对这个3.3折的课程感兴趣。
坑一直在踩，从未停过。哈啊哈。
苦了我的开发小伙伴了。
只不过每次都有进步。踩过的坑不会再踩了。
人生没有白走的路，每一步都算数！ 😉
是啊，对所有踩了坑的人都适用，不止pm
技术问一行显示多少个字，当时懵逼了，没想过这个问题🙈
我们是在UI设计阶段的时候已经确定好了
这个跟设备分辨率不是也有关系么
1.不懂技术，在设计功能时不能够很好的优化逻辑，导致产品不够优质
2.不懂技术说话总会少了一些底气，千辛万苦设计好的功能，因研发的一句实现起来代价太高，研发资源不足，就要砍需求。
3.懂了技术，才能不被研发忽悠，不被研发带着走
别不带底气呀，虽然技术是牛，但是没有逻辑，用户体验等等都达不到，做出一个自己都嫌弃的产品，基本上就已经死掉了。
研发成本在设计产品前就要考虑的，这个看公司吧，没有足够的资金就慢慢迭代，猥琐发育。
至于被研发忽悠，和被研发带着走，这点站在产品以后运营的角度和产品的发展很好反驳的，除非他们能拿出数据说为什么这个不好，没有实凭实据就喊技术按照产品的意思走。
因为是开发外包，产品交付之后，发现了很多问题。提出的问题程序员都说暂时解决不了，或者很麻烦。其实从逻辑上来看应该是很简单就能够处理的。导致公司老板催我，程序员那边拖着，我这边是两头不讨好。通晓技术是多么重要啊！
运营转产品，分不清原生页面和H5页面，测试链接，正式链接傻傻分不清～
你好可爱
那你做运营是怎么做的…
作为toB的外包公司无技术背景的0岁产品人员，搞的项目都是接包再外包技术部分，一方面在客户那边代表着“技术方”，另一方面觉得每天都在技术流的深水区中狼狈扑腾怀疑人生。 😥
我们公司团队都是刚毕业的孩子们，其中两个技术同事，因公司为技术型公司，而懂技术的就他俩，有种占山为王的感觉，因为知道我不懂技术，只要是提出来的产品功能，如转盘抽奖，解决搜索不精准的问题，后台批量上传更新等等，回复我的都是现在没法做，然后抛给我一句话，自己拿出方案了再跟我说怎么改。很多功能想法一时执行不下去，觉得特别挫败，可能自己不太适合做产品经理。后来为了能让自己在别人眼里不那么傻瓜，我就自己在百度上去找解决办法，自学w3c，看css，学MySQL但是只是大致明白原理，都是一些零碎的知识点，不成系统，特别系统的也看不懂。为了在团队里能把工作进行下去，把想法变成现实，我买了第一版的，《产品经理必懂的技术那点事儿》，觉得受益匪浅，后来在工作中不断的让自己的文档更专业，提功能前都会先把解决办法找到，以备技术推辞时能给对方提供思考角度。但是对于技术我了解的还是很皮毛，即使看了些但是工作中还是不太会应用，无法很好的入门，觉得特别迷茫，想要成为一名好的优秀的产品经理，技术短板必须得补上来。
恭喜你被唐韧老师翻牌啦！你可获得唐韧老师新书《产品经理必懂的技术那点事儿：成为全栈产品经理》1本。请于2月8日晚20:00前联系起点学院betty（微信/手机：18680310383），备注“领奖”，领取奖励，过时视为自动放弃领奖资格，快抓紧时间勾搭betty吧
刚看到消息，前段时间工作上出现很大的变动，没有领，还有嘛 😥
设计转产品，公司是金融理财平台，银行存管要改，认看他们的接口文档完全看不懂唉
+1
觉得产品不用看懂接口文档（代码部分）懂逻辑就可以了，然后测试技术做的接口是否能正常使用。比如支付接口，正常的支付、到账和退款这些流程是否能正常使用。至于怎么搭建接口是技术的事~
具体的小坑就不说了，最大的坑就是开发人家会瞧不起你啊，数据库的刚开始还心平气和地和我交流，后来就越来越难沟通了，我知道他们很累，只能自己找书看，想了解个大概，自己找的书又太高深了。我觉得这本书挺适合我的，希望新一年别再被技术瞧不起。
之前公司也有一批趾高气扬的技术，后来被一个个开除了。技术可以有点优越感，但是都是出来工作的，瞧不起那是做事做人方面出现了问题。
什么是一个好的产品经理？懂市场、懂设计、懂用户、懂运营、懂项目、懂技术？有时候当产品觉得蛮辛苦，什么都要懂一点，反过来想一想有很幸福。在接触用户反馈的时候，能够快速帮助用户答疑解惑，能够开阔自己的眼界。当然这也是很辛苦的一件事情，如果后悔那来干嘛呢？懂的多了和生产开发撕的频率低了，和设计师沟通更加流畅。感觉产品也该加一个全栈式的称号。老师辛苦
你不懂技术，我懒得跟你说。。。
我理解技术分两种，一种是纯粹的代码技术，用于实现功能，另一种是公司各种制度，后台，掣肘。这些无形的东西也能影响功能的落地和实现。
又一次，app新上了一个领券中心，试运营了一段时间，我们准备把入口位置前置，让用户更方便看到和使用。结果因为各种内部原因，前后2周提出的6个方案都
被否了，宝宝心累。
对你说的入口前置比较好奇，公司有管理后台，可以完成一些置顶、banner更换、开屏设置等工作，都是可以跳转页面的。只能尴尬的说这些都用不着技术~
如果单纯说写代码，我说的这个事情确实用不到技术。但是就是在现有app上开一个入口，各种为难，各种牵扯到别的部门利益不能动。其实单纯的技术问题倒不是太难，一般的功能实现难不到哪里去。功能立项排期，和各方协调处理好关系，为自己争取资源，这个也是个技术活。你要面对的不仅仅是研发人员，还有自己部门其他产品经理，一线运营人员需要，一线运营人员不同部门的矛盾，高层领导平衡各个部门之间的决策，这里面有一个环节有问题，整个都受影响。
可爱的研发工程师们，有时候反而是最容易支持你的人。不坑你，
经历过这些，当执行一个简单的事情都非常难，没有人愿意承担责任或者负责，且出现产品和运营之间各种甩锅，公司发展不久矣。经历过的那家公司也是这样倒闭的。
产品还是要懂些技术的，有时候单纯的就一个记录汇总成一条展示和一个记录不汇总该几条展示几条展示，但是技术说两种方式写法会有很大的不同，顿时一脸懵逼，所以了解一些基础的技术，有利于不被忽悠，也可以了解技术的工作量，更有利于沟通。
哪种方法更好不是技术决定的么？虽然要相互交流，但是也得各司其职吧！
客户经理转产品经理，从金融行业到互联网行业，不懂技术踩过的坑，自己心里明白。一开始工作，可怜的连一些技术概念和技术常识都不懂，其次对于用户研究、行业趋势、市场现状的了解也不够深入，做产品时面临着很大压力，比如没有权威，无法说服开发大哥，他认为像我这样新来的产品经理啥都不懂，还想给他提需求，没门。其次是在和需求方沟通时，不懂技术实现的可行性以及开发的工程量，全盘接受需求方的提出的需求，导致开发大哥非常抓狂，以至于后来在沟通时总是要以技术无法实现或开发量太大的理由推托，这时候，我对开发大哥说：砍我可以，咱能不砍需求吗？
与开发大哥软磨硬泡，死缠烂打，开始每天泡”人人都是产品经理社区”看一些关于技术的文章，逛逛“天天问”中关于技术的问答，此外为了夯实自己的产品基础，17年买了《人人都是产品经理》，18年1月又买了《人人都是产品经理2.0》，疯一般的迷上了人人都是产品经理，但我知道看书逛社区看文章并不一定就能提升我的产品及技术方面的能力，我觉得重在实践，就是通过看《人人都是产品经理》和人人都是产品经理网站上的热文，去发现自己缺乏的知识和方法论，并运用到实践中，要以致用为目的去学习。
被技术忽悠
产品经理是否要懂技术？要懂什么技术？达到什么程度？不同环境，不同领域，不同经历的人对待这一问题的看法可能都不同。本人转型产品时间也不算太长，现在有项目经理专岗进行配合，技术这一块也就交给专业人去做专业的事，只要配合好就OK了。但对于技术这一块的缺失始终是个心病，却总觉得无从下手。从产品的角度讲，这就是痛点之处在，所以也希望可以拜读唐老师的《产品经理必懂的技术那点事儿》提升自己，谢谢！
UI转产品经理，嗯嗯，会是个不错的选择
本身计算机专业，懂点技术。
但还是非常非常想看看这本书，觉得自身很多不足，看看我到底还需要学点什么。
为成为更好全栈产品经理奋斗！！
+1
入产品这行3个月，发现确实比其他行业更加有意思，此处并无贬低其他行业的意思，从一点不懂的小白到现在慢慢开始独立负责项目，得益于人人都是产品经理的网站，现在想更加进阶的做好产品这份工作，改变世界的梦想很大，目前只能先一点点提升自己，充实本行以及其他行业的知识，技术这块确实得懂点，好和开发对接交流 😉
目前属于软件设计行业，做的是类似CRM、ERP之类的定制化软件，经常碰到的问题就是客户流程变更，需要审核，不需要审核，需要谁审核之类的。
每次都会想当然设计一个完美的可适配流程，哈哈，其实就是界面级的，觉得增加个按钮、少个按钮很随意啊。
然后就会被研发骂的很惨，后来才知道流程牵一发动全身。
流程引擎是好东西。
HA HA HA，先告诉我什么是【全栈】吧 😯
新人战队，等开发哥哥为我转身。做产品优化，被开发一句数据性能差驳回，我竟无语凝噎；产品在技术这个层面最重要的是要懂技术的可行性吧，求赠书砸过来