本文作者在本文阐述了自己从事产品经理以来，三年的工作经验。在自我总结的同时，期待可以提高自己。

目录：

一、产品经理的素养

1. 内建的能力

• 熟悉你的领域（垂直生态和行业动态）
• 业务素养

2. 对外协同

• 沟通的艺术
• 向团队交付你的价值

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

• 技术侧
• 运营侧
• 用户侧

三、我们究竟在做什么？

一、产品经理的素养

关于产品该懂什么，或者说应该具有怎样的能力，这是个见仁见智的话题。

譬如说，C端产品人，大多熟悉用户思维，有深度的关于用户体验的思考，甚至需要一定的“APP深度使用成瘾”的“症状”。很多B端产品人，可能更多关注业务解耦，处理事务的逻辑关系和层次结构。

大家常常自身和对外的角度，去剖析事务的两面性。

我是一名偏向于C端的产品人，从0-1也完成了多款鲜活的APP，从其中不乏某些垂直领域的黑马。

如果让我来谈谈产品人的素养：

1. 内建能力

1.1 熟悉你的领域（垂直生态和行业动态）

1）垂直生态

垂直生态是指你策划的项目所处的行业。

例如，你负责公司“股票”类软件的设计，不管是“导流获客”用户也好，还是“工具类存量养护”用户也罢，都是在互金行业的线上“证券”这个领域；类似的竞品例如“大智慧”“雪球”“同花顺”等。

那么此处的垂直生态就是由多家头部（50万 DAU）和其他小众产品（5千~5万 DAU）组成的生态圈。

基于大家生活在同一个生态圈中，大家尽管玩法不同，目的也不一样，但是挖掘的用户基本是同一批人。作为产品人做竞品调研或市场分析的时候，着重研究这个生态圈的“空洞之处”。

当没有把握基于竞品成熟的业务模式去创新时，往往最成熟的办法就是“钻空子”。能在大的成熟的生态圈中寻找到另一份”养料“，你的产品才能生根发芽。

图1：某行业调研报告截图

2）行业动态

行业动态是一个泛泛而谈的概念，小到头部公司的资源调整（可能会波及整个生态引发恐慌），大到国家监管层面政策导向，都还属于行业动态这个范畴。作为一个产品人，理应运筹帷幄有关行业的最新动态，定期做好资料收集

1.2 业务素养

大多产品人工作重心都放在“设计”上，每个产品经理都有自己的一套设计思路，在BAT等大厂，大家熟称为“中观的套路”；并在此基础上，深入研究“微观思想（人性）”。

譬如，你在设计一款“社交类”APP，从用户点击应用图标开始，你就应该能详尽预料到该用户的后续点击操作（当然，可能用户的操作是无序的，甚至是没有任何的逻辑）。

这里有这样一套方法论：模型抽象出来是“一个用户”，去参观“游乐场”，当没有“引导员”陪伴的时候，他怎样能充分的利用“门票”（时间和金钱），游览整个园区？每个用户从进入园区开始，基于不同的兴趣或产品感官，用户会选择不同的浏览方式。

反馈到APP中来看，还是以股票类软件为例：

每个用户进入首页（或其他锚定页面）之后，有一部分用户可能去“添加自选股”，而有的用户可能去查看“行情信息”，甚至还有用户着力去寻找行业资讯为下一次投资做舆情基本面分析。

那么，作为产品，我们考虑的重点是通过哪些手段来分析这些用户路径，根据这些信息（可能是数据报表，可能是用户体验地图）寻找到什么样的逻辑和层次关系，来优化我们产品的用户体验，提高这款产品对于多数用户的用户价值。

此外，更多的产品经理可能负责从0~1搭建一个项目，当从设计开始就要考虑到产品的定位，页面风格，核心优势……跟进应用市场上架，SEO、ASO优化等问题，还要考虑短信签名、域名网址登记备案等工作。

图2：读梁宁《产品思维》总结

2. 对外协同

2.1 沟通的艺术

可能越是大厂的同学，对沟通这个词颇有微言；往往跟开发、运营、市场等部门的小伙伴协同办公的时候，伴随着沟通更多的“甩锅”“效率”“留痕”等字眼。

网上关于“沟通”效率的书很多，当我从产品助理一路走来，感悟最多的是“协同”这个词。

首先，大家能共信的是“沟通是为了让别人帮你解决问题”，怎么让别人“乐意”为你服务呢？

我觉得销售行业有一种模式特别有意思，销售员在推销一款产品之前，往往不会简明了当地去说服别人。

你应该怎样做，或者我觉得你应该怎么做，在发起请求之前，他们会跟客户聊有关这个产品的价值，你“拥有这款产品之后的美好”和“你不能拥有这款产品的严重结果”，这招对于犹豫不决的用户有奇效。

类比到我们产品人的沟通中来，当我们同开发的同学去提“要加个小需求”时，我们就可以跟他去聊“但我们上了这个功能/页面之后，这款APP将多美好，能给用户提供多少价值。同理，当跟UI同学去提修改个页面样式的时候，应该去聊“当这个刷新按钮放左下角的时候，用户用起来得有多爽啊”。

其实沟通处理问题变得娴熟了之后，大家能体悟到的是，“沟通”就是让别人帮你解决问题，你需要通过“艺术的手法（手段）”让别人乐意帮你解决，并且大家都能获得好处，这样才能达到团队效率的最大化（即很多团队中OKP目标的逐步取得）。

图3：关于“沟通”

2.2 向团队交付你的价值

很多产品人太注重怎么给用户交付价值，往往忽略了团队的建设（我是一个例子）。

这里把我抬出来给大家做剖析。

我曾在一个月内做了4个版本的“开通会员页（支付页面）”，面对我这种“频率不合理”而又“貌似很专业”的需求邮件，UI设计师很忧桑。

那一个月，我请了那个哥们吃了两顿火锅才让他消消气。很巧的是，有次我跟他吃饭，他跟我说了一句让我醍醐灌顶的话“我不怕忙，我怕瞎忙”。

大家应该能预料到我会怎么做，我拿出改版后的“会员支付率”对比改版之前的数据，并跟他反馈每一次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能存活在庞大的应用市场里”。

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

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

你的回答是什么？

本文由 @夏日 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议