从商业视角看MVP在SaaS中的落地与实践

从商业视角看MVP在SaaS中的落地与实践

编辑导语：SaaS是近年来较为火热的一个赛道，MVP在产品的应用中也是十分广泛，如何把二者结合起来，实现降本增效和开源增收呢？作者从三个方面分享了商业角度的MVP在SaaS产品中是如何落地与实践的，我们一起来看下吧。

前段时间和人人都是产品经理的起点学院合作了一些直播课，把之前的一篇文章做了进一步的细化，本篇是这次直播课的具体内容做一次文字稿的呈现。

这次直播用了1个小时，相信我值得你找个安静的角落细细阅读。

我是张浩然，是住客云的创始人，同时也是一名拥有8年产品经验的产品经理，现创立垂直交易型SaaS，在过去的几年里，我以SaaS及tob产品为载体，帮助多家企业在降本增效和开源增收两方面做出贡献，并取得了一些成果，主导过各个阶段的全周期多类型tob项目。

今天就结合实战案例，为大家来讲解在SaaS产品中，如何利用MVP思想主导我们的产品工作。

先来了解一下本课程的结构：

首先我们先全面的了解MVP的设计思想，然后通过几个案例来拆解SaaS产品MVP的落地方法论，最后延展一个日常基本都会遇到的跨行业设计产品的知识点。

在工作中我们难免会遇到以上问题，本次的课程学习后，你将获得一套面对早期SaaS产品的体系化思维与实操能力。

先来进入第一章从商业视角，重新解读MVP设计思想。

一、从商业视角，重新解读MVP设计思想

首先，什么是MVP，行业里的各种解读有很多，这里我做出一个更接地气的解释，我作为一个老板，MVP对我来说就意味着用最具性价比的方式，通过最小的投入，来明确我的商业猜想。

我是继续对这件事加大投资，加人加资源，还是这件事不对，换个方向或放弃。所以从宏观的角度看，mvp可以帮我我的商业选择提供一个强有力的决策依据。

ok，我们先来看看MVP运营在toc和tob两种产品上有什么区别。

我们可以把两者的差异分为两类：

1. 使用者与决策者的不同
2. 价值感知方式的不同

先来看第一个，使用者与决策者。

• 我们都知道toc产品是直接面向消费者的，所以在产品的购买和决策层面，是一个独立的个体。
• 那么B端产品呢，使用者是谁？是不是企业的员工或某部门人员，决策者是谁呢？是不是部门负责人或企业负责人，所以b端产品的使用者和决策者是分离的。

再来看这两种产品的用户决策链：

c端产品往往是，产生需求后马上去找方案，然后决定是否采用这个方案解决需求。

而b端产品因为使用人和决策人的分离，导致中间需要有理性的分析及汇报行为，是一个较为理性的决策行为。

我们再来看价值感知方式的不同：

toc产品的价值感知是非常直观的，主要围绕自然人用户日常的需求进行满足。

比如我们要打法时间可以刷抖音，或者打王者，这就是一个明确的价值感知，【我的需求被满足】这个感知系统是非常主观的，用户自己觉得ok 那就是被满足了。

C端产品的MVP的设计中就要找到能够凸显【我的需求被满足】这个用户价值的核心关键点，比如用户想打发时间，我们继续细分，可以分成1小时以上的，和15分钟碎片化的，然后我们就可以做一款小游戏，来满足15分钟左右的打发时间这个诉求。你看，所以C端产品的MVP多为产品的创新。

b端产品的价值感知是相对滞后的，在企业的业务指标提升的情况下才能被感知。

这就意味着从产品被使用，到感受到产品价值中间需要运行一段时间后次才能被客户感知到是否有价值，你的产品帮他节省了人工，从10个人变成2个人，或者是提高了利润率，而这些指标的提升都需要一定的周期。所以b端产品的价值感知方式是【业务指标是否提升】。

了解到了这个事实后，我们在做B端MVP的时候就要先从企业的角度出发，去找到企业内的某个业务指标，然后看完成这个指标有没有阻力，换句话说，SaaS产品其实就是帮助企业清除掉达成某个业务指标的障碍。

比如分销系统，当企业找上1000个分销渠道后，财务的结算和对账压力巨大，几乎不可执行，上一套分销系统后就可以保证顺利达成企业通过分销带来业务增长的目标。而不增加财务的任何工作压力和人员。

