转载声明：文章来源https://zhuanlan.zhihu.com/p/116902191

1.产品立项

产品在立项前需要评估该项目是否有价值、能否带来收益、投入产出比如何等等。

1) 项目价值挖掘

各个行业在运行的过程中总会存在一些问题，各类人群在生活中总会存在不满意的地方。当我们发现了这些问题、不满意，并且有办法可以解决他们，也就是找到了项目的机会。

也就是说，一个项目要有价值，它必须得针对某一人群，在某些特定场景下，可以解决某些问题。

2) 项目收益评估

在确定项目有价值后，不表示这件事情就是值得做的。还要看一下该项目的市场规模有多大、市场环境是否已经成熟、竞争对手给我们留的空间有多大、公司是否具备研发实力、投入产出比如何等等。

市场规模可以根据目标用户特征，大致划定范围。目标用户的规模也跟公司可行的推广方案有关，有些情况可能潜在的目标用户很多，但触达成本很高


市场环境是否成熟主要是看行业切入点的上下游是否支持新业态，或者用户的行为习惯到达改变时机；比如沉浸式家庭教育系统得在智能音箱、智能投影等智能家居硬件成熟后才有可能落地。

我们在找到一个需求点，准备想做这件事情的时候，肯定也有很多人跟我们想到的一样。往往一些点子如果只有一个人想到很有可能是不可行的。

所以在立项之前可以先去找找竞品（一般针对同一目标用户，解决同一问题的称为竞品）。看看这个领域竞争对手已经做到什么程度，已经占领了多少的目标用户，剩余给我们的市场空间有多大。如果有足够的空间，这件事就可做，可以在竞品的基础上对产品进行改良，挖掘自身优势

3) 项目分步计划

项目分期计划首先需要明确行业现状、最终产品目标。考虑已有研发与市场资源，分步制定可行目标，使现状向目标靠近。

一些好的产品规划往往是一环扣一环的，前期的产品目标完成后，会为后面的方案创造可行性条件。

比如数据类toB产品，往往是先做能满足用户基本需求的工具型产品，等产品在行业中应用达到一定程度后，会积累常用的场景模板以及行业指标知识库，这个时候我们的产品就不仅只是工具，还有内容，做为工具也可以实现整个流程的智能化

2.产品定位

产品定位是指明确该产品的标用户是谁、能解决他们什么问题、在什么场景中使用。（在产品立项的时候就应该明确）

产品定位是否明确至关重要，如果产品在定位未明确就急着做功能规划，那是本末倒置。产品设计时会失去方向，不知道哪些功能是重要的、哪些是没用的。做好也无法在实际场景中落地使用，甚至产品都不知道该推销给谁。

1) 目标用户明确

Ø 很多时候目标用户不是简单的年龄、性别、职业等单一人群属性可以描绘清楚的。我们需要采用多维属性对人群进行深入刻画。但无论如何目标用户必须是现实组织中切实存在的某一人群，而不是通过感念抽象出来的。

比如敏捷BI产品的目标用户可以初步定义为有数据分析需求的业务人员。但这些业务人员具体指的是哪类企业或单位中的哪些职位人员呢？我们需要将它具体落地到比如“xx类别电商平台的运营人员”、“房企车企的市场决策人员”、“xx政府规划部门的xx级别的领导”等等具体的人物描述。这样才能够预估准确的市场规模，做产品推广时也更有针对性，产品设计时功能也会更加清晰

Ø 同一产品的目标用户必须在对功能的需求上有高度的一致性，如果能保证这点，目标用户越广泛产品的价值越大。

比如‘’英语趣配音“，一款动画或英文歌曲配音软件。它的目标用户可以是有学英语口语需求的儿童；也可以是有学英文歌曲需求的学生；或者是需要提高日常语言表达能力及个人气质塑造的职场人士；当然也有需要提高台词功底的影视剧演员。尽管这些用户的人群属性不一致，看似不同的群体，但它们在配音练习上的功能需求是一致的。可以做为同一产品的目标用户群体。

反之，如果将有不同功能需求的人群定义为同一产品的目标用户，那产品的定位就会凌乱。因为如果想将一种功能设计的满足多样需求，必定会造成哪种需求都不能得到很好的满足。

2) 场景与问题明确

Ø 要想明确进行产品定位，必须深入他们的使用场景以及具体能解决的问题。

比如有款叫“数据识别”的产品，可以对未知数据库的数据质量、业务属性、数据更新情况进行探查。在立项的时候要明确具体什么角色用户，在什么情况下才会有对目标数据库进行探查的需求。

可以初步设定数据仓库开发人员在做ETL开发前需要对源数据库的数据有初步的了解，以帮助他后续ETL开发工作更为顺利的开展。基于这个目的可以去深度挖掘目标用户在这个情景下可能会碰到的问题点是什么，产品需要如何做产能解决问题点。这样才能有针对的做产品设计。

3.产品规划

产品规划包括子产品功能划分、平台选型、版本迭代规划等方面。

1) 子产品功能划分

往往一个项目有多个用户角色，不同的用户角色对应不同的操作功能。产品设计首先要做的是将功能根据不同的角色分配清楚，切忌不同角色下的功能混为一谈。

