我的产品方法论
产品阶段区分

从0开始立项
已有完整产品，新需求开发
产品类型

C端：工具型、社交型、内容型、社区型（UGC）、电商类、预定类（酒店）
B端：各行业SaaS系统、ERP、WMS、PMS、DSP、OA、政务系统、企业建站、B2C、B2B
复合型
产品形态

纯线上产品：在划分行业的情况下是解决某个行业用户的效率或改造的问题，不划分行业的情况下是解决用户普遍的痛点、社交或效率问题
线上+线下：判断在该行业利用互联网产品实现的是提升效率，还是通过互联网创新改造商业模式
结构化思维的重要性

每个人做的产品不同，面对行业不同，接受的信息不同，会形成不一样的方法论，不能一概而全。所以不管是谁的方法论，对自己都不会完全适用，只有自己从0到1真正多次经历，才会有自己成熟的思考方式。

方法论说到底，其实是结构化思维，方法论不能适合所有人，也不能适合所有产品，但结构化思维可以。

C端B端，抑或纯线上还是线上+线下，这里的组合再搭配行业，会有各种各样的产品，没有哪种方法论是适合所有产品，特别是情况特殊的B端，以及线上+线下的产品。结构化思维就能提炼一些需要重点思考的问题，放到整个产品流程中，确保产品的正确方向。

我自己的结构化思维会贯穿整个产品流程，比如接到新需求的时候，我第一个想法是什么，接下来怎么验证，怎么做，怎么上线，都是一个个比较小的关键节点形成的结构。

我的结构化思维

定位

用户的真实面貌

场景设计

回到原点，是否满足了用户需求

竞品的战略是什么

开发具体的实现流程是怎样

产品方法

调研阶段
需求整理
竞品分析
开发阶段
一、调研阶段

产品定位是什么？

很多时候定位不是产品经理决定的，就算是立项的新项目，大多也是在原项目的基础上做的改造、升级或矩阵式发展。

所以，从0开始立项的产品经理，需要理解产品定位，并有机会参与制定。理解之后对后面的工作都有方向的指导作用。

在已有产品的基础上立项新需求的定位，则是要了解该需求在整个产品层面是什么地位，什么目的，以及整个产品层面的定位和战略是什么。知道大的方向，才能做好当前的需求。

市场情况如何？

首先从大的层面整体了解市场概况，从市场数据、用户存量、需求场景、用户感受、媒体分析及报道、竞品功能了解、国外产品参考、频次预估、收益预估的角度做整体了解

C端和B端，以及纯线上或线上+线下的区分在于B端和线上+线下的形式，场景体验方面做产品的人不太容易触达，但通过用户访谈和真实体验也是能完整体会到的。

了解用户

在定位和市场都准确把握后，对用户的画像也会逐渐清晰，但范围也非常大，描述出来可能就是20-30岁，白领上班族，年轻女性居多之类笼统的关键词。

需要用到侧写的方式，给用户做详细到行为习惯的关键词概况。

这个方法适合对用户心理把握极高的C端产品，不同产品功能和场景也需要把握不同的用户心理。而且这个方法难度很大，需具备一定行为心理学和认知经济学知识，和掌握大量数据后分析得出。

做不到这个程度的情况下，通过访谈、数据分析、评论反馈等途径了解用户心理。

B端产品不需要揣测用户心理，但需要通过体验用户工作场景的方式，了解用户在使用产品想要解决的问题。

二、需求整理

判断需求存在的意义、价值和真伪

基础概念信息的把握如果没做好，不能着急开始整理接到的需求，或者定义需求之前。

草纸手画、墨刀、sketch、keynote等工具都能实现需求原型制作，动手之前还是得根据基础信息判断需求的真伪，是否可以通过其他的创新方式从源头解决这个问题。

判断需求的真伪就必须基于对用户的了解，用户的背景、场景的因素、当下的动机，都会影响那一刻用户做的决定。

大多数时候，B端产品因为存在的技术债务或历史原因，不断的通过新需求来修修补补，解决不了真实问题，时间越长越难改。

基于场景设想需求的设计

确定需求存在后，怎么设计很自然的使用流程，必须基于场景来思考。给货车司机用的产品，那必须坐在开在高速公路上的货车上，在货车司机休息站吃饭的场景下来思考，才能做出准确做出自然的功能设计。

不然都是坐在办公室里人的臆想。无论做任何产品任何设计，基于场景的设计非常重要。

三、竞品分析

从0开始立项的产品如何做竞品分析？

从0搭建，必然是连产品的商业模式，运营框架都还没完全想清楚的阶段。这时候的竞品分析需要大而全，最终目的就是要从整个大的方面参考别人怎么做，是否能赚钱。

这时候的竞品分析可以从几个点确定分析模型：商业模式、成本及收益预估、运营模式、用户规模、市场概况、产品情况。

已有产品新需求的项目如何做竞品分析？

弄清楚想从竞品那分析出什么，新需求是什么目的？一个发私信的功能满足用户交流的欲望？一个用户数据CRM管理后台给运营做详细分析？整体网站架构修改，以满足SEO需求？

无论是什么需求，竞品分析无非就是参考功能做法、营销方式、运营手段，目的是为了参考和减少试错率。

这时候的分析模型就需要从想了解什么内容的角度去确定，从而得到想要的东西。

四、开发阶段

交付流程的确定

每个团队都有不一样的交付方式，工具也用的不同，这点因人而异。

工作流的确认主要是为了团队内部形成快速的沟通效率，保持和技术团队的持续沟通更为重要，毕竟所有交付的东西，都是为了给他们看懂，而不是为了形式而形式。

反复查看需求

很多人在交付后就懒得再管，就等测试阶段在回来看。没有人是毫无差错的，只有经验越丰富出错越少，所以交付之后还需要经常查看需求，和开发做必要的沟通。因为偶尔会出现某个需求定义，在开发做逻辑的时候发现这个方向好像行不通，产品经理就会发现好像确实是这样，最终只好不做或改需求，在开发那的威信荡然无存。