小白产品经理看产品：

什么是互联网产品

当你开始准备做一个产品经理之后，你就开启了产品经理之路。但刚开始的产品视角还不是产品经理的视角，只是小白产品经理的视角。为什么是小白呢？因为什么都不懂！一张白纸，没有框架，也没有太多整体感觉。

小白产品经理什么都没有？当然不是，他们有的是想法，有的是问题，有的是“要是我来做就不会这样”的海口。

破除小白产品经理的视角是通往一个合格产品经理的必由之路。

第1节　产品经理面试的第一道题：你用哪些产品

很多大学生找到我，希望我给他们推荐一个职位，有些也通过我获得一些面试机会。这个面试过程就有很多有意思的事情发生。在我的面试里面，有一个问题是必须问的。那就是“你的手机里经常用的产品有哪些？”。

我曾经在一个现场活动里面问过一个刚刚毕业的大学生朋友：

我：你想做什么工作？
她：产品经理。
我：想去什么样的公司？
她：百度。
我：你手机里经常用的APP是哪些？
她：微信、QQ、淘宝，嗯……
我：思考10秒还有没有第四个？
她：想不起来了。

全场大笑。

这是一个非常典型的新人，想做产品经理，但不知道产品是做什么的，也从不用第四款产品。那么，我想问的是，你觉得一个让面试官想要的产品经理是什么样的呢？

另外一个例子：我在负责百度搜索产品的时候，遇到一个候选人，我面试完成之后，希望他做一个搜索产品的产品分析作业。他回去做了3页百度搜索的体验报告。我不禁为他捏把汗。我并没有让他做百度搜索的体验报告，只是让他做搜索产品的体验报告。

他做百度的，其实写到头也未必能有多出色的地方，而且肯定不如我了解百度搜索产品。他不如写谷歌的，如果他写谷歌，我觉得他还有点儿想法。如果他写Bing的，我觉得他应该是个挺有产品感觉的人，毕竟敢挑战Bing的产品分析也是难得。如果他写Yandex的分析，我觉得肯定能进二面。如果他写一个比较好的Naver的分析报告，那我几乎就要录用他了。

可是，在面试百度的人里面，有多少人是用过Yandex和Naver的呢？又有多少人知道这两个搜索产品呢？

产品经理的早期阶段，最难的事情就是培养产品感觉。我们认为培养产品感觉其实很难有捷径。只有多用产品，多尝试各种产品，才能在长期的积累中形成一些感觉。就像“1万小时理论”说的一样，做一件事，持续做超过1万小时后，你就是这个领域的专家。像我们读研究生的时候，长篇累牍地读论文，老师要求每周至少80页外文论文，当时觉得很枯燥，但读完之后发现慢慢地就有对某些知识的感觉了。

多尝试，多体验，不要怕，不紧不慢，坚持下去就能培养出产品的感觉。然后用一些系统的方法认识产品。具体的认识方法，我们会在下面提出来。

你认识这些产品吗？自测一下吧，如果这些产品你都用过，那恭喜你，你已经涉猎颇丰。那接下来你应该知道他们的竞品在国内外都有哪些。如果你都还没用过，那赶紧加油去用一下吧。

广泛的体验产品，是从一个小白用户转化为职业产品经理的重要一步。如果不能做到这一点，就像设计汽车的不研究各种设计风格、踢球的不研究各种比赛视频、设计园林的不考察各种园林一样。

我们曾经做过线下活动，把一些很少见的APP截图去掉Logo后，一张一张地让大家去猜这是什么产品。比较厉害的产品经理基本能猜到80%，厉害的小组20个APP都对。这说明他们不仅在用产品，而且能把这些产品记住，把一款产品和竞品区分出来。

你能通过图片看出哪个是百度外卖、哪个是美团外卖吗？也许你觉得这样很变态，但我反而觉得这样很好看！

第2节　什么是好产品，好看还是好用

什么产品是好产品？好看的还是好用的？我想，略微经过思考的同学，都会回答好用的产品是好产品。但是，又有多少人在使用产品的时候，会认为好看的产品比较喜欢呢？

我曾经在很多场合问过大家：请问，在座的各位，有没有看到过一个产品是丑死的？因为它太难看，活活丑死了？如果有，请告诉我，我可能能救活它。答案是没有。

我并不否认设计和交互越来越影响产品的认知和感受，第一印象真的很重要。我也特别认可“设计改变生活”这个理念。但是，我们真正在反思一个产品的时候，往往会发现，先要让它好用，然后再让它尽可能地好看。

