你不必学会写代码或者读懂代码，不必关心程序逻辑细节。你要做到的是，能够听懂并理解大家在说什么，边界在哪里。

一、基础概念及其之间的联系

了解任何一个学科的新知识，首先需要把基础概念搞清楚；然后尝试把它们关联起来，你就建立了相关领域一个基础的知识结构，后续再补充的知识，才有可能在这个结构上生长开来。

1. 互联网应用的简化模型

端与后台

目前我们提供的产品，无论最终的产品形态是网站还是APP，其基本构成是类似的。都有服务端（后端，后台），服务器主要负责数据存储，增加，删除，修改与查询。它是7X24小时随时待命，等着响应来自用户端的请求。

用户端，就是用户访问我们服务的界面，常见的有三种。

可以是APP(有些公司叫客户端)，常见是就苹果和安卓，当然Windows Phone, Blackberry也都是类似的：

Web端，通常指网页；

Wap端（通常指手机浏览器访问）。

其实在PC互联网时代，还有Winform端，常见的如QQ，就是运行在PC电脑桌面上的程序，这种产品形态在移动互联网时代相对少了，产品经理不需要特别关注，除非你就是PC客户端产品经理。

2. 信息流动

理解典型的信息流动非常关键。信息流动，就是指用户使用我们的产品时，在技术视角下，发生了什么。以使用今日头条App为例，我们点开头条打开App，这时候发生了什么呢

一次典型的Pull(拉) 请求

我们把端向服务器请求过程，称为“Pull”拉数据。服务器根据我们的请求，从数据库里把数据查询出来，预处理，排序等，返回给端，端本地把这些数据，按自己的模板呈现出来，就完成了一次典型的数据请求——展现过程。

上述前后端协作模式，在技术上我们称之为C/S（Client/Server）模式；当下App基本都是这种数据请求模式，与C/S相对的是B/S（Browser/Server）结构

B/S结构数据请求

B/S结构，通俗的说：就是用户不需要安装应用，直接通过浏览器来访问我们的服务。所以，服务端查询数据后，会先用模板把数据填充好，再返回给浏览器来呈现。从信息流动的角度，就这一点区别。

3. 端的能力不同

App应用，或者我们称之为“原生应用”，使用C/S结构访问与呈现数据。由于是原生应用，它能够访问系统的能力是很强的。重力感应，地理位置，光线亮度等典型的手机能力。

“按手机壳变色需求”的不可实现性就在于：连手机操作系统本身都无法知晓自己有没有附着手机壳，更不用说判断其颜色。

如果不考虑需求合理性，从端的能力来看，需求可以这么提：“按环境光线的亮度，改变屏幕的亮度”。这是可以做到的，而且很多应用已经具备，比如“夜间模式”。像爱奇艺的播放界面，你关灯后，它会把屏幕亮度降下来，避免黑暗里观看太刺眼，在你开灯之后，它会自动恢复正常亮度。

浏览器，无论是手机浏览器，还是PC浏览器，前端使用的脚本是Javascript，对操作系统的访问能力很受限。只能得到环境的IP，浏览器版本，操作系统版本等。了解了这个层面，前面提过的“Web页/Wap页灰度上线”的需求，你就知道，可以通过IP(用户所在城市)进行灰度，就是比如，只有是北京（IP城市在北京）的用户访问时，看到的才是改版后的产品界面。

二、典型案例

产品经理中需要理解自身产品典型的信息流向，把技术问题的边界就框定了，下面我们举几个典型的案例加以说明。

1. 信息流产品

信息流产品，大家最熟悉的如今日头条。可以根据用户喜好，把用户可能感兴趣的内容进行自动推荐。作为产品经理，逻辑与算法，你只需要把握边界，细节都当成黑箱即可

推荐系统简化模型

作为一个推荐系统，肯定有一个技术上相当复杂的架构；但在产品经理眼里，你就抽象成一个”推荐模型“就好。内容管理系统是运营干预内容推荐的一个平台，比如一些固定的运营位，对一些内容的修改，删除等。

对于前端产品经理而言，了解用户一个请求，在后台流经了这几个系统，且大致发生了什么就可以了（如果是AI产品经理，专门负责算法优化的另当别论，这种当然经理大部分是科班出身，不在本文探讨之列）。

比如请求拉取信息流，典型的流程会是推荐模型给出算法建议的N条内容，然后内容管理系统给出几几个固定运营位，结合一些黑白名单，对内容权重进行适当的人工干预，形成最终的内容列表，返回给端。

理解了这个流程，你在提一些偏后台的需求，就会有的放矢。常见的需求比如在”feed流的第三条加一个广告位“，那么这时候，你知道这个需要应该提给”内容管理系统“，同时前端在返回的数据里，针对你这个固定广告位，作特别的渲染就可以了。