什么是产品边界

❶ 产品观念的两个错误是什么

一、被用户牵着走

我们都知道，产品是为了解决某个核心问题或者满足某个核心需求而诞生的。所以明确产品设计的目的很重要，想清楚我的产品到底是为了解决什么问题。

很多的朋友都在做B端的行业解决方案，说好听一点是用数字化的手段助力行业升级，说直白一点就是外行指导内行，很多时候就被内行牵着鼻子走。

1. 真实场景

友人A所处行业是房产估价，传统做法是通过可量化的公式对房产价值进行评估，但公式本身非常复杂，算式项很多，估价师做一份估价报告要做很久。

针对这个问题，他们给出的解决方案是：一个报告自动生成功能。通过后台的特殊配置对计算过程做简化处理，用户只需要几次简单的点击就能够生成准确的评估结果。

但这个功能给客户的感觉就是：不够专业。他们很难接受这么复杂、专业的评估报告就用鼠标点几下就出来了。收到用户反馈后，他们又增加了一些“专业性”上的考虑，增加了一些花里胡哨的流程让报告显得更专业，效率大打折扣，最后让这个功能变成了一个鸡肋功能。

2. 分析

这种情况对应的主要问题是：产品的设计目的不明确，没有明确产品为客户所解决的核心问题是什么。

出报告这个环节的核心痛点就是效率问题，高效是当前场景的第一设计需要。从整个解决方案的呈现，每一个环节和交互，都是在提高整体的效率。能够一步得到的结果，绝不会为了照顾用户的心理需求，让流程变得更复杂。

在这个案例中，高效与专业显然不是互斥的需求，用户想要的是既高效，又符合专业需要的评估报告，所以我们思考的出发点是在合乎专业的基础上提高生产效率，所以不见得需要在流程上让报告更繁杂。

做tob的产品，我们面对不同群体的诉求，每个群体提出的诉求在他们看来都是实际要解决的并且非常重要的问题。这时候如果业务流程再复杂一些，分支情况再多一些，很多产品经理直接懵逼，丧失思考能力，用户说啥就是啥了。

3. 鸡汤

面对这样的问题，身为产品经理一定要保持独立思考，不要对客户的意见进行盲从，透过现象看本质，找出现这个问题的根源。而不是拆东墙补西墙，想不清楚，只顾解决当下的问题，这样的产品慢慢会做成四不像，成为“臃肿难懂、抱怨连天”的代名词。

道理很简单，但是在实践的过程中容易随着产品的演变发生变化，这种变化有好的一面也有坏的一面，需要产品经理们审慎把握好尺度。

二、需求范围不明确

灵魂拷问：什么样的产品才能称之为好产品？

如果好产品的定义是：解决用户的问题，那么我们的产品是不是解决越多的问题就代表越往好产品的方向发展呢？

1. 真实场景

友人B所处的是垂直领域的CRM产品，他们的产品已经做了很长时间，相对成熟，在业内也算是小有名气。但是他最近做得很不得劲，因为他总感觉产品做到一定程度以后就没太多内容可以做了，好像做的全是一些边边角角的需求。

而且用户提的需求严格来说也不能算是CRM产品的范畴，例如增加一些知识库和企业通讯之类的功能，这让他很迷茫，产品的边界到底在哪里，这种情况下，什么需求应该做什么需求不应该做？

2. 分析

产品的边界性是某个阶段内对产品的约束，可能是一个季度、一个版本甚至一次升级的约束，让我们在这个边界范围内去解决一些需求。做C端产品时经常会提到需求链，即用户顺延场景延伸的需求。

当我们设计一款产品时通常抓一个点，解决一个核心场景下的问题。当产品逐渐成熟之后我们就要开始思考需求的前面是什么，有什么场景可以进行更广度的覆盖，实际上这就是产品边界的延伸。

例如一款理财产品，当用户出现买基金这样的需求时，可能是因为客户需要理财，再往深入去探索可能是用户存在一次性大额消费的需求，这可能就是一款理财产品打通购物商城的缘由，所以对需求链的深入探索也是产品边界扩散的过程。

边界是会扩散的，随着产品被赋予不同的使命而向外进行更多的扩张。

边界扩散的方向是无法被预知或者被计划的，再好的棋者也只能掌控三步以内的棋局，对于互联网这个瞬息万变的行业也是一样，产品难以按照一条既定的路线去前行。

所以我们可以采用控制边界的方式来引导我们产品的发展走向。阶段性的目标要清晰、边界要明确，什么事情该在这个版本做什么事情不应该做都有了更加明确的定义方式。