好用是普世诉求，好看是因人而异的。

我们看到的是58同城和爱帮网。这两个网站，其实做的事情有点儿类似，都是本地生活服务。我们也能很容易地发现，58很丑，而国外有个类似58的网站叫Craglist，更丑。爱帮从UI层面看，还是很好看的。但前者的市值应该是后者的百倍，用户量也是千倍的差距。

第3节　什么是互联网产品：黑盒子模型

那么，你认为什么是互联网产品呢？我曾经面试过上千个产品经理，也被很多人面试过。有很多次的面试，我们都会问：你认为互联网产品是什么？

这是一个很大的问题，很少有人能回答得特别清楚。大部分人说互联网产品是解决方案、是一套流程、是服务、是平台、是一整套代码……

我一直追求一个互联网产品的定义，这个定义不仅可以用来定义互联网产品，还可以逻辑性地用来推演出产品运营、产品设计和商业模式的选择。如果它真正可以定义产品，那么也应该可以用来推演一些结论。

本书的一大创新点，就在于我们尝试着建立了一套产品的定义。

我认为，互联网产品就是黑盒子（Black-Box），我们下面所有的推论都是从这个定义开始的。

互联网产品是一个黑盒子，通过这个黑盒子，用户会从哭脸变成笑脸，同时它会从底部掉出一些钱来。

所以互联网产品是一种能够带来用户微笑价值和可能带来商业价值的黑盒子。这个黑盒子因为不同的行业和语境，内部结构也不一样，但最基本的结构是T模型。T的上面横向是信息架构，纵向是业务流程。

也就是说，互联网产品是一个通过信息架构和业务流程组成的黑盒子，它首先能够带来用户微笑，然后能够带来商业价值。

• 推论一：互联网产品的第一价值是微笑价值，然后才可能带来商业价值。
• 推论二：传统行业的产品，比如房地产，就是反向进行的，用户从微笑变成哭，然后带来商业价值。
• 推论三：不管什么行业，黑盒子里面的基本结构都是T模型组成的，而横向的信息架构一共有3种类型，纵向的业务流程应该也是呈现“泳道状”的。

以上，我们基本完成了互联网产品的定义。我们后面还有许多推论，同时，我们也会用这个定义去解释互联网产品的运营核心、运营方法和其他内容。

我特别高兴，在这本书里能够第一次把我的这一发现分享给大家。

第4节　像庖丁解牛一样去观察产品

那么，我们在定义好什么是互联网产品后，是不是可以根据它的定义去使用了呢？第一个问题就是，如何观察产品和认识产品。

观察产品和认识产品，有两个阶段，第一个阶段，远远看，看外观；第二个阶段，细细看，像庖丁解牛一样剖析它的结构。下面我们就一起来看看怎么去观察、认识产品。

既然互联网产品是黑盒子，那么我们就套用这个概念来分析。我们把它分为黑箱和白箱两个方式去认识。

所谓黑箱，套用测试里面的定义，就是不去考察产品内部的线路、流程和设计思路，而是直接按照它的交付预期去测试。比如这个产品就是让100个人站上去不会垮，它的黑箱测试就是让100人站上去，看看会不会垮。如果不会，就成功了。至于里面是用钢筋水泥做的，还是塑胶做的，统统不管。

所谓白箱，就是要看产品里面的设计逻辑、线路结构、流程等细节是否符合设计方案。

那我们认识产品也是一样，首先可以通过黑箱的方式，去看产品是否带来微笑价值。这一微笑价值的评估，我们采用了一套画布的方式来解析。

白箱则是要去分析产品的流程、交互、原型和版本迭代了。

接下来我们详细说说这两个方法。

画布分析法。我们通过回答画布上的问题来认识这款产品。产品分析流程对应了相关的工作流程。我们认为，把产品当一个黑箱去分析它要解决的问题、提供的解决方案、独特买点和用户场景及目标用户等，可以让一个产品比较清晰地勾勒出它的框架。

要注意的是，我们一定要真实地回答问题，比如用户的痛点和问题，我们可能要站在用户的角度去想，用户到底有什么问题，而不是这个应用目前解决了什么问题。

说起来有点儿枯燥，我们看看用户对一些APP的认识吧。

第5节　学会用App Store的版本还原产品

