在进入职场之后，产品经理要如何实现自身的能力提升，从而更好地投入产品岗位、应对产品工作？在本篇文章里，作者就总结了初级产品岗位人员的能力提升方向与可学习的路径，一起来看看吧，或许会对初入职场的产品经理们有所帮助。

2019年～2021年期间，我在做智能写作项目创业的时候，由于当时市场相关产品较少，遇到了问题没有可以参考的竞品。

我们只能一路探索，一路踩坑，一路修正。随着产品的迭代，我也在不断地迭代自己的认知，梳理AI产品的方法论和技能树。当时还和Shadow在“蔚来”做了一次关于《AI时代的产品思维》分享。

但是光有方法论还不够，随着团队越来越大，也出现了一些管理上的新的问题。团队中新入行的同学，在职业发展的道路上产生了迷茫，甚至也有人提出了离职。

我回想起刚毕业的时候，我的导师告诉我：“如果赶路时候，心中有地图，那么你就不会惊慌，你要找到心中的那张图。”因此，作为产品合伙人，我提议在公司内部推行职业岗位上的能力模型。让小伙伴们能看到自己的成长的方向。

其实，我并不是想要推行大厂的那套职级的天梯，更重要的是让小伙伴们有明确的修炼方向，产品小伙伴的也觉得跟着我获得了专业提升。

现在正值毕业季，有很多刚毕业的小伙伴加入产品岗位中来，也希望能帮到大家。

一、修正观念：人人不都是产品经理

大多数人听到“产品经理”这个词，总会联想到“人人都是产品经理”这句话。但实际上产品经理这个岗位并没有那么简单。

用一句话概括产品经理的职责就是“帮助团队交付正确产品给用户的人”。也就是说，产品经理要能凝聚团队的力量交付有价值的产品给用户，而不是一个人孤军奋斗。

我认识的一些优秀的产品经理，往往都是程序员或者交互设计师出身，他们的特点是学习能力很强、知识面广博、思维敏捷、逻辑严密、沟通能力很强。他们能带着你一步步思考，能够清晰地告诉你怎么样的产品才是正确的产品；另外，他们还有很强的驱动能力，不管是对自己还是对他人，是团队不可多得的发动机。

我个人的成长经历也比较杂糅，大学是学工业设计的，却阴差阳错的做了程序员，还和朋友一起创业。有人评价我不够专注，但是恰恰正是有这样的经历，让我对如何做产品有了最直接的体感，这个能力区别于在大厂单一岗位培养的产品经理。另外，我也不是完全跟着感觉走，平时也在不断的学习和总结，用体系化的思维框架整理自己的经验和知识，每个职业都有自己的最底层的思维框架，产品经理也不例外。

从思维框架层面，产品经理的核心能力就是要懂得如何平衡人的需求、技术的可行性、商业价值三方面问题。这个思维框架被著名的设计公司IDEO称之为“设计思维”（Design Thinking）。

我在从业的过程中，用这三个圈的指南针来指导我在产品岗位上学习、工作和决策：

1）人（Human）：以人为中心。产品经理应该深入了解用户的需求、痛点和行为，通过观察、用户研究和用户反馈等手段获取关于用户的信息。产品经理需要思考如何创造出对用户有意义、有价值的产品和服务，以提供优秀的用户体验。

2）商业（Business）：关注商业可行性。产品经理需要理解公司的商业目标和战略，将用户需求与商业需求相结合。产品经理应该思考如何创造出具有商业价值的产品，并将其与市场需求和竞争环境相匹配。同时，产品经理还需考虑产品的盈利模式、市场份额和增长潜力等商业指标。

3）技术（Technology）：利用技术实现创新解决方案。产品经理需要了解现有的技术趋势、技术能力和可行性，以确定合适的技术方向和解决方案。产品经理应该与工程团队紧密合作，探索和评估不同的技术选型，并确保产品在技术上可行、成本可控、系统稳定和可扩展。

通过综合考虑人、商业和技术，产品经理可以更全面地理解和分析问题，找到平衡点，并在设计和决策过程中做出明智的选择。这三个圆圈相互影响、相互支持，帮助产品经理设计出具备用户满意度、商业可行性和技术可行性的产品。

另外，从产品经理的职业能力上看，可以分成四个圈层：素质层、认知层、影响力层和交付成果层：

1）素质层：素质层指的是产品经理的个人素质和品质，包括职业道德、责任心、团队合作能力、沟通能力、自我驱动等。这些素质是作为产品经理的基础，能够帮助建立良好的工作关系、处理复杂的工作情境，并展现出专业和可信赖的形象。

2）认知层：认知层指的是产品经理对产品管理领域的知识和理解能力。这包括对产品开发流程、市场分析、用户研究、竞争分析、商业模式等的理解。产品经理需要具备全面而深入的行业和产品知识，能够从战略和商业角度思考问题，并做出明智的决策。

3）影响力层：影响力层强调产品经理在团队和组织中的影响力和领导能力。产品经理需要能够有效地沟通和协调各方利益，与团队成员、上级、利益相关者进行有效的合作和交流。他们应该能够激发团队成员的潜力，建立良好的工作氛围，并在组织中推动产品管理的重要性和影响。

4）交付层：交付层是指产品经理能够通过实际行动和结果展现自己的能力。这包括制定产品战略方案、需求管理、撰写需求文档等工作，最终的结果通过成功推出具有商业价值的产品、实现产品目标、提高用户满意度等来呈现。产品经理要能够有效地管理产品项目，与团队紧密合作，按时交付高质量的产品，实现业务目标和商业价值。能力越大，责任也就越大。

产品经理的交付能力成长过程分类三个阶段：方案交付能力、产品交付能力、战略交付能力。

这四个层次相互关联，结合设计思维的三个圆环构成了产品经理综合能力的框架。通过不断提升自身的素质、扩展认知领域、增强影响力和能够交付出色的成果，产品经理可以更好地应对各种挑战，发挥更大的作用，并取得成功。因此有了这张岗位能力模型图：

二、方案交付能力：千里之行始于足下

你可能会发现，初级的产品岗位名称（对标阿里P4及以下）常用的是产品专员或者产品助理，为什么不用“产品经理”这个Title？

初级阶段的产品工作人员工作和能力，其实配不上“经理”的Title，产品经理是需要承担团队最终的交付结果的人，需要学习产品管理知识、需要有深刻的行业知识、需要有技术和设计能力、需要有沟通和协调能力等等，没有三到五年的基本功修炼，是不可能有好的“产品交付能力”，先要达成“方案交付能力”。当你具备了基本“产品交付能力”才能算一个合格的产品经理。

因此，针对初级的产品从业人员，我们团队用“产品设计师”的岗位名称。从而强调我们新晋的产品工作者，首先要有交付正确方案的能力，“方案交付能力”是“产品交付能力”的基本功。起码要能产出高质量的产品原型设计方案和具有可行性的需求文档。

如果把P1到P4，比作做是大学四年的学习的话，我们需要修完所有的专业课程才能顺利的毕业。现在我开始对这些“专业课”进行介绍，并且推荐了一些“课本”，希望不管你是产品设计师还是初级产品经理，都可以查缺补漏一下。

首先，要把一个合格的方案交付给团队，我们就需要有基础的设计能力，能够将合格的原型给到团队。

1）原型设计

原型设计是很重要的交付成果物，让团队成员能够清晰的知道需要做什么。主要讲清楚产品需要有哪些信息，是如何与用户交互的，分为低保真和高保真图，想要产品体验好，交互设计能力不可少。

需要了解交互设计基本原则，推荐书籍《About Face: 交互设计精髓》《点石成金》《简约之美》《用户体验要素》《破茧成蝶》；设计心理学，推荐阅读唐纳德诺曼《设计心理学》系列。

需要有信息架构的设计能力，如果是AI产品经理，还要从传统UI的信息架构还要延伸到语音对话的沟通信息架构，推荐阅读《信息架构，超越WEB设计》《语音用户界面设计：对话式体验设计原则》《Google 对话式交互规范文档》《Amazon 语音交互设计规范文档》《Machine Learning for Designers》。

另外，就是UI设计的相关知识，我们不仅要去关注流行趋势，更需要熟悉UI设计的理论和准则，推荐阅读书籍《认知与设计：理解UI设计准则》《平面设计原理》《写给大家看的设计书》《通用设计法则》。

除了活动类产品，强调活泼有趣的画面感，大多数产品UI都遵从设计规范（Material Design、iOS规范等），需要具备了解设计规范的制定逻辑（配色、排版、组件、图标），并且能够将规范和产品的灵活结合在一起，最后通过UI设计软件（Sketch、Figma）进行输出。

2）产品规划

产品规划中需要产出对应的规划文档，最常见的有产品需求文档PRD、其次是市场需求文档MRD和商业需求文档BRD。

针对初级的产品工作人员，最基本的要求是需要能够写好PRD。需求制定并不是把原型图简单的往上一放。一方面，你要深入地理解用户需求和产品目标，并且对需求进行识别和拆解，推荐阅读《金字塔法则》《软件需求（第三版）》；另一方面，要能撰写清晰、具体的需求文档，包括需求描述、功能需求、非功能需求等，以便开发团队和其他相关团队理解和实施需求，推荐书籍《火球UML大战需求分析》《需求工程》以及阿里巴巴的“五导家”模型。

随着产品开发的进行，需求可能会发生变化。因此，产品工作人员应该定期更新PRD，以确保文档内容与产品的最新需求保持一致。

3）市场调研与竞品分析

市场调研与竞品分析的内容通常呈现为调研报告，也会呈现在BRD和MRD上，用来推动领导层和团队达成共识。

市场调研不是一堆复制黏贴、截图就完事了，需要收集数据和分析、解读和洞察，将调研结果能够应用于产品决策和战略制定上面。我们通过对于企业的调研可以分析它的产业价值链和商业模式，推荐学习波特五力模型、SWOT分析和商业模式画布。

我们还要通过分析产品的迭代情况和功能反推背后的战略目标，推荐阅读和学习《用户体验要素》《蓝海战略》的价值曲线图、“用户体验地图”分析等。