一般产品会根据不同角色来划分子产品。角色之间如果有比较多共用的功能，不同的角色功能可以做在同一平台（子产品）上，通过角色权限来控制各自可使用的功能，如果角色之间基本上没有可共用的功能，最好不同角色分别各自做一个使用平台

2) 平台选型

一个项目有多个子产品，往往需要多个平台载体去实现，比如pc端、app、小程序、公众号等。我们需要根据角色需求及各阶段的营销目的进行平台选型。

比如电商平台前期为了快速推广，一般会选用小程序、公众号、h5页面等轻量级的平台。一是迭代更新快、二是获客门槛低。后续有大量客户了，为了维护稳定、高质量的客户关系，一般会将客户引流至app。而运营平台、数据分析平台等特定职位的员工需要使用的平台一般都是用pc端。

再比如敏捷BI产品，通过指标维度自由拖拽、图表自助排版的形式形成大数据分析结果页，该产品的使用角色有两类：普通业务人员（运营或销售）、领导决策人员。

一般是业务人员通过指标维度的搭配组合进行数据分析探索操作，再通过自定义排版形成以专题为单位的分析结果页。

业务人员将形成的分析结果页分享给领导，领导可在手机端或pc端实时查看分析结果。有些分析结果版面可能还需要投放到大屏上。这样整个脉络就很清晰，针对业务员的数据分析探索操作服务，需要有一个pc端操作系统。而针对领导层的需求，最好是同时兼容手机、电脑、大屏对分析结果进行展示。

3) 版本迭代规划

产品的功能都是不断迭代完善的，需要对整个产品线的动态发展做一个统筹规划。

统筹规划时需指定分期目标，目标指定切忌两个极端：

1、只顾着当下要解决的问题，功能的设计缺少可持续的扩展性。这种情况往往会导致产品开发一开始的技术架构不足以支撑后续不断增加的迭代功能，这样会导致用不了多久产品就需要做代码重构。

2、不考虑公司实情，一开始就功能立意太庞大，巴不得呼啦啦造出一座大厦来。一方面外部市场环境总是不断变化的，我们考虑不了这么深远，太过长远的规划容易将方案做的理想化没法落地；另一方面现在互联网公司的生存发展周期普遍很短，很多公司熬不过5年，所以做10年规划就毫无意义了。

我们可以兼顾未来大致3年内发展的所有情况，做一个整体功能方案（可以画一些结构图）。再将这些功能做分步拆分，能解决当前问题又具备可实现条件的先做，以此类推进行版本迭代规划。

4.原型设计

在产品确定好子产品的划分及对应功能模块后，需要为各子产品设计原型。原型体现的是整个产品的设计思路，前期可以面向老板或客户画一个简略的做功能演示，也可以面向开发人员做技术调研，先做简单点，方便沟通修改，直到最后敲定产品方案。（方案确定后，可以对原型做细化，跟后续的prd一起作为开发的说明文档。）

原型设计的实质是产品具体功能的可视化，在画原型之前先得对功能的组建有个清洗的概念。

原型的设计原则是，在满足用户需求的前提下，设计尽可能简单。可以降低用户的使用门槛，也可以减少开发成本。

1) 功能设计

a) 功能重要性评估

功能不是做得越多越好，产品经理在产品开发中起到了方向性的作用，如果胡乱的加功能会造成开发资源的浪费，很多时候做减法很重要。所以功能设计的是否核心精准，很能够考验一个产品经理的能力。

评估功能的重要程度有以下方法：

Ø 目标检验：明确该产品要解决的问题，预估当前功能对要解决的贡献度有多大，再评估当前功能的开发成本；

Ø 频次检验：当前功能可能会提高用户使用体验，但还得预估用户可能的使用频次，如果经常使用，说明很重要，如果不经常使用，哪怕功能设计很完美，也可以缓缓，除非没有更重要的功能可以开发了。

Ø 用户调研：一般toB产品通过用户调研可以很明确的知道某一功能点是否核心有用；

Ø 数据埋点：toC产品评估功能点是否有用，可以通过埋点让数据说话；

当我们在说明原理的时候似乎一切都理所当然。但实际中确实存在很多莫名其妙的问题。

b) 功能的正确打开方式

有时候我们知道一个功能很重要，但具体如何实现才能满足用户的需求可能会走偏。

c) 形成功能闭环

在将项目划分成子产品后，需要为每个产品设计功能。在功能设计的时候需要注意各独立的子产品或者相互之间是否能够形成功能闭环。

产品闭环是指产品的功能可以跟使用场景无缝对接，同时也要跟需要配套使用的其它产品无缝对接。从实操层面，产品只有形成了闭环才能够真正落地使用。

比如敏捷BI产品的功能闭环是：连接数据库、导入数据、数据配置、数据同步、分析报表配置、分析结果分享。相当于从原材料（数据）接入到服务后结果产出的整个功能链路流程都有了。