❷ 产品的定义究竟是什么

上次回家遇到同学，聊起以前他校招的时给我投产品经理的简历被我刷掉的事情。我便问他一个我问过所有候选人的问题：你究竟为什么想要做产品？同学回答我：”学长告诉我，产品经理入门简单，啥都不会就可以干，而且工资很高！”

我不禁骂了句：”我*！”

后来我又在知乎上看到一个问题：“产品经理究竟是干嘛的？“，看到长篇大论貌似很有用的回答，实在有些看不下去，就想写一下我所理解的产品经理的主要工作究竟是什么。

商业模式的产品定义这一块得考虑相当多的内容，不光得深入到行业，还得深入了解经济趋势，政策风险等，才能较为准确的对产品有所了解。而商业模式在未得到验证的情况下，是不能进行快速批量投入的。得先小批量验证，验证无误，解决了批量推广的瓶颈以后，然后再花大力气去推。

所以我们总是说创新是一件很难的事情，更好的一种方式是直接抄袭然后修改，COC ( to china)就是这样一种把在国外得到验证过的商业模式，直接抄到国内，然后稍微进行改造一下的商业模式。这些成功的例子有很多，比如美团就是复制高朋的团购模式，人人网复制facebook，微博复制twitter……

❸ 从项目制到产品制（1）：确定正确的产品边界

IT不是成本中心，而应该是利润中心——这几乎成为转型企业的共识。实现这一跨越，从项目制转向产品制，则是必经之路。

一直以来，业务与IT的关系是建立在职能分割的基础上，无论直接或间接，IT作为收单的乙方来承接业务甲方过来的投资项目。但是，项目制的思维，以管理确定性驱动，强调计划、预算、分工、人员利用效率，带来了很多问题：

随着组织的规模化越来越大，这些挑战将越来越严重，成为组织应对不确定性、持续创新的严重掣肘。大多数IT组织都意识到了这个问题，在敏捷转型的同时，也开始了由项目制到产品制的转型。

产品制的思维和项目制思维最本质的区别是， 项目制是以确定性（IT要解决的问题是确定的）为基础的 ，因而注重计划、预算、执行效率（人力利用率）； 产品制的基本观则是，IT所要解决的问题都是高度变化的，因此应该不断挖掘客（用）户的真正需要，持续迭代更新解决方案，一切以提供给客（用）户的价值为目标 。

疫情当前，互联网公司积累的响应力势能引人瞩目，美团"无接触配送"从确定需求，到上线只要了24小时，一周内覆盖到全国重点城市；腾讯从采购、到直接配送45000套防护服至医院也就是3天左右的时间。这是长久锻炼出来应对突发情况的“高响应力肌肉”——投资能够持续创新的基础平台和能力、以响应力和业务成效为导向、跨职能的团队（从供应链到硬件到软件全通路协调）、鼓励团队自主决策（让一线听见炮火声音的员工直接做决策）、快速上线迭代优化方案。

对比于当前很多企业中的IT还在运行的方式——业务和IT完全就像是甲乙双方两家公司、规划时主要看是否符合预算要求、是否能达成当前KPI、以“人均交付功能点”和“人员利用率”为绩效、开发测试完全各顾各、领导必须通过层层审批需求文档来获得安全感——差距之大，上下立见。

大多数敏捷转型的IT组织，理念上非常接受“产品制”。等到落地时，第一个问题往往是：我们这里有项目、平台、组件、功能特性、团队......那到底怎样算是一个“产品”？一个项目对应于一个产品吗？一个团队是一个产品吗？一个大的特性能算一个产品吗？“产品”的正确边界又在哪里？

在当前数字经济上下文里面，我们所说的产品肯定有别于传统的有形产品（比如杯子、肥皂），我们先称其为“数字产品”以与传统意义上的产品相区别。那么，怎样才算是一个“数字产品”呢？

首先，我们认为，数字产品具有两个本质特性：

如果具备了前两个本质特征，在业务定位、服务对象、表现形态、业务模式、渠道、范围、生命周期，则可能具有不同的样态。以一个大型金融企业为例：

由项目制转为产品制，不是一个“革命”的过程，一夜之间城头变幻大王旗，由若干个XX项目，变成了若干个XX产品（如果真地这样，那多半是假的产品制），而且也不存在绝对的产品态——组织中总有一些本质上就是应该用项目来解决。

这种情况下，要落地产品制，需要有个逐步演进的过程：

