作为一名软件工程的学生，每当考虑以后的发展方向时我总能想起软件工程老师在课堂上说过的：“咱们学生最对口的专业是产品经理”。再加上近两年不少网上的诱惑——“产品经理是离CEO最近的职业”，使得不仅仅是我们“对口”专业的学生更亲睐往这方面发展，也使得产品经理成为了许多非相关专业学生的种草职业。

最近看了几个名校学生面试产品经理的视频，其中不乏很多非相关专业的学霸，从他们的回答问题的角度和逻辑来看，有很多是有“道”无“术”，但非常具有潜力的学生。即使是在相对硬核的技术面，如果能够理解问题的基础和核心，并且把用户核心需求放在第一位，那些不懂具体技术的学生也能给出相对满意的回答。

那么不懂技术的产品经理是不是好产品经理呢？

先问是不是 再问为什么！

可以是。

那么为什么呢？

我将结合一个实际的例子和我的一些心得体会来说明到底好的产品经理需要的是什么。

开宗明义的说，我认为一个合格的产品经理需要的是：理解基础的技术知识 + 把握用户需求。

理解基础的技术知识

就像我的搭档郭老师说的：“我和火箭专家说，你那火箭不行，燃料不好，我认为得烧柴，最好是烧煤，煤还得精选煤，水洗煤不行。如果那科学家拿正眼看我一眼，那他就输了。”

如果你是一个“烧柴”的产品经理，我觉得你可能真的需要在这方面先下下功夫。当说起MVC三层架构，你至少可以理解三层架构是如何组织代码和通信的。可以看不懂具体的代码，但是要理解核心思想以及可以类比，这种能力是至关重要的。但你要是说MVC和MVP是什么关系？这就鸡同鸭讲了。

把握用户需求

这一部分我以一个大家应该都写过或者分析过的”后台管理系统“作为例子，来说明什么叫做把握用户需求。为了能够具体且落地我们加上一个前缀——实验室·管理系统。

好，让我们带入到一个技术小白的视角来让思考一个问题：“开发一个为高校实验室使用的实验室管理系统。”

是不是感觉顿时有很多思绪：应该有学生管理、老师管理、签到打卡功能… 但再往下思考就开始觉得没有了思路，慢慢的新的想法与上面的想法相互重叠，乱七八糟，又回到了一片空白的状态。其实这个问题很大、需求也不明确有些模棱两可。

一个及格的产品经理应该这样思考：

首先细化、量化需求。实验室是什么类型的实验室–是化学实验室？是物理实验室？是程序员的实验室？还是人文社科的实验室（不知道有没有啊）。

那么这个实验室现在是用什么方式进行管理——靠人？靠通用的管理系统？靠一个不稳定的系统？

在往下分析：他们为什么要换或者使用一个管理系统？原来的方式出现了什么问题？

经过这样分析我们可以看出我们要做的是一个网络安全实验室的管理系统，原来这个实验室都是靠老师自己人工管理但随着学生和老师数量的不断增加、论文专利发表的数量也在增加、传统的方式效率越发低下，急需一个定制化的管理系统用来解决问题（以上为假设）。

现在我们的基本需求分析出来了，接下来还需要明确一下。

我们的目标用户是：一个网安实验室的成员。

他们的需求是：一个针对他们实验是定制化的管理软件。

基于他们的使用场景下，基本的需求应该包括：

比人手动管理效率高

最小的学习成本、非计算机的财务老师也能够快速上手

稳定可靠，毕竟很多论文or专利都要放在上面

可以快速向前兼容–以往的数据可以通过便捷的方式上传到系统上

可以向后兼容–随着实验室的不断壮大可能需要新增一些功能

解决以往的一些痛点

系统不需要那么复杂–这往往意味着更低的开发时间和更便宜的价格

这种管理系统应该是每个毕设答辩中老师最讨厌的类型了，但我觉得这并不意味着这是一个完全体现不出技术含量的题目（除非你是完全抄的或者就是买的），相反这是一个”五脏俱全“的问题，你要做的是更具体、更能满足实际的需求。

好，到目前为止，我们已经解决了一个看似无从下手的问题，描述了将要使用它的用户，并从这种系统中了解了他们的基本需求（或期望）。那么是什么方法帮助我们解决的问题呢——带入角色。

这就好比是您听相声的时候，常常听到的是我（于谦）父母的故事，这代入感一下子就让您想象到并沉浸在故事当中了。做一名产品经理也是需要有这种能力的，当带入到使用者的角色时，你将会把这个角色与实际生活联系起来，紧接着你就会开始思考“我”要的是在什么场景下的什么东西。