4）业务数据分析

业务数据分析的报告内容通常出现在产品的规划文档和复盘报告中。初阶的产品工作人员需要，了解常用的一些数据指标的计算方式，如DAU/MAU、PV/UV、GMV、ARPU、点击率等，产品经理需要经常计算业务的转化漏斗，需要擅长使用Excel或者Python，推荐阅读书籍《深入浅出数据分析》《深入浅出统计学》《数据思维：从数据分析到商业价值》《产品经理数据分析实战手册》 《网站分析实战：如何以数据驱动决策，提升网站价值》。

另外，也会涉及到一些通过SQL查询获得业务报表的场景，所以产品经理还要了解基本的SQL语法，推荐书籍《SQL必知必会》《利用Python进行数据分析》。

并且产品经理也要知道，如何根据不同的业务特点制定的核心的可衡量的业务指标、制定产品的改进策略，推荐阅读《精益创业》《精益数据分析》《增长黑客》等相关书籍。

5）用户分析

用户分析的内容会出现在产品规划文档中，也会出现在产品复盘的文档中。在产品项目前期，我们也要参与到用户调研和用户画像制定的过程，在阶段性复盘的过程中我们也要去了解和收集用户的反馈。我们需要能够有以人为中心的设计思维方式，站在用户的场景和视角来思考问题，推荐学习“用户体验地图”的相关知识点。

绘制出有效的用户画像 Persona（相关书籍推荐《About Face：交互设计精髓》），通过分析用户在场景中的流程，找到痛点，使用心理学一些知识点去发现问题解决问题，提出产品需求和迭代的方向，推荐书籍《认知心理学》《社会心理学》《思考，快与慢》《马斯洛需求层次理论》。

对于C端产品来说，还有很重要的是，自己也要能带入到用户的角色中去和用户打成一片，成为自己产品的用户，在使用中发现更多的问题。另外，能够了解定性和定量的用户调研手段和分析的一些方法，推荐相关书籍《用户体验与可用性测试》《用户体验度量》。

有了上面5项基础的交付技能还不够，你需要更多的背景知识的支撑，才能让你的方案更有灵魂：

1）商业认知

初级产品工作者通过学习市场营销的知识，来提升自己对市场和运营的理解。例如，4P理论、STP理论。

另外，产品经理需要与运营团队紧密合作，知道产品运营的思考方式，推荐阅读书籍《流量池》《运营之光》《参与感》《爆款文案》，要从一个简单的营销页面就能感知到很多的门道。

此外，产品的每个前台功能都可能涉及到一个运营后台，涉及到推荐逻辑和管理逻辑，也要充分考虑到内容运营和用户运营的各种底层逻辑。

2）软件工程与架构

虽然产品工作人员不需要亲自敲代码，但是产品是怎么做出来的需要有清楚的认知，否则就是盲人摸象。

软件工程知识可以帮你系统的了解软件生产过程，推荐书籍《软件工程最佳实践》《软件工程：实践者的研究方法》；软件架构的相关知识，能够让你知道如何设计软件系统才是合理的，让你的需求文档更有说服力，推荐阅读《系统架构，复杂系统的产品设计与开发》、《大象：Thinking in UML》等书籍。

另外，建议所有的产品经理应该亲手尝试编程做一两个小项目，这样你对技术会有更深刻的体会。其实编程语言比英语要简单很多，特别是今天有了ChatGPT的加持，门槛变得更低了。

3）人工智能技术

AI产品经理需要了解人工智能的相关知识，知道如何将AI技术应用到自己的项目中去。包括但不限于以下几个方面：

首先，对常见的人工智能算法和模型有基本的了解，如机器学习、深度学习、自然语言处理等，能够知道常见的模型评估指标，如准确率、召回率、F1值、AUC等。

其次，需要了解数据处理和数据标注的基本原理和方法，以确保数据质量和训练模型的有效性。

同时，了解人工智能的伦理和法律问题，如隐私保护、数据安全等，以确保产品的合规性。

最后，对人工智能技术的发展趋势和应用场景有一定的了解，以保持对市场的敏感性和判断力。

此外，了解常见的人工智能工具和平台，如TensorFlow、PyTorch，以及GPT、Stable Diffusion、Midjourney、LLaMA等，能够理解它们的使用和优缺点。

4）行业认知

产品工作人员需要对自己企业当前所处的行业有足够的了解，小到一个常用业务功能的设计的最佳实践，大到整个行业竞争的格局和市场变化。

能够分析生态链和已有商业模式，推荐书籍《商业模式新生代》的商业模式画布、迈克尔·波特的“价值链分析”。

了解市场规模、增长趋势、机会和挑战，同时评估竞争对手的产品特点和定位，推荐书籍《市场竞争战略》。

预估行业的趋势，推荐阅读《跨越鸿沟》《创新者的窘境》高德纳Gartner的《技术成熟度曲线》。

另外，还要关注国家的法律法规的动态，避免在产品设计的过程中触及红线。对于行业信息的获取，一方面是同行或者业内资深人士的交流，另外一方面可以通过一些行业的自媒体或者媒体网站如36氪等媒体网站来了解。

另外，还有三个对于基础素质的考核：

1）执行能力

作为执行层，执行力毋庸置疑的重要，执行力并不是低头干事，我们需要明确自己的目标，通过能够分析问题，拆解问题。需要了解“金字塔法则”，”5W1H分析“，并合理安排的自己每日的时间和计划、“SMART法则”和“重要紧急四象限”、PDCA循环（Plan-Do-Check-Act）（推荐书籍《麦肯锡问题分析与解决技巧》），从而提升自己的工作效率（推荐书籍《高效能人事的七个习惯》）。

另外，也要了解项目管理的敏捷开发相关知识，你才能更好地管理和执行需求。

2）沟通能力

不懂沟通，就不会执行。做产品的一定要和开发撕逼的吗？不同的人有不同的沟通方式，核心的关键是站在对方角度思考，而不是陷入到不良的情绪中。

所谓沟通能力并不仅仅是把事情说清楚的能力，善于沟通的人往往善于倾听。很多时候，你的解决方案并不是完全来自你自己，需要产品经理有专业的沟通能力，要能用相关专业知识带领大家层层深入，最终达成团队共识，推荐书籍《关键对话》《非暴力沟通》。

3）学习能力

其实“学习能力”是一种心态。在职场上，许多人工作了好几年，为什么没有什么长进？其实大部分人对工作的态度是做一天和尚撞一天钟，并没有主动提升的意愿；还有一部分人虽然看似热爱学习，但陷入了“理障”和“我执”。

“理障”是把自己限制在自己认为的道理或逻辑中，忽视其他差异性的观点和信息；“我执”是相信自己永远都是对的，不接受别人的批评和挑战。这两类心理现象都会限制我们成长。

如果要破除“理障”和“我执”需要我们做到以下三点：保持开放心态、有批判思维、做到知行合一。

例如，当你画原型图的时候，可以根据一些设计原则进行设计，但是不必太拘泥某个设计原则，因为设计原则是前人总结的经验，并不适用于所有场景，当你无法决策时候，一方面你可以根据业务目标判断。另外，你可以和他人交流，有时候直觉判断可能会更加准确。另外，上线之后可以通过复盘和反思修正自己的认知，推荐书籍《刻意练习》。

三、小结

初级产品岗位的历练大概2~3年左右，时间并不漫长，如果你能知行合一，你可以学到很多东西，但也可能会遇到很多困难……但这并不是坏事，因为简单的事情是无法铸就你独一无二的竞争力的。

产品经理是一个极其需要综合能力的岗位，但是学校并没有产品经理专业，每个行业、每个公司，每个团队，每个人的理解都会有所不同。

我大学本科和硕士都是读工业设计专业，当时受保罗·格雷厄姆的《黑客与画家》的影响，有种想自己亲手把软件做出来的冲动。我在临近毕业时候特地去学习了编程技术，并找了程序员的工作，又工作了一段时间，我最终选择了产品经理这个岗位。很多人不理解，认为我做事情不够专注。其实，我并不这样认为，其实设计和编程都是一种创造性活动，我真正的目标都是要把一个好产品做出来。

正是因为有这份经历，让我对于怎么做一款互联网产品也有了更深刻的理解，之后在创业的过程中，也能够更好做好创业者的角色。

有一次创业，我的合伙人都是算法工程师，因为公司没有像样的产品，导致这家创业公司开了快一年了还是没有一个订单。当时团队也没有钱招聘设计师和前端开发人员，我和团队说：“这样吧，给我点时间，把东西做出来，到时候看看能不能卖钱或者融资”。然后，我主动承担起设计和前端开发的任务。半年过去，产品做出来了，也成功谈到了投资，团队续命成功。这就是产品交付能力的最好证明。

毕业许多年后，我偶尔还是回学校讲课。我也经常提醒学弟学妹：“产品设计师不仅仅要能出设计方案，还要有足够强的动手能力，这是传承百年的包豪斯精神。”

如果你已经正式地进入产品经理的行列，请听下回讲解《产品经理如何交付产品和战略》。

产品经理这一岗位下有许多细分范畴，其中，财务产品经理就是一个细分类别，它属于B端产品范畴，不仅需要懂业务，还需掌握财务知识。那么，你了解财务产品经理的职责所在吗？财务产品经理又有着怎样的发展方向？一起来看看作者的总结。

一、产品经理与财务产品经理

产品经理，指针对某一项或某一类的需求进行规划、设计、管理的人员，注意这里的“经理”是指个名词，泛指一种岗位，不是管理序列的“经理”、“主管”概念。

产品经理概念比较广泛，从研发对象主要分为有形产品经理、无形或数字化的产品经理，如“产品经理”概念创造者-宝洁公司，他们的产品经理主要设计、研发各种洗护用品，是看得见摸得着的有形实物；而最近火爆全网的ChatGPT，则是由微软收购的OpenAI公司的产品经理设计出来的，是一项无形、数字化产品。本文主要讲后一类（数字化）产品经理，它又分为C端产品经理和B端产品经理。