所以，”如何确定数字产品的边界“， 本质上不是”如何切（划分产品团队）“的问题，而是识别出战略性产品，为这些产品配齐从需求到价值角度端到端的能力，构成真正的跨职能产品团队 。

同样，以如上的金融企业为例，首批可能识别出了10个左右的战略产品，比如：

这10个左右的产品覆盖了所有的业务定位类型：

从产品形态上覆盖了系统应用、触点应用、平台、API服务等；从产品生命周期来看覆盖了从孵化到成熟期的四个阶段（处于衰退期往往趋近于停止投资，所以不会是战略重点）。这在第一期足以支撑在产品制实践落地措施的方案反馈和验证。

这些产品的团队构成现状总体来看分为三种类型，各自的能力配备措施如下：

这在真正落地中，即使在IT内部，当涉及到人员的调配、职责的调整，也会受到当下现实的各种约束和阻碍。这种配齐也可以先由”虚拟岗“和”虚拟团队“（比如保留原职责岗位归属，但给定办公空间，让这些人坐在一起），逐步过渡到真正的跨职能团队。不过无论如何妥协，都要先保证开发和测试归属于同一团队。

当然，怎样认知一个数字产品、怎样识别组织中的战略数字产品、怎样识别战略数字产品所需要的能力是简单的，真正的落地挑战还有很多：数字产品团队，该有怎样的工作流程和实践？实践如何一步步真正把产品制的原则落地？如何衡量数字产品管理的成熟度？数字产品的成效和进展如何度量？如何动态调整持续积累”高响应力肌肉“，如美团一样？让我们持续探讨。

文/ThoughtWorks亢江妹 王汝佳

❹ 一张图讲清楚产品架构，手把手教你画产品框架图

什么是产品架构图

产品架构图是产品经理用来表达自己产品设计机制的一张概念图：

它将可视化的具象产品功能，抽象成信息化、模块化、层次清晰的架构，并通过不同分层的交互关系、功能模块的组合、数据和信息的流转，来传递产品的业务流程、商业模式和设计思路。

由于产品架构图通常用于比较复杂的产品项目中，目前介绍产品架构图的相关书籍和资料极少（尤其是入门级别的资料很少提及），却是设计复杂产品时不可或缺的文档之一。

没有资料的探索过程漫长且没有方向，在终于有所沉淀后，我花了四周写下了这篇总结，希望可以为你绘制产品框架图时提供简明的参考。

为什么要画

梳理自己对产品方向的判断：

思考这张图如何设计的过程，也是帮助你梳理“半年内自己的产品该往何处去、需求应该如何分期和落地、和其他产品的依赖&竞争关系是什么、未来的可拓展性在哪里”等问题的过程。

为技术&运营的输出形成支撑：

当这张图被设计出来后，按照产品架构图的结构和路径，项目的里程碑（RoadMap）就可以被清晰的拆解出来，同时项目成员也可以根据这张架构图产出运营计划、技术系统架构方案等强依赖产品方向的方案。

让他人可视化的理解你的产品架构：

能较为清晰简单的呈现自己的思路、明确自己的产品边界、指明发展的方向，常用于在项目规划或项目总结中进行演示，帮助不了解你的产品的人快速的建立对你的产品结构、功能、复杂度的认知。

何时需要画

建议在复杂项目开始前写：

当你要开始设计一个系统性、完整的需求时，如果跳过画产品架构图的步骤，直接开始画原型、写PRD、kick off，就很容易发生“改了又改”、“做了一版需求然后又推翻”的情况。

但“种一棵树最好的时间是十年前，其次是现在”：

如果你的项目已经进行到一半，自己却从未产出过这张图，那么就从此刻开始，按照下文的步骤尝试为自己的产品产出一张产品架构图吧。

如何画

之前我们分享了【AR最全干货及资料】设计AR产品，你一定要看的总结 ，你可能对AR相关的背景知识已经有所了解。为了分享的延续性，我们来做一个大胆的假设*：

假设你是 微信-扫码功能 的产品经理，有一天老板把你叫到办公室，一番鼓励后拍着你的肩对你说：

“苹果发布会看了没？苹果这么重视对AR能力的支持，我们微信也要赶紧把AR功能做起来。这是个Allen（张小龙）很重视的项目，你回去好好设计一下，明天来跟我过方案。记住，要能够一炮打响，全民参与喔！”

啊，张小龙级别的项目啊！明天就要出方案，怎么办 ？

画前准备

列出问题域

在需求初期，产品经理得到的往往只是一句比较模糊的需求描述，它们可能来自于老板、运营或用户。

