本文4000字，内容比较枯燥。阅读完毕需要10分钟左右。
- 说明
- 关于我 我在初创安全公司做过产品负责人，在千人规模的安全公司以及上市安全公司做过资深产品经理。大中小三种类型的公司都干过，结合三种类型的公司特性和基因，总结了一些具有共同点的经验和技能要求。供想要转行以及新入行的小伙伴参考。
- 关于方法论 对外输出观点和方法论，也是验证自己观点和方法论的过程。所以也就有了这篇文章。
- 产品规划
- 产品目标确立
确定产品目标与策略。产品目标是产品每个版本要达到的目标点，目标点可以有多个。产品策略是为了达成目标所需要执行的策略。策略后面还会有具体的动作。这里举个例子：产品目标：增强安全事件聚合能力，提升安全运营效率产品策略1：默认按照名称聚合重复的安全事件产品策略2：针对聚合后的事件提升批量处置能力产品策略3：梳理用户关注的威胁事件场景，以场景进行聚合策略本身是目标拆解之后的产物。 - 产品RoadMap确立 在确立RoadMap之前，需要先确认每个主线版本包含哪些产品目标与策略，随后才能基于资源和时间排期进行RoadMap的确立。没有什么产品规划是凭空产生的，它一定是基于产品目标与策略的。
- 原始需求的管理 在很多项目型安全公司，原始需求就是产品目标。甚至产品目标就是消化掉市场上各种琐碎的原始需求。如果是纯销售型公司，渠道和销售能力极强。产品存在的价值就是消化用户的原始需求的话，这种模式也无伤大雅。但是如果，销售能力没有强到离谱。产品最终需要靠产品能力取胜的话，这种模式可能会造成产品能力的深度不够。原始需求的坑在于提出方千千万，场景千千万，动机千千万，诸多变量可能导致产品需求根本没有统一性。这就造成了产品边际效应过高的问题，做的都是一次性生意。需求跨用户和场景不能复用。边际成本一直降不下来。原始需求的梳理重点在于以下几点：
通用性：是不是一次性生意，需求做完其他用户根本用不上
按照产品能力分类：原始需求千千万，哪些需求是哪些模块能力范畴下的进行归类
投入产出比：实现需求的代价和能获取到的市场收益是否成正比
当然以上的几个点可能还远远不够。我在这里想要表达的核心就是，不要一股脑的把原始需求全部变现到产品中，一定要做好判断。这里还隐含了一个决定性因素——产品经理是否能与行销团队在一个频道。假设行销团队为了业绩或者转化率一股脑的把需求全部抛过来，每个用户都要满足，每个项目都要冲一冲，那么这个团队也很难做出好产品。
- 先有规划还是先有需求？ 这是一个灵魂拷问和哲学问题。通常来讲产品规划需要先有大的产品规划-策略-动作，而需求只是动作的一部分。 比如“需要实现单点登录”，这是一个非常小的需求，它可能是某个策略的执行动作。比如“增加与第三方设备的联动”，最终对应的目标可能是“在异构方案场景下形成安全运营闭环” 没有人能够凭空对产品进行规划，目标与策略也不是拍脑袋能能够定出来的。可参考以下几点因素：原始需求：原始需求管理的最大的作用在于，你可以根据已经梳理好的原始需求，提炼出当前的产品目标。比如可将用户反馈较多的需求进行场景化分类，从而把类似场景的需求在一个目标中归纳。这里再举个例子
“我需要修改安全运营平台的系统评分，每次领导来参观都是低分很难看”
“希望将外部攻击不计入系统评分中”
以上两个是原始需求，那么怎么找出同场景的原始需求呢。首先我们需要进行需求分析，为什么用户想要修改评分。是当前的评分机制不准确？还是威胁事件处置效率过低？或者是爆出的威胁事件大多是误报，用户觉得不需要处置？这些场景可以自己去推导，也可以做用户访谈。这样我们就可以将以下的原始需求关联到这个改分的场景中来了。“希望对威胁事件提供批量处置的功能”“希望减少系统的误报，只提供我关注的威胁事件类型”经过归类、分析、提炼。我们就可以将很多琐碎没有关联的原始需求，合并到一个目标中。可能这个目标就是“提升安全运营的效率”。看似一个修改评分的需求，最终可以提炼到提升安全运营效率这个目标点上。这就是从原始需求提炼目标的过程。 - 竞品分析竞品分析是一种系统性从产品角度反编译友商产品的过程，从中至少可以提炼出友商的产品目标与策略。以及每个功能模块围绕的场景点，甚至结合市场信息可以反推出用户的市场策略。竞品分析我打算单独开一篇文章来写细节。从方法论总体框架来看，竞品分析也是非常必要的一环。甚至0经验起步的产品经理或者从0到1的产品，竞品分析是第一环。所以，产品目标与策略的有一部分来自于竞品分析。尤其是在落后竞品的情况下，你遇到的很多问题竞品在很早就遇到了，并且也给出了答案。我们只需要从产品中找到答案即可。
- 报告解读
安全行业基本上都绕不开Gartner。作为安全行业最权威和全面的咨询机构，他们对外发布了无数的市场分析报告和产品分析报告。其中最有名的应该是魔力象限了。针对Gartner等类似的咨询机构的报告解读，可以了解最新的市场趋势和产品动向。假设我们不满足于做一个跟友商不相上下的产品，做报告解读也是提升竞争力，以及做到市场领先的因素之一。
从市场报告中，至少可以提炼出国外友商早已总结好的很多理念和观点。以及他们的针对类似问题的解法。
- 产品设计
- 产品PRD交付物标准如果说产品是产品经理与世界对话的方式，那么产品PRD是产品经理与整个项目研发团队对话的方式。这里把产品原型和交互说明也认为是PRD的一部分。我理解的好的PRD至少要包含以下的部分：1）更新记录
2）产品目标与策略3）需求分析包含需求分析、竞品分析、用户场景、原始需求反馈、设计折衷（基于各方观点、意见、限制条件折中的过程性总结）
4）需求LIST
5）原型及交互说明6）后台逻辑说明至于原型要不要高保真，交互说明到什么颗粒度、写在Axure原型上还是用Word写。这些都是与团队磨合后不断优化的结果。基于研发设计怎么方便怎么来的核心思想。 - 交互准则仅限安全分析类平台产品1）先给结论再给原始数据（这里的结论可以是统计结果或者基于各种算法得出的结论）2）能够关联查询的信息可以直接查询好展示在主键的鼠标浮窗上3）能够方便的在多个页面之间跳转查看4）能弹窗展示的就不要跳转新页面5）意义不明的图标不如直接用文字6）异常操作结果给出答疑提示
- 市场行销
- 项目支撑通常来讲，项目支撑工作可能包含如下，分工越细致的公司需要做的越少：1）招标参数评估2）投标技术方案编写3）现场方案讲解
4）项目总结报告5）专利编写
6）期刊编写
7）投标演示视频录制与剪辑8）大项目的DEMO环境设计与视频录制9）甲方产品规范编写制定10）给甲方领导写会议总结 针对以上种种支撑工作，在部分机制不健全的安全公司，可能有一部分甚至全部都是产品经理的工作内容。破解之道就是，多看，多抄，多写以及自信。要坚信，在自己的领域没有人能比你懂。假如你是新来的根本就不懂，也得装作很懂。 针对方案编写以及项目总结等文字性支撑工作。可以使用历史材料进行参考，确立内容框架。其次再基于历史材料以及网上搜索到的素材进行融合拼凑即可。 针对视频demo讲解类，一定要站在视频观看者的立场。把技术规范中要求DEMO要提供的功能点，一字一句抠字眼级别的表达出来。即使功能上是A，在表述时也要按照B表述。对于评审者来说，与技术规范书的匹配程度才是第一要素，匹配程度就取决于文案和讲述。至于专利与期刊，更多还是素材收集和包装的事情。一般都有专门的机构负责，产品经理从中起到的还是素材收集的作用。 - 产品支撑1）产品主打PPT2）产品解决方案
3）产品白皮书4）产品使用手册5）产品部署手册6）产品招标参数
7）产品需求说明书
8）产品技术设计
9）销售指南
10）产品定价11）产品硬件选型（纯软件不涉及） 针对以上产品类支撑，大多数安全公司或多或少会涉及到。其中涉及到产品介绍和解决方案等文档类支撑的。一定要结合前面提到的产品目标与战略。前面梳理到的目标和策略，在市场宣传阶段就是产品的亮点和特色以及主要功能点。其次是多参考友商的材料。 针对销售和市场类的文案，重点需要摸清楚销售和售前关注的点是什么。对于销售来讲，他们更关注你的亮点以及你有友商没有的能力。针对售前，他更关注产品能够从哪些场景解决哪些问题。 在这里，我需要表达一个观点。并不存在“控标参数”这个概念。严格来讲，“控标”是一个伪概念。本质上企业之间的竞争打的只是时间差和效率差。这个世界根本不存在你有我无的产品能力，最终只是时间和效率的问题。那么为什么还会有“控标”概念产生呢，因为部分项目型友商针对招标，特地设计了一些非常冷门生僻的参数，用户根本用不到的功能。比如一些冷门的协议，一些特别奇葩只有他们能看懂的概念。对于用户来讲，保留这些生僻参数是需要承受别人的质疑和举报的。所以能留下所谓“控标”参数的项目，本质上也是销售实力非常强势的预兆。假设销售实力不强，你安排进去的生僻参数分分钟会被销售实力强的公司删除殆尽。所以提升产品整体实力，才是走正路。 - 团队协作
- 与研发人员携协作本着目标一致的原则，与研发同学合作的最终目的是把产品做好。当然在过程中，产品经理需要起到团队的协调与润滑作用。比如测试与开发的协调，前端开发与UE的协调。网上有很多产品经理与研发的段子我是不能理解的。与研发搞好关系应该是产品经理的必备技能之一，这里就不再赘述了。想要了解的，可百度搜索我2016年写的文章《产品经理如何正确而优雅的强势》。产品经理需要建立自己的影响力，不断做出正确的决策，带领团队尝到甜头，才能可以更好的推进产品落地。
- 与行销人员的协作对于行销人员来讲，他们是产品线和销售售前之间的缓冲地带。与他们的合作主要是能够支撑他们的需求。比如他们搞不定的参数评估，需求的规划排期之类的。
- 与领导的协作日常工作时要做到事事有回响，事项有计划。delay之前提前预警。不能决策的事情，不要瞎决策。汇报时挑重点，列数据。不要事无巨细什么都讲，对于领导来讲。产品的发展，决策的依据，你个人的规划才是他关注的。适当的时候，可以讲讲苦劳，毕竟会哭的孩子有奶吃。
- 与销售售前的协作与销售售前的协作，需要自己把握好度。毕竟是你一对N的关系，事情的轻重缓急需要理清楚。不能确认是否需要支撑的，及时和上级联系。分清楚工作的主次。主要工作是产品规划设计，次要工作是支撑项目。（当然上级如果拎不清，一直让你做项目支撑，那就乘早跑路）
- 其他推荐