版本还原是一种重要的产品认识方法。我在百度的时候，曾经指导过一些产品经理，通过App Store和豌豆荚市场的版本描述，还原产品版本。最后我们发现，这样的方法在复盘一个竞争对手的时候是非常有用的。你可以很清晰地看出这款产品的迭代节奏、走的弯路、交的学费，同时你也能看出，哪些功能点的发布带来了用户的显著增长。

我自己也曾经用这个方法还原了微信这款产品，发现了微信很多的“秘密”。

我们以春雨医生为例。可以看到，第一个版本（1.0）和第二个版本（1.1）之间经历了3个子版本，都在修复之前的Bug。第一个版本到最后一个稳定版本之间，经历了大概８个月的时间，这个时间是什么？测试用户需求，寻找产品定位！

４个月的时间内，一共发布了8个版本，其中每隔两周就有一个产品版本发布。从大量产品迭代周期来看，这是一个比较健康的节奏，不是很快，但也不慢。其中有7个版本是新增了一些功能。

在2.7.0版本之后，我们发现春雨医生的版本节奏变慢了，趋于稳定，更多的时候，可能在做市场运营和资源整合。

我们再更多地看一下春雨医生在这些版本中都实现了哪些功能。我们希望通过这些功能来还原春雨医生的产品历程。虽然我没有参与他们当时的产品设计和开发经过，但我今天依然可以看得很清楚。尤其可以看出，在V5.0的时候当时上线了几个核心功能，比如“私人医生”“预约就诊”“线下求助”等，这些看起来非常重要的功能其实不是在产品一开始就上线的。这是为什么呢？

为什么很多产品都找不到节奏，或者浪费了很多走回头路的时间呢？是否可以通过这样的版本复原，找出你的竞争对手或者潜在的竞争对手，来看看他们是怎么做的，是不是比和某“产品大牛”吃顿饭，找一些八卦来得好呢？

梳理完了版本功能之后，我们再试着归纳一些产品的发布节奏。V1.0-V2.0时隔5个月，V2.0-V3.0时隔10个月，V3.0-V4.0间隔了10个月，V4.0-V5.0间隔了6个月，这样的节奏看起来是比较长的版本更新节奏。但事实上，我们在当时的场景下理解，第一个版本到第二个版本的过程看起来是有些产品需求和想法要去实现的，这个过程应该是开发摸索过程，其中团队磨合、开发设计的时间都比较正常。而第三个版本以后，可能进入不断调整和面向用户测试不同功能的阶段了，所以这个阶段小版本多了，发布的功能也多了，在大型框架上暂时没有太多的时间更新。第四个版本也是一样，这两个大版本都坚持了接近1年。

所以，我们可以看出一些常规的规律。

1. 大型版本早期要更加扎实和简单，这样可以容纳不同的小版本失措和功能迭代，不断测试用户需求。
2. 大版本的更新不应该太频繁。如果太频繁，则小版本没法充分释放，用户需求也没法充分测试。而且，如果大版本更迭频繁，那一定是整体思路没有想清楚，不断在底层设计上“调头”。
3. 小版本要快速发布，不断测试用户需求，不应该对小版本功能的定位太过纠结，要知道，小版本的需求可以不断更迭，最快的一周就可以更新。这个时候，重要的是不断更新需求、排出优先级，控制节奏。

最后我们做一些总结，看看这些版本的迭代和节奏的控制过程，产生了什么重要的产品功能，哪些产品功能点带来了市场影响力。
其实，经过两年多的版本建设，春雨医生并没有创造性地“发明”很多功能。大部分做的事情都是“打地基”，少部分功能实现了“微创新”，所以如果你的想法有一堆创新点，那这个开发时间会拉得更长。

要知道，“打地基”的事情就要做好久。我们不是不喜欢创新和发明一些东西，而是产品的每一步，都是在前面的台阶上往前走。很多传统行业或者不专业的老板不深知这些道理，都是“拍脑袋”出想法，“拍大腿”定方向，“拍桌子”训产品经理。

不遵循产品规律的项目和负责人，也不会受到太大的挑战，无非就是多交一些“学费”，多浪费一些时间，比别人先“死去”而已，放心吧，不会出大事的。

选出你喜欢的3款作业，从App Store去还原他们的版本迭代信息。

根据我们的白箱分析方法，用版本还原的方法，去苹果应用商店，或者豌豆荚应用商店寻找3款产品，做一个分析。在这个过程中肯定会遇到问题，我相信你们一定可以自己解决，而且一定要自己解决。

因为，产品经理生来就是解决问题的！

本文选自《产品的视角：从热闹到门道》

未经书面授权，禁止转载，违者追究法律责任。