直接把这句话作为核心产品功能是不恰当的，合理的做法是先把这个产品所有的问题域列清楚。

“问题域”是指自己的产品能够解决的所有问题的空间集合。从核心需求出发，将所有当前需要解决、未来可能要解决的问题放入产品框架的范围，能够帮助你的产品架构图拥有更高的可拓展性，在后续具备迭代和优化的空间。

以微信AR的需求为例，问题域是这样一个集合：

详细操作步骤：

1. 找到收到的需求中，跟产品形态、产品目标相关的词句，去列出“XX的流程会是什么样”、“XX该怎么达成”之类的问题，直到如果这些问题解决，能够实现核心需求的方向和业务目标。

2. 去逐次寻找这些问题需求被解决的过程中，是否有其他要先解决掉的问题、或者其他跟业务相关的问题能够被解决/改善。

3. 按照层级去罗列出所有的问题，并附上自己的初步回答，从而形成一个初步的、自己的产品能够解决的“问题域”。

确定产品方向

在经过问题域的罗列后，你应该能够得到一个模糊的产品方向和功能范围。把这些问题域的答案抽象总结成一个确定的产品需求。

以微信AR的需求为例，根据问题域，我们发现需求不只是扫码组件增加AR识别能力这么简单，整个需求里需要引入广告主的角色，并且需要和广点通、腾讯开放平台等团队合作。最终得到的产品方向描述是这样的:

详细操作步骤：

问题域的环节非常发散，这一步需要回归基础，把模糊的需求补充、拓展和翻译成一个在商业模式和用户体验上能够形成闭环的产品需求。

1. 核心需求确定：我的产品核心解决的是哪批用户、哪个用户需求？

2. 产品目标：如果以一个数字指标衡量我的产品，它应该是什么？

3.用户场景：核心需求基本的产品形态、用户使用的路径是怎样的？

清晰的业务流程

这一步需要根据核心产品需求和问题域的答案，画出简单的业务流程。业务流程是产品设计中常见的图表，绘制方法就不再多做说明。

以微信AR的需求为例，从广告主准备AR互动，到用户在前台使用摄像头参与互动，整个业务流程如下:

着手绘制

搭建基础框架

基础的产品框架脱胎于业务流程，但相比业务流程，更加注重产品功能的枚举、功能模块之间的分界。

详细操作步骤：

1. 对照业务流程，根据自己设想的产品机制、基本产品形态和用户的使用路径，列出需要的页面&功能&模块等前后端逻辑。

2. 将刚刚得到的多个流程图中所有功能类似或者范围有包含关系的机制/功能放在一起，以模块化的形式形成一张简单的矩阵图。

3. 将明显是同一个产品范围、同一组产品功能的模块放在同一层级，得到一个基础的产品框架。

明确架构分层

一个具备前后台关系的产品架构图至少分为三层：用户感知层（在何种场景下通过何种方式触达用户）、功能模块层（通过哪些功能模块实现产品的核心功能、和哪些外部平台功能有信息交互）、数据层（产品的数据从哪里来、产品的数据沉淀到何处去）。

在上一步进行简单分层后，我们已经得到一个初步框架，但是难免会有分层不明确的问题。此时需要按照两种维度来处理架构图的层级：不同信息层级的边界、同一层级内模块和模块的边界。

1. 处理不同信息层级的边界：

架构图的层级表达的其实是信息之间的流转关系，不同信息层级之间一定是有逻辑关系的。

其中用户感知层和数据层通常可以简化为一层（用户端的功能表达往往逻辑简单、数据的来源问题则不是自己产品的核心功能），而功能模块层则需要按照自己产品的逻辑去将功能模块层内的主要模块变成新的层级。

2. 处理同一层级内子模块的边界：

各层次之间虽然相关，但同一层次内的子模块之间一定是互相独立、界限分明的（常常对应着不同的开发团队和系统应用）。将解决不同问题的功能拆分成两个子模块，做到一个问题只在同一层解决，避免牵一发而动全身的情况出现。

3. 明确产品间的边界：

产品边界对于开发设计系统架构、业务间的合作模式都非常重要。用不同颜色标识清楚产品框架中，各个部分所属产品的边界，通常其中属于自己团队的部分用亮色表示。

加入信息流转机制

产品架构图在表达产品的核心功能外，也应该体现信息流动的路径：当前层级数据的交互形成产品功能，产品功能又产生新的数据，从而推动下一层级的功能运转起来。

