前段时间, 我面试了一个国内一线门户客户端的产品经理, 她是学计算机出身的 PM, 但是由于编程能力比较弱, 所以做了产品经理. 后来在工作中, 有时和技术同学打交道比较费劲, 所以自己吭哧吭哧开始学习 SQL 和 PHP.
我不太认可这种直接去学习编程的方式, 因为产品经理应该是很忙的, 你的宝贵时间不该花在学习编程这件小事上.(多说一句, 我也是学计算机出身, 毕业于国内某最好的大学之一的计算机系. 我并无贬低编程之意, 恰好相反, 我身边很多优秀的产品经理都是学计算机专业出身.)
所以, 结合自己的工作和创业经历, 以及后来与诸多大厂, 创业公司的优秀 PM 交流的心得, 我觉得可以简单谈一谈到底 PM 要不要懂技术, 或者说 PM 到底要懂什么样的技术.
1. 产品经理这个岗位是怎么冒出来的
在我们的大学里, 从来没有一门叫做产品经理的课程, 也很少有专门的课程或者课题是关于如何做产品的. 没错, 我们在学校的时候, 如果不是互联网老炮跑来忽悠, 我们本不知道有产品经理这个岗位的存在.
在软件工程的过程中, 本不需要产品经理, 反而对工程师的要求很高.
工程师需要将客户的需求, 进行有逻辑的产品架构设计, 然后基于产品架构进行自底向上的系统架构设计, 最后映射到客户使用的 UI 界面, 便是最终的产品 形态. 在这个过程中, 工程师需要懂得如何理解客户需求, 懂得如何进行产品架构设计, 如何进行底层数据库设计, 如何进行系统各模块的设计等等, 最后还要进行 非常可靠的基于面向对象的指导思想的编程. 而且整个过程还是通过团队协作来完成, 而非单一个体. 这样一个繁琐的过程下来, 逐渐衍生出了几个关键的职能岗 位, 包括产品架构师, 系统分析师, 项目经理, 各级别开发工程师, 测试工程师, 运维工程师等等.
大学里的《软件工程》课程中教给我们, 在上个世纪, 软件工程方法论确保了几乎所有软件产品的落地实施, 特别是《人月神话》一书中, 更是将这种方法论讲述到极致.
可是, 互联网时代到来, 一切开始变化.
首先要变化的, 是客户群体.
由于客户群体从清晰可见的甲方客户变成了捉摸不定的互联网普通用户, 这就麻烦了, 一下子捕捉客户需求变得越来越重要. 而且, 随着对用户体验要求的重 视, 工程师们需要花更多的时间来进行产品交互设计, 界面逻辑等细节的优化. 互联网也逐渐对产品架构提出更高的要求, 要求产品架构可扩展性, 开发速度, 迭代 速度, 模块间复用能力, 对外合作与开放能力越来越高. 这样的一些列变化, 导致互联网下的研发工程师难以应对多变复杂的变化.
于是, 互联网产品经理岗位应运而生.
这是一个对产品进行完整设计的角色, 他背负着产品的架构设计, 可扩展性设计, 交互设计, 甚至商业逻辑设计等使命. 今天, 产品经理应当被赋予更高的职能.
2. 一个优秀的产品经理, 首先要拥有的是框架思维
在我看来, 产品经理最优秀的能力, 是框架思维, 而不是需求调研或者交互体验.
从产品经理衍生的过程来看, 产品经理其实是从最优秀的工程师身上拆分出来的, 一个专注于产品设计的角色.
我们看《社交网络》电影时, 发现扎克伯格自己独立设计并开发了最早的 Facebook(最初叫 The Facebook), 而张小龙也是最初自己独立设计并开发出了 Foxmail. 他们当时并没有什么产品经理帮忙, 而自己就是个超级产品经理 + 研发工程师. 他们明白产品应该如何设计框架, 模块间的关系如何, 如何进行后续迭代设计等等.
这些最棒的工程师都拥有的, 就是在一开始就想好了产品应该如何向下发展, 脑海中已经拥有了蓝图.
那么框架思维应该如何来理解呢? 我觉得有以下几个点:
(1) 良好的产品分层与模块化设计
所谓产品分层与模块化设计, 其实是基于产品系统框架来看的. 我认为, 好的产品经理应该懂得你背后的产品在系统结构层面上是如何设计的, 而这种要求并不需要你懂得如何编程, 而是要理解逻辑关系.
我们举一个简单的例子, 比如一个简单的商城产品, 它可能是需要分为三个大的层面来考虑的: 首先是其最底层的数据设计, 包括 SKU 结构的设计, 角色数 据的设计, 其他相关数据, 然后是中间层, 包括订单模块设计, 交易模块设计, 规则模块设计等, 最后是订单管理系统, 商品搜索系统, 商城系统设计, 积分体系设 计等等.
我们去看这个商城的时候, 如果你只看到商城的交互界面, 那很容易陷入到功能设计时逻辑思路不清楚, 不知道优惠券和订单是什么关系, 不知道商品复用与推荐系统的设计等等.
良好的模块间逻辑理解与设计能力, 可以帮助你更好地与研发同学打交道, 而且还会帮助你更好地理解你的产品各模块间关系是如何确立的.
(2) 良好的产品使用路径设计
有了模块逻辑理解之后, 你接下来要做的, 就是进行产品在交互使用中的路径设计了.
几乎所有好的产品, 都拥有一条明确清晰的用户使用路径, 而这条路径是基于流量控制的.
我们先来看一个简单的例子, 比如 Slack,Slack 中流量最大的地方一定是对话沟通, 因为在所有的协同工作中, 对话沟通频率最高, 也是最灵活的 部分. 所以在 Slack 的产品设计中, 所有基于第三方平台的任务提醒或者机器人提醒, 都被融入到沟通中. 然后通过沟通将用户流量导入到各个任务功能模块 中. 在 Slack 中, 排名第二的流量部分, 是通讯录, 因为沟通的主体是人, 而快速的找人是关键. 所以, 我们看 Slack 时便会发现, 最容易找到的是聊天界 面, 然后是搜索人或者直接打开通讯录, 最后才是各个任务功能模块. 这便是基于流量来控制的一条产品使用路径.
你会发现, 好的产品路径也同时带来了一个好的用户体验设计.
我们可以看到, 产品路径的设计是基于模块间关系的, 如何在各功能模块间建立良好的路径, 必须有清晰可靠的框架逻辑支撑. 想象一下, 加入 Slack 在设计之初没有考虑到要扩展无限个第三方任务功能模块, 那也就不会有这款产品如今的伟大.
我再举一个比较难理解的例子, 但是恰好说明用户路径的重要性.
商城, 社交, 工具这些应用都有几乎一眼就能看明白的用户路径, 可是门户 App 的路径是怎么设计的呢?
在门户中, 最关键的是用户流量和多次转化率, 也就是一个用户进来了, 能连续阅读多少篇文章. 所以在门户中, 最关键的路径就是如何利用内容将用户留住.
一般有三种类型的内容会比较受人关注, 一类是与自身相关的 (比如自身兴趣点), 一类是有趣的 (比如社会热点), 一类是显而易见的. 这三种类型内容的展示, 就是为了增强流量的留存, 而后在每次阅读之后, 遵循着三类内容的有序呈现, 便引导了用户的多次转化.
如此, 一条将用户流量进行留存与引导的路径便清晰可见.
在产品使用路径中, 最高优先级流量的部分决定了产品的定位, 比如微信最高流量的地方就是聊天列表, 而支付宝却是各类支付通道.
良好的产品路径设计, 会协助你将各个模块间的关系有机结合, 这种结合是产品向后迭代最重要依据.
(3) 良好的商业思维设计
最后谈一个点, 就是商业思维. 说白了, 就是你做的产品在整个企业或者团队的产品矩阵中占据何等地位, 又是如何为其他产品带来益处的.
一种模式是产品的功能属性, 也就是你所做的产品可以成为一种 SDK, 为其他产品直接提供能量支撑; 还有一种模式, 就是你本身是一个平台, 可以在体系内孵化或者融合其他产品.
要能达到以上这两点, 必须是产品已经拥有良好的模块化设计, 以及完善的路径设计, 否则你的产品只能自己苟活, 无法产生更多的附带价值.
另外, 什么是业务模式
无论是 To C 还是 To B 的产品经理, 你最终要做的不仅仅是一个功能而已, 而是要搭建一个生态结构. 互联网的本质是连接多边群体, 作为产品经理, 要明白你所在的企业究竟是靠什么业务在支撑整个生态.
比如百度, 它是通过连接网民, 网站内容, 广告商 这三边, 来构建了一个基于搜索引擎功能的生态结构. 产品经理站在产品的背后, 要看到的是自己所做的功能是处于生态的哪一个部分.
为什么要懂得业务呢, 是因为你最终要成为更优秀, 责任更大的产品经理, 而不是永远在做需求分析, 用户体验优化这些事情的小朋友, 你越早有这样的思维模式, 就越对未来做好准备.
最后, 说给非理工科专业出身的同学
大学学什么专业并不一定影响你未来从事哪一个岗位, 或者你可以变得多么优秀. 关键还是在于自身的能力.
许多优秀的产品经理本就是学文科专业出身的, 但是优秀的逻辑思维能力和框架感, 使得他们在产品设计中很明白自己所做的产品在哪一个维度, 也很明白自己是如何进行产品后续迭代设计的.
学文还是学理其实未必最重要, 最重要的还是那个大局观. 多读书, 收获一定更大.
来源: http://www.bubuko.com/infodetail-3100039.html