财务产品经理，属B端产品范畴，但比B端更具特色，不仅要懂业务，还要精通财务知识，在纷繁复杂的业务变化中要敏锐定位到对财务的影响，并能迅速找到解决办法。

二、财务产品经理工作职责

1. 什么是财务产品经理

简单来说就是负责财务相关需求并落地实现的产品经理。关键词：财务、需求、实现。

不懂？没关系，我们来看《资产负债表》：左青龙、右白虎，呸呸呸，是左“资产”、右“负债及权益”，相信了解点财务知识的同学就明白，这是负债表的构成。如下图：

2. 财务产品经理的范围与边界

财务产品经理根据职责内容的不同会分为不同的类别。通过上图，我们大概知道，有“货币资金”科目，对应“支付产品经理”；有“应收账款”、“应付账款”，对应“结算产品经理”；有“应交税费”，对应“税务产品经理”；固定资产、无形资产对应有”资产产品经理“；还有体现在《利润表》中的“收入”科目对应“营收产品经理”，以及“成本产品经理”、“管报产品经理”等等。

在不同的企业根据企业实际特性进行划分，如金融企业的“支付产品经理”、提供第三方服务的企业（如滴滴打车）的“结算产品经理”均会划为业务类而非财务类产品经理。

由此可以看出，财务产品经理的边界以财务为核心，到业务系统的交互点为直径所形成的圆圈。

作为财务产品经理，应该理解并能评估业务如何影响财务及后果。另外，需要具有财务敏锐度，以便在企业产品架构中定位财务产品。

3. 与财务信息化经理的区别

也许有同学会问，财务的需求，似乎并不一定要产品经理来实现，外采一款ERP也能满足财务需求了。

这话，说对也对，说不对也不对。业内大多财务信息化经理都是从友浪蝶或OS记的实施顾问转换而来。如果仅仅是满足财务的标准需求，市面的ERP确实能满足八九成。再加上ERP实施商一般都身兼咨询业务，如德勤、毕马威等，还能给企业带来一波赋能，将先进的管理理念引入企业，确实是件双赢的事。

那是不是说，就不用财务产品经理了呢？不能。

企业是发展的、变化的，企业的管理思想与理念也在不断改进、完善，从战略、规划、预算、经营、及预实对比及分析等方面为抓手，这些措施的落地都得依赖业务系统、财务系统。一千个人有一千个哈姆雷特，市面上的ERP都是标配功能，无法完全适配企业的各种特性需求。如何将企业的需求落地，就需要财务产品经理发挥聪明的智慧，或二开、或全新研发一个系统。

针对财务信息化这块，涉及方方面面，详见：《还傻傻分不清：财务信息化与财务产品？》。

三、财务产品经理如何快速做出成绩

大家都说要向T形发展，即一专多能，但作为财务产品经理得向π型人才发展，成为拥有2种（财务、业务）专业技能，将多门知识融会贯通的高级复合人才。形成知识广博、经验丰富，同时又具有几项独特竞争力、对某项专长特别突出的新型人才。

1. 理清财务事

作为财务产品经理，应站在公司整体层面设计财务产品架构。非常敏锐的感知和判断每一项业务的变化对财务的影响。

如公司开拓一项业务线，相应就会有新的收入、成本、费用、资金（收、支）等，收入会涉及收入确认准则、类型、税率；成本，如果是销售有形商品则会涉及存货、资产、库存商品等，如果是提供劳务或服务，如美团外卖、滴滴打车的撮合服务；费用会涉及计价、结算、费用控制、确认时点（五步法或三步法）；资金涉及支付、银行、对账，以及与收入的关联。

考考大家，如百度的搜索排名、抖单的广告、京东的会员费，他们的收入与成本分别怎么确认与计量？从产品化思考，应怎么设计？

另外，财务产品经理的主动意识很关键。不能等着财务或业务提需求，要主动梳理财务流程与业务流程，发现和挖掘业务、财务存在的不合理点，思考解决办法，用四象法列出重要程度、难度（实现成本）、影响面、优先级，与干系方沟通，取得支持后主动推进。

2. 钻研业务

平时都说干一行爱一行，作为财务产品经理，干一行得爱二行，财务产品要专要深，业务更不能落后。初入一家公司，最好申请到业务一线呆上1-2周，与一线业务同学手把手的干活，多听多做少问为什么。把问题与思考记在本子上，思考业务背后所隐藏的动因或原理，业务动作为什么要这么做，目的是啥。当把业务摸得门清时，才会让你不被各种伪需求和无效需求带偏。

同时成为业务最贴心的财务伙伴，将财务语言转换成业务语言，及业务当中哪些会涉及财务的点提前告知与宣贯，避免踩坑。

3. 站在产品架构思考财务产品规划

相对C端或B端其他产品线，财务产品有其特殊的一面。一是企业一般都有现成的ERP系统，无论是国际领军的Oracle或SAP，还是国内拔尖企业用友、金蝶，总有一款ERP适合不同阶段不同行业。二是如果现有ERP标准功能不满足业务需求，是基于ERP进行二开还是另行建设一个系统、再对接到财务，这很考验财务产品经理的功底，甚至连产品总监都无法能做出财务产品经理更专业的判断。

举个栗子：

A公司研发了一款智能售卖机（脑补下地铁、商超的各种自动售卖机），销售方式有3种：

• 一种是A公司直接将机器卖给终端企业B，由他们自行管理、售卖饮料、零食，并提供管理软件；
• 一种是A公司将售卖机租赁给终端企业C并提供管理软件，租金按月从C企业收取；
• 最后一种是A公司将售卖机免费提供终端企业D，根据售卖机的销售额按比例收取D企业服务费。

我们来分析下3种业务模式下如何实现自动化入账：

B企业，纯粹的销售商品行为，A公司能根据ERP的销售出库信息实现自动化确认收入、成本。

C企业，租赁模式，根据合同期间每月确认收入，同时还要将折旧、维护费记入成本，一般的ERP无法自动化实现，只能手工录凭证。需要在财务中台实现租赁收入的自动化分摊（将合同期间拆分到月）、生成应收单推送到ERP；同时需要在固定资产将处于出租状态的售卖机的折旧转入成本，这个ERP通过凭证模板能实现。

D企业，提供机器并共享收益与风险，在法律上实质为租赁经营，难点在于收入的确认。ERP是无法知道这种业务信息，需要在财务中台搭建专门模块，通过获取售卖机的销售额（无论是自动获取还是由人工填报），计算出A企业当月的服务费收入，并生成应收单、推送到ERP。

四、财务产品经理职业发展方向

财务产品经理的发展方向主要有两类，一是专业方向，二是管理方向。

1. 专业方向：财务产品专家

财务产品经理无论在甲方还是乙方，根据公司业务规模大小、发展阶段，会有不同的岗位职责。初期时也许一人负责所有财务需求，发展到一定阶段时就会产专门的财务产品团队，每负责一块或几块，专业领域会相对聚焦，产品形态会更加趋向于中台化；对个人而言，可以在其负责的领域获得深入研究的项目机会和平台。

具体的领域划分如收入、总账、税务、应收应付、资产、成本、资金、对账、结算等；成长到一定阶段后，就能独挡一面，成为财务产品专家。

2. 管理方向：财务信息化总监或负责人

在这个层级，更多的是思考建设一套合适的产品和团队，支持财务快速结账、流畅分析，赋能业务发展。眼光与格局，方向不能错，还有资源的争取与协调。在产品规划上有一定前瞻性，对财务相关信息化领域有一定研究，将业界最佳实践与最佳管理思想在企业落地。

在与团队进行需求评审的时候，如果碰见一些难以沟通的意见该怎么正确处理，不让双方都心累？本篇文章，作者将对此问题发生的原因进行分析，并提供对应的解决思路，希望能对你有所帮助。

前些天一位产品同行和我聊了一件最近遇到的工作困惑，他今年在负责自研产品的迭代设计。

当他费心尽力的完成主体方案之后，在需求评审阶段总是要花费大量的精力和其他岗位的成员解释这里为什么要这样设计。

解释的过程是很正常的，尤其是对于关键逻辑，一定要在团队内部达成共识。而他们的问题在于，关注点、争论点聚焦于一个按钮的名称，一个错误反馈的消息。时常花半个小时的时间来争论这种“细枝末节”。

有时，他甚至不想争论了，后退一步。但又觉得作为产品不能总是退让，这样不仅成果会打折扣，还会在团队内部加剧这股风气。

他说：我并非不重视这些细节，而是觉得在这些事情上投入的精力过多。甚至于可能是相互抬杠，而非正常讨论。

另外，其他成员在争论时经常说：我也是用户，我觉得你这样设计不合理。让我这位朋友哑口无声。

他觉得，团队的关注点跑偏了，本末倒置了，也觉得自己推进的太累了。

不知道其他同行遇到这类问题的概率有多大？

实不相瞒，我前些年也遇到过类似的问题，只不过当时自己比较强势，或者说能够找到一些沟通技巧，快速让对方接受。具体方法可以参见这篇文章（如果你提的需求，技术同学“百般推诿”怎么办？）。

其实愿意提意见的同事，本质上出发点都是好的，我们不能过于打击对方的积极性。但是任何事情都讲究一个尺度，过犹不及。

所以，对于上述的现象，我是这样考虑的：

我觉得这是一种“披着用户思维的外衣抬杠”的行为。因为“用户思维”这四个字，看似简单谁都能做到，实则不然。

就像人人都是产品经理一样，但真的人人都能做一位合格的产品经理吗？

答案自然是否定的。

你是用户，不一定具备用户思维，你认为自己在以用户思维考虑问题，也许只是“局部用户思维”，这和我们常说的局部思维陷阱是一个道理。

那么，我们如何解决这类问题呢？我浅析以下几个方面作为参考。

一、产品团队要树立自身的口碑和“设计话语权”

首先，最直观的表现是我这位朋友在团队中没有足够的口碑及话语权，或者说让同事足够的“信任感”。

从另一个角度讲，他没有说服你，你也没有说服他。那你为什么没有说服他呢？我觉得你理应可以说服他。

所以要么是自己对于自身的决策没有足够的信心和全盘思考，因为如果真的想明白了，再加上一些沟通技巧，大概率是能够说服对方的。