所以SaaS的mvp是以消除业务阻碍为核心，来进行验证的。

所以SaaS产品的本质是洞察到独特的解决方案并以产品为载体传递给客户完成服务。

客户在使用SaaS产品的同时，也在接受你产品背后经营方式和认知的改变，所以SaaS不单是一个产品，更是一种方法认知。我们做SaaS的MVP本质就是要去验证我们提供的独特解决方式是否正确。

好，我们来总结一下cb端产品的区别。

了解了toc与tob产品的区别，我们接下来先从产品视角来看看MVP如何实现。

我们通常讲的MVP大多是产品视角下，从产品角度看，MVP的本质就是通过阶段性的产品去满足阶段性的业务需求，然后不断推动阶段的的提升持续迭代的过程。

通常情况下做一款产品的MVP是这样的流程：

第一步：锁定需求

确认一个业务阶段，并列出阶段内的对应需求点。

第二步：明确功能点

根据上述已经明确的阶段对应的需求点进行产品设计，要注意的是除此之外的功能一律不做，即便是有功能的缺失导致个别流程走不通，也不需要去做，比如没有登陆流程，这都不重要。

第三步：推出mvp产品

快速推出首个版本的mvp，注意，是首个mvp版本，不是首个版本的产品，mvp阶段我们是不确定产品要不要做以及怎么做的，既然是mvp的第一个版本，那就一定要保证效率和速度，在ui及技术完整性上产品经理已经要有意识去引导团队放弃多余动作。

第四步：复盘决策

当mvp推出后要高频的进行数据整理及复盘，通过反馈来确定更换产品方向还是进度到下一个业务阶段继续进一步的mvp实验。

以上就是一个产品经理在做mvp时的常用方式。

我们都知道任何产品都是建立在满足某种商业目基础上的，而做商业其中一个最重要的能力就是去判断一件事是否值得去做，避免团队在错误的道路上狂奔是一个决策者最重要的责任，而作为产品经理或产品部门负责人，这样的产品方向决策牵一发动全身，一个错误的产品方向将导致运营 市场 技术 等多个相关部门造成大量时间和金钱的损失。

所以做产品一定要有极为敏感的商业思维，下面我们就看看在商业视角下，MVP是怎么做的。

首先，任何商业行为的本质都是价值的交换，既然是价值交换一定要以效用为核心，我们可以把效用理解成是成本/效率/投入产出比等指标的综合表达。所以商业视角去做mvp就是通过高效用的验证方式，对商业目标进行初步的佐证。

来看看商业视角去落地MVP的具体步骤：

第一步：明确商业目的

一个mvp产品首先要和商业目的相互呼应，mvp是服务于商业目的验证，所以第一步要提出一个好问题，也就是目标。

第二步：竞争环境分析

当我们明确了目标后，首先要做的事情不是去动手规划mvp产品，我们要用更高效用的方式去验证目标不是吗，所以明确了目标后，我们马上要进行的是去分析商业环境，赛道有多大？

目标商户数是不是支撑的起来营收？主要竞对做到了什么程度他们遇到了什么问题，等等，尤其是竞争环境，研究竞品的发展过程实际上是最高效的商业目标验证方式。

第三步：设计MVP产品

这个环节我们重点来讲讲，当我们明确了商业目标以后，是不是就需要用一个MVP产品去验证了？

这里我想说，有时候验证的方式未必需要做出产品，因为MVP产品的本质就是去验证商业假设，能验证商业假设的方式有很多，可以是访谈，可以是更巧妙的方式验证，我们要更开放的去思考，不能因为我们是产品经理就依赖做出产品解决任何问题。我们下面会举一个具体案例。

第四步：复盘决策

这里和产品视角一致，需要决定接下来的产品方向

第五步：验证收入模型

相比产品视角下的mvp商业中我们更要考虑商业化的可信性，所以商业视角去做MVP产品的最后一环是验证收入可能性，通过一些简单的手段去验证收入可能，比如我们做一个Saas收不上来费用，用户不付费，前面的一切努力就都白费了。

我们来看一下两种视角下对MVP的思考。

产品视角做mvp更加局限，被包含在商业视角内。

产品视角只是商业全盘思考其中的一环，这也成为产品格局，格局就是用高维视角思考低位问题比如，我们做一家企业的时候能从行业的视角出发，当我们身处行业，能基于国家的战略逻辑来思考问题，这就是格局。

