《产品经理必懂的技术那点事儿：成为全栈产品经理-唐韧.pdf》由会员分享，可在线阅读，更多相关《产品经理必懂的技术那点事儿：成为全栈产品经理-唐韧.pdf（333页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、目录封面推荐序一推荐序二自序前言1 产品思维与技术思维1.1 产品经理为什么要懂技术1.2 产品经理和工程师分别是干什么的1.3 产品设计中需要注意的技术边界1.4 工程师的思考方式：工程思维1.5 入门产品经理的思考方式：功能思维1.6 高阶产品经理的思考方式：产品思维1.7 产品经理必须回答的8个问题1.8 本章小结2 互联网技术与产品2.1 互联网技术发展史2.2 互联网产品发展史2.3 互联网开源社区和技术2.4 互联网产品技术架构2.5 移动互联网技术的特点2.6 下一代互联网产品2.7 下一代互联网产品经理2.8 本章小结3 产品经理学编程3.1 产品经理为什么要学编程3.2 主流
2、编程语言介绍3.3 编程语言中的数据类型3.4 编程语言中的逻辑结构3.5 数据的组织方式：数据结构3.6 什么是程序3.7 程序的最小执行单元3.8 程序与产品功能之间的关系3.9 本章小结4 产品经理学数据库4.1 产品经理为什么要学数据库4.2 关系型数据库4.3 非关系型数据库4.4 数据存储与恢复4.5 从数据角度看产品设计4.6 本章小结5 产品经理学客户端技术5.1 产品经理为什么要学客户端技术5.2 Android基础技术及基本控件5.3 Android界面布局原理5.4 Android系统的权限控制5.5 Android应用打包及发布5.6 Android多屏幕适配5.7 i
3、OS基础技术及基本控件5.8 iOS界面布局原理5.9 iOS系统权限控制5.10 iOS应用打包及发布5.11 Web基础技术知识5.12 如何判断产品问题是否出自客户端5.13 本章小结6 产品经理学服务端技术6.1 产品经理为什么要学服务端技术6.2 服务端的基本架构6.3 数据接口及结构6.4 服务端与客户端的交互模型6.5 服务器部署及运维6.6 云服务器6.7 如何判断产品问题是否出自服务端6.8 本章小结7 产品经理学数据7.1 什么是数据7.2 数据分类及数据分析7.3 p数据指标7.4 数据仓库7.5 数据可视化7.6 数据驱动下的产品与业务7.7 本章小结8 产品经理如何写
4、一份高质量的PRD8.1 PRD的基本结构8.2 产品经理如何评判一个需求的价值8.3 基于目标读者写作8.4 PRD里的产品逻辑8.5 PRD里的技术规则8.6 常用的PRD写作工具介绍8.7 功能型PRD与技术型PRD的区别8.8 沟通胜过文档8.9 本章小结9 如何与工程师正确沟通9.1 工程师是一个什么样的群体9.2 如何向工程师阐述产品需求9.3 如何从产品角度参与技术讨论9.4 产品需求变动时的沟通方法9.5 非技术背景产品经理的沟通技巧9.6 用讲故事代替介绍功能9.7 本章小结10 产品经理的自我修养10.1 三种类型的产品经理10.2 产品经理的三项核心技能10.3 懂技术不
5、如懂产品10.4 为什么懂得这么多还是做不好产品10.5 设计完功能不等于做好了产品10.6 理解场景比设计功能更重要10.7 产品是技术与艺术的结合10.8 如何跨越产品经理初级阶段10.9 产品经理如何驱动技术团队10.10 成为产品领导者10.11 本章小结11 产品经理工作中会遇到的问题及解决方法11.1 解决问题前先定位问题11.2 产品经理工作中遇到的问题11.3 “聚焦答案”而非“聚焦问题”11.4 一个可能的解决问题模型11.5 从问题和答案中获取洞察力11.6 一个需求从无到有经历了什么11.7 MVP：化繁为简的方法11.8 如何合理地把握产品节奏11.9 非技术背景产品经
6、理三大生存指南11.10 本章小结12 产品经理的职业发展12.1 产品助理的日常工作及晋级12.2 产品经理的日常工作及晋级12.3 产品总监的日常工作及晋级12.4 从产品助理到产品总监的跨越12.5 如何系统化地提高产品能力12.6 本章小结13 产品经理必懂的运营“技术”13.1 产品与运营的关系13.2 产品运营与业务运营的区别13.3 如何围绕产品设计运营方案13.4 如何通过产品杠杆提升运营效率13.5 本章小结14 产品经理必懂的技术名词14.1 类、对象、抽象和实例14.2 工程师口中的“打印”是什么意思14.3 工程师口中的“写死”是什么意思14.4 架构和框架14.5 控
7、件和组件14.6 进程与线程14.7 什么是“脚本”14.8 同步处理和异步处理后记 致在产品路上不断前行的我们本书由“ePUBw.COM”整理，ePUBw.COM 提供最新最全的优质电子书下载！推荐序一2010年，我创办了人人都是产品经理（）社区，至今已经8年。这8年来，我接触最多的就是产品经理。我很少在外抛头露面，通常只会在人人都是产品经理社区创建的上百个产品经理交流群里活动，因此经常会被大家抓着问问题，其中被问最多的一个问题就是“产品经理需要懂技术吗？懂到什么程度？”其实这是一个比较有争议的问题，没有正确答案。你说需要懂，也对；说不需要懂，也没错。以我个人的从业经历而言，我倾向的答案是产
8、品经理需要“懂”技术。在大学里，没有产品经理这个专业，所以绝大部分产品经理都是半路出家。早期的互联网公司基本都是以技术为中心驱动产品的，因此在很多公司里，产品经理这个角色都是技术或者项目经理兼任，他们都有一定技术背景。随着互联网的迅猛发展，以技术为中心逐步走向以产品和用户为中心，尤其是在乔布斯发布iPhone 3GS以后，各大互联网公司CEO都说自己是产品经理，于是产品经理就火起来了，从此一发不可收拾。接下来出现的情况就是一大拨从事技术、运营、设计、编辑、市场的人转型做了产品经理，非技术职位转型做产品经理的占了绝大部分。因为没有技术门槛，越来越多的大学生也都选择了产品经理职位。从产品经理的演变
9、来看，毫不夸张地说，绝大部分产品经理是不“懂”技术的。注意，我特意把懂这个字加了引号。因为“懂”技术不等于要会写代码。这里有一个误区，很多产品经理听别人说产品经理需要懂技术，不懂技术就会，而感到非常焦虑，非常着急，就去买了一大堆技术相关书籍（JavaScript、PHP、Java、MySQL等各种从入门到精通的宝典），然而能坚持看完、看明白的人微乎其微。因为技术类书籍是有门槛的，还非常枯燥，不像产品和运营类书籍，贴近生活，通俗易懂，谁都可以看明白。因为我是站长出身，做了十来年站长，对各种开源系统非常熟悉，也做过几十个网站，大家都知道做站长的人通常都是一个人能搞定所有的事情（产品、设计、运营、推
10、广、技术、运维、内容等），于是很多人跟我说：“老曹，要不你写本产品经理能读懂的技术书吧，因为你懂技术通产品，这书你写再合适不过了。”每次遇到这样的提议，我都非常尴尬，这对我来说挑战太大，但我一直有一个梦想，组织几个懂产品的技术兄弟一起写一本产品经理的技术科普书。直到今天，我的梦想将被实现。帮我实现梦想的人不是我自己，而是本书作者唐韧同学。唐韧是人人都是产品经理社区的专栏作家，在平台发布了很多作品，其中一篇文章我是如何从程序员一步一步走向产品经理的备受认可，他本人也是技术转型产品经理的优秀代表。希望本书能为从事产品经理职业的同学对技术的认知有更好的帮助，产品经理学习技术不是为了在技术人员面前证明
11、你很牛，而是为了更好地与技术人员沟通需求、更好地合作，一起做好产品。曹成明人人都是产品经理、起点学院创始人兼CEO本书由“ePUBw.COM”整理，ePUBw.COM 提供最新最全的优质电子书下载！推荐序二犹记那天作者邀请我为他的书作序，我的内心是充满惊喜的。算起来我们共事已然有六七个年头。作者当年是我在北航软件学院设立的移动应用联合实验室的第一届学生，算是我的开山弟子。在他作为大师兄带领师弟师妹组成的项目团队实践着敏捷开发和移动产品方法论的时候，他就已然立志要成为一名优秀的产品经理。后来，作者与我一同征战移动互联网创业之路，从App开发做起，经过多款创新产品的设计和研发历练，他已然成功转型成
12、为一名优秀的移动互联网产品经理和互联网产品设计专家。我和作者亦师亦友的关系一直延续至今，在共同走过的许多个日日夜夜，有相知相和的共鸣，有观点分歧的碰撞，更有对产品设计的每一个细节孜孜不倦的研讨和琢磨。正是在无数次对产品不断精益求精的思考和实践中，作者深深体会到产品经理这个角色对一个人全方位的历练和素质要求。作为把握甚至主导互联网产品的关键角色，产品经理必须具备的一项重要素质就是要懂一些有关的互联网技术。众所周知，产品经理是处于业务需求和技术实施中间的桥梁和枢纽，肩负着理解、明确、界定业务需求，将其翻译为技术研发工程师能够听得懂的语言，并交付给工程技术团队实施这样一个关键而重要的职责。在这个过程
13、中，懂技术不仅能让产品经理用更准确的、更缜密的、工程师更喜闻乐见的语言清晰描述业务需求和业务逻辑，更能让产品经理在产品设计阶段就前瞻性地预见到技术落地时可能存在的挑战和障碍，进而提前对设计进行优化、折中，甚至取舍。在邀请工程师协助评估技术难点的时候，也能迅速理解工程师所说的语言，实现高效的互动和沟通，为自己赢得工程师的尊重和配合。所谓的懂技术，并不是说产品经理一定要自己拥有大量的代码编写经验，而是说产品经理要尽可能全面地了解与自己的产品落地息息相关的各方面技术。了解它们是什么、位于哪一个层次、有什么作用，可能出现的技术难点一般会存在于哪些方面，如何在设计上进行调整应对，等等。更值得一提的是，本
14、书不仅较全面、浅显地综述了产品经理需要了解的一些互联网技术体系，更分享了很多作者对产品设计方法论、产品与运营等上下游环节的关系、产品经理职业提升和职业发展等方面的心得和感悟。对非技术背景的产品经理而言，一定会感到开卷有益。从技术转型而来的产品经理也一定会从作者的文字中找到共鸣和收获。很高兴能向有志于做出伟大的互联网产品、已经或即将成为产品经理的各位读者推荐本书。刘青焱前阿里巴巴雅虎数据平台主管，爱立信大数据研究部总监，朱李叶集团CTO本书由“ePUBw.COM”整理，ePUBw.COM 提供最新最全的优质电子书下载！自序真的，别“想不开”当产品经理产品经理，一个略带理想主义光辉和神秘感的称谓。
15、乔布斯、张小龙等一众大神的出现让“产品经理”这个词在现在的互联网环境下颇为流行，让顶着这个头衔的人自觉地站到了“改变世界”的阵营。产品经理又是一个极具神秘感的头衔，外人不知道他们究竟是做什么的，对互联网完全不了解的人会说他们是做电脑软件的，也有人说他们是做系统开发的。学生、已经在其他岗位工作的人都陆续投身或转型到产品经理的行业，抱着理想主义情结，想去改变世界。他们开始疯狂地使用各种产品，买各种产品类的书籍补充基础知识，从网络上观看大佬的演讲，激动之余，一番激烈的思想斗争后，更加坚定了自己投身产品经理岗位的决心。没错，这就是现在的产品经理，是大部分产品经理或者即将成为产品经理的人的现状。产品经理
16、不会自带光环站在产品门外的人看到的是产品经理的光鲜，看到的是那些功成名就的产品大牛，看到的是舆论如何把他们神化。然而，只有产品人自己知道，事情并不是这样美好，除了外界的看法，产品经理本身不会自带光环。人人都是产品经理，这句口号让无数有志青年怀揣对产品经理的热情与渴望入行。如果把生活比喻成一个作品，那么每天我们都在设计和完成着属于自己的产品，每个人都是自己的产品经理。互联网行业的产品经理，每天需要与形形色色的人打交道，他们背景各异，“语系”各样，这着实是一场惊心动魄的外交风云。需求评审前的夜晚，产品经理独自一人思考和打磨着每一个产品功能和细节逻辑，生怕出现漏洞和疏忽，在评审会上被一众人等“喷”成
17、筛子。好不容易写完产品需求文档，自信满满地迎接第二天的战役，望望窗外，已是深夜，作为产品经理的你，面对刚刚完成的“大作”，是不是有一种拥有了全世界的感觉？第二天，带着昨夜的激动来到公司，早上需要听老板对产品的展望，还需要汇报产品的最新进展。上午还要组织研发、设计、测试人员评审前一天熬夜准备好的产品需求，又是一场无硝烟的舌战。信心十足地宣讲需求，还没说完一个逻辑，工程师说“这种功能做了有什么意义”，设计师说“这样设计影响整体美观”，测试人员说“特殊情况如何处理”。此时，昨日拥有全世界的那种辉煌感一扫而光，开始逐一回答这些问题，评审会完全没有按照预定的节奏推进。虽然磕磕绊绊把需求全部讲完了，问题也
18、全部解决完了，但似乎没有找到那种特别的成就感。开完需求评审会只是两万五千里长征过了三分之一，开发过程中遇到的各种问题都会让产品经理来救火，这种时刻准备着的紧张感让产品经理不敢有一丝的松懈。好不容易到了产品上线前夜，陪着技术团队加班调试，却发现仍有一大堆问题没有解决，看着上线时间要被延后，想着许给老板的承诺，心里顿时一万只乌鸦飞过。好不容易产品上线了，结果出了一个线上BUG，火急火燎召集开发人员紧急修复，十万火急完成测试然后重新上线。产品终于上线了，两万五千里长征走了三分之二。问题马上又来了，运营人员反馈发现产品上线后的产品设计跟实际用户需求有不匹配的地方，老板十分关注，要求马上改进。产品经理打
19、起十二分的精神重新梳理产品设计，改进优化方案，迎接新一轮“拥有全世界”的感觉。就当两万五千里快到终点时，又开始了新一轮的万里长征。是的，这就是现实中的产品经理。他们顶着产品经理的头衔，实则没有经理的实权，却操着老板的心。“智斗”研发、“武斗”运营，每天都在高速思考的状态下搏斗四方。回家后做梦都在总结白天的招式，提炼心法，慢慢地学会了一身识别真实需求的本领，产品经理逐渐成为了产品的主人，而且是真正深入其灵魂的主人。是的，产品经理不会自带光环，他们经历了从产品小白到产品经理的过程，这是一个痛苦蜕变的过程，被围攻、被逼着思考、被推着改进、被刺激着学习。历练过后，只有他们自己心里明白，光环不是自带的，
20、是经历千锤百炼争取来的。原本不善言谈、思维“稀疏”的产品新人，逐渐成长为对上搞得定老板、横向搞得定研发设计和运营人员、对下能传道授业的产品人。这个过程，只有他们自己明白，路虽孤独，必成大器。产品经理每天都在绝望中睡去，第二天依旧充满斗志地醒来！真的，别“想不开”当产品经理。你必须比别人努力十倍，才会得到一点认可当产品经理必须习惯与孤独为伴，这种孤独并不是没有朋友的孤单感，而是指思考和决策的过程并不会有人给你明晰的指引，只能靠自己的独立思考和理解给产品赋予生命力，做出关键决策。这是一个极度困难的过程，过程中不会有人真正帮你，就算有，也是所谓善意的建议。你必须比别人努力十倍，才会得到一点认可，所以
21、优秀的产品经理屈指可数。做一个有价值的产品并不简单，好的产品往往深入浅出，直面人性需求，这就要求产品经理深谙人性。设计一个功能非常简单、逻辑严谨、体验良好的产品不难，难点在于如何用最简单的功能和文字让用户产生想象力。微信朋友圈的设计从上线之日起到现在都没有变过，用户还能利用朋友圈的头像、文字和九张图片玩出各种花样，这都取决于朋友圈的基础功能让用户具备想象力。这种想象力带来的成就感会让用户在产品中感受到人的力量，这是一种莫大的来自内心的认可。这是人性使然，面对简单时，人的大脑会基于简单的东西开始“创作”，俗称“开脑洞”，会让简单的东西尽可能地被丰富。这种能力也叫“产品力”，是经过无数次思考、被推
22、翻、再思考、被打击、被质疑后沉淀下来的能力，不是看书和画原型图能培养的。真正厉害的产品经理不是能做出一个多么复杂的产品，而是能把一个复杂的流程做成一个简单的产品。为什么早期的安卓手机有三个实体或虚拟按键，而iPhone始终只有一个Home按键？滑动解锁这种自然的设计被运用在一个极度复杂的科技产品中，就连几岁小孩都能一用就会。简单的就是最好理解的，自然的就是最容易被人接受的。当然，刚开始做产品经理时，这种产品哲学问题基本跟我们没关系，但是，我们必须努力往这个方向发展，要不然以后万一成功了怎么“吹”呢？这不是一个贬义词，而是一种将认知升级的过程。同样是看一个产品，有的人看功能，有的人看背后的价值和
23、思想。别忘了，产品经理没有那么强的生存竞争力，一家公司有很多工程师不足为奇，但一家公司的核心产品往往就那么几个，每个产品背后的灵魂操刀手只有一个。也就是说，要成为那一个，无异于千军万马过独木桥。你必须产生一种新的认知，产品除了需求、功能设计和需求文档，还有产品战略、产品定位、市场环境、业务切入点、产品运营，以及财务模型和商业模式。每一个环节都是通往产品大神路上的必过关卡。你必须比别人努力十倍，不是指加班时间长，也不是指工作量的多少，而是指深度思考和提升认知的能力。这是一句虚话，但已经做到的人心里一定明白，自己付出的努力一定超出同行十倍。从0到1这本书中提到一个概念，新创企业必须在效率上高出同行
24、竞争者十倍才有机会脱颖而出并存活下来。同样，与你身边的产品经理相比，你的优势在哪儿？是需求分析的逻辑能力吗？是画原型的能力吗？是写文档的能力吗？如果不在认知上有渐进式的提高，就体现不出效率的差异，自然就不会形成个人竞争力，更谈不上被认可。这是一个非常艰难的过程，产品做久了就会陷入自我怀疑和瓶颈中，不知从何突破。当做了一段时间基础工作后，觉得自己处理需求已经很顺手，画原型写文档也很熟练，就需要跳出来看看产品之上的天空，了解一些行业知识，熟悉运营方法，研究财务模型和商业模式，这些都能帮助你提高综合能力。这是一个非常压抑的过程，因为你会碰到来自各方的挑战，从小白跨越到能手是需要承受许多委屈的。这是一
25、个揪心的过程，内心敏感的人不适合加入这场战役，因为这种冲击会伤害到脆弱的神经。这是一个需要改变的过程，自尊心太强的人要学会放下自己的身段，因为这是一个会面对各方挑战，甚至是不留情面抨击的战场，自尊心会成为你前进的障碍。如果你以十倍于别人的努力冲锋，若干年后你会发现，你关注的是行业机会、资源整合、市场潜力、效率优化、整体认知和洞察力的提升。并且，你有能力将这些战略层的内容缩小到范围层、落地到结构层、实施到框架层，最后在产品表现层展示给世人。这么看，你之前引以为傲的需求分析、画原型和写文档的能力只占里面的1%。未来的你，够清晰吗如果不走运，你真的当了“产品经理”，首先恭喜你，你没有进入即将被淘汰的
26、行业，因为你每天的工作和环境会逼迫你成长。其次，要祝福你，因为你很可能倒在进阶路上的任何一个环节。如果你是产品新人，五年后，你希望自己是什么样子？如果你已经做了35年的产品，五年后，你希望自己是什么样子？如果你已经是工作超过十年的产品老兵，五年后，你希望自己是什么样子？这个问题只有你们自己能回答，因为不同阶段的认知决定了看到的未来是什么，未来的你，够清晰吗？我以前做开发时，常听人说做技术是一碗青春饭，到了30岁还不寻求转型以后可能干不过小年轻。我相信，其他职能也会遇到类似的问题。于是在30岁来临前的几年，一部分人准备成为某个技术领域的专家，让自己在垂直技术方向成为权威；另一部分人准备转管理岗，
27、或是项目经理，或是带团队，其中就有一部分人一不小心成了产品经理。我，就是其中一个，只不过，我从写代码的第一天起，心里就埋了一颗产品的种子。是的，我算是想不开的那类人，我成了“产品经理”，我也是星辰大海中的那一叶扁舟，在这里挣扎，在这里成长。我已经在这场开始已久的战役中，未来已来。本书由“ePUBw.COM”整理，ePUBw.COM 提供最新最全的优质电子书下载！前言我为什么写这本书我是从技术开发转型为产品经理的，在转型的过程中对于技术背景的思维方式和产品背景的思维方式有一些个人的认识。在做技术开发的几年里，我从纯技术的角度去理解问题；转型做产品经理后，我带着技术背景处理与产品相关的业务、运营和
28、市场问题，用一种全新的角度看待产品。本书是继产品经理必懂的技术那点事儿之后的升级版，不仅添加了非技术背景产品经理需要了解的技术知识，更是从产品方法论和产品运营层面全方位地补充了产品经理的能力模型内容，力求以全栈产品经理的要求丰富本书的结构和内容。在做产品的过程中更多是与工程师打交道，面对一群专业性很强且逻辑思维很强的群体，产品经理的内功就显得尤为重要。在实际工作中，我也与非技术背景的产品经理合作，发现对非技术背景的产品经理来说，技术知识的缺乏是硬伤，由此会带来对产品实现的理解与工程师的理解偏差过大的问题。同时，也会造成一些沟通不畅的问题。如果你是一位非技术背景的产品经理，在工程中可能会遇到对产
29、品技术实现方案不理解的情况。工程师跟你沟通时所用的技术语言你完全听不懂，你精心设计的产品方案拿到评审会上评审时，被工程师批判得体无完肤。这些问题的出现其实都归结于非技术背景的产品经理在技术知识上的信息不对称，持续处于这种状态会严重阻碍工作能力的提高。对业务、运营、市场背景的产品经理来说，增加对基本技术知识的了解能在实际工作中起到很大的帮助作用。这些使我产生了写作本书的想法，本书力求通过通俗易懂的方式讲解基本技术原理，减小非技术背景产品经理与工程师之间的知识差距，使合作和沟通更顺利，同时也提高产品经理的产品内功。对非技术背景产品经理来说，在与工程师的合作过程中，掌握一些基础技术知识显得尤为重要，
30、对于技术的理解可以不用深入到实现层面，但要对基本原理及产品背后的整体技术架构心中有数。产品经理属于信息上游，在拿自己的产品想法与工程师沟通和推动产品实施的过程中，对技术要有一定的了解，这就好比手上多了一把好武器，能让问题顺利解决，让产品不断向前发展。本书的目的是通过浅显易懂的方式，面向非技术型产品经理讲解基础技术知识，打开技术领域这一神秘的大门，使非技术背景产品经理在产品工作中更游刃有余。产品经理的工作内容涉及面广，而且对个人综合能力的要求高，要想做好产品经理就需要涉猎广泛，具备更多的横向知识体系，同时在产品这一纵向知识体系内做深做精。本书既可作为产品经理平时学习技术的基础资料，也可作为工具手
31、册，希望本书能助力非技术背景产品经理开展工作。书中内容不涉及很深很具体的技术，以基本技术概念和实现原理介绍为主，配合一些具体例子加深读者的理解，力求帮助非技术背景的产品经理对具体的技术知识有一个整体的认识，在设计产品或者与工程师沟通合作的过程中能更加顺畅。技术能力是产品经理的核心技能之一，但不是全部，产品经理的职责是通过产品创造用户价值和商业价值，了解用户、发掘需求并持续对产品进行优化才是产品经理的使命。如何阅读本书读者在阅读本书时，可以通过理解技术的一些基本原理反观产品设计的细节。非技术背景的产品经理在阅读本书时可以结合自己在实际工作中遇到的技术问题或者是与工程师沟通产品方案时所遇到的技术挑
32、战重现当时遇到问题的场景。读完本书后，重新审视当时遇到的问题在现在是否能很好地处理，以场景化的方式结合自身工作中的问题，然后从本书中寻找答案，总结并且复盘，这样能对自己在技术知识方面的欠缺有一个比较好的补充和提升作用。本书第1章介绍了产品思维与技术思维的具体表现和差别，有利于产品经理站在不同的角度审视产品。第2章是对互联网历史和基础技术知识的介绍，为非技术背景的产品经理科普互联网的简要发展历史及互联网技术和产品的几个阶段性特点。第3章从理解原理的角度向非技术背景产品经理介绍编程语言的内容。本章的目的并不是让产品经理学会编程，而是希望产品经理通过了解编程语言的基本原理，了解技术产品的实现逻辑及工
33、程师思考问题的基本逻辑。第4章介绍数据库的基本内容，数据库作为数据的存储和处理中心，在产品的大版图里不可或缺，产品经理了解数据库的一些基本知识能增加对产品的全盘了解（从界面到数据）。第5章以介绍主流移动平台的一些基本技术内容为主，目的在于让非技术背景的产品经理了解视觉界面下的实现细节，降低与工程师的沟通成本。第6章介绍服务端的基本内容，服务端作为大后方，在产品技术体系内扮演着极其重要的角色，产品经理了解服务端的典型技术知识有助于从系统架构的层面理解产品设计，知道什么样的产品设计能降低技术实现难度和成本。第7章是从数据的角度观察产品，产品经理对数据的敏感度决定了产品的优化方向。从本章中产品经理可
34、以了解到不同维度的数据标准和基于数据驱动的产品设计方法。第8章是对产品需求文档的一个格式和内容介绍，力求为产品经理提供一个可参考的产品需求文档样式。第9章将内容重点放在沟通上，产品经理需要与各方沟通，其中的沟通技巧和沟通侧重点会在本章详细介绍。第10章介绍了产品经理的不同类型和成长进阶的经验。第11章重点对解决问题这一话题进行了分析，以聚焦答案的解决问题方式探究问题的解决方案，本章能提供给产品经理一种新的解决问题的方法，值得一读。第12章针对不同阶段的产品经理的职业发展做了介绍与建议，对每个阶段的产品工作重心和进阶方式给出了一定的参考建议。第13章以产品经理必懂的运营技巧为话题，从产品与运营的
35、关系及如何更好地通过运营将产品用起来等角度分享了一些实战经验。第14章对一些常用技术概念进行介绍，力图帮助非技术背景产品经理对实际工作中常用的技术术语有更深入的了解。希望本书能帮助读者从产品、技术、运营三个角度建立三位一体的综合能力体系，助力读者朝着全栈产品经理的方向发展。读者可以添加我的微信公众号“唐韧”与我交流沟通，也欢迎读者多提宝贵意见和建议。致谢首先感谢我的家人一直以来对我的鼓励和支持，不管是在求学过程中还是工作过程中，始终在背后无微不至地关心我，让我有信心和动力去完成自己想做的事情。在求学和工作的过程中，难免会遇到各种挫折和困难，有家人的鼓励和支持就有了最大的理由去迎接并战胜这些困难
36、，让自己在前进的道路上勇往直前。写作的过程是孤独的，尤其是身处繁忙的工作中，每天写作的时间非常有限，工作之外的休息时间基本都用来写作。我相信，这段经历是给自己最好的成长礼物，这段经历让我处于不断思考和认知升级的状态。对产品的理解、对技术的理解、对行业的理解在写作的过程中都得到了空前的提升，这是我要感谢自己的地方，也庆幸自己能有这个机会在这个年纪写了一本属于自己的书。其次，感谢那些正在和我一起奋斗和曾经一起奋斗的小伙伴，虽然你们有些已经离开，但曾经有你们的陪伴和并肩战斗，我们都在成长，我们都在逐渐成熟，我相信我们都会越来越好。你们中有技术出身的，也有非技术背景的，与你们的配合使我在构思本书的内容
37、时有了很多的素材和灵感。另外，感谢在工作中帮助过我的领导、同事和朋友，我的成长离不开你们的关照和提携。尤其感谢我的领导，也是我做产品的领路人刘青焱先生，他是一位具备丰富工作经验且在互联网行业工作十余年的老江湖，在产品和技术领域颇有建树。我需要学习的东西还很多，非常感谢读者选择本书。做任何事情都是一个持续优化和完善的过程，本书中存在的不足希望得到读者的指点和帮助，也希望同为产品经理或者即将成为产品经理的你，一起在奋斗的路上寻找更远的那一个里程碑！唐韧本书由“ePUBw.COM”整理，ePUBw.COM 提供最新最全的优质电子书下载！1 产品思维与技术思维1.1 产品经理为什么要懂技术如果把产品比
38、喻为房子，那产品经理就是房屋设计师。如果设计师不懂基本的房屋结构设计和施工原理，那么设计出来的房屋很可能就是无法落地的空中楼阁。理想的设计和物理的限制必须有效结合，不存在真正的空中花园和通天塔，在工程领域，每一个设计都是可以被实现的。对产品经理来说，置身互联网领域，设计互联网产品，每一个设计都应该在现有互联网技术下可被实现。产品经理学习一些基本技术知识，了解技术边界，对实际开展产品工作有非常大的益处，所谓知己知彼，特别是在与工程师的工作配合和沟通中能起到关键作用。在实际工作中不难发现，当产品经理与工程师就某一个具体问题进行讨论时，双方站在各自角度就问题进行分析和讨论，固有知识结构的差异导致思维
39、模式和视角的差异，工程师通常是路径推理的技术思维，产品经理通常是用户场景的产品思维。产品思维和技术思维的碰撞让问题没有在正确的方向上被解决，原因就是双方用了不同的语系，好比一个讲英语的人和一个讲法语的人讨论一幅画，结果可想而知。产品思维和技术思维如图1-1所示。图1-1 产品思维与技术思维产品思维侧重从用户和商业视角出发，技术思维侧重在技术实现和系统架构层面，两种思维方式也有交叉点，那就是产品的需求、设计和产品功能。由此可见，当产品经理与工程师讨论产品时，各自的利益出发点是不一致的，产品经理需要思考产品的用户价值和用户的产品使用场景，同时还需要考虑产品所承载的业务闭环和商业价值，因为单纯的产品
40、功能没有价值，所以产品经理需要思考如何通过产品功能完善整个业务闭环并构建具备商业价值的产品体系。工程师是技术思维的代表，从技术思维角度去思考问题，首先就是基于产品需求的实现方式的考虑，工程师看到产品设计后在脑海里构建的是拆解后的实现要点，好比一栋房子的内部结构，需要先构建产品的技术架构，然后评估产品功能的技术价值和开发成本。工程师和产品经理虽然基于同样的产品需求和设计进行讨论，但双方的出发点不同会影响共识性的达成，所以对产品经理来说，掌握一些技术思维，学会从技术视角看待产品设计，能更有利于产品需求的落地和推动产品的实施。对产品经理这一职能来说，需要掌握更多的语系，因为产品经理是信息的衔接者，在
41、一个产品项目中起到信息中枢的作用，产品经理需要与老板、业务人员、市场人员、设计师、工程师等进行合作，他们有各自不同的背景和沟通方式，要求产品经理具备与不同职能的人打交道的能力。对于合作最为密切的工程师来说，这就要求产品经理具备一定的技术知识，在与工程师合作和沟通时需要切换至技术语系。试想一下，如果工程师告诉你“这个数据是用栈存放的”，作为非技术背景的产品经理是不是顿时感到蒙圈，接下来的场景大概就是工程师不断从技术角度跟产品经理解释，产品经理似懂非懂地听得云里雾里，然后说了一句“那换一种实现方式呗”，此时工程师瞬间蒙圈，换一种实现方式好比让建筑师把房子全拆了重建，工程师和产品经理友谊的小船说翻就
42、翻。作为一个有理想有抱负的产品经理，在工作中要应付各种场景，快速精准地处理问题，了解工程师这类亲密合作伙伴的工作、了解他们工作中运用的知识，是促进合作提高效率的有效方法。1.2 产品经理和工程师分别是干什么的在互联网公司里，产品经理和工程师分别有各自的职能属性。产品职能属于信息上游，负责发现并定义需求，将用户需求通过具体的产品功能设计呈现为用户可用的产品，包括需求分析、功能定义、原型设计等。产品经理同时也是产品的核心灵魂，因为产品的发展走向很大程度上由产品经理把控，产品经理需要权衡业务与市场，需要将老板的战略意图贯穿到产品设计中，需要向工程师传递产品的核心价值，需要讲解设计背后的需求逻辑，在将
43、设计落地为实施的过程中，产品经理扮演着重要的角色。技术职能细分为很多种，比如架构师、前端技术研发、后端技术研发及系统运维等。技术职能属于信息下游，负责从技术实现角度评估产品设计，设计技术方案，最终将产品设计实施落地为用户可用的产品。在这个过程中，工程师需要先理解需求，同时需要从技术角度衡量需求的合理性及投入产出比。例如，某一项产品设计只是优化了1%的用户的使用问题，却需要投入极大的开发成本，那就是不合适的。工程师在对产品设计进行评估后，需要将实施层面的技术成本反馈给产品经理，产品经理需要据此灵活调整产品设计。对技术职能来说，在不同的产品阶段，需要持续对技术方案进行调整与优化。比如在产品设计不变
44、的情况下，用户规模上了一个层级，原本的技术实现方案不足以支撑大规模用户的使用，此时就需要对技术方案进行升级。在这种情况下，产品经理实际上不需要调整产品设计，工程师需要对技术设计进行调整。产品职能与技术职能在工作流上是上下游配合的关系，但从一个长远的角度看，技术是需要持续演进的，而产品在远期会进入一个相对稳定的状态。以微信为例，微信产品的功能更新基本变化不大，但微信的技术却一直在演进，从1千万用户到1亿用户，对产品底层的技术要求是不一样的，而且随着产品生命周期的发展，对技术灵活性的要求也会随之提升。还是微信的例子，现在微信更新一个版本的成本是很高的，每个版本影响到的是上亿的用户，确保不同版本之间
45、的兼容性及新老版本的稳定性，这些都是技术上的挑战。在整个产品生命周期中，产品职能和技术职能始终相辅相成，持续对产品进行改进与优化，两种职能是天生的配合者。作为产品经理，需要了解一个技术团队中各个职能分别是做什么工作的，图1-2所示为一个常规技术团队的组织结构和基本职能分布。图1-2 技术职能结构图在职能分布上，CTO（首席技术官）是管理和领导的角色，是技术团队的负责人，统筹技术和产品相关工作的开展，简单说就是技术团队的老大。在CTO之下又划分为几个大的职能模块（可能不同的公司有不同的划分方法），即产品设计、研发、测试和运维。产品设计包括产品本身的功能和流程设计，同时也包括产品的交互和视觉设计。
46、在大公司里，交互和视觉设计分工比较明确，职能更细；在创业公司里，产品经理通常承担了产品功能流程设计和交互设计，视觉设计一般由专业的设计师负责。产品设计师在整个工作流中类似建筑规划总设计师，负责设计整体蓝图。研发版块是技术团队的主要构成部分，一般是人数最多的职能版块，研发分为前端开发和服务端开发，前端开发又可细分为Android开发、iOS开发、Web前端开发等，服务端开发可以细分为应用接口开发、数据库开发等。虽然都属于开发人员，但同样是术业有专攻，每个开发人员都有各自负责的技术领域，当然也有跨技术领域的工程师，比如既能做前端开发又能做服务端开发的。技术团队通常都有一个架构师，架构师是一个高级技
47、术职位，一般是一位具有丰富经验和技术能力的技术人员，架构师负责系统的整体架构和规划，类似于建筑实施总设计师，设计整体实施方案。测试是保证产品高质量上线发布的保障职能，测试具体可以细分为黑盒测试和白盒测试。黑盒测试是指一般的功能性测试，测试人员会从用户视角对产品进行全方位多角度的使用，模拟出各种可能出现的用户场景对产品进行全流程测试。白盒测试是比黑盒测试更进一步的测试，白盒测试会深入代码层面进行测试，使用测试用例对某一代码模块进行测试，白盒测试对测试人员的要求更高。测试人员类似建筑工程中的质检人员，负责对实施的工程进行质量控制和把关，对于不合格的部分进行标注并返工处理，测试通常有一套严格的测试标
48、准，叫测试用例，测试用例覆盖越全，测试所覆盖的可能性问题就越全，更有利于遍历所有可能的问题。运维是对系统进行持续稳定运转的保障职能，需要持续监控和优化系统的运行状态，例如对带宽的监控、对系统负载能力的监控和优化等。运维类似于建筑工程中的交付保障部门，对交付后的产品进行持续维护，当出现问题时及时响应并处理。运维是系统工程，而且是持续进行的工作，对系统的要求是724小时全天候无故障运行。我们每天使用的各种互联网产品能正常工作，一方面是在开发和测试阶段解决问题，另一方面是在后期运维阶段持续保障。例如，当用户量或访问量到达一定阶段后，运维需要提高服务器的处理能力，所以运维是产品的后勤保障。以上各职能相
49、互配合，为产品的整个生命周期服务。1.3 产品设计中需要注意的技术边界技术边界是指在现有技术水平之下，可以被技术实现的需求范围。超出技术可实施范围的设计无法落地，互联网技术日新月异，技术在快速发展的同时也对互联网产品设计的发展提供了保障。例如今天的智能手机，可以手指滑动操作，可以多点触摸，可以使用一些内置传感器实现诸如摇一摇之类的功能。很多产品设计都是基于这些技术之上的，有了基础技术的支持，可以产生很多很好的产品创意。十年前，很多技术还不成熟，今天使用的很多产品功能都是无法被满足的。所以，对于产品设计者来说，在设计产品时需要了解技术边界在哪儿，需要知道什么样的设计在今天能被满足，但同时也不要受
50、制于技术边界，想象的空间无限大，在思考层面需要无边界。这里所说的边界实质上是指实现边界。想法可以足够大，但实施需要脚踏实地。产品经理在提需求的时候首先要询问在技术实施角度的可行性，否则一个看似酷炫的设计方案有可能只是个空中花园无法落地。我们能使用移动App产品实现自动定位和导航功能，是因为在智能手机里内置了GPS导航模块；能在微信内使用摇一摇功能，是因为手机内置了重力传感器和加速度传感器，包括现在流行的计步器类产品都是应用了该项技术。在实现层面，例如苹果的iOS设备和谷歌的Android设备，在开发上也封装好了非常方便使用的接口，开发人员只需要简单调用就可以实现这些在以前看来非常复杂的功能。接