要么是自己在团队内的“威信”不足，所以产出的设计方案缺少话语权，或者缺少天然的信任保护。

试想，如果自己有一定的设计话语权，当你的方案对方不认可时，大概率他会先自我怀疑：是不是我自己哪里考虑的不周到？而不是双方意见不一致时，对方坚信自己的对的，你是错的。

二、其他成员可以建议，但产品团队有决策权

尤其是一些自研团队，我们需要头脑风暴，需要各抒己见。但对于这些观点的筛选、过滤、最终再进行挖掘与整合，打开产品团队的视野和思维，将是个很重要的过程。

而且，业务相关建议的决策权，一定要掌握在产品团队手中。即大家可以提建议，但决定采纳与否你们说了不算。

如果你觉得自己的意见弥足珍贵，那请你拿出可信的理由。

这一点，很多创业型团队，或者有些同行很不好意思拒绝对方的建议。我觉得这是产品人在成长过程中势必要迈过的一条“心理障碍”。

假设连自己同事的“伪需求”都无法解决，将来如何解决客户的建议、用户的建议、领导的建议？

三、产品团队要对结果负责

结合上一条的决策权，紧接着就是：谁决策，谁负责。

产品团队要勇于对结果负责。当你觉得对方的建议会对结果造成不利影响时，那就坚持自己的思路。

毕竟，踩坑也要踩到自己的坑里，而非别人的坑里。这是一个很正常的现象。

四、本质上是团队各个岗位职责边界的问题

试想，产品经常给研发提管理意见，研发经常给产品提设计意见。乍一听这个团队挺扁平化，大家能够充分发挥自身能力。

但细想一下，你经常被其他岗位同学“提建议”，你是什么心情？会不会想着：将来也给他提回去。

而且我们经常会发现，自己的本职工作还没有做好，关注点就会向外探索。这种模式不利于自身的专注和深耕。

相信专业的人做专业的事。当团队内部互相不认可对方是专业的，那便是出了大问题。

当然，并不是说各岗位之间各司其职，却不相互沟通；而是凡事都有一个尺度和体系在下面支撑着，我们需要在这套体系里运转。

当体系缺失，又没有绝对领导者时，便是纷争的开始。

很多问题，都要打破自己的惯性思维，不要停留在表象去考虑如何说服对方，而应该向内观察一步，从表象的背后寻找更深层的“道”和“因”。

我只把这个问题向内挖掘了一层，如果继续探寻背后的问题，可能需要更高层的领导介入解决了。因为这本身又是如何统一内部目标和思维边界的团队管理问题。

五、写在最后

最近刚刚读完《复盘》这本书，虽然我对本书的整体评价不高，但其中有一个对于团队U型复盘的章节还是能够为今天的话题带来一些启发。

团队管理中的一个核心挑战，就是如何从外在驱动到内在驱动，这需要一个反思的文化和向内看的氛围。

无论是个人还是团队，我们都习惯了一种“自动反应”。即在面对问题的时候，没有经过深层思考，而直接给出条件反射式的答案。

而且，如果一件事偶然出现，责任可能在别人；如果一件事反复出现，责任可能在于你自己。

所以，把关注点先向内挖掘，再尝试突破自动反应，再从个人走向组织，重复向内看和突破自动反应的过程，循环几次就会有更多有效的方法出现。

聊了这么多，最后只想说一句话：

我说的都是错的，真正的答案在你的脑海里。

需求是产品设计中非常重要的一部分，有需求才能输出对应的产品。本篇文章将分析完整需求中包含的一些场景，对产品经理岗位提供一些参考，希望能对大家有所帮助。

产品需求的重要性：

在整个产研过程中，产品需求是源头活水，是产研工作最重要的输入。产品经理作为产研体系的发动机，交付高质量的产品需求，是提高产研效率、节省产研成本的重要保障。

从项目管理角度看，如果需求是不清不楚的，意味着项目范围的不确定性，更无从谈起项目成功了。

产品需求质量差的表现：

研发、测试同学吐槽的需求不清不楚的常见场景：

• 一句话需求。
• 需求点这里漏那里漏了。
• 需求描述模棱两可、含糊不清。
• 缺少以前功能逻辑的描述。
• 有没有性能需求。
• …

交付高质量的产品需求：

一份高质量的产品需求，应该是具备以下重要特性：完整、具体、准确、友好。

完整

产品需求的完整性，包括标配需求，分支流程、异常流程的闭环；包括功能逻辑的齐全；包括不同的业务场景；包括上下游关联影响的说明；包括附件资料；包括非功能性需求…

标配需求

犹如键盘之余电脑、座椅之余桌子，是最基本该有的，一提到主体就该想到不能缺的部分。

很常见标配需求的场景：

1. 表单（新增、修改数据）

• 是否必填：需描述字段是否必填，以及必填的提示。
• 是否可编辑：说明数据项是否允许编辑，是否只允许特定用户、特定条件才能编辑，允许哪些用户、哪些特定条件才可编辑。
• 数据唯一性：哪些字段值、或字段值组合不允许重复。
• 长度：允许输入内容的长度，包括最大长度、最小长度；输入、黏贴超长的内容如何处理。
• 格式：允许输入内容的格式； 例如只允许输入数字和小数点、不允许输入“*”。
• 默认值&选项：需要有默认值的字段（例如下拉框），描述清楚 默认值是多少，有选项的字段，列举每个选项的具体内容。
• 隐藏字段：界面不展示但需赋值的隐藏字段，描述该字段的取值逻辑。
• 非输入字段：非手动输入但界面又需展示的字段，需描述如何取值；如果是由其他触发条件自动带出数据的情况，描述清楚具体触发条件，以及根据什么逻辑带出数据。
• 表单验证触点：描述数据验证的触点；例如光标离开验证、键盘松开验证、提交表单验证。
• 验证提示：每种验证（必填、格式错误、重复等）都需提供验证提示语；验证提示语中如有变量，需描述变量的取值规则；验证提示语的展示位置，展示形式。
• 提交数据：提交表单时，提交、或保存按钮不可重复点击；表单提交后，页面跳转的目标页面。

新增数据的示例：

2. 数据列表

• 查询条件：指明默认的查询条件；输入类的查询条件，描述输入的字符种类、长度限制，以及是否支持模糊查询、左模糊、右模糊、还是左右模糊查询； 选择类的查询条件，描述具体的选项、以及是否支持多选等。
• 查询：进入数据列表默认就查询并展示数据，还是需点击“查询”按钮再展示数据。
• 查询的数据量：当查询的数据量很庞大，需限制只能查询满足特定条件的数据（例如只查某时段的数据）；或者查询出结果前提示用户：查询大量数据需等待。
• 数据展示形式：列表中默认需展示哪些字段；特殊数据类型的展示格式、内容超长情况下的展示形式；例如时间字段，格式展示为1900-00-00 00:00 。
• 排序：数据列表默认按哪个字段排序； 列表中哪些字段需支持点击列头排序。
• 分页：数据列表是否有分页，每页默认展示多少条数据，是否支持动态选择每页展示的数据量、选择项有哪些。
• 其他配套功能：是否需要个性设置列表字段的功能；是否需要导入、导出功能等。

3. 增加字段

• 字段的用途、业务类型、长度：描述清楚 要增加字段的作用和用途，用于存储什么类型的业务数据，该种业务数据可能的最大长度，最好提供示例数据。
• 字段默认值、取值规则：要加的字段的默认值，如果是选择类型的字段，列举选项有哪些；如果要加的字段是系统自动赋值，需描述具体赋值规则。
• 字段的展示：要增加的字段在哪些地方需要展示，例如详情页、列表页；描述字段加在那个功能模块。
• 字段的查询、编辑：要增加的字段是否要支持查询、是否用于查询条件；是否可编辑，是否由特定人才能编辑。
• 对外接口：需描述哪些数据接口需要同步增加出参。
• 存量数据：描述清楚，增加字段后，存量数据是否需处理，以及如何处理。

增加新字段后，对于存量数据的处理是被遗漏最多的。

在以下示例中，要在客户信息中增加新字段 最后跟进时间， 对于增量数据从客户跟进信息的子表中自动赋值，对于存量数据如果漏了做处理，则该字段就是空值。

用户想查询最近N天未跟进的客户，就查不出完整的数据，对于用户就是个系统Bug 。

4. 删除数据

• 删除限制：描述 删除数据前，要有哪些限制，不允许随意执行删除逻辑。
• 删除提示：描述 删除数据前的确认提示，提示用户系统将删除哪些或多少条数据；如果删除数据失败，如何提示。
• 批量删除：是否需要支持批量删除；如需要批量删除，数据列表中需要支持批量选择数据；批量选择数据后，如选中了不可删除的数据，执行删除时如何处理。
• 级联删除：删除主表数据后，是否要同步删除子表数据、以及上下游强关联的数据，删除哪些子表的数据，哪些强相关联的数据；删除子表的数据后，是否要同步删除主表的冗余数据，删除主表哪个字段的数据。
• 数据恢复：描述清楚，被删除的数据是否还可以恢复，如何恢复。

如以下示例中，1个客户对应有N个联系人， 同时客户信息主表中冗余了客户主负责人姓名和电话。

当删除客户信息时，需说明对应的N个联系人是否需同步删除。

同样的当删除客户联系人子表中的主负责人时，客户信息主表中冗余的主负责人姓名和电话是否需同步删除。

5. 导入数据

• 导入模板：需提供导入摸板，以及导入的示例数据；提供重要字段的填写说明；用星号标明必填字段；如果是枚举字段，模板文件中需支持下拉选择；对于金额类字段，标明金额的单位，设置数据验证只能输入数字和小数点。
• 模板格式：针对Excel模板文件，设置好模板文件的默认行高，避免用户要重新自己表格行高。
• 导入验证：描述 导入模板中哪些字段必填，模板中字段与系统中字段的对应关系；描述 允许导入什么格式的数据文件、导入多大的数据文件。
• 导入结果：展示执行导入的进度信息，提示导入数据的结果（成功多少条、失败多少条）。
  需提供查看、或下载导入失败的数据的功能，并且记录某项数据导入失败的具体原因，可在导入失败的文件中查看。