如果当前产品的主要使用角色只有一个，则只需要用箭头标明模块间信息流动的方式即可。如果当前产品会涉及的主要角色比较多，则需要用不同颜色的线条将他们和各个模块之间的信息交互关系外化出来。

最终检查

一张好的产品架构图，应该具备以下特点。

清晰的模块功能边界

功能经过抽象，做到标准化、互相独立

上下游产品功能边界清晰，架构分层明确合理

具备迭代优化的能力

记得不断根据你的产品的发展情况来更新产品架构图，每次修改的过程对提升产品架构能力的帮助非常巨大。

————————————————

原文地址：https://blog.csdn.net/pmcaff2008/article/details/78111282

❺ 产品的顶层架构是什么

有时候大家发现做事情会很顺，有的时候会很拧巴，为什么开发和产品老在打架？为什么各种资源政策都在和我作对？为什么男生思路和女生思路永远走不到一块去？谈到根上，这都是顶层架构决定的。

顶层架构就是一个产品或者体系的宏观设计，设计准则，边界规范。 一款优秀的产品或者一个高效的体系，一定拥有一套优秀的顶层架构。

产品的顶层架构包括:

1.拥有确定性的目标和愿景。

这款产品，我的愿景是什么？我要达成的目标是什么？要去到哪个地方？

2.有着明确的边界。

边界就是克制和约束。产品是有边界的，世界上不存在无限大的产品。想清楚，什么东西能做，什么东西不能做。用户能联想到吗，用户的心智边界在哪里，做出来的是不是无用功？

3.清晰的产品定位和承载的使命。

我的产品定位是什么，要在哪个场景下解决哪个问题？对公司/用户/产品不同的纬度来说，产品的使命是什么？

4.聚焦的服务和服务人群。

我要提供什么样具体性的服务，我的服务对象是谁。

5.逻辑清晰的功能框架。

对产品要做的事情和提供的服务进行归类排序。哪些功能属于同一等级？同层级下哪个功能是我的第一优先级，哪个是第二？

这五条就是我理解的产品顶层架构，他决定你的产品会走到哪，走的好不好顺不顺，如果没想清楚开始做产品，是不负责任的。

举个例子，我们来看看互传这类文件传输产品（当然我们作为一个厂商应用有和纯粹的第三方应用不一样的地方就是我们要更多的考虑换机用户的体验）的架构是怎么样的，

目标愿景：成为市场第一的文件传输工具，3000万月活，50%以上的用户换机使用

边界：互传要提供的是基于近场通信的文件传输服务

产品定位：互传是服务于换机和跨平台近场文件传输的工具产品

使命：对公司侧，降低换机成本提升复购率；对用户侧提供高速免流的传输服务满足用户求；对产品侧能持续产生保持用户黏性和产生价值养活团队

服务的人群：换机人群，网络环境不好或分享文件时对流量有诉求的用户

聚焦的服务：近场传输、一键换机、跨设备互联传输

架构可以有大有小，都没问题，也可以随着体量和阶段的变化不断调整。但无论怎么变化， 重要的是清晰+完整 。

优秀的产品不一定是复杂的产品，不一定提供多么精致多么全面的服务。很多爆款产品往往聚焦在一个痛/痒/爽点上，针对性的解决用户的某个问题或满足某种诉求，麻雀虽小五脏俱全，就是一款能打的产品。比如说脸萌、ZEPETO、足记，都算一款好产品。因为他们满足了用户的确定性需要，那五个问题每条都很清晰。

同时，顶层架构某种程度上代表了格局和愿景，就是你能解决多大问题，干多大的事。

再拿“脸萌”举例，为什么脸萌的开发团队不继续在脸萌的基础上迭代，而是另起炉灶做了一款Faceu呢？因为架构包含了产品边界，产品达到了他的边界，用户的心智向外拓展是非常困难的，对于小团队来说我宁愿再做过一个。在原有的边界里，我干不了更多的事情了。

但有的时候我们不得不去打破产品的边界，因为市场和竞争对手在不断变化，不做你就死了，做不做？这也是互传不断探索能够打破的产品边界的原因。当然，能够带领产品跨越非连续的产品经理都是最优秀的产品经理，因为这可能比做一款新产品更困难。最经典的案例可能就是我们自己了，从当时命悬一线的功能机时代跨越生死线，慢慢变成了今天这个平台型公司。这真的是非常难的，不仅仅是产出的产品发生了变化，组织架构，供应链，思维模式都要发生巨大的变化， 所以vivo真的是很厉害的企业 。

