ToB网络安全产品经理技能树(含部分方法论)

本文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的关系,事情的轻重缓急需要理清楚。不能确认是否需要支撑的,及时和上级联系。分清楚工作的主次。主要工作是产品规划设计,次要工作是支撑项目。(当然上级如果拎不清,一直让你做项目支撑,那就乘早跑路)
  • 其他推荐