典型的导入模板文件示例：

6. 导出数据

• 导出模板：提供导出模板，并描述要导出的每个字段的取值逻辑。
• 导出大批量数据：描述导出数据量的最大限制，如果要导出的数据超过最大限制时，如何提示。
• 导出数据以及结果：描述导出哪些数据，比如是导出 查询出的所有数据、还是导出当前页的数据；查询无数据时导出按钮是否可点击；导出数据完成后，需提示导出的结果。

7. 定义数据接口

• 接口的调用场景：描述清楚接口在业务上的应用场景。
• 接口调用方：描述 接口用于给哪些业务系统调用。
• 接口调用量：描述清楚接口大概的日调用量，用于技术同学设计接口性能时作为参考；例如某个查询数据的接口调用量100次/日、与100万次/日，在设计接口性能时需考虑的因素就完全不在一个量级。
• 接口功能描述：接口内部读取、新增、修改、删除数据的主要功能、业务逻辑。
• 输入参数：列举接口需要的每个入参，每个入参是否必传，以及每个入参对应哪个模块的哪个字段；接口入参是否要求批量传入。
• 输出参数：列举接口的每个出参，以及每个出参的读取、计算逻辑。

如以下为定义数据查询接口比较典型的示例：

未完待续。。。

想要做出一款完美的产品几乎是太不可能的，所以产品经理在做一款产品时，需要考虑其优先级的问题——做好决策，懂得取舍。那么，作为一名产品经理，如何做好决策？让我们看看作者的对此的分析。

本文主要的感悟来源于B端和平台业务，大抵是不适用于所有产品的，尤其是To C的产品或业务。

在现实情况下，兼顾业务实现、管理质量、用户体验等多方价值的“完美”产品是很难存在的，由于商业行为天然存在的逐利性，投入产品设计和研发的人员资源总是有限。

在B端业务中，由于其目标行业、覆盖场景的范围，因资源问题需要做出的取舍尤其常见。

下面展开谈谈常常会遇到的决策场景类型。

一、以业务为中心or以用户为中心

C端产品更接近日常生活，知名度更广、声量更高，所以市面上大部分产品经理的分享习惯以用户为中心的框架来设计产品，但实际上在2B的业务中，单纯以用户为中心的设计会有诸多不足。

产品或者说信息系统有整体性、逻辑性、时效性等特点，得以支持复杂度高、需要多角色协作的业务活动，但其本质仍是解决问题的手段之一。如果在特定场景有更高效率、更低成本的手段能解决问题，产品设计就不是第一优先级的解决方案。

所以，产品的第一优先级仍是解决业务问题，而不是用户体验。（仅说明优先级，不是用户体验完全不重要的意思）

经常会有同学抱怨，内部系统如OA、财务结算平台、订单管理等怎么怎么难用，体验怎么怎么差。其实究其本质，这些系统的出现不是在满足操作者的使用体验，而都是为管理质量和管理效率服务的。

这个就是典型的为业务服务而非为用户（操作者）服务的场景，体现也是B端业务与C端业务主要的区别（B端是客户（付费角色）与用户（使用角色）分离的）。

这时候有人会犯嘀咕：“不对啊，我做的业务也是To B的，但是用户使用体验我们也很重视啊”。

那基本上就2种可能：

1. 用户操作体验已经差到对业务目标流程有阻塞（如成交）或显著的导致成本增加了（如客户咨询量）。
2. 业务红海，业务本身已经没东西可以卷了。

二、扩展性与过度设计

前些年阿里中台带来的中台风潮，一直到今年阿里拆中台的尘埃落定，“中台”这个词或多或少的会出现在产技人的视野里。“中台”本身偏技术概念，产品经理没有这个能力和背景展开，这里要讨论的是伴随“中台”而来的扩展性。

扩展性

“指一个软件和系统能够让其他程序员在未来能增加新的功能以及修改现有功能，并且新增功能的同时还必须不损害现有系统或软件功能”（wiki释义）。

白话点讲，就是当前的设计是否能兼容或者快速适应未来业务的变化。看似是技术同学的工作范畴，但在部分To B复杂业务场景中，花大量时间接触业务方，理解并抽象业务的角色是产品经理。

扩展性设计的过程是在抽象业务，抽象程度越高扩展性越强，配置越灵活，但是否抽象程度越高就是越好的设计呢？

• 不尽然。一方面，配置灵活带来的是更高的开发和测试成本，于业务而言，配置的大多数场景可能存在理论里的“伪场景”，所以很大一部分可能是无用的投入。
• 另一方面，越抽象越通用的设计，在一定程度上是“牺牲”业务细节的，进而“牺牲”一部分的业务效率。

高扩展性的设计，适用于需要快速试错的业务方向，但对于大多数业务知识相对稳定的场景，需要谨慎权衡，否则可能会因为过度设计，让本不富裕的开发资源雪上加霜。

提到抽象设计，这里推荐一本书：《“图解”产品：产品经理业务设计与UML建模》。

笔者认为是目前市面上对产品最友好的领域设计和UML建模的工具书，过去DDD（领域驱动设计）的相关书籍和文章主要面向的是开发人员，序言之后很快就进入技术设计层面的讨论，读起来十分痛苦且收获有限，于非技术同学十分不友好。

三、长尾需求是否要被满足

面向C端的长尾场景做的产商品服务，近些年获得成功的案例屡见不鲜，但面对B端业务的长尾需求，应该是怎样一套决策逻辑？

这里总结下笔者的分析链路：

• 长尾需求出现的原因是什么：线下业务不规范？没有引导用户导致的奇异使用姿势？
• 长尾需求是否能通过非产品手段解决？
• 长尾需求是否是阶段性的，是否在未来可能成为主流？
• 是否有其他不可抗力：如大客户需求依赖？政治需求等等

面对长尾需求需要谨慎取舍，因为长尾需求很可能一不小心就做成ROI极低的“私人定制”。

四、结语

对于从业3年以上的产品经理，相信基本工作技能已然扎实，什么需求分析、绘制原型、跨职能沟通等在这个阶段都不太值得再做展开。

这个阶段产品经理的工作实际上是在不断地做决策，核心竞争力来源于做正确决策的范围和能力，是对逻辑能力、业务建模、行业理解等的综合考验。

B端产品经理在B端市场中，是赋能业务的重要角色。那么如何具体的对产品进行赋能？作者将以B端产品的四个形态分别做详细地介绍，希望本篇文章能对你有所启发。

最近常常被问到，企业内部的B端产品怎么去赋能业务。这个问题一般也是老板和技术部门经理常常要思考的问题，产研团队的价值该如何定义？高薪养了这么多人，这笔钱到底花的值不值？

那么今天我以一名业务产品专家的视角，分享一些实践经验。

一、B端产品所在公司是什么样的

B端产品，它不像C端产品那样可以直接面向用户需求，C端产品通过汇聚流量或促成交易来为企业带来收入。而B端产品面向企业，以低边际成本的产品形式传播企业管理思想和管理手段，最终帮助企业管控流程、划分责任、降本增效。

B端产品来源于业务，服务于业务，可以说赋能业务是B端产品的天职。那么在谈赋能业务之前，先看下B端产品所在的公司是什么样的，这样方便我们在具体的组织结构下谈赋能思路和方法。

1. 企业内部都有哪些角色

当企业发展到一定阶段，就会产生B端产品的需求，辅助其规范管理，公司业务形态范围也非常广，涉及生产、制造、零售、销售、供应链、物流等等。

那么这里以一家快递公司的组织架构为例，拆解公司内部人员角色和定位，并且以离客户的远近将企业分为前中后三个组织：

• 前台为一线执行人员，例如快递公司的快递小哥、仓管员等，一线执行人员按照公司管理要求直接或间接服务客户。其身位离客户最近，所以前台的服务质量，会直接影响客户体验。
• 中台为业务人员，一般像战区、大区、总部的业务管理部门等等，业务人员通过管理一线员工按照既定的业务流程和业务动作服务客户。业务人员会直接为公司的业务目标负责，是业务目标完成好坏的直接利益干系人，有责则有权，中台业务人员拥有业务规则的制定权和解释权，在绝大多数情况下产品规则服务于业务规则。
• 后台为技术部门或一些其他的职能部门，后台人员以其角色擅长的方法辅助业务部门完成业务目标，比如HRBP会贴合业务目标来配置业务成员，包括人数和级别结构。

技术团队早些年一般是负责系统落地实施的被动角色，但近年来随着数据的积累，技术的升级迭代，技术能做的事情越来越多。所以技术部门的地位上升的很快，甚至在一些有数字化基因的企业，技术部门可以直接把控业务。形成技术决策，业务辅助的局面。

但这需要诸多前提，大部门公司还是业务主导，技术辅助的格局。

2. 那么这些角色都是如何赋能业务的

首先，这些角色的产生都是为了保证公司业务的正常运转；

其次，他们通过各自的专业力来差异化赋能业务。

• 一线员工用执行：一线员工通过严格执行公司的管理要求，完成与客户的服务闭环，用实际执行赋能业务目标达成。
• 业务员工用流程：业务员工通过制定标准化SOP，来规范一线员工的执行动作，保证一线员工的服务质量，是用流程用SOP来赋能业务标准化发展。
• 产品经理用技术和数据：①产品经理以技术和产品为手段，帮助业务团队高效落地管理要求，通过赋能业务团队的方式间接赋能业务。②通过数据分析发掘业务问题，制定系统策略对现状进行调优，从而直接赋能业务。

如何赋能业务，不仅仅是产品经理，而是企业内各角色都需要思考的问题。

如何发挥角色优势，从不同角度助力企业业务发展，值得思考。

二、B端产品经理如何赋能业务

B端产品细分类型很多，不同形态的产品有着不同的赋能业务的路径和方法。

大体将B端产品粗分为以下四种形态：工具型/管理型/流程型/策略型。

1. 工具型产品

介绍：工具型产品以提供简单便捷的操作工具为目标，通过线上化集约的方式，减少相关人员完成业务活动的时间和精力。

