冲浪网站优化 / Products Center

移动互联网产品经理和互联网产品经理，基本的技能要求并没有本质的区别。但是因为无线自有的一些特点对以下几部分是要额外关注的（注意是额外关注，即相对互联网产品经理要更多出的一部分）：
1.对各种移动平台（iOS,android ，WP）了解充分
（1）所谓的了解，最基本的，是指需要对系统的边界、极限很清楚，如iOS上哪些特性是系统自带的，工程师几乎无需开发就能实现的（如定位）；哪些是需要工程师做底层开始进行开发的，哪些是不可能实现的，哪些是越狱后可以支持的（如电话拦截接听）。
（2）上面是基本要求，更进一步的，最好对系统整体架构有所认识，如iOS的架构中3d引擎使用的是什么，有什么优劣？
这里的理解其实并不需要产品经理深入底层，也不需要阅读代码，而是只从系统构架和逻辑角度能做到心中有数，尤其是对性能边界很清楚，如，android系统的浏览器内核是怎样的？有什么操蛋的地方。

2.对产品质量的控制力较web更高
无线产品中除基于WAP、Html5的外，只要是以APP形式出现的，都是用户以软件包的形式下载并安装的。这意味着，无线产品不像互联网产品，可以出了问题随时可以修正。一个软件包一旦发布，就意味着覆水难收——你显然不能指望通过升级版去纠正上一版的重大错误，因为重大错误足以让用户不再浪费时间再去更新。因此，产品经理需要对质量高度重视，包括：
（1）发布前反复测试，确保没有质量纰漏——说直接点，无线产品经理对测试方法、流程要有较web深入得多的了解。原则上，一个无法像测试一样去发现复杂bug原因的产品经理，不能成为一个特别优秀的无线产品经理。
（2）熟悉各种通过产品设计提前留好挽救冗余（如push功能，自动乃至强制升级功能）。
（3）对发布后，不幸出现的问题，要能及时的响应和解决，这里的即时主要不是指速度上，而是指策略上，因为那个时候你往往要面对很对“艰难的决定”，如：
a.是否要马上发布一个bugfix版？
b.还是等待下一个常规版本（可能是6周之后）再解决？
c.是否该功能模块可以在服务端做补救？
d.是否可以终止此模块服务但保证其他的继续可用且向用户做出解释？

3.对项目的控制力要强于web
由于上面提要的质量需要更高要求，再加上客户端开发无法做到无限拆分功能模块，周期一般长于web项目。因此，产品经理对项目的控制力将会很受考验，如何有效的在前期规避项目风险，较好的在整个项目中均摊项目压力，以及当项目不得不delay时，如何做出决策。这都将很考验一个无线产品经理。相比web上delay1个月算大“事故”，客户端delay2个月的状态在十分成熟的团队中都会偶有发生。

4.对“小产品”的管理和产品线的构建要有很好的意识
（1）无线产品经理有一个很幸福的地方，产品天然不能做得太大——有经验的PM一定很能理解这话的意思：）。但，如何找到合适的切入点，以简单、小巧为“基本面”，同时又能满足核心用户的重要需求？这是难的课题。
（2）由于产品小，对应的情况是，往往会出现产品线会多的情况。一个一线的、资深的无线产品经理同时cover3~5个完整的产品线甚至更多，并不是什么很奇异的事（但你让做平台型web站点的产品经理试试看？）。产品线多了之后，产品线之间如何配合，如何做到互相支撑、借力而不是彼此打架，这是非常难的课题。

5.资源控制、节奏控制要很极强，要能让项目和团队既能多线运作，又有重音、有节奏。
项目周期长，产品线多，平台多。这是一个倍乘关系，我们有时会看到一个无线产品经理做2个产品，但是4个系统平台，实际上他是占用了4*2=8 个开发项目资源！这在任何公司都是很恐怖的。无线产品经理必须能即时、敏锐的做好资源控制，节奏设定，在砍掉不需要的项目和产品的同时，为整个研发部建立节奏感。
多久发布一个版？ 多个产品线产品、UED/UI、 前端开发、后端开发、测试如何穿插协调？
项目有冲突怎么预防、实际发生怎么解决？
但更高的要求是，这些问题都不存在，产品经理能做到在团队中建立起节奏，让所有人能像跳竹竿舞一样，灵动、高效、发自惯性和直觉，而又能不被竹竿夹着腿。
实际上，能为无线研发团队建立好开发节奏的无线产品经理在整个行业都是很珍贵和难得的。