toc|从商业视角看MVP在SaaS中的落地与实践( 六 ) 视角|晏涛|找到你|持续性|用户

同时我们也不能为了做小产品而去为了小而小，必须要能够满足最小的业务闭环。
三、新入一个行业，如何快速应用MVP作为产品经理，通常我们会面临很多的跨行业需求，SaaS分为通用型和垂直行业型，不管两者的哪一种，都会面临着跨行业的情况出现，那么遇到完全不懂没有经验的行业，但我们需要设计一款产品此时该怎么办呢。

文章插图
这里我给大家带来三个认知一个方法，帮助我们在遇到跨行业项目或跳槽到一个新行业时快速上手。
第一个认知：抛弃主观思想，不做预设
在你深入了解一个行业之前，你所能提出的任何解决方案大概率都是思考不充分的，所以不能去提前预设立场和方向，要认清自己是个行外人，但同时又要保持第三方视角，因为很多深扎行业的人视角比较单一，不具备我们这样结合互联网和行业的多角色认知。
第二个认知：寻找一手信息
在我们调研行业的时候通常会去拜访一些企业，往往会由一个中层管理人员开始为我们讲解整个企业及行业的各环节运作方式，当然这是一个比较快的了解情况的方式。
但你依然要拿到一手信息，因为只有这样你才能从最本质的问题出发，以产品经理的视角通过信息的组合可能会有全新的解决方案，直接接触一手信息的方式有很多，这里我推荐要去到一线，直接参与一线人员工作的经营，不要只是了解，是要跟随他们一起去做，还记得么之前我们讲过场景冲突的问题，只听别人讲是一定发现不了冲突的。
第三个认知：不要只找大客户去调研需求
我们在做一些项目的时候经常会想，找到一个行业内头部的案例，基本上就应该能学习清楚了吧，但事实是相反的，实际情况是大客户有太多的定制化需求，和因为规模而产生的独特需求，而我们做SaaS产品最重要的是去规避定制，抽象标准化需求，然后尽可能普适性的覆盖更多商家，所以要警惕头部公司的意见，集中度比较高的行业可能不是这样，我们这里特指集中性比较低的产业。
好，我们了解了基本的认知为我们定义了一个边界，下面来看看具体的实践方法。

文章插图
核心用户倒推法：
首先我们依然要完成第一步，求证，要搞清楚我们的求证点是什么。
第二步：挑选至少5个这些客户的KPI必须和你的求证点有所关联
第三步：对每个客户进行匹配度加权，根据他们的特点，我们需要把这5个客户根据各个维度进行拆分然后加权，这个需要你的业务维度去判断，比如我是做电商SaaS的，这个客户的维度我至少会拆出来，品类匹配度、消费频次匹配度、客单价匹配度，这样这三个维度的权重就就代表了这个商户的指导意见，
第四步：加大对选中商户的需求支持，甚至无脑满足，这时候需要一定的冗余性，因为你不是行业专家，我们需要在更中立的视角去审判，所需需要一定的容错空间。
最后，我们根据每个商家的实际运行结果，以及权重的最终一个大概分值，就可以判断一个SaaS产品是否满精准满足了需求，要删哪些功能，迭代哪些产品方向。
我就用我的创业项目，住客云，来跟大家聊聊我们在早期是如何做的

文章插图
首先我有一定的行业基础，但在做SaaS的时这个时候候依然还是有些hold不住，这个时候我们选择了3个一起内测的种子商户，他们分别有几个特点，
商户1：酒店非常分散在同一个城市中，管理模式是以门店加盟模式，所以总部和门店之间是股权关系，不是上下级关系。这个商户我们在分散性和内部组织沟通成本高这两个维度给了一定的权重。
商户2：是一个乡村民宿，有一个中小规模的客栈在大山里，这个客户的特点就是低频，非刚需，所以我们在消费频次上给了比较低的权重分。
商户3：是一个多城市的酒店品牌，我们认为这个品牌是最可能验证我们想法的，所以我们在各个维度都给了他较高的权重。
当住客云启动产品研发的时候，我们就会更加重视商户3的需求，研发经历重点倾斜，当有一些营销功能涉及到流量转化的时候，我们会更加重视商户2的需求，因为这个商家对流量的需求远远大于其他，因为规模小，还非刚需，当我们出现了一些组织协同的需求的时候，我们会优先考虑商户1的需求，因为他们的组织模式是合作模式，而非企业内的部门关系，合作模式的关系会更考验产品力，合作伙伴不会睁一只眼闭一只眼的。