如各类工作台产品，提供计算工具、分析工具、任务管理工具、沟通工具、报表工具等功能，均属于此范畴。

赋能思路：工具型产品核心目标之一是化繁为简，简化流程、优化交互，所以工具型产品可以向着傻瓜化、简单化、便捷化三个方向去赋能业务。

• 傻瓜化：想用户之所想，通过数据采集、分类、标注等，提前预测用户下一步行为，并提供参考信息辅助决策，代替用户去做信息收集、整理、判断的事情，如智能调度、智能客服等；
• 简单化：简单化分为交互的简化和流程的简化。交互的简化是指替用户排除不必要的信息干扰，使信息要素以直白无争议的方式呈现给用户，做这块的产品经理可以参考John Maeda的《简约至上》，书中有介绍一些实用的设计方法和工具；流程的简化指的是去掉重复的流程，合并相似的流程，避免在业务流程和产品操作层面产生浪费，如审批流下放等，需结合实际业务场景进行流程梳理，请注意先穷举再删减，避免遗漏。
• 便捷化：便捷化的操作体验可以让用户身心愉悦，便捷化的最理想情况是业务人员即用即走，用最短的时间完成规定的业务动作，便捷化的产品设计如各种一键操作（合并多个操作步骤）、智能记忆、表单自动填充等。

2. 管理型产品

介绍：管理型产品是帮助业务高效管理的手段，也是管理者与执行者之间的信息交互平台，该平台既是业务管理者向执行者传递业务管理要求的渠道，又是业务执行者记录回传线下业务活动的通路。

例如快递公司给快递小哥使用的app，既向快递小哥约束了每件包裹的揽收妥投时效，通过超时预警/违约罚款等方式进行管理，又负责记录回传快递小哥完成揽收/妥投的位置及时间。

赋能思路：管理型产品的赋能方向，是以产品为载体将业务管理思想低成本落地。那么怎么体现管理型产品的业务价值呢？

1. 管理要求生效要快；
2. 管理效果要好。

1）管理要求生效要快

体现在两方面：

① 系统上线要快

快速厘清业务规则，快速输出mvp产品原型，快速上线验证，适当留一些开关和配置以防上线后业务规则变更，如何将业务需求快速实现落地，需要产品经理从业务理解力和产品技能力两方面去提升自身能力。

② 上手应用要快

开发完是第一步，让一线用起来才是关键。系统上线后一线不会用或不按规定使用的情况很常见，那么可以通过前置产品宣导、产品操作指引、线上学习sop等方式让一线快速上手，来达到业务预期。

2）管理效果要好

即产品功能上线后，业务数据要有好的改观。

产品功能的实现只是第一步，对产品经理来说产品上线意味着苦劳分拿到了，但功劳分能不能拿到，还得看能不能推动业务数据向好。

在推动业务数据向好的方面，也有很多可以做业务赋能的触点。比如产品沉淀的数据流，可以用于分析业务链路中的薄弱点或断点，并通过技术手段进行修复或联动业务调优业务模式。

举例，快递配送，在城市郊区等密度较低的地区。郊区配送站负责的配送范围要远大于市中心配送站的配送范围，这就带来快递员往返配送站和目标配送小区的路程很远，就会发生配送超时遭到客户投诉的情况。通过结果数据（客户投诉）和过程数据（配送时效）都能发现这个业务问题，那么产品联动业务，对超时严重的线路增加临时中转站，通过二程接驳的方式，来减少快递员往返于路上的时间，来使业务数据向好发展。

3. 流程型产品

介绍：流程型产品，主要负责设计数据在系统内或系统间的流转规则，以人类比：如果说数据是人体的血液，那么流程就是血管，为数据的流通提供管道。

流程型产品设计包括出入参定义、触发条件设计和状态机设计等，以保证业务数据可以按照既定业务规则正确流转。

如用户在电商平台下订，商城订单系统生成订单，并将订单收发货地址等信息传递给物流系统，物流接单系统接收订单，经加工后下发给运单系统生成物流运单，物流运输完毕后生成结算单给结算系统，结算系统完成轧账无误后通知运单系统结算关单。

这个流程中客户订单信息在多个系统中流转，不同系统侧重的信息不同，不同业务场景下的处理逻辑也不同，流程型产品需要考虑正向、逆向、异常分支等流程，逻辑严谨且面面俱到。

赋能思路：由于流程型产品负责系统内部的数据流转，甚至可能无外在的可视化界面，对业务是黑盒。所以流程型产品可以考虑数据本身的业务价值去赋能业务。

1. 首先将黑盒中的数据状态、等待时间等关键业务信息可视化，将数据在系统中的流转过程以用户语言呈现。
2. 其次，数据流转会产生痕迹，有痕迹就可以做路径分析，可以从响应速度和准确度等方向去识别业务问题。比如618在商城买的手机，为什么迟迟没有发货，抑或是订单爆仓时触发时效报警等。
3. 最后，以数据的视角给与业务输入，与业务一起复盘业务问题，调优业务流程。

4. 策略型产品

介绍：B端的策略型产品不同于C端，C端策略如搜索/推荐策略、广告投放策略等，属于供需匹配型策略，而B端更侧重业务策略。

比如为了应对618快递量猛增，快递站点都会提前招募临时工，那么招几名临时工，提前几天招，自营和临时员工的最优比例是多少，策略型产品会根据站点模型输出一个成本体验最优的解决方案。那么这是业务策略，是复杂业务场景下的人机交互全链路解决方案。B端的策略型产品，会在传统的信息化产品之上更进一步，产出用于辅助业务人员决策的分析型产品方案，甚至是代替业务人员的自主型决策产品。

赋能思路：B端策略型产品的业务赋能过程，一般以数据为起点，对物理世界中的业务活动进行数字建模，然后在数字世界的沙箱环境下不断通过历史数据对策略模型进行回归调优，直至得到目标结果最优的策略方案，最后将策略方案放回物理时间进行应用和验证。

策略型产品的工作流可简化为以下三步：

1）发掘业务问题

寻找那些在物理世界不可能或需付出高昂成本去做策略实验的业务场景。如快递场景下：临时工招募策略、车辆行驶路径规划策略等。

这类业务场景在物理世界有着天然的时空限制，完成一次业务活动的条件多、周期长，且无法多次重复的进行线下验证，那么这类业务场景是比较适合在数字世界进行模拟实验，需要产品经理拥有一双“慧眼”识别出这类问题。

2）设计&实现算法模型

1. 首先，策略产品与业务人员共同对业务场景进行深层次剖析，对流程环节、业务动作、参与角色、前置条件、后置行为等维度进行业务规则穷举和排列。
2. 其次，抽象影响业务的信息元素并赋予权重，纳入算法模型参数。再次，制定衡量业务好坏的指标，作为算法模型的输出结果，如时间最短、成本最优、质量最高等维度。
3. 最后，与算法工程师一起进行模型实现，并通过不断的参数调整得到最优策略模型。

3）进行线下验证

经验告诉我，线下验证这步是最重要也是最难的，如果做不好方案很难落地。

重要是指无论在沙箱环境下策略模型运行的多么稳定和优秀，放到现实环境后都可能“水土不服”。原因是算法模型的训练过程是用历史数据做预测，而现实世界的输入是随机和不可控制的。如时间因素、人为因素等，所以需要把算法模型拿到线下去跑一跑是至关重要的，线下跑的通才是真的有价值。

有难度是指线下环境的配合能力，因为要在现实环境中验证算法的正确性，需要线下的人、物、动作都必须要严格按照算法的指导完成，即使算法结果是有错误的也必须照做，否则实验无意义。

那么就需要业务侧提供一块“试验田”来配合，要知道线下的业务单位都是企业运营流程中不可或缺的一环，是紧凑不可打断的，基本不会有容错去配合做实验。

所以如何找到一块合适的“试验田”，需要自上而下的去共识推动，对实验对象进行说服和免责。这个过程本身是充满挑战和有难度的，需要产品经理对算法策略价值有清晰的认知和表达，为了获取一定的支持和资源，有时讲一个“好故事”也很重要。

三、写在最后

在B端市场中，产品经理的角色不仅仅是开发产品，更是赋能业务的重要角色。

B端产品经理要突破舒适区，去探寻业务的本质，去感受用户的需求，去探索先进的技术，让业务更加高效、智能。

只有这样，才能在激烈的市场竞争中脱颖而出，成为行业的佼佼者。

比波特五力模型是产品经理在工作中常用的一种行业分析工具，帮助产品经理分析不同的工作问题。而本篇文章，将为大家介绍更简单、更细致的分析工具——CPCC分析模型，接下来，让我们看看作者对此模型的解读。

CPCC(Customer,Product,Company,Competition)分析模型在融合了波特五力模型的基础上进行了更细维度的拆解，是一个非常好用的思维工具。

你在工作中或者面试中是否常遇到以下问题：

是否应该研发某款新产品、是否应该进入某市场领域、某个创业项目是否有成功率、某个策略对公司是否有效，如何让产品保持增长、公司行业地位评估、竞品分析等等。

也许这些问题让你感觉无从下手，又或许你进行了点状方式的思考疏忽了一些关键要点导致分析的结果不合理。

笔者今天想在这里给大家推荐CPCC(Customer,Product,Company,Competition)分析模型，该模型在融合了耳熟能详的波特五力模型的基础上进行了更细维度的拆解，在好记的同时也能更友好地帮助你思考以上问题。

一、Customer

1. 谁是目标客户群体

（1）目标客户细分，可以通过客户的规模、成长速度、占市场的比例来对目标客户进行分类。

以按照规模分类为例，SAAS公司常常是根据客户的用户规模来进行分类：

• SOHO Customer, 1-19个用户
• SMB Customer，20-99个用户
• Mid Market Customer，100-499个用户
• Major Customer，500-999个用户
• Enterprise Customer, 1000个用户及以上

（2）客户数量增长趋势，通过对比今年数据与往年历史数据的差异，能看出市场是属于上升期还是平稳期。