商业视角做MVP是用更全面的视角判断一件事值不值得做。

从商业的视角看任何问题其本质都是值不值得的问题，如果在一个错误的赛道上投入，很快会到天花板，死也死不了长也长不大，浪费了生命。

商业视角是以商业目标为导向，在验证产品可行后也要验证商业化的可行性。

如果一款产品被用户所欢迎，但是没有任何方式产生收入，这就陷入了困境，SaaS产品大多无法像c端产品那样能靠广告带来收益的，所以商业化的可行性也是SaaS产品经理要去思考和验证的问题，甚至这个点需要被前置，在产品MVP的设计阶段就可以融入收入模式面向用户从而得到反馈。

总而言之，商业MVP更加考验一个产品经理的综合能力，产品经理在除了产品本身之外也要更多的去了解行业基础/竞争情况，以及商业空间，这些都是在MVP阶段要去结合思考的维度，而不单单是做出产品，否则一件事盲目启动很快达到天花板不再增长，这是在浪费企业的生命。

了解了理论我们来看一个案例。

我有一个好朋友是非常资深的室内设计师，有一次她找我聊创业的方向，她想做一个SaaS来帮助室内设计师快速搭建设计样板方案，大致的思路如下。

先维护一个丰富的家具模型库，然后通过简单的拖拽组合，拼出一个设计方案，这样做的好处就是可以将设计师繁琐的设计工作进行优化，快速完成初步的效果图给客户，然后设计师只需要支付一定的费用，就可以把这个设计方案买走。

我们先不聊这个项目的可行性，单纯来看看这个项目的MVP该如何设计。

首先要明确商业目的，这个项目在商业上的价值点需要挖掘出来，我们就拍脑袋一下，将他定义为改变室内设计师的工作方式，希望高效输出设计图提前进入客户沟通环节。

有了明确的目标定位后要先来看看市场环境如何，这是我们的第二步还记得吗，但这是个虚构的项目，我们就不去真的分析市场了，我们假设市场上没有先行者，这个项目是第一个想要这样做的。而且家装工装加起来是个万亿市场，赛道没有大问题，设计师和工作室的数量也在百万级以上体量巨大。

明确了以上，接下来就是我们的第三步：设计mvp产品，乍一看这个项目是不是维度很多，需要做设计工具，也需要做家具模型库，还要涉及到支付及后续环节，这个MVP怎么做呢？

其实非常简单，我们只需要找到我们要证明的那个问题点，在这个项目中要去验证什么？肯定不是能不能做出模型库吧，肯定也不是做一套支付体系吧，是在线完成设计的工具吗？也不是吧，这些早就有解决方案了吧，都不需要验证。

还记得第一步我们明确的商业目标么，是省去繁琐的设计环节，提前产出相对完整的设计图，改变传统的设计工作方式对吧。ok这才是我们要去验证的核心。除此之外的事情可以一律不做。

怎么验证？非常简单，你可以去淘宝选出一些家具图片，并复制链接，全部维护进一个表格里，一套方案对应一个表格，搞上二三十套，然后去找设计师卖你的方案。

快速获得反馈，能卖出去解决设计师的问题，还是卖不出去，为什么卖不出去，是业务场景里有关键点满足不了，还是模板不够好。如果是模板不好，继续做上几十套再卖，反复几次复盘，马上就可以知道这件事的核心关键点了。

你看，一个MVP的设计也许根本不需要做出产品，你只需要找到一个可以验证你想要证明的问题方法他可以很简单，很粗糙，只要可以帮助你获得信息得到反馈就是一个好MVP方案。

来做个小结：

到这里我们已经完整的了解了MVP思想。

大家注意，打起十二分的精神，我们接下来进入本课程最核心的部分。一定会让你有所收获，下面我们一起来看看SaaS产品MVP的核心方法。

二、SaaS产品中落地MVP验证的关键要点

我总结SaaS产品做MVP的三步分别是：

1. 找到核心求证点
2. 找到最小业务闭环
3. 以及警惕场景冲突

我们先来看找到核心求证点。

什么是求证点呢？其实在上面室内设计师SaaS的案例中，我们提到了一个信息，就是根据商业目标去判断最需要验证的那个问题，其实这就是求证点，所以在我们可以把求证点看作是精准定位业务的最核心部分。

