3年产品，这些你知道吗？(2)

大家应该能预料到我会怎么做，我拿出改版后的“会员支付率”对比改版之前的数据，并跟他反馈每一次UI的调整，对于用户有着怎样的体验改观，对公司有着怎样的营收进步。后来，发展到他竟然主动替我设计页面，并主动和我沟通在他的设计库里面，还有哪些设计能改善运营的数据。

产品人作为团队的核心，应当主动维护大家的工作热情和效率（1+1>2）。

二、协同能力（从不同视角看产品经理所需的能力）

1. 技术侧

我是技术出身转的产品，对此深有体会。

开发的兄弟们可能更多把精力是放在怎样实现这个功能，并在项目经理的排期中定时定量完成，缺少对产品整理的思考。

例如，首页加载较缓慢，能不能考虑本地缓存以优化数据链路？本次需求共有10个页面，哪些需要调用native开发，哪些需要H5开发以便后期灵活运营？ 运营反馈后台拉大盘报表加载太缓慢，能不能考虑协同DBA、数据部门优化Sql逻辑？

成本也是需要产品着重考虑的点，在开发之前，产品大都会召开需求评审会。此时，着重考虑哪些是核心需求需要严格实现，哪些只是“添头”可有可无（可以参考KANO模型去规划），并和项目经理确认好优先级和排期。有条件的话可以参与到项目中来，细化到H5页面是用Vue还是Angular框架。

一些中小型企业的产品经理往往肩负着更重的责任。例如，产品可能会被委任“上云服务”，老板要求所有业务实现线上部署……那么，此时产品经理就要考虑相关业务迁徙工作。此时，线上Redis、OSS服务等概念不需要精通，只需明白它们的含义，以便参与到这些事情中去。

图4：某项目阿里云部署架构（产品参与设计）

2. 运营侧

运营部门可以说是产品的“保姆”，只有APP的内容饱满，富有吸引力才能吸引增量、养护曾量用户。

产品经理更多服务的是来自运营部门的需求，在功能交付到运营人员的阶段，我们应该及时跟进，协助运营人员提高KPI，这里谈谈两个重要的点。

2.1 数据赋能

关于数据赋能的优秀文章太多，本人拙见的关键点是数据的分析和研判，落地到运营侧。

数据分析研判的目的，是找出批量数据之间的逻辑关系和层次结构，以验证数据对策略的支撑。

举个例子：

某位运营人员当日在公众号或APP进行了15条推送，发现DAU并没有新增，老用户激活数占比也没有提高。此时“燕子”开始分析推送数据，并整理成推送时刻表，开始验证不同时刻推送的点击率跟推送时间的关系。后来发现只有（a~b）此时间段推送的触达频率很高，于是第二天她开始调整推送时间。

图5：运营人员维护-推送时刻表

拉取之前3天或者7天的运营数据，发现通过多次策略的调整，DAU峰值和谷值存在较大落差。此时应该协助他分析产生峰值的原因，并持续验证该策略是否能复用；分析谷值产生的原因，从而规避该错误的策略（此时要注意一点，策略的优劣能通过数据得以体现，但数据并不能完全代表该条策略的对错）。

再例如：

某位内容运营负责APP内容产出，发现产出的文章有几篇文章点击量很突出，此时他开始分析是否是文章标题吸引了用户？还是文章内容方向比较有吸引力？还是这几篇文章发布的时间契合APP的日活高峰期？这些假设通过验证，能节省很多运营成本，从而提高效益。

图6：新增留存率-策略 数据监测表

Tips：数据分析的手段有很多，建议产品经理在设计产品时做好数据埋点（最好是全埋点树）。

2.2 迭代（或新增需求）

从运营角度来说，迭代意味着运营人员有了更好的想法去运营产品。此时，产品应该同运营人员重点研究需求可行性，本次需求迭代解决了什么问题？在现有基础上不开发新功能能不能解决这个问题？各个需求的优先级是什么？

当确认好只有通过迭代才能解决问题后，我们要规划好迭代的周期和迭代的方向，并做好需求排期表。

3. 用户侧

我能得到什么或者说这款产品给我解决了什么问题，每个用户在接触一款新的APP，能吸引他留下来的时间可能只有几秒钟。相信大多产品人，也是秉承为用户提供实际价值为导向，去做设计迭代的。

为用户解决问题，需要APP有良好的感官，尽可能简单的操作，和稳定可靠的功能。此时产品经理应该放弃从管理员视角去看待和设计产品，从一个普通用户的角度，体会这款产品的实际意义。

此外在APP上，我建议保留与用户沟通的渠道，能让用户及时获得意见反馈。可能一个小小的建议，能减少团队庞大的试错成本

三、我们究竟在做什么？

当我是产品助理的时候，我的回答是“写需求文档，偶尔创新一下，让APP能存活在庞大的应用市场里”。

当我是初级产品经理的时候，我的回答是“做好一个产品，让别人用的爽”。

现在我是中级产品经理，我的回答是“给别人提供一种确定性，我的产品是你可靠的依赖”。

你的回答是什么？

本文素材来自互联网

（编辑：ASP站长网）