这个链路的最后一步“分析结果分享”也可以没有，这样的话产品的产出就是分析报表，用户可以登录分析系统，进行自助配置后得到想要的分析报表，其实也能满足部分的用户需求。但实际中，很多用户觉得每次都需要登录分析系统才能查看报表不方便，希望在生成分析结果后可以随时快捷查阅。

也有些用户希望在已有的管理平台中查看分析数据，不希望工作时同时打开多个平台。就是说，我们的产品要想满足更多用户的需求，需求解决分析服务中的最后一步——分析结果分享。可以将分析结果页一键生成url，通过访问地址分享就可以随时在手机端、PC端查看分析结果，也可以将url嵌入到其它平台的菜单中。

d) 保留适当的灵活性

在做功能设计的时候，不能只考虑当前要满足的需求，要保证功能有足够的扩展性与灵活度。比如一些后台管理系统的菜单项如果经常变动的话，需要做一个菜单配置模块。再比如，用户的数据同步周期如果不确定，就需要有一个模块让用户可灵活配置。

当然产品设计并不是越灵活约好，太灵活了配置项太多，那用户的操作成本是非常高的。实际上，一个产品的设计需要太多灵活可配，很有可能意味着对用户的需求还不够明确的了解。

【例子待续】

产品的形态演变往往是以下的三个步骤：功能固定——灵活可配——半灵活半智能。

一开始的“功能固定”是只着眼于眼前的用户需求，功能扩展性差；“灵活可配”可以满足用户不断变化的需求，但用户的操作门槛太高；“半灵活半智能”是指对用户的使用习惯、细化需求有足够了解之后，系统自动为用户做了智能化的配置，降低了配置门槛，用户可将精力集中在核心业务，在一定程度上回到了固定的设计模式。

BI产品的发展历程很形象的体现了以上的规律。从”传统BI”到“敏捷BI”再到“AI+BI”，正是以上产品形态的3个发展阶段。

“传统BI”分析页面的指标、维度、图表排版都是固定的，用户如果要更换分析需求，需要开发人员重新开发页面；

“敏捷BI”的分析指标、维度以及页面排版都是灵活可配的，相当于给用户提供了一个可自助服务的数据分析平台。因为太灵活了，配置项太多，对一般用户来说有一定的使用难度；

“AI+BI”是指在敏捷BI的基础上引进了AI技术，系统在积累了一定的行业知识库之后，知道各个行业用户常用的分析维度、分析指标是什么，也知道相对于哪些指标对应怎么的数更新规则是最佳的。可以通过流程自动化与内置分析模板的形式来降低用户的使用门槛。

2) 流程设计

流程设计的原则是在保证功能操作完整性的同时，尽可能减少用户的操作步骤。

对于一些业务逻辑较复杂的产品，可以通过绘制业务流程图来辅助原型设计，一个业务流程涉及多个角色可考虑泳道图。如下图所示，为玻璃招标购买的泳道图。

a) 流程完整性

流程设计的前提是保证流程能够走通，好的流程链路往往是四通八达的，重要的信息可以由多个不同的入口进入，在完成当前任务时要依赖的信息最好在当前位置显示，或者通过简单操作就能触达与返回。

b) 流程简化

在保证以上操作流程的完整性之后，尽可能的使流程简化。繁琐的流程设计有以下几种情况：

Ø 太过复杂的冗余配置项
Ø 信息组织层次太多
Ø 没有实际用处的花哨的交互效果
Ø 实际上可以条件合并的分情况考虑

c) 流程自动化

可以在流程设计中引进AI技术，使得流程中的配置自动化或半自动化。可以减少用户操作，体验更好。

【多维模型自动配置】【同环比条件自动识别】

5.开发PRD

产品需求文档（PRD）是给开发人员看的，一般是越详细越好。有经验的产品经理知道开发人员关注的细节在哪里，会提前做好规则的定义。一份好的PRD，开发人员脱离产品经理便可独立开发。PRD的格式不限，可以是word、excel格式，也可以直接在细化的原型上加注释。具体使用什么格式可以跟开发人员进行商定。

初级的产品经理写的prd一般只会介绍一些主体功能的交互流程；有点经验的产品经理会深入交互细节，也会介绍交互流程中出现的一些异常情况；而比较成熟的产品经理，除了交互细节会考虑的更加周全，也会深入后端开发逻辑，定义数据流走向、指标计算公式、条件判断规则等。

【例子待续】

Prd的细致程度可以评价一个产品经理的功力，曾经一个贝贝网的技术总监说他们公司一个月薪30k的产品经理，写出的prd直接扔给技术人员，即使后续他不用跟进，开发人员也能顺利的进行开发，应为prd上把一些可能的开发会产生的疑惑都考虑到了。

Prd的细致程度可以评价一个产品经理的功力，但对于团队来说，要把文档写得很详细才能够顺利沟通的话，说明磨合的不是很好。当团队默契到一定程度，很多约定俗成的设计规则是不需要说明的。对着一份很烂的prd，是否还能做到逻辑自洽、顺利开发很能够考验开发人员的技术功底。

开发过程中的及时沟通也能够弥补prd的不足，但有一点prd如果写得不够具体或者逻辑不通，团队间很容易扯皮。