这一步至关重要，如果求证点都是错的，整个mvp的设计方向也将毫无意义，你可能会问了，老师那有没有什么方法论是可以确定这个求证点的正确性呢，想1+1=2一样，只要满足了XXX情况就一定是对的。

很可惜，没有这样的公式，也不是所有问题都可以被量化，商业世界不是考试，有清晰的卷子有对与错，商业世界很难有绝对的对于错，我们常常在说不上对也没那么错的事情上浪费了生命。

求证点的判断只能是通过层层的抽丝剥茧，结合目标和经验去做判断，这需要大量的练习反馈再练习，形成一种对项目的判断手感。

用一个案例来加强一下理解。

为什么选择这个案例呢，因为SaaS产品往往是对传统行业的一个应用或改造，这个案例的特点就是用新交易行为去替代老交易行为，用新的经营理念替代老经营理念，所以在求证点的选择上是类似这样互联网解决方案赋能传统行业时产品能否解决商家问题的核心。

• 是给商家做一个能承载预定能力的小程序吗？
• 提供一整套获客营销工具吗？
• 或者是建一个SCRM私域运营系统？

你可能会说需要满足以上全部功能商家才能完整运营起来。

但事实肯定更不是这样，这太不精益了。

我们刚刚说找到求证点没有公式，但根据我的经验，我们可以通过前置北极星指标来做标靶，假设你是这个商家，当用上这个SaaS产品后你最希望提升的业务指标是什么，也就是北极星指标。

在这个项目中，商家希望摆脱对OTA的绑架，所以北极星指标是不是酒店商家的官方预定量。

这时候求证点就出现了，在这个指标下最大的问题是客人是否愿意脱离OTA跟商家达成点对点的交易。

对吧，也就是在没有类似于携程这样的平台保护的情况下，客人能否信任这个商家，那么这个项目的MVP我们就需要优先考虑这个问题，后续的设计也是围绕着推出一些列的直面客户的产品来得到反馈.

可以是在公众号写篇文章介绍房间，也可以是直接在微信内联系推动客人预定，我见过最牛的MVP是商家用纸画了个预售券，客人提前支付一定金额，拿到这个劵，疫情过后可以抵扣，靠这个方式商家提前收回了十几万的费用。

那么这就是第一个核心方法，找到求证点，找到求证点以后，我们还要解决一个问题，那就是避免MVP过大，下面就来看什么是最小业务闭环。

先来定义一下什么是业务闭环，业务闭环我们可以理解成是一个组织中的某一个经营环节从起点到终点的全过程，那么最小业务闭环呢，就是在企业内部的流程中，完整的去满足一个最小的业务单元全环节的诉求，从而形成一个小规模的闭环。

这么说比较抽象，我们可以把最小业务闭环的要素记下来，最小业务闭环要满足一下三点👇

我们在日常的工作中，不管是企业内部系统，还是SaaS产品，都面临一个问题，那就是闭环过大，回忆一下最开始的软装设计师SaaS的案例，如果要满足这样一整套业务环节，是不是太大了，大到几乎不可落地，类似的案例经常发生在一些业务流的系统里，基本上都是要最一个起点开始，环绕整个企业的全部环节然后结束，这个闭环太大了。根本不是MVP的思想。

那怎么找到最小业务闭环呢，我们来用一个案例拆解。

这个案例也是非常典型的一个通用情况，基本上效率管理型SaaS都会涉及到业务流的管理系统，而物业管理系统（长租公寓、地产管理）是业务复杂度最高的一类，所以这个案例能更好的的帮助我们理解最小业务闭环。

如果要满足这样的业务需要一个怎样的闭环产品呢，大家看左边的这个图。从资产收录环节开始到收益分配环节结束，经历了至少6个节点，我们都是做产品的，完成这样的一个系统工作量可想而知，而且还没有经过MVP的验证，一单出错成本非常可观。

那最小业务闭环呢，大家看右边的这张图。

从资产上线环节开始到数据监控环节结束，仅经历了4个环节，我们对比可以发现一个特点，较大的闭环是以企业单位的，而做小业务闭环是以角色为单位的。

所以找到最小业务闭环的方法其实就是聚焦在某一个角色下的行为闭环。

这样我们就得出了一个结论，SaaS产品是不存在“小步快跑快速迭代”的，最小业务闭环不满足的情况下，很难验证需求的准确性，很可能会因为功能的缺陷导致了商家给出不好的反馈结果，每个环节都做了一部分，而每个环节中的最新小闭环大概率都没闭住，你认为持续迭代就行，可是用户根本不买账，用不起来。