例如2019年到2022年这段时期由于疫情许多公司开放了居家办公政策，线上会议需求随之激增，所以有相关需求的客户也翻倍增加；而到了在后疫情时代，员工返司办公对于线上会议的需求随之降低，客户增长趋势就回到了相对平稳的复合增长率。

2. 每类客户的核心需求

以上述提到的按照规模方式分类为例，SOHO customer的核心需求跟Enterprise常常有较大的差异。如SOHO客户作为个体户或者小企业运营者，往往没有专业的IT管理员来对产品做维护管理。

所以他们在功能方面更在意易用简便能快速上手，在价格上也更为敏感，对统一化管理、批量化数据导入导出、产品合规性、是否可集成的需求往往要比财大气粗的Enterprise更低。

3. 愿意为产品支付的价格

这与你的产品定价策略有很大的关联，只有你的产品价格锚定在目标客户群体的付费意愿范围内，客户才会愿意买单。

以共享单车为例，出行者更多使用其作为3公里左右距离的交通方式，如果涨价到单次骑行10元以上，是否很多出行者会改为打车或者步行呢？

4. 目标客户群体偏好的购买渠道

1. 例如对于奢侈品牌来说，顶级商场酒店还有机场是目标客户群体偏好的渠道。
2. 如果你的客户是普通宝妈群体，也许宝妈交流群、短视频直播是更适合的切入渠道。

5. 客户的集中度和议价能力

假设我是一家土豆供应商，我公司收购的土豆中有80%都是卖给麦当劳，20%是卖给其他的蔬菜分销商，在这种情况下单一客户对我的销售份额占比大，议价能力也强。

当客户集中度过高的时候，就会给公司的运营带来更大的风险。

二、Product

1. 产品的核心价值

满足了客户什么需求？客户是否会有购买动机？

核心价值往往越简单直接越好，一款优秀的产品往往用一句话就能概括其核心价值。

2. 质量绝佳或有否差异性

你的产品是否能够在质量/功能上做到较高水平？或者能够创造什么样的差异性打动目标客户？

最近常常有互联网人士开玩笑说35岁以后去摆摊，那在同质化严重处处是铁板鱿鱼、臭豆腐的各大夜市，你怎么让自己的摊子脱颖而出呢？

3. 识别行业中优秀的产品

行业中优秀的产品是什么样的，你的产品是否能做到。

4. 替代者

人们往往疏忽对替代者所带来的威胁，但它带来的冲击往往可能是毁灭性的。

比如鲜果茶饮市场对传统瓶装饮料、雪糕售卖量的巨大冲击，刷抖音应用对刷微博、朋友圈等碎片化时间的瓜分。

5. 产品生命周期

一般我们把产品的生命周期分成种子期、成长期、成熟期、衰退期，处于不同时期的产品需要有不同的运营与研发策略。

6. 打包或组装成套餐以满足客户的需求

部分产品虽然在产品特性上没有差异性，但是通过打包或者组装的方式满足了客户的一揽子需求，也能够得到客户的青睐。

比如卖烤箱的商家打包卖打蛋器、烘焙手册、防烫手套等等，满足客户了做甜品场景下的一系列需求，客户怕麻烦就直接购买套餐来节约时间。

三、Company

1. 能力与专业度

公司的优势是什么，专业度在市场中的认可度如何，对于创业公司来说，创始人队伍的能力矩阵重要性就特别高。

2. 分销渠道

渠道是否优质，渠道是以自营为主，经销商合作为主，亦或是两者的组合？公司的渠道管控能力强不强？

3. 成本框架

总成本 =（固定成本+浮动成本）* 数量

分析固定成本和浮动成本所占的比例各自是多少，高固定成本+低浮动成本的结构往往更佳，浮动成本低时能降低公司运营的风险，高固定成本则是行业资金门槛要求。

4. 无形资产

包括品牌价值以及品牌忠诚度，例如可口可乐以及百事可乐拥有巨大的品牌忠诚度。

同时每年也在维持品牌曝光度上持续投入高额的广告费用，让其他玩家完全没有信心能够去抢得一杯羹。

5. 财务状况

如果是上市公司，可以通过看财务报表的方式了解其现金流情况以及负债情况。

6. 组织结构

是否与客户需求契合，比如一家ERP公司，把产品分割成了HRM、CRM、FI等多条产品线，每条有不同的销售负责人。但客户想要的却是与单一联系人合作完成各产品线的组合购买，那这也许就不是一个好的组织架构。

四、Competition

1. 竞争者集中度以及结构

现有的竞争格局是什么样的，是垄断、寡头垄断、强竞争还是玩家尚少。

2. 竞争对手行为追踪

可以追踪下对手在上述提到的Customer, Product, Company方面各自的表现如何。

3. 标杆竞品

行业中的翘楚产品是什么样的，他们正在往哪个方向发展迭代，他们是否正在执行一些我们未启动的项目。

4. 进入门槛

进入门槛越高，能入场分蛋糕的玩家越少，门槛可以是资金门槛、技术门槛、法律门槛、管理门槛、规模效应等等。

如对于具有规模效应的企业，当其规模越大成本分摊得越低也能够把产品价格打得更低，新进入者想要逆风翻盘就会异常困难。

5. 供应商集中度

如高端芯片就是典型的供应商集中度高产品，当供应商集中度越高的时候话语权就越大，如果产品对供应商有着强依赖关系，那供应商涨价你也只能跟着涨价。

6. 行业监管环境

监管严格的行业往往竞争相对来说没那么激烈，同时如果行业监管环境变化频繁，那企业的风险也更高。

如之前教育行业政策的变更，对许多K12企业和机构就是灭顶之灾。

7. 行业的生命周期

类似于产品生命周期，每个行业都有其兴起也有其式微的时候。当行业处于上升期时，蛋糕越来越大，即使你的产品竞争力一般，也能够从中分得一杯羹。

以上就是CPCC框架的所有内容，该框架既可以运用于工作以及创业中各类战略问题的分析，也可以用来在面试中有条有理的回答面试官提出的假设类场景题，希望对大家能有所帮助。

需求变更是指对项目功能、性能、进度、成本等的变化调整，作为一名产品经理，如何正确应对需求变更？本篇文章作者将详细为我们介绍在项目的不同阶段处理需求变更的不同方法，希望对你有帮助。

提起需求变更，多数产品经理人并不会陌生，它基本在我们日常的需求迭代中都可能会出现，控制的好，项目正常上线，项目组成员皆大欢喜。

控制不好，业务负责人、合作方、老板，包括研发兄弟们，都有可能不满，甚至情绪激愤时还会“口吐芬芳”，故此乃产品经理“荣辱之地”，不可不察也。

可是，需求变更就像五月的天气一样，说变就变，且牵涉多个相关方、上下游，如何应对？且如何在变化之中，能够快速精准识别定位变更原因，应对风险？

以下我将就自己的一些个人经验和大家分享一下。

一、认识需求变更

要搞清楚需求变更，我们先要清晰需求定义和分类。

1. 名称定义

需求变更是指在项目开发过程中，客户或相关方对项目需求的变化，包括对功能、性能、进度、成本等方面的调整。

2. 常见分类

• 用户反馈。用户使用产品后提出的反馈和建议可以导致产品需求变更。用户反馈可能包括对产品功能的需求、对用户体验的改进建议、对产品性能的提升要求等。
• 市场调研。市场变化可能是产品需求变更的原因之一。竞争对手的发布、市场趋势的变化、新技术的出现等都可能导致产品需求变更。
• 业务需求。公司的业务需求也可能导致产品需求变更。例如，公司可能需要推出新产品以扩大市场份额，或者需要将现有产品与新的业务线进行整合。
• 法律法规。突然更新的法律法规的变化也可能导致产品需求变更。例如，某些国家可能颁布新的隐私法规，这可能会导致公司在产品设计中需要进行相应的调整。
• 技术限制。技术限制也可能导致产品需求变更。例如，在某些情况下，技术限制可能会导致产品无法实现某些功能，或者需要使用新技术来实现。
• bug修复。产品中的错误和漏洞可能需要修复，这直接会导致产品需求变更。

二、需求变更的生命周期

产品的生命周期分为：需求调研、产品方案初步阶段、详细阶段、方案评审、研发阶段、上线验收。

需求变更在产品生命周期的整个周期内都可能会出现，而每一个阶段应对措施是不一样的，为什么？

因为在每一个阶段需要花费的时间和人力资源成本是不同的，这也决定了应对措施的不同效率和应对方案。其中，最重要的一项：成本控制。

成本的控制影响到你的需求方，合作方的直接收益，以及研发兄弟们的付出能不能应对老板年底述职的“灵魂拷问”，自然也包括你自己。

三、分阶段逐个击破

原则：明确当前阶段，识别风险程度，快速正确响应、同步相关干系人。

以下是具体实战措施：

1. 需求变更沟通前

线下组织沟通会，可以是正式的，也可以非正式会议，重点在将需求变更聊透彻。

• 把握重点。确定产品定位，把控业务发展方向、渐进明确，挖掘业务侧显性与隐性需求，重点在于将需求聊明白（可落地的层面）。
• 信息拉齐。同业务方leader、各相关方，保持理解一致，形成明确结论，并邮件通晒相关方（集体决策）。

这个阶段出现需求变更，保持正常的心态，积极拥抱。

因为在这个阶段，方案没有确定，调整方案的成本是最小的，但在这个阶段需要及时纸质化需求结论，并及时同步各相关方。保证信息拉齐，重要变更事项，一定邮件中颜色加粗@重要人员（保证留痕）。

2. 产品方案落地中

组织线下需求变更方案评审会。

• 主导会议方向：同业务方、合作方、运营、财税法，所有项目需求相关人员，线下组织产品方案评审会，沟通确认变更流程，主导方案会议方向，给出合理落地建议（识别关键决策人）。
• 注意事项：不要局限在方案原型设计，系统交互上，以及接口细节中，重点在判断业务需求变更合理性与系统可行性，提出专业性建议。

会议开始前，提前重点和关键决策人，沟通项目可能面临风险，获取其应对变更预期（包含上线时间，成本收益），在会议中做到有的放矢。