总之，大有大的雄浑，像阿里一出手就是气吞天下片甲不留天下万物都在我双手间翻覆；小有小的精巧，像soul准确的咬住兴趣灵魂社交在巨头遍布的时代守住一片江山。重要的，是完整和清晰。

回到最开始的问题，

为什么开发和产品老在打架 ？

是因为谁很傻难以沟通吗？不。是因为目标和愿景不同，如果开发小哥的目标和KPI是保证产品的稳定性和效率，产品的目标是不断迭代新功能提升产品指标，你们当然就打一起去了。如果统一一下目标，我相信大家能很快达成一致，这也就是为什么涉及钱的问题大家总是能同仇敌忾，因为没人和钱过不去呀，换个说法，团队里的所有人目标是一致的。PS：这里讲一句题外话，我很感谢我的团队，总是在尽力满足我各种傻逼需求，从产品的角度保证目标达成，感谢这帮小哥小姐。

为什么各种资源政策都在和我作对？

因为大家伙的目标会有区别，因为你产品的定位和使命不清晰，大家理解得这产品就是解决巴掌这么大个问题的产品，产品经理不死心，非得把他做的气吞山河功能把天都顶破，那当然走不到一块去。所以怎么才能走得顺，一上来给团队和老板讲明白了，我到底要干啥，要走到哪，怎么走，你们全力支持我，自然就顺了。所以一个有战斗力的团队一定要心齐。

为什么男生思路和女生思路永远走不到一块去？

因为你们的思维模式不同，脑子结构决定了，男生偏理性，女生偏感性，这叫功能框架结构不同。社会对男性要求的社会属性是硬汉，所以你不能多愁善感要快速的解决问题；社会对女性要求的属性是柔软和包容，所以她需要更细腻的感受，这叫产品使命不同。

总结一下，顶层架构就好像血肉皮里的骨头，他是撑住一个产品和体系的关键，一定得想明白了。（这么简单是因为我写累了）

❻ 消费者需求特征分析

产品价值的最终落脚点——需求

我们先来看一下俞军提出的新三条军规。

产品价值分析法：用户价值=(新体验-旧体验)-换用成本
用户样本量：用户即需求，用户是自然人的某一类需求，用户不是自然人，随着内外部场景变化会发生变化。
怀疑精神：自我迭代。
俞军新三条军规中的第一条建立在一个前提条件之下——需求不是被创造出来的。第二条将最重要的需求融入用户之中。这也和上图中描述一致，需求分析在输入阶段， 要进行对需求的收集、发现、挖掘。

需求决定了最终的产品价值。

所以需求分析推导至现在，目的开始越来越清晰——发现、挖掘具有商业价值的需求，并给出具备用户价值和商业价值的解决方案。

这时应该会有人疑问，产品的日常工作中很多时间是对单个功能的分析，根本涉及不到商业价值啊。别着急，东方还没讲完呢。不是所有的需求都能挖掘出商业价值，一个好产品也不等于一个能够赚钱的产品。

刚才已经提到过，商业价值建立在用户价值的基础上。所以我们首先要满足的是用户需求，然后将其与企业的需求结合。刚才的疑问只不过源于我们更多时候只是在提升用户价值，这和产品属性与所在职位等级有关。

需求分析的几个要素
需求分析的过程当中，会诞生出几个极其重要的产物——产品目标、产品定位、产品边界、产品规则。

产品目标——产品承载的使命
产品是需求分析得出的解决方案的最终承载地方。它承载了实现用户价值和商业价值的使命。明确的产品目标能够让我们实现产品价值的时间变得更短。比如工具产品转型为社区，是在一开始就预设的产品目标还是市场所逼？可能两者都能转型成功，但前者赢在了时间上面。

产品定位——产品要做什么
到底做一个什么样的产品好呢？社交、社区、社群，傻傻分不清楚。社交好像也可以做社区，好像也可以做成社群。好，那就都做试试吧！不能评断到底是对是错，但是做得越多，耗费的时间也就越多。大公司可能无所谓，试试水嘛。小公司可拖不起啊！

产品定位围绕产品目标确定。产品定位不清晰可能造成的问题是选择太多而不知道要做什么。

产品边界——产品不做什么
虽然我是做金融的，但我就是要做社交！我不仅要做社交，我还要让全国人民都参与进来，调动他们的荷尔蒙积极性，走出金融社交的第一步！

产品边界由产品目标和产品定位确定。强行打破产品边界，要么出现跨领域引领时代带动革命浪潮的生态化反，要么就是自己闲坑太少再多挖几个。