我们就误以为求证失败，实际上根本还没到验证那一步就被弃用了，所以小步快跑快速迭代也是以最小闭环为单位的。

而tob业务下即便在小的闭环，也比TOC产品大的多。

所以我们做SaaS的产品经理一定要警惕老板或技术要求我们小步快跑。

到这里，我们已经明确了MVP的求证点，还通过最小业务闭环的方式，打造了一个小型的MVP产品，还剩下最后一个要格外留意的维度，就是避免场景冲突。

我们都应该有过这样的经历，你推出了一个SaaS产品，你的客户试了试对你说，你的XXX功能有怎样的问题，我用不起来。

这既是场景冲突，也就是说虽然我们满足了整体的一个业务闭环，但是在实际的运营中有我们没有考虑到的场景细节，导致商家无法全员推广或使用该产品。

也就是说，在特定场景下，某一个需求的不满足，需求与业务场景存在冲突，并因该冲突导致整个业务链条无法正常运行的情况。我们就可以称之为场景冲突。

最典型的案例就是权限问题，给不该看的角色展现了过多的信息。比如上面举例的物管公司，会分为业主端和运营端，业主端如果过多展示经营信息，过于实时的表现出经营状态，就会让业主更深度和高频的关注和参与经营，给托管公司造成运营上的困扰。

再比如，我们做了一个帮助用户顺利入住民宿的工具，因为民宿很多是隐藏在小区里的需要引导。然后这个工具需要匹配订单，而用户这边获得指引工具的方式是通过手机号，这就有可能出现一个问题，预订人不是入住人，如果该问题不解决，这个工具并不会帮助运营人员减少工作量，反而会让他们提心吊胆，半夜客人没到房间不敢睡觉。这个功能就完全起不到作用用不起来。

大家注意一下这个点就好，主要是需要在特定的业务场景中要提前找到可能出现的场景冲突规避掉MVP在触达商户使用时被用起来的几率。

到这里我们就完成了整个MVP内容我们来总结一下。

第一步：找到案关键求证点

（以北极星指标反推，找到与指标关联的核心业务环节加以求证）

第二步：设计最小的业务闭环

（以组织中的某个角色为单位展开业务流程下的产品设计就是最小业务闭环）

第三步：确认没有场景冲突

（自查是否存在影响业务运行的特殊场景）

到这里相信大家已经掌握了一套在项目中可以实际落地的针对早期SaaS产品的MVP方法。

我们常说一款好的产品一定是非常极端的产品，如果一个产品在每个维度都满足了一点需求，那这一定不是一款能被使用的好产品，这是常识，在MVP的设计上我们要把这个维度发挥的更加极致，这就是为什么说MVP要像针一样。

产品设计要非常小，且精准，一针扎下去见了红，说明我们做对了，如果没扎透说明没打中，要在返回去重新尝试。

除了MVP的方法之外，还要额外提一下成本，我们做MVP的本质就是去求证，如果没有成本的限制mvp就失去了意义，就不够精益了。

同时我们也不能为了做小产品而去为了小而小，必须要能够满足最小的业务闭环。

三、新入一个行业，如何快速应用MVP

作为产品经理，通常我们会面临很多的跨行业需求，SaaS分为通用型和垂直行业型，不管两者的哪一种，都会面临着跨行业的情况出现，那么遇到完全不懂没有经验的行业，但我们需要设计一款产品此时该怎么办呢。

这里我给大家带来三个认知一个方法，帮助我们在遇到跨行业项目或跳槽到一个新行业时快速上手。

第一个认知：抛弃主观思想，不做预设

在你深入了解一个行业之前，你所能提出的任何解决方案大概率都是思考不充分的，所以不能去提前预设立场和方向，要认清自己是个行外人，但同时又要保持第三方视角，因为很多深扎行业的人视角比较单一，不具备我们这样结合互联网和行业的多角色认知。

第二个认知：寻找一手信息

在我们调研行业的时候通常会去拜访一些企业，往往会由一个中层管理人员开始为我们讲解整个企业及行业的各环节运作方式，当然这是一个比较快的了解情况的方式。