会后形成需求变更邮件，并保证信息拉齐，及时邮件同步项目组全员。

3. 方案确认中

同关键决策人沟通需求变更项，确认变更内容。

识别关键人：线下干活沟通的人可能没有决策权，多数情况下只负责需求的传递，往往在需求传递中，真实信息就会衰减。为了避免上线后，做无用功识，需求变更方案最后确认阶段，一定和关键决策人达成共识。（关键决策人即是为项目收益直接负责的人，简单点理解，对其OKR、晋升有重要影响的人）

重点和关键决策人确认变更方案，达成共识，并邮件同步各相关方，保证信息及时拉齐。

4. 方案实施研发中

识别变更来源，确定需求变更优先级。

1）来自内部（这里特指需求发起方【外】和执行方【内】），包括研发、测试。

场景类型：

• 设计缺陷、代码bug。
• 直接影响业务发展，包含敏感数据、错误信息。
• 上线后可造成直接资金损失或重大舆情风险问题。

以上场景发生，即刻应对变更：

• 及时邮件同步各相关方，并确保关键人识别该风险紧急程度。
• 组织关键人和各相关方积极采取应对措施。

2）来自业务方（需求发起方），主要包含商务BD，产品运营等。

① 是否关键干系人发起的变更

是：判断合理性。

• 合理：积极应对，由业务方明确变更需求邮件（包含变更背景，带来的风险，应对措施），通晒相关方知悉变更内容。
• 不合理：陈明利害，拒绝变更。

否，与关键干系人沟通确认是否可以变更。

② 是否合理的需求变更

合理：是否可以放在下一个迭代。

• 是：放入下一个迭代完成。
• 否：积极应对，由业务方明确变更需求邮件（包含变更背景，带来的风险，应对措施），通晒相关方知悉变更内容。

不合理：陈明利害，拒绝变更。

5. 方案实施已完成

按照新需求处理！！！

一款产品，首先要服务于用户，让用户满意并了解它的价值。想要做好一款产品，对于产品经理而言就需要具备一定的产品思维，那么什么是产品思维呢？作者将分享他对产品思维的思考，希望能对你有所帮助。

作为产品的你，一定对“产品思维”这个词非常非常熟悉，毕竟它是产品经理最重要的思（zhuang）想（B）方式。

但是好像看了很多的文章，你对这个概念还是不明不白，它是时刻保持用户视角思考问题？还是深刻而全面地面处理你的决策？还是我们可能会用到的一条条产品准则？

可谓有一千个产品经理就有一千个产品思维。所以这篇文章，我们就来总结一下，这个无处不在的产品思维，到底是个什么东西？

一、产品思维的核心是对现实的准确理解

似乎你可以在各种软文，各种大V的口中得到很多的关于产品思维是什么的答案，他们可能是一个个模型方法论，也可能是某些准则，也可能是别的什么东西。

但是所有这些模型，所有这些准则，其实都是基于一个核心出发的：他们反映了某些重要的现实规律。所以我们可以总结说：拥有产品思维的核心是要拥有对现实的准确理解，并进行归纳。

我们所接触到的任何的模型、任何的方法论，他们不是死板的教条，而是对现实的总结。只有真正理解了每一个用户，他作为人，作为他的角色，他的思维有什么特点，行为模式是怎么样的，才能真正将一些模型融汇贯通。

这里举一个PMF的例子作为说明：

1. PMF

我们都知道，一个新的产品在进行推广时，必须要经历一个阶段，那就是PMF，也就是验证产品的市场匹配度。

当用户来到你的产品中，留存率大于一个既定值并且随着时间的流逝不会轻易流失之后，你的产品才算是实现了PMF，这才说明你的产品是真实被这个社会需要的。

有了PMF之后才可以大规模进行推广和宣传，否则就是浪费流量。

“浪费流量”这个概念的背后，其实是人对于一个事物的第一印象的重要性。在产品第一次接触到一个新用户时，就要足够好（至少核心价值要传达到位），这样他才会对产品有一个深的印象，选择留下来。

如果当一个用户第一次看到你的产品是很没感觉的，没有感受到任何价值，那么可能不会再打开第二次。这个流量就会流失，尽管你后期再进行迭代再进行弥补，也很难扭转第一次流失所带来的反噬。

这个例子中，“浪费流量”的概念对应到现实中其实是“第一印象的重要性”。

接下来我们来看第二个例子：

2. AARRR模型

AARRR 模型研究用户和产品相遇相识相知相爱的过程。它包含了五个环节：获取用户、激活用户、留存用户、获取收益、传播。

但是这个模型背后的逻辑是用户来到你的产品中所经历的流程：

• A – 获取用户：想象一下一个用户在网上冲浪，从公众号文章或者别的什么渠道接触到你的产品广告或推荐信息，然后广告中有吸引他的点，然后他点击你的广告链接进入到你的产品中；
• A – 激活用户：在引导页了解了你的产品的基本概念；
• R – 留存用户：用起来觉得，诶这就是我需要的，我需要产品来帮我处理某些问题，或者带给了他某些良好的感受，也不是很贵；
• R – 获取收益：于是他开始持续付费，并将产品推荐给周围的朋友：“我用这个还挺好用的，你也可以试试”；
• R – 满足分享欲：这个流程里包含的现实概念其实是一个用户接触你产品后的心理变化过程，某一个阶段没有做好就会造成流失和损失。

如果你了解了这一点，其实不需要非得按模型的五个步骤来分析，比如激活和留存其实就是一个概念，就是充分让用户认识到你产品的价值。

所以产品思维的核心其实是对现实的了解，对现实理解的越正确，你就越能对所有这些原则和模型融会贯通，甚至你会形成自己的原则和模型。

当然这需要靠不断的经验积累，不断的深度思考。

二、产品思维的外在是一整套结构化的现实经验

如果说产品思维的核心是对现实的准确理解，那么产品思维的外在则是一整套结构化的现实经验。而这些经验才是真正能够在工作中能够用得到的东西。

下面是笔者的总结，供大家参考：

• 对市场本身的了解。充分了解这个市场有多少规模？有哪些角色、他们各自的需求来源、他们的核心诉求 、他们希望得到什么？
• 对友商的了解。充分了解这个市场上有哪些主要的玩家在分蛋糕，他们的刀子长什么样子以及是否锋利？
• 产品和服务架构设计。知道产品应该是什么样子。怎么把产品设计好，可以创造产品的竞争优势。厉害一点的知道怎么把产品和服务的架构设计好。
• 产品增长和推广。拥有产品增长和推广的方法和经验。知道如何使用数据来反馈产品增长。
• 神奇妙妙能力。1. 拥有一些创新精神、会设计一些亮点以及新鲜的东西出来。2. 同理心，能够想到别人之所想，体验别人之所体验。

下面我们聊一聊这些部分的实操方法论。这里用一张图来表达这些内容：

三、产品思维实操

1. 产品的定位

一款产品要坚持产品定位，为相似的某一群体提供服务，拒绝掉会把你产品带偏的需求。这个规则其实很好理解，拿智慧校园举个例子，不同的校长，对于产品的要求是不一样的，这往往跟他们的学校定位有很大关系。

对于同样一款产品，可能有的资金条件比较充沛的学校会要求更多的自定义模块来彰显学校特色。但是可能有的比较普通的学校，就对乱七八糟的特色功能不感兴趣，只要能提供简单易用的解决方案，够满足日常的使用，最后能够完成教育局的指标就好。

对于这样的差异，肯定会存在架构不一致的问题。为了满足另一方而进行大规模重构，如果重构结果好一点还说得过去，如果重构结果会对原本的定位造成伤害，那就会有很大的风险，另一方肯定不会买账。

这个时候就要坚持一种定位，服务好一类群体，那么你所选择的那类群体就会被你牢牢把握在手里。不至于两头开工，最后手忙脚乱。

所以产品的定位就是思考你要服务哪种人，而且这种人要足够的相似，他们的诉求和场景也要足够的相似，就算看上去是同一类人，也会有差异性存在。

卖甜豆腐脑和卖咸豆腐脑都很好，但是你不能把甜豆腐脑和咸豆腐脑掺在一起去卖，那是折磨你的用户。

尤其对于目前这个环境，增量时代已经离我们而去，再也不可能出现能够服务所有人的大产品，因为人的共性已经被满足完毕，只可能出现更加精细化的差异性小产品。

所以重新思考你的定位吧。

2. 产品优势

有一次笔者去参加中国教育装备展，在展会上其实能对“优势”理解的更为透彻，你会发现有的产品你一看就觉得很有优势，有的则亮点不足，

那到底什么才是一个产品的优势呢？

优势可以是很多方面：更精准的场景创新、提供更完善的内容体系、提供更到位更贴心的服务、提供更完整更闭环的解决方案。

这些都是一个产品的优势，小的产品就坚持精准的有效创新，大的解决方案就坚持更完整更完善的产品内容体系。

许多人说，产品的竞争优势是差异化。其实不然，或者说这句话没有说完，差异化不是竞争力的核心，精准地解决某一个问题+持续不断的构建壁垒+差异化才构成了产品竞争力。

如果没有精准地嵌入某个场景，那你的方案是空中楼阁，如果没有持续不断的构建壁垒，你很容易被同行模仿和超越，如果你没有差异化，你将泯然众人。所以产品优势三要素缺一不可。

总之找到一个点，一个用户真正需要的点，去持续不断的迭代优化补充，一个功能不能构成竞争力、一个idea也不能构成竞争力。持续不断的投入和经营，一点一点的积累筹码，才是竞争力的核心来源。

3. 需求分析产品迭代

在进行产品迭代时，要以产品定位为边界、构建优势为目标地进行迭代，合理的大脑里要清晰的知道，未来，产品应该是什么样子，以此来进行需求分析。

需求不是接一个做一个，而是一个场景一个场景的做。也就是说，面对一个需求，它背后其实是一个场景，用户提给你的需求只是他认为的一个比较好的解决方法。

但是你作为产品，你要思考明白，你要如何体系化地真正解决这个问题。往往对于一个问题有不同的解决方法。

更多精彩，请期待《产品思维，到底是个什么玩意儿（二）》