强行打破产品边界和自掘坟墓没有多大区别。

产品规则——指明方向的北斗七星
产品目标、产品定位、产品边界共同构成产品规则。进行需求分析的时候，我们要随时提醒自己遵从产品规则，以避免偏离产品重心和陷入分析误区。无论是需求评估，还是需求优先级排序，如果不遵循产品规则很容易走上很多弯路。

两点之间，直线最短。我们可以通过很多种方式实现产品目标，但明晰的产品定位和产品边界能够让我们更快速地达到产品目标。不管夜晚有多黑暗，只要北斗七星依旧闪耀，我们就绝不会偏离方向。

❼ 产品架构图的定义和基本画法

本小节主要介绍 产品架构图 的相关知识，整个内容框架分为三个部分，分别是： 产品架构图是什么（what） ； 为什么要画产品架构图 （why） ； 如何画产品架构图（how） ，下文将对各部分的内容做详细介绍。

1、产品架构图的定义

产品架构图是一种将具象产品的业务架构、功能架构、信息架构、技术架构，生态架构以及商业模式等，通过层级划分、模块组合，而设计出的可视化图形，其抽象且精简的表达形式，很适合用来介绍复杂产品体系。常见的产品架构图有业务架构图、功能架构图、信息架构图，以及混合架构图。

有句俗语叫做： 思考常常越复杂，形式往往越简单 。人类历史上许多伟大的知识和定律都是以精简而优美的形式表达出来的，例如亚里士多德的三段论表述、牛顿的三大定律、欧拉的上帝公式，达尔文的进化论表述等。思考的足够通透后，只需要用简单的形式就可以表达复杂的体系结构和逻辑关系，相反很多看似简单的表现形式，背后却承载着巨大的复杂。

对比各种产品输出物（文档、原型图，流程图等），产品架构图的形式最为精简，都是由单一的矩形控件排列组合形成，但却在所有的产品输出物中拥有最高的抽象程度和复杂度，输出产品架构图是对产品经理产品设计能力的衡量和体现。

2、为什么要画产品架构图

在进行产品设计的时候，首先应该输出的是产品功能架构图，思考这张图如何画的过程，是帮助你梳理产品设计思路以及确定产品边界过程。例如，现在让你设计一个CRM系统，可以试着先画出具体业务的CRM系统的功能架构图，在画的过程中，会辅助你思考整个CRM系统有哪些核心功能模块组成，各模块的关联关系是怎样的，每个阶段应该做什么，从而形成完成的产品设计思路。

其次，产品设计的过程就像是盖大楼的过程，输出产品功能架构图就好比是搭建大楼地基的过程，产品原型设计的过程就像是大楼建造的过程，地基没有问题，后面的添砖加瓦就不会有太大问题。如果一开始地基质量就有问题而没有被重视，后续盖了一半发现整个工程出现问题，修复重建则会浪费巨大的资源和成本。所以项目初期产品功能架构图是很重要的交付物，当你要开始设计一个完整的产品方案时，如果跳过画产品架构图的步骤，直接开始画原型、写PRD文档，就很容易发生改了又改，甚至是做了一版需求然后又推翻的情况。

最后，在产品上线后无论是对内普及还是对外推广都需要有高度抽象，简洁易懂的载体来介绍产品整个情况，介绍和推广的不可能去用繁杂的页面和文字去描述，这个时候产品架构图会是介绍整个产品理念，功能和设计的一个很好的传达媒介。

3、如何画产品架构图

上文介绍了什么是产品架构图以及为什么要画产品架构图，接下来要介绍如何画产品架构图，产品架构图的画法主要分为四个步骤，分别是：（1）确定对象；（2）拆解结构；（3）挖掘关系；（4）表达输出。

图5-1产品架构图的画法

（1）确定对象

首先要明确产品架构图描述对象的范围和边界是什么，例如，对于一个CRM系统，要画的是CRM系统的业务架构图、功能架构图、信息架构图、还是综合了多种元素混合在一起的混合架构图。

（2）架构拆解

确定好描述对象的类型后，要对其进行架构拆解，例如，输出一家借贷平台的业务架构图图，可以拆解为贷前业务、贷中业务，贷后业务等。又例如输出一个CRM系统的功能架构图可以拆解出整个CRM系统的功能模块，如账户管理模块、客户管理模块、用户管理模块、权限管理模块，系统设置模块等。

（3）关系挖掘