因此同理心or带入感是成为一个优秀的产品经理所必须的。

这个时候基本的技术基础又该上场了，我们需要把用户的需求转化为技术需求：主要是在pc web端、基于某个简单易用的框架、敏捷开发、可能需要手机端小程序（另外加钱）、做好数据冗余备份、代码要向后兼容等等。

可能具体的需求还需要与各个老师与学生认真沟通和交流，最后得出一份完整的需求分析文档。

接下来就要开始动手推进项目了。另一个问题随之而来–确定功能开发的优先顺序。

我们可以把定制化作为程序的核心亮点，那么我们应该上来就开始实现那些这个实验室单独需求的功能么？或者说一个相声演员上来就该练他的成名节目么？我想不是的，至少我是从贯口学起的，我可没上来就”抽烟、喝酒、烫头“。

我们要从整个程序的基础，也就是那些最基本的功能开始入手。

也就是说我们现在有了一个基本的mvc架构下的程序，用户与视图交互，控制器控制视图的跳转以及数据的处理，再通过模型与数据库。

视角再放大一点，用户在浏览器上操作，如果不涉及太多细节，查询将转到该服务的服务器，服务器根据相应的请求做出处理，并且调用数据库中的数据并做出相关操作。最后服务器把处理后的结果返回到客户端并呈现在浏览器上。

至此，我们有了一个基本的管理系统，可供少数人使用。接下来我们将着眼于定制化的需求和可扩展和兼容性的开发上来。到目前为止，我使用的技术术语非常有限。更多的是概念性的。让我们看看是否可以保持这种方式到最后。

假设你调研时发现，以往老师组织手底下学生开会总会遇到，不同学院的学生时间冲突的问题。那么你的程序是不是可以根据实验室学生的课程表，计算出每周可以大家一块开会的时间。

接着这个思路往下想，学生的课程表信息如何获得？学生自己填写么？可不可以通过识别校园卡，自动从教务系统里读出他的课程表，是不是其他的基本信息也可以一并读出。省的学生新注册时磨磨唧唧自己要填写一大堆了。

或者说，你发现以往老师报销经费，总是各种出问题，流程繁琐，能不能优化一下流程，绝大部分放在线上，等线上审批合格了，再去财务那盖章签字等等。

我们可以暂时脱离一下这个实际问题，想一点更通用的。如果这个程序获得了很高的认可，并开始推广起来，用户数量开始指数级递增，一台服务器能够处理负载吗？可能不够。

就好像德云社从天桥剧场开始，当我们越来越出名时是不是要考虑更多更大的场馆了。北京的北展，上海的梅赛德斯 看上去都是个不错的选择。

我们要添加几个新的服务器用于负载均衡，需要什么技术呢？

这不完全是你需要掌握的核心，你只需要知道有一些技术可以以编程方式将传入的请求分发到空闲或负载较小的服务器上。好的，当前我们设法引入了负载均衡，硬件已经设法扩增了，那其中的内容呢，内容是不是也需要有相应的冗余，因此我们应该为他们添加多个副本。

可能有的实验室在哈尔滨、威海、深圳都有使用系统的需求，如何能保证他们的使用体验是一样的，也就是保证一样的延迟。一方面我们需要建立各大中心城市的机房，另一方面如果有相关的计算机思想，是不是应该考虑设计相应的缓存机制。

另外我们可以发现我们与数据库的交互往往是一份文件上传一次，但是多次被不同用户下载。那么，为什么不将它们分开呢？

保留一组仅实时接收写请求的数据库，以及另一组（更大）仅从中读取的数据库。这是新的问题又出现了，如何保证两类数据库的信息同步问题。这里边可供选择的方法也很多：半同步赋值、中间件、缓存法等等。相信你的研发人员会告诉你在当前情况下什么是最好的选择。

OK说了这么多，回过头来看，我们解决了一个实验室管理系统的小问题，并且把他的应用范围适当扩大，考虑了负载均衡、冗余备份等更大视角的问题，其中没有用到任何高深的技术。可能在实际开发的时候会遇到更复杂，但万变不离其宗的是，把握用户需求，了解用户想要什么才是产品经理分析问题的关键。

回到最初的问题，不懂技术能不能做一个好的产品经理？

相比看完整篇文章你也有了自己的答案。产品经理是一个对硬实力要求没有那么严格的职业，更多的是要求你有全面的软实力。学心理的也好、学电气的也罢，只要热爱并且持之以恒的在正确的方向上坚持，我相信你肯定会成为一名优秀的产品经理。