但你依然要拿到一手信息，因为只有这样你才能从最本质的问题出发，以产品经理的视角通过信息的组合可能会有全新的解决方案，直接接触一手信息的方式有很多，这里我推荐要去到一线，直接参与一线人员工作的经营，不要只是了解，是要跟随他们一起去做，还记得么之前我们讲过场景冲突的问题，只听别人讲是一定发现不了冲突的。

第三个认知：不要只找大客户去调研需求

我们在做一些项目的时候经常会想，找到一个行业内头部的案例，基本上就应该能学习清楚了吧，但事实是相反的，实际情况是大客户有太多的定制化需求，和因为规模而产生的独特需求，而我们做SaaS产品最重要的是去规避定制，抽象标准化需求，然后尽可能普适性的覆盖更多商家，所以要警惕头部公司的意见，集中度比较高的行业可能不是这样，我们这里特指集中性比较低的产业。

好，我们了解了基本的认知为我们定义了一个边界，下面来看看具体的实践方法。

核心用户倒推法：

首先我们依然要完成第一步，求证，要搞清楚我们的求证点是什么。

第二步：挑选至少5个这些客户的KPI必须和你的求证点有所关联

第三步：对每个客户进行匹配度加权，根据他们的特点，我们需要把这5个客户根据各个维度进行拆分然后加权，这个需要你的业务维度去判断，比如我是做电商SaaS的，这个客户的维度我至少会拆出来，品类匹配度、消费频次匹配度、客单价匹配度，这样这三个维度的权重就就代表了这个商户的指导意见，

第四步：加大对选中商户的需求支持，甚至无脑满足，这时候需要一定的冗余性，因为你不是行业专家，我们需要在更中立的视角去审判，所需需要一定的容错空间。

最后，我们根据每个商家的实际运行结果，以及权重的最终一个大概分值，就可以判断一个SaaS产品是否满精准满足了需求，要删哪些功能，迭代哪些产品方向。

我就用我的创业项目，住客云，来跟大家聊聊我们在早期是如何做的

首先我有一定的行业基础，但在做SaaS的时这个时候候依然还是有些hold不住，这个时候我们选择了3个一起内测的种子商户，他们分别有几个特点，

商户1：酒店非常分散在同一个城市中，管理模式是以门店加盟模式，所以总部和门店之间是股权关系，不是上下级关系。这个商户我们在分散性和内部组织沟通成本高这两个维度给了一定的权重。

商户2：是一个乡村民宿，有一个中小规模的客栈在大山里，这个客户的特点就是低频，非刚需，所以我们在消费频次上给了比较低的权重分。

商户3：是一个多城市的酒店品牌，我们认为这个品牌是最可能验证我们想法的，所以我们在各个维度都给了他较高的权重。

当住客云启动产品研发的时候，我们就会更加重视商户3的需求，研发经历重点倾斜，当有一些营销功能涉及到流量转化的时候，我们会更加重视商户2的需求，因为这个商家对流量的需求远远大于其他，因为规模小，还非刚需，当我们出现了一些组织协同的需求的时候，我们会优先考虑商户1的需求，因为他们的组织模式是合作模式，而非企业内的部门关系，合作模式的关系会更考验产品力，合作伙伴不会睁一只眼闭一只眼的。

所以这样的一套商户组合，帮助我们在核心产品、营销产品和协作产品，三条产品线的融合起到了关键作用，最终住客云这个项目仅用了竞争对手40%作用的研发费用就达到了和他们几乎持平的产品能力，主要原因就是因为和几个商户一起共建，几乎没有走弯路，所以在商户的选择上首先要非常清楚的知道自己的目标也就是求证点，其次是要把商户分析的非常透彻。

好了，课程内容就结束了。

你看，对于一个SaaS产品经理是不是有更全面的要求，从方向的选择，到竞争环境的分析，再到产品的操盘，最后还要考虑商业化的策略。

没错这就是B端产品经理，每个产业都值得被数字化的方式重做一遍，如果你想要推动一个行业的数字化发展，首先是一定要充分了解这个行业的结构，产业链的关系，企业的商业模式，产业的利润是如何分配的，各个公司的市场占有率如何，行业特征是集中的还是分散的等等。

只有这样你才能找到更合理的切入方式，以及创造出新的价值点。

toc的产品可能会因为你的文案很有调性或产品很美观而选择你，但你服务于某个企业，一定是因为他愿意为你提供的新价值模型买单。

作者：张大伦，公众号：张大伦（ID：zhangdalun010）

本文由 @张大伦 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于 CC0 协议