输出对象的架构拆解完成后，需要发掘出各个模块之间的关联关系，同样以CRM系统的功能架构图为例，在拆分完整个系统的功能模块时，接下来要分析出各个功能模块的关系，产品架构图内部元素之间的关联关系主要有四种：统计并列关系、父子包含关系、辅助支撑关系，底层支撑关系。

（4）表达输出

确定了各个功能模块的关系之后，则需要进行关系表达，层级相同的模块元素，则按照同级并列关系，需要排列在一起。

例如，在CRM系统中，客户管理模块和权限管理模块就属于同层级的并列关系。而权限管理模块和权限分配这个功能模块之间则属于父子包含关系，在表达父子包含关系时，通常父级模块会包含住子级模块。

其次，一些产品的非核心的功能模块或者产品之外的一些功能模块，例如第三方平台的短信功能模块，这些模块对产品自身功能的实现起到了一定的辅助作用，与其他产品功能模块呈现出辅助支撑的关系，辅助支撑模块一边画在产品架构图的右侧。

最后是底层支撑关系，例如产品的 会员体系 是建立在账户体系的基础上的，所以账户体系与会员体系属于底层支撑关系。底层支撑关系的表达方式一般是支撑模块在底下，被支撑模块在上面。这些基本关系的图形化表达方式，会在后面小节结合实际的案例做详细介绍。

整个边界范围内的结构关系表达完成后，整体检查一遍是否有遗漏和错误，检查完毕后配上整个架构图的标题，架构图标题往往是对整个架构图内容的说明，一般放在最上面或者框架左右两边，最终输出完整的产品架构图。

爱因斯坦说过： 如果你不能把一件事情用最简洁的语言描述清楚，说明你还没有理解他。 对于产品架构图而言： 如果你不能用简单的矩形， 通过 排列组合的方式 ， 把一个复杂的产品 结构描述 清楚，说明你还没有真正理解 你做的产品 。 所以，在日常的产品工作中，要培养自己去画产品架构图的习惯，培养抽象思考能力的同时，辅助自己高效的完成产品方案设计。

原文地址：https://www.cnwebe.com/articles/157113.html

❽ 什么是超出产品边界的需求

产品定位于只满足用户甲的需求，然而你想把乙的需求也去满足，那么就算超出产品边界的需求。

需求边界的重要性：

首先，在任何阶段对客户的需求来者不拒，肆意扩大边界范围，那么将导致项目迟迟无法交付上线。

其次，在开发阶段，需求依然充满变数，团队将产生疲惫抗拒心理，对团队士气是”致命“的。

最后，对公司来说，阶段性验收形同虚设，无法交付就没有项目尾款，最终造成项目亏损。

我们需要有个认知，在业务方面，我们的客户是专家，他们一定是有需要没有得到满足，所以希望我们提供解决方案。我们无法根据业务技能去识别产品需求，只有使用对象才能决定需求边界的范围和深度。

当对需求还没有认知时，最好的办法就是深入业务场景，通过调研、仿真、模拟，建立对需求理解的一致性，这样使我们能想象最终的产品形态是什么样的。

再从结果倒推出需求边界，清晰界定自己的边界，以及需要遵守的边界。毕竟客户只是需要解决问题，而如何解决，功能如何呈现，还是靠产品经理决定。

❾ 产品差异是否存在边界为什么

摘要 谢邀，我认为产品差异是否存在边界要视情况而定，有时候是存在边界，有时候是没有边界的。因为每个企业的实际情况是不同的，所以服务单应该属于定制开发的项目，不是标准产品。

❿ 企业的三个基本属性是什么

企业的基本属性

1、经济性。企业是从事商品生产和商品流动的经济组织，因此，经济性便成了企业的首要特征。通过这个特征来实现自己的价值和商品的使用价值。

2、营利性。由第一个特征导致第二个特征，企业的经济性是从企业的营利水平来体现的，也就是说，企业是为赢利而经营的一个经济组织。因此，构成企业的一个根本性的标志就是营利。需要说明的一点是，有些组织它也从事一些经济性的活动，但是它并不是以赢利为目的的，所以就不能称为企业。

3、独立性。企业除了要具备经济性、营利性之外，还必须要具备一定的独立性，企业必须要能够独立核算、自负盈亏、自主经营，并且是一个独立的法人组织。这里，我们要弄清楚企业与工厂并不是同一个概念。企业它可以是一个工厂，但是工厂就不一定都是企业。工厂只不过是一个从事生产活动的场所而已。有些工厂虽然也从事经济性的活动，也以营利性为目的，但是不具备独立性，因此，就不能称为企业。