作者：唐韧
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
产品经理必懂的技术那点事儿：成为全栈产品经理试读：
前言
我为什么写这本书我是从技术开发转型为产品经理的，在转型的过程中对于技术背景的思维方式和产品背景的思维方式有一些个人的认识。在做技术开发的几年里，我从纯技术的角度去理解问题；转型做产品经理后，我带着技术背景处理与产品相关的业务、运营和市场问题，用一种全新的角度看待产品。
本书是继《产品经理必懂的技术那点事儿》之后的升级版，不仅添加了非技术背景产品经理需要了解的技术知识，更是从产品方法论和产品运营层面全方位地补充了产品经理的能力模型内容，力求以全栈产品经理的要求丰富本书的结构和内容。
在做产品的过程中更多是与工程师打交道，面对一群专业性很强且逻辑思维很强的群体，产品经理的内功就显得尤为重要。在实际工作中，我也与非技术背景的产品经理合作，发现对非技术背景的产品经理来说，技术知识的缺乏是硬伤，由此会带来对产品实现的理解与工程师的理解偏差过大的问题。同时，也会造成一些沟通不畅的问题。
如果你是一位非技术背景的产品经理，在工程中可能会遇到对产品技术实现方案不理解的情况。工程师跟你沟通时所用的技术语言你完全听不懂，你精心设计的产品方案拿到评审会上评审时，被工程师批判得体无完肤。这些问题的出现其实都归结于非技术背景的产品经理在技术知识上的信息不对称，持续处于这种状态会严重阻碍工作能力的提高。对业务、运营、市场背景的产品经理来说，增加对基本技术知识的了解能在实际工作中起到很大的帮助作用。
这些使我产生了写作本书的想法，本书力求通过通俗易懂的方式讲解基本技术原理，减小非技术背景产品经理与工程师之间的知识差距，使合作和沟通更顺利，同时也提高产品经理的产品内功。
对非技术背景产品经理来说，在与工程师的合作过程中，掌握一些基础技术知识显得尤为重要，对于技术的理解可以不用深入到实现层面，但要对基本原理及产品背后的整体技术架构心中有数。
产品经理属于信息上游，在拿自己的产品想法与工程师沟通和推动产品实施的过程中，对技术要有一定的了解，这就好比手上多了一把好武器，能让问题顺利解决，让产品不断向前发展。
本书的目的是通过浅显易懂的方式，面向非技术型产品经理讲解基础技术知识，打开技术领域这一神秘的大门，使非技术背景产品经理在产品工作中更游刃有余。产品经理的工作内容涉及面广，而且对个人综合能力的要求高，要想做好产品经理就需要涉猎广泛，具备更多的横向知识体系，同时在产品这一纵向知识体系内做深做精。
本书既可作为产品经理平时学习技术的基础资料，也可作为工具手册，希望本书能助力非技术背景产品经理开展工作。书中内容不涉及很深很具体的技术，以基本技术概念和实现原理介绍为主，配合一些具体例子加深读者的理解，力求帮助非技术背景的产品经理对具体的技术知识有一个整体的认识，在设计产品或者与工程师沟通合作的过程中能更加顺畅。技术能力是产品经理的核心技能之一，但不是全部，产品经理的职责是通过产品创造用户价值和商业价值，了解用户、发掘需求并持续对产品进行优化才是产品经理的使命。如何阅读本书
读者在阅读本书时，可以通过理解技术的一些基本原理反观产品设计的细节。非技术背景的产品经理在阅读本书时可以结合自己在实际工作中遇到的技术问题或者是与工程师沟通产品方案时所遇到的技术挑战重现当时遇到问题的场景。读完本书后，重新审视当时遇到的问题在现在是否能很好地处理，以场景化的方式结合自身工作中的问题，然后从本书中寻找答案，总结并且复盘，这样能对自己在技术知识方面的欠缺有一个比较好的补充和提升作用。
本书第1章介绍了产品思维与技术思维的具体表现和差别，有利于产品经理站在不同的角度审视产品。
第2章是对互联网历史和基础技术知识的介绍，为非技术背景的产品经理科普互联网的简要发展历史及互联网技术和产品的几个阶段性特点。
第3章从理解原理的角度向非技术背景产品经理介绍编程语言的内容。本章的目的并不是让产品经理学会编程，而是希望产品经理通过了解编程语言的基本原理，了解技术产品的实现逻辑及工程师思考问题的基本逻辑。
第4章介绍数据库的基本内容，数据库作为数据的存储和处理中心，在产品的大版图里不可或缺，产品经理了解数据库的一些基本知识能增加对产品的全盘了解（从界面到数据）。
第5章以介绍主流移动平台的一些基本技术内容为主，目的在于让非技术背景的产品经理了解视觉界面下的实现细节，降低与工程师的沟通成本。
第6章介绍服务端的基本内容，服务端作为大后方，在产品技术体系内扮演着极其重要的角色，产品经理了解服务端的典型技术知识有助于从系统架构的层面理解产品设计，知道什么样的产品设计能降低技术实现难度和成本。
第7章是从数据的角度观察产品，产品经理对数据的敏感度决定了产品的优化方向。从本章中产品经理可以了解到不同维度的数据标准和基于数据驱动的产品设计方法。
第8章是对产品需求文档的一个格式和内容介绍，力求为产品经理提供一个可参考的产品需求文档样式。
第9章将内容重点放在沟通上，产品经理需要与各方沟通，其中的沟通技巧和沟通侧重点会在本章详细介绍。
第10章介绍了产品经理的不同类型和成长进阶的经验。
第11章重点对解决问题这一话题进行了分析，以聚焦答案的解决问题方式探究问题的解决方案，本章能提供给产品经理一种新的解决问题的方法，值得一读。
第12章针对不同阶段的产品经理的职业发展做了介绍与建议，对每个阶段的产品工作重心和进阶方式给出了一定的参考建议。
第13章以产品经理必懂的运营技巧为话题，从产品与运营的关系及如何更好地通过运营将产品用起来等角度分享了一些实战经验。
第14章对一些常用技术概念进行介绍，力图帮助非技术背景产品经理对实际工作中常用的技术术语有更深入的了解。
希望本书能帮助读者从产品、技术、运营三个角度建立三位一体的综合能力体系，助力读者朝着全栈产品经理的方向发展。
读者可以添加我的微信公众号“唐韧”与我交流沟通，也欢迎读者多提宝贵意见和建议。致谢
首先感谢我的家人一直以来对我的鼓励和支持，不管是在求学过程中还是工作过程中，始终在背后无微不至地关心我，让我有信心和动力去完成自己想做的事情。在求学和工作的过程中，难免会遇到各种挫折和困难，有家人的鼓励和支持就有了最大的理由去迎接并战胜这些困难，让自己在前进的道路上勇往直前。
写作的过程是孤独的，尤其是身处繁忙的工作中，每天写作的时间非常有限，工作之外的休息时间基本都用来写作。我相信，这段经历是给自己最好的成长礼物，这段经历让我处于不断思考和认知升级的状态。对产品的理解、对技术的理解、对行业的理解在写作的过程中都得到了空前的提升，这是我要感谢自己的地方，也庆幸自己能有这个机会在这个年纪写了一本属于自己的书。
其次，感谢那些正在和我一起奋斗和曾经一起奋斗的小伙伴，虽然你们有些已经离开，但曾经有你们的陪伴和并肩战斗，我们都在成长，我们都在逐渐成熟，我相信我们都会越来越好。你们中有技术出身的，也有非技术背景的，与你们的配合使我在构思本书的内容时有了很多的素材和灵感。
另外，感谢在工作中帮助过我的领导、同事和朋友，我的成长离不开你们的关照和提携。尤其感谢我的领导，也是我做产品的领路人刘青焱先生，他是一位具备丰富工作经验且在互联网行业工作十余年的老江湖，在产品和技术领域颇有建树。
我需要学习的东西还很多，非常感谢读者选择本书。做任何事情都是一个持续优化和完善的过程，本书中存在的不足希望得到读者的指点和帮助，也希望同为产品经理或者即将成为产品经理的你，一起在奋斗的路上寻找更远的那一个里程碑！唐韧1 产品思维与技术思维1.1 产品经理为什么要懂技术
如果把产品比喻为房子，那产品经理就是房屋设计师。如果设计师不懂基本的房屋结构设计和施工原理，那么设计出来的房屋很可能就是无法落地的空中楼阁。理想的设计和物理的限制必须有效结合，不存在真正的空中花园和通天塔，在工程领域，每一个设计都是可以被实现的。对产品经理来说，置身互联网领域，设计互联网产品，每一个设计都应该在现有互联网技术下可被实现。产品经理学习一些基本技术知识，了解技术边界，对实际开展产品工作有非常大的益处，所谓知己知彼，特别是在与工程师的工作配合和沟通中能起到关键作用。
在实际工作中不难发现，当产品经理与工程师就某一个具体问题进行讨论时，双方站在各自角度就问题进行分析和讨论，固有知识结构的差异导致思维模式和视角的差异，工程师通常是路径推理的技术思维，产品经理通常是用户场景的产品思维。产品思维和技术思维的碰撞让问题没有在正确的方向上被解决，原因就是双方用了不同的语系，好比一个讲英语的人和一个讲法语的人讨论一幅画，结果可想而知。产品思维和技术思维如图1-1所示。图1-1 产品思维与技术思维
产品思维侧重从用户和商业视角出发，技术思维侧重在技术实现和系统架构层面，两种思维方式也有交叉点，那就是产品的需求、设计和产品功能。由此可见，当产品经理与工程师讨论产品时，各自的利益出发点是不一致的，产品经理需要思考产品的用户价值和用户的产品使用场景，同时还需要考虑产品所承载的业务闭环和商业价值，因为单纯的产品功能没有价值，所以产品经理需要思考如何通过产品功能完善整个业务闭环并构建具备商业价值的产品体系。
工程师是技术思维的代表，从技术思维角度去思考问题，首先就是基于产品需求的实现方式的考虑，工程师看到产品设计后在脑海里构建的是拆解后的实现要点，好比一栋房子的内部结构，需要先构建产品的技术架构，然后评估产品功能的技术价值和开发成本。工程师和产品经理虽然基于同样的产品需求和设计进行讨论，但双方的出发点不同会影响共识性的达成，所以对产品经理来说，掌握一些技术思维，学会从技术视角看待产品设计，能更有利于产品需求的落地和推动产品的实施。
对产品经理这一职能来说，需要掌握更多的语系，因为产品经理是信息的衔接者，在一个产品项目中起到信息中枢的作用，产品经理需要与老板、业务人员、市场人员、设计师、工程师等进行合作，他们有各自不同的背景和沟通方式，要求产品经理具备与不同职能的人打交道的能力。对于合作最为密切的工程师来说，这就要求产品经理具备一定的技术知识，在与工程师合作和沟通时需要切换至技术语系。试想一下，如果工程师告诉你“这个数据是用栈存放的”，作为非技术背景的产品经理是不是顿时感到蒙圈，接下来的场景大概就是工程师不断从技术角度跟产品经理解释，产品经理似懂非懂地听得云里雾里，然后说了一句“那换一种实现方式呗”，此时工程师瞬间蒙圈，换一种实现方式好比让建筑师把房子全拆了重建，工程师和产品经理友谊的小船说翻就翻。作为一个有理想有抱负的产品经理，在工作中要应付各种场景，快速精准地处理问题，了解工程师这类亲密合作伙伴的工作、了解他们工作中运用的知识，是促进合作提高效率的有效方法。1.2 产品经理和工程师分别是干什么的
在互联网公司里，产品经理和工程师分别有各自的职能属性。产品职能属于信息上游，负责发现并定义需求，将用户需求通过具体的产品功能设计呈现为用户可用的产品，包括需求分析、功能定义、原型设计等。产品经理同时也是产品的核心灵魂，因为产品的发展走向很大程度上由产品经理把控，产品经理需要权衡业务与市场，需要将老板的战略意图贯穿到产品设计中，需要向工程师传递产品的核心价值，需要讲解设计背后的需求逻辑，在将设计落地为实施的过程中，产品经理扮演着重要的角色。
技术职能细分为很多种，比如架构师、前端技术研发、后端技术研发及系统运维等。技术职能属于信息下游，负责从技术实现角度评估产品设计，设计技术方案，最终将产品设计实施落地为用户可用的产品。在这个过程中，工程师需要先理解需求，同时需要从技术角度衡量需求的合理性及投入产出比。例如，某一项产品设计只是优化了1%的用户的使用问题，却需要投入极大的开发成本，那就是不合适的。工程师在对产品设计进行评估后，需要将实施层面的技术成本反馈给产品经理，产品经理需要据此灵活调整产品设计。对技术职能来说，在不同的产品阶段，需要持续对技术方案进行调整与优化。比如在产品设计不变的情况下，用户规模上了一个层级，原本的技术实现方案不足以支撑大规模用户的使用，此时就需要对技术方案进行升级。在这种情况下，产品经理实际上不需要调整产品设计，工程师需要对技术设计进行调整。
产品职能与技术职能在工作流上是上下游配合的关系，但从一个长远的角度看，技术是需要持续演进的，而产品在远期会进入一个相对稳定的状态。以微信为例，微信产品的功能更新基本变化不大，但微信的技术却一直在演进，从1千万用户到1亿用户，对产品底层的技术要求是不一样的，而且随着产品生命周期的发展，对技术灵活性的要求也会随之提升。还是微信的例子，现在微信更新一个版本的成本是很高的，每个版本影响到的是上亿的用户，确保不同版本之间的兼容性及新老版本的稳定性，这些都是技术上的挑战。在整个产品生命周期中，产品职能和技术职能始终相辅相成，持续对产品进行改进与优化，两种职能是天生的配合者。
作为产品经理，需要了解一个技术团队中各个职能分别是做什么工作的，图1-2所示为一个常规技术团队的组织结构和基本职能分布。图1-2 技术职能结构图
在职能分布上，CTO（首席技术官）是管理和领导的角色，是技术团队的负责人，统筹技术和产品相关工作的开展，简单说就是技术团队的老大。在CTO之下又划分为几个大的职能模块（可能不同的公司有不同的划分方法），即产品设计、研发、测试和运维。
产品设计包括产品本身的功能和流程设计，同时也包括产品的交互和视觉设计。在大公司里，交互和视觉设计分工比较明确，职能更细；在创业公司里，产品经理通常承担了产品功能流程设计和交互设计，视觉设计一般由专业的设计师负责。产品设计师在整个工作流中类似建筑规划总设计师，负责设计整体蓝图。
研发版块是技术团队的主要构成部分，一般是人数最多的职能版块，研发分为前端开发和服务端开发，前端开发又可细分为Android开发、iOS开发、Web前端开发等，服务端开发可以细分为应用接口开发、数据库开发等。虽然都属于开发人员，但同样是术业有专攻，每个开发人员都有各自负责的技术领域，当然也有跨技术领域的工程师，比如既能做前端开发又能做服务端开发的。
技术团队通常都有一个架构师，架构师是一个高级技术职位，一般是一位具有丰富经验和技术能力的技术人员，架构师负责系统的整体架构和规划，类似于建筑实施总设计师，设计整体实施方案。测试是保证产品高质量上线发布的保障职能，测试具体可以细分为黑盒测试和白盒测试。
黑盒测试是指一般的功能性测试，测试人员会从用户视角对产品进行全方位多角度的使用，模拟出各种可能出现的用户场景对产品进行全流程测试。白盒测试是比黑盒测试更进一步的测试，白盒测试会深入代码层面进行测试，使用测试用例对某一代码模块进行测试，白盒测试对测试人员的要求更高。测试人员类似建筑工程中的质检人员，负责对实施的工程进行质量控制和把关，对于不合格的部分进行标注并返工处理，测试通常有一套严格的测试标准，叫测试用例，测试用例覆盖越全，测试所覆盖的可能性问题就越全，更有利于遍历所有可能的问题。
运维是对系统进行持续稳定运转的保障职能，需要持续监控和优化系统的运行状态，例如对带宽的监控、对系统负载能力的监控和优化等。运维类似于建筑工程中的交付保障部门，对交付后的产品进行持续维护，当出现问题时及时响应并处理。运维是系统工程，而且是持续进行的工作，对系统的要求是7×24小时全天候无故障运行。我们每天使用的各种互联网产品能正常工作，一方面是在开发和测试阶段解决问题，另一方面是在后期运维阶段持续保障。例如，当用户量或访问量到达一定阶段后，运维需要提高服务器的处理能力，所以运维是产品的后勤保障。以上各职能相互配合，为产品的整个生命周期服务。1.3 产品设计中需要注意的技术边界
技术边界是指在现有技术水平之下，可以被技术实现的需求范围。超出技术可实施范围的设计无法落地，互联网技术日新月异，技术在快速发展的同时也对互联网产品设计的发展提供了保障。例如今天的智能手机，可以手指滑动操作，可以多点触摸，可以使用一些内置传感器实现诸如摇一摇之类的功能。很多产品设计都是基于这些技术之上的，有了基础技术的支持，可以产生很多很好的产品创意。十年前，很多技术还不成熟，今天使用的很多产品功能都是无法被满足的。所以，对于产品设计者来说，在设计产品时需要了解技术边界在哪儿，需要知道什么样的设计在今天能被满足，但同时也不要受制于技术边界，想象的空间无限大，在思考层面需要无边界。这里所说的边界实质上是指实现边界。想法可以足够大，但实施需要脚踏实地。产品经理在提需求的时候首先要询问在技术实施角度的可行性，否则一个看似酷炫的设计方案有可能只是个空中花园无法落地。
我们能使用移动App产品实现自动定位和导航功能，是因为在智能手机里内置了GPS导航模块；能在微信内使用摇一摇功能，是因为手机内置了重力传感器和加速度传感器，包括现在流行的计步器类产品都是应用了该项技术。在实现层面，例如苹果的iOS设备和谷歌的Android设备，在开发上也封装好了非常方便使用的接口，开发人员只需要简单调用就可以实现这些在以前看来非常复杂的功能。接口和调用就好比我们用电，我们不需要关心发电厂如何生产电，我们只需要把插头插入插座接口，就可以点亮电灯。
对产品经理来说，在设计某一项产品功能时，需要考虑在现有技术条件下该功能能否被实现。对技术边界的了解可以先从了解常用技术基础开始，另外，在与工程师的沟通和互动中也能学习到很多技术边界有关的知识，在具体实现时会遇到很多问题，哪些是现有技术能解决的、哪些是现有技术解决不了的，工程师最了解。案例分析
举一个有关技术边界的例子，使用微信的人应该都熟悉微信运动，每天一到晚上10点，大家总会看朋友圈里今天谁走的步数最多，“很坏地”给步数最少的人点赞，这已经成为一种运动和生活习惯。
微信运动这个产品功能其实受限于使用的手机传感器，细心的同学可能会发现，出现在微信运动列表中的朋友大部分都是使用iPhone的用户，很少看见使用Android手机的朋友出现。其实，微信运动这个产品功能使用到了手机中的重力传感器和加速度传感器，这种传感器在iPhone等高端手机中是自带的，但是在一些低端Android手机中没有。重力传感器和加速度传感器通过手机的移动和一套计算走路跑步的算法计算用户携带手机走了多少步或者跑了多远，微信只是开发了一个功能通过重力加速度传感器获取这个数值。
这就是一个典型的技术边界的例子，同样一个产品功能，在不同的物理设备上，由于设备的技术标准限制，使得同一个产品功能在一些设备上可用，在一些设备上不可用。
作为产品经理，在设计某一个产品功能时，首先要判断在现有的技术边界下该产品功能是否可被实现，否则一个再好的功能，缺失了基本的土壤条件，也无法落地。尤其对非技术背景产品经理来说，在提出一些产品功能时，建议先和工程师就该产品功能的实现方案进行初步沟通，明确其技术可行性再做进一步分析和设计。技术可行性受限的，需要及时调整产品设计策略。1.4 工程师的思考方式：工程思维
产品经理需要具备多种思维模式，首先就是工程思维，大部分工程师都是工程思维。工程思维往往是理性的逻辑思维，从实现的难易程度和系统的角度定义产品和设计产品。这么做有一个最大的弊端，就是脱离实际。这个实际并不是指技术实现的实际，而是指需求和实际场景。当工程师接到一个需求时，首先是从现有工程架构和扩展的角度考虑，这是一种很正常的思维，但从另一个角度看，一个需求的价值不在于它本身的技术难易，而在于是否解决了用户的问题，我们要避免为了设计而设计。
用户需求的具象表现是产品功能，单纯地研究和设计产品功能好比是实验室进行的科研任务，例如，对某个功能的流程设计或者是交互体验设计。但是，产品本身不仅仅只有功能，还有背后的业务和商业逻辑，功能之下体现的是业务和商业目的。现在流行的购物智能推荐就是在用户首次浏览商品后，再进入浏览页面时，系统会自动推荐与上次用户浏览的产品相关的产品，这样做的目的是提高用户的购买率，通过这个功能的设计，达到提升购物转化率和平台成交量的目的。
作为产品经理，在工作实践中需要不断了解工程思维，特别是对非技术背景产品经理来说，在与工程师的合作中，经常是在与工程思维进行互动。工程思维是一种实现思维，而产品经理恰恰代表的是用户思维，如何将用户思维与实现思维有机统一，是产品经理的必修课之一。1.5 入门产品经理的思考方式：功能思维
功能思维是从软件产品角度出发的思维模式，是从系统功能的角度评判产品的完整性和实用性。功能思维是有别于工程思维的一种表现，功能思维更多的是产品经理所具有的，有句话经常这么说，“是做功能还是做产品”，其实功能是产品的一种表现形式，功能思维会为了完成一个需求考虑功能体验上的各种可能性，重点都是关注产品功能本身，而忽略了其业务目标和业务价值。而且，一个产品从商业战略到最后产品上线，期间不仅是一个技术产品，还包括业务定义、全业务流程设计等，产品始终与业务并行发展，真正好的产品应该做到产品驱动业务，在产品设计过程中不能忽视与业务的互动，包括产品上线后产品运营和业务运营，这些环环相扣构成一个整体来支撑一个产品的运转。
不管是技术型产品经理还是非技术型产品经理，具备功能思维比较容易，日常的产品设计大多都是基于一个需求设计功能，功能设计同时也受技术边界的制约，尤其对非技术型产品经理来说，具备一定的技术知识对设计产品功能起到直接的帮助作用。1.6 高阶产品经理的思考方式：产品思维
产品思维是一种结合工程思维、功能思维及商业思维的综合思维模式，包括对商业目标的理解、对目标用户及用户使用场景的理解。在充分理解商业战略的前提下完成产品定义和产品设计，通过了解产品所围绕的业务场景提升产品的可用性和易用性，改善业务体验和产品体验，提升整体的用户体验。返璞归真，回归产品的本质。在产品思维下，既包括工程思维也包括功能思维，同时涵盖用户思维和商业思维。在产品意识和产品思维的驱使下，产品经理在前期定义产品阶段需要充分了解业务并清晰地定义业务目标，衡量在目前的产品环境和可用资源下如何快速实现。期间需要完成大量的沟通工作，包括与业务、运营、设计、技术和公司其他相关职能部门的沟通。在共识和可行性的基础上开始进一步的详细设计工作。
产品思维可以大大简化产品工作，按《用户体验要素》一书的观点，整个产品体系从下往上分为战略层、范围层、结构层、框架层和表现层，如图1-3所示。图1-3 用户体验的五个层次
最下层的战略层决定了业务和产品需要实现什么目标，为谁和什么场景服务；范围层需要定义清楚在既有战略的基础上做哪些东西来实现战略目标；结构层需要基于范围层的内容完成基础信息架构和交互设计；框架层完成我们能看得到的界面设计；表现层则是视觉表现设计，让产品看起来更友好。一个完整的产品定义和设计过程都需要经历这5个阶段，缺失某一个阶段都会导致产品不完整，重点关注某一个阶段也会导致产品的不平衡，所以需要产品经理找到其中的平衡点。就重要性来说，越往下，重要程度越高。
产品思维还有一个非常重要的环节就是对业务流程的设计，产品经理为最终的产品质量和用户体验负责。在设计前期产品经理需要考虑产品从设计到开发到最终投入使用需要经历哪些环节，需要与哪些人进行合作。例如，需要数据准备的产品，在产品设计阶段就需要与数据提供方达成一致，保证产品上线时数据已经准备好。需要运营介入的产品设计，需要在前期沟通阶段就邀请运营人员加入，确保其对整体业务流程和产品环节足够清晰且理解一致，才能在最后产品上线时大家集体发力保证产品高效运转，而不是产品经理单方面思考和定义然后交付给下游配合方，这样会导致产品与业务脱节。所以，产品思维是要在考虑整体性的同时顾全细节，心里装下业务、运营、设计、研发等很多环节，可见产品经理是一个综合体。
图1-3所示的五层结构，每层的侧重点不同，产品经理做产品的过程中需要从战略层思考开始。当然，通常战略层的内容都是公司高层已经确定的，产品经理要做的就是理解战略，在理解战略的基础上挖掘符合战略的用户需求，即解决用户的什么问题，范围层解释的就是要做什么并且为用户解决什么问题。战略层和范围层的内容明确了产品定位，产品定位是否清晰直接决定了产品以什么样的形态呈现给用户使用。案例分析
在微信V6.5.12之前的版本中有一个产品功能设计很有意思。我们从微信第二个模块“通讯录”进入某一个联系人主页，单击“发消息”按钮后进入会话聊天页面，此时单击页面左上角的“返回”按钮后，直接返回到第一个模块“微信”，也就是聊天列表页面。我们可以看到，从第二个模块“通讯录”进去，却从第一个模块“微信”出来，这个设计似乎有点违背基本逻辑。恰恰是这个设计，体现了微信背后产品经理的产品思维。
我们来分析微信为什么要这么设计，首先有这么一个场景，我们通过通讯录找到一位好友开始聊天，聊完后用户可能的动作有：第一，在这次聊天的过程中有别人发来了消息，需要及时查看；第二，长时间聊天产生了社交疲惫感，想看几篇公众号文章缓解或者刷朋友圈。从可能的场景可以看出，回到第一个模块“微信”处理信息的概率远远大于留在第二个模块“通讯录”，所以在结束聊天返回后的这个动作所触发的下一个动作更有可能是处理别的事务，而不是继续留在通讯录找另一个人聊天。
但是在微信V6.5.12之后的版本中，这个设计发生了变化，进入微信后选择“通讯录”，选择某一个联系人后就可以进入他的个人“详细资料”页面，点击下方绿色按钮“发消息”进入聊天页面。此时，点击左上角的“返回”按钮后回到的是“详细资料”页面，也就是从哪里进入就回到哪里。
这个变化在某种程度上反映了微信设计产品的逻辑变化。这种变化有可能是产品经理设计思路的变化，也有可能是数据驱动下的决策，或者是用户反馈后产品经理做出的妥协。无论是哪一种，背后折射的是微信产品经理对产品在不同阶段的不同理解。
微信的这种设计思路是典型的产品思维，将用户的使用场景与产品功能设计结合。同样是这个产品功能，如果使用工程思维或者功能思维进行产品设计，那么从聊天页面返回时应该直接返回联系人主页，因为这符合工程实现中栈的思维。关于栈，后面的章节中我们会做详细介绍。1.7 产品经理必须回答的8个问题
一个标准的互联网公司如果没有产品经理，还真不好意思说自己是互联网公司。但是，如果画几个原型图、设计几个功能就叫产品经理的话，那互联网行业产品经理的数量还要翻上几倍。那么问题来了，如果画原型图和设计功能的不叫产品经理，那产品经理到底该干什么呢？如果你是一个产品经理，先试着回答如下8个问题，若你对大部分问题都没有明确而坚定的答案，就要小心，可能你做的不是产品经理的工作，而是抢了功能经理和设计师的工作。第一问：产品的目标用户是谁？
在《用户体验要素》一书中，作者提出了经典的产品五层模型，这个理论模型比较好地解释了产品的层次架构，也给了很多产品新手一个概要性的指导纲领。理论框架只能为我们建立思考模型，回到产品本身，我们需要回答的第一个问题就是，我们产品的目标用户是谁。
这不是一个“我是谁”的哲学问题，产品的目标用户直接决定了产品原则的设定标准。简单说，产品原则就是产品本身的道德准则，即坚持什么、抵制什么、做什么和不做什么。一个产品的目标用户往往是一个特定的人群，这群人会基于一个共性的需求来使用产品。例如，滴滴出行的目标用户是某一时刻有出行需求的人。这些人的需求是通过交通工具将自己从A地运送到B地。明确了目标用户，掌握了他们的需求，就可以进入下一个问题。第二问：产品为目标用户解决了一个什么核心问题？
回答目标用户的特征和需求之后，需要明确产品为用户解决的一个核心问题是什么。用户只会因为产品的一个核心功能而使用产品。一个产品往往具备很多功能，这些五花八门的功能看似解决了用户很多问题，但如果缺乏一个核心功能，这些附属功能是无法支撑整个产品的。产品为用户解决的核心问题就是产品功能的主路径，明确主路径之后，一切产品功能的添加和优化都需要围绕这个主路径展开。例如，微信为用户解决的核心问题就是沟通。第三问：产品的核心功能是什么？
明确了目标用户，明确了要为目标用户解决的核心问题，那么从产品功能层面，为用户提供的核心功能是什么呢？核心功能的选择决定了用户该如何使用产品。还是以微信为例，如果解决的核心问题是沟通，那核心功能可以是语音、可以是文字，也可以是视频。基于微信原始版本所处的时代和网络环境，选择实时文字短信收发作为核心功能是最合适的选择。第四问：产品的使用场景是什么？
产品设计必须依托于用户使用产品的具体场景。我们知道用户在什么样的场景下使用产品，即可以对该场景下如何更好地满足用户需求提供真实的现场感受，从而利用这种感受指导产品设计，也可以基于真实的使用场景优化产品定位。例如，阅读类产品有白天模式和夜晚模式，这种产品功能的设计是了解用户的真实使用场景后才能得到的洞见。第五问：产品给目标用户带来的价值是什么？
这个问题回答的是目标用户为什么要使用我们的产品。用户不会无缘无故使用我们的产品，我们需要给用户一个使用产品的理由。这个理由就是产品给用户带来的价值。价值的体现形式可以是物质的也可以是精神的。例如，司机使用滴滴出行的产品能带来实际的收入；我们使用微信和别人交流互动体现自己的存在感。第六问：如何用一句话介绍产品是什么？
这是一个最难也最容易的问题。难在回答这个问题需要对产品的本质有充分的理解，容易在通过简单的表象也能回答。
例如，以比较火的国外社交产品Snapchat（色拉布）为例，这款产品的创始人用一句话介绍他们的公司和产品，“我们是一家照相机公司”。这个描述足够精炼也足够简单，让人非常好理解的同时给人无限的想象空间。因为Snapchat做的是一款图片类的社交产品，他们通过产品的设计传递一种将照片作为沟通载体的理念。所以，将自己比喻为一家照相机公司既能让别人听懂，也能让别人产生想象，这家新型的“照相机”公司究竟与传统的照相机公司有什么区别？这会激发人的好奇心和求知欲。第七问：与同类产品的定位差异是什么？
前面的问题回答了我们自己是谁。这个问题回答的是我们在别人眼里是谁，以及别人在我们眼里是谁。与同类产品的定位差异化是拉开产品和业务差距的核心。例如，百度基于搜索场景完成人与信息的连接，阿里巴巴基于购物场景完成人和商品的连接，腾讯基于社交场景完成人与人的连接。他们的定位各有差异，面向的市场也各不一样。即使他们的产品在功能上有重合，例如百度有搜索功能，阿里的天猫和淘宝同样有搜索功能，但定位决定了目标市场的差异化，也决定了公司的基因差异化。第八问：产品的盈利模式是什么？
不以赚钱为目的的生意都是耍流氓。情怀是给文艺青年玩的，追求是给理想青年玩的。一个正常公司的产品经理需要清楚地知道自己主导的产品究竟如何给公司创造商业价值。当然，互联网产品都是用户价值至上的，早期可以不考虑产品如何产生商业价值，等用户量达到一定规模，或者产品带来的用户价值足够明显时，再整体规划如何将产品商业化。
例如，谷歌推出的面向普通用户的搜索引擎产品，天生就是一个具备盈利模式的产品，满足用户使用体验的同时，公司还赚得盆满钵满。谷歌至今都是全球市值最高的几家公司之一。
以上8个问题，总结起来就一句话，“知其然，更知其所以然，知己知彼，百战不殆”！1.8 本章小结
本章主要介绍了产品经理懂技术的必要性，尤其对非技术背景产品经理来说，在设计产品的过程中需要了解技术边界，避免设计出一些在现有技术下无法实现的产品。
另外，对技术职能的划分做了介绍，帮助产品经理在与技术人员的配合过程中对每一个领域的具体职责有清晰地理解，知道出问题的环节该对接到哪个技术职能，精准地找准问题解决者对工作效率的提高非常有帮助。
了解技术职能的划分对整个技术产品的研发流程也会有更清晰地认识。准确把握什么是工程思维、什么是功能思维，以及什么是产品思维。产品经理设计的是产品，但产品不仅仅只有功能，产品是业务的表现形式，抓住业务的本质并洞悉用户，沉淀出关键功能的产品才是好产品。同时具备技术思维和产品思维的产品经理才是好产品经理。2 互联网技术与产品2.1 互联网技术发展史
互联网技术一直在更新换代，产品形态也在持续演进。纵观互联网技术的发展历史，大致可以分为三个阶段，分别是基础技术发展期、PC互联网时代和移动互联网时代，而下个阶段的互联网形态究竟是什么样的，现在有很多畅想，比较主流的是互联网即将进入人工智能和万物互联的时代，那将是一个互联网极度发达和普及的时代，我们生活的方方面面都有可能被互联网影响和覆盖，如图2-1所示。图2-1 互联网发展阶段
20世纪五六十年代，计算机技术刚刚开始，属于基础技术发展期，最初计算机技术被应用在美国军方，后逐渐引入学校，早期的互联网网络逐渐形成。之后互联网技术一直处于高速发展阶段，计算机也逐渐进入民用领域。20世纪八九十年代是互联网的雏形期，这段时间主要是互联网基础技术的发展。紧接着第二阶段大概在20世纪90年代，互联网技术开始在全世界普及，进入PC（个人电脑）互联网时代，技术层面应用最广泛的是Web技术，具体表现形式就是我们所说的网页。台式计算机的成本下降和计算机在生产生活中的普及，导致互联网技术进入多样化发展的阶段，各种技术创新使得很多产品创新成为可能。
一些技术社区也逐渐形成，很多互联网技术都采用开放共享的模式，一门技术并没有版权限制，这也给互联网奠定了开放的基因。接着是第三个阶段，也就是目前所处的移动互联网时代，智能手机的发展带动了移动互联网技术的发展，比较典型且主流的是以美国Google公司推出的Android系统和美国苹果公司推出的iOS系统为主的移动平台。从PC互联网时代向移动互联网时代转型的过程中，基础技术也在随之更替，移动互联网时代技术产品的表现形式就是我们平常用得比较多的App，同时HTML 5技术也在移动互联网时代得到极大发展。
试读结束[说明：试读内容隐藏了图片]