To B产品如何做MVP？

首先，我向你打招呼。我好久没见到你了。我真的很久没有更新了。主要原因是我的个人状况最近发生了很大的变化。我以前说过我从今年开始成为自己的公司；离上一篇文章不到半年了。上次，在第一笔融资到位之前，公司还没有正式成立，有时间写作；现在公司走上了正轨，团队相对稳定。同时，第二笔资金到位，压力略有缓解，所以花时间在周末写下这几个月的经历。这个数字仍然将关注产品内容，输出一些我深入独立思考的内容；不一定是对的，但我希望它能引发读者的思考，如果内容能激发讨论或辩论。这个数字仍然将关注产品内容，输出一些我深入独立思考的内容；不一定是对的，但我希望它能引发读者的思考，如果内容能激发每个人的讨论或辩论。说真的。自今年以来，TOB一直处于风暴的最前沿，SaaS作为主要的产品形式终于达到了顶峰；我在16年里做了SaaS产品，当时很痛苦，商家没有支付习惯，资本市场仍在TOC业务上花钱，产品本身没有公式，每个人都在探索。作为产品经理，我第一次面对SaaS产品时看起来很困惑。在探索过程中，我们的产品团队成功地浪费了公司的宝贵资金。今年创建自己的SaaS产品后，对资金投入格外谨慎。在有限资金的压力下做决定是一件非常有训练的事情，也迫使我们一次做对事情；因为没有第二次试错的机会，公司可能会一次性消失；因此，我们必须找到一种TOBMVP方法，以提高每个产品的功能/模块与市场的匹配率。第一，MVP的核心是验证，“验证”是MVP最本质的价值。我们不想做MVP来做一个小产品，也不想做一个小产品或MVP；真正的MVP甚至不需要做任何产品，所以我们说，只要我们能围绕一系列低成本的验证方法进行“验证”，我们就可以认为它是一个优秀的MVP。例如：我有一个好朋友，她是一个室内设计师，有一天她让我做一个系统工具，可以帮助室内设计师快速解决模型房间——可以快速构建设计方案，支付一定的成本；并订购相应的软装饰产品，实现高效的生产设计，高效完成商品采购。抛开这个案例在商业上的可行性，简单从MVP的角度来分析；如果做这个项目，应该“验证”的关键问题是什么？乍一看，这个项目需要很多维度、工具、丰富的商品和在线支付。事实上，这些都不重要。最后，验证的核心观点非常简单——看看室内设计师的原始工作方法是否可以通过组合模板来取代。仔细想想。因此，验证方法实际上非常简单，可以使用第三方工具，通过表格制作模板；所涉及的软服装产品直接从淘宝购买链接发布，然后以赞商城为销售节点销售，在设计师组推送和描述；你也可以写一篇官方账号文章来介绍这种工作方式。如果设计师购买，我们将在淘宝上下订单；这样，就可以轻松快速地验证，设计师是否接受这种新的工作方式。好吧，快速结束这个案例。毕竟，本文的重点是谈论B端MVP。在上述情况下，我们已经就MVP的核心概念达成了共识；但事实上，这种情况仍然相对较轻。当我们从事行业SaaS或其他TOB产品时，我们经常会遇到更复杂和多样化的问题。例如，你会听到商家说：“你没有XX功能，我当然不能使用这个功能。”，是的，这是B端场景中的一个典型问题：“缺乏闭环”。B端MVP首先要考虑什么是最小闭环，最小闭环是什么？2、B端MVP首先考虑最小业务闭环。什么是最小闭环？事实上，不难理解。如果一件事有一个清晰的着陆点，它可以简单地理解为闭环。我们应该如何理解TOB产品中的闭环？SaaS产品必须服务于某些业务场景。SaaS产品的某个功能点可以解决商家员工在特定场景下的完整支持操作过程，即闭环，但我们可能面临一个常见的现象，即“闭环太大”。例如，在上述情况下，如果这样的软装饰设计师SaaS根本无法着陆，闭环太大；因此，找到最小的“业务”闭环是B端产品去MVP的方式。如何找到最小的业务闭环？当我们计划SaaS产品时，最容易犯的错误是把一个完整的大闭环误认为是一个小业务闭环；因此，业务闭环是基于产品的用户，而不是基于企业。以长期租赁公寓为例。我们需要看的是长期租赁公寓业务中经营管理人员的业务环节，比如客人签订合同，然后激活一系列硬件，而不是整个公司的业务流程。关注一个角色下某种行为的闭环是最小的业务闭环。这样，我们得出结论，B端产品没有“小步快速迭代”，最小业务闭环不满足，难以验证需求的准确性，可能因功能缺陷导致业务反馈不良；我们错误地认为验证失败，可能是闭环没有关闭，在验证步骤之前被放弃。现在我们找到了验证点，做了最小的闭环业务，下一步就是谈产品。3、MVP产品应该像“针”一样。众所周知，一个好的产品必须是极其有价值的产品。如果一个产品满足了一切，那一定不是一个好产品——这是常识。把它放在MVP产品上，你需要把这一点打得更极端，这就是为什么MVP产品是针。产品设计要非常小，同时要准确。如果一针扎下来，要么说明不对，要么说明一针见血就打中了。让我们来看看TOC和TOB业务的区别——C端面向消费者行为链短，B端面向企业，多行为链长；因此，我们可以激活用户通过非常感性的维度获得反馈结果，这通常是以数据为导向的；相反，做B端，做可靠、安全、合理，这是非常合理的，而且群体的理性不能让你有任何风险；B端MVP结果相对不容易被数据反映，主观体验和主观选择很多。B端还面临着另一个问题。服务企业的需求完全不同。A和B不同于B和C，A和C也不同。你不能像服务C端用户一样解决所有人的问题。B端还面临着另一个问题。服务企业的需求完全不同。A和B不同，B和C不同，A和C也不同。你不能像服务C端用户一样解决所有人的问题。这就要求我们有更强的标准化能力，我们需要找到我们在这些企业要做的产品中验证的共同维度。还有一个关键词必须提到，“成本”我们做MVP的本质是验证，如果没有成本限制MVP失去意义，不够精益；但我们不能做小产品和小，必须能够满足最小的业务闭环。我想在这里写一个案例，但当我完成我们三个失败的MVP时，我发现它涉及到一些无法披露的内容，所以很遗憾我找不到更好的纯TOB或SaaS案例来描述它。C端有很多案例，但我不想写在这篇文章里。4、跨行业创业TOB产品如何制造MVP？在跨行业制造产品时，无论我们如何对行业和企业有深入的了解，我们都无法与行业内资深从业者的认知相匹配。解决跨行业产品MVP问题的好办法是什么？您可以尝试“核心用户倒推法”。首先，我们彻底了解商家的运营模式，找到您需要验证问题的最匹配商家，然后无脑满足他们的需求——这种方法非常危险，但相对适合跨行业企业家；这个想法来自于“信任加权”，这意味着我们需要听取周围专业人士的意见，然后在不同的维度上给不同的专业人士增加权重，在做决定的时候，我们可以放弃一些执念，选择相信权重更高的人的意见，这样可以提高整体成功率。当一个跨行业企业家进行早期产品验证时，我们可以使用这种方法——在不同的维度上对不同的企业进行权重评分，然后抛出我们需要验证的问题，吸收各种企业的意见和需求；有些是积极的，有些是消极的，然后根据业务的权重点对冲，最终得出结论，这个结论可能不是企业家心中的最佳答案，但这是一个值得尝试的答案。5、现值和价值是MVP结果的衡量标尺。如何验证我们的核心问题是否值得？5、现值和价值是MVP结果的衡量标尺。如何验证我们的核心问题是否值得？从现值和价值两个维度来看。现值是指这一功能在当前市场中值得成为当前市场的价值，当前行业的需求可能确实存在；但是，随着市场的发展，我们现在所做的是否仍然存在于未来的发展轨迹中，是否会直接被更高维度的需求所覆盖，这是对创始人决心的一个很大的考验。价值很简单，可以理解。最近，《价值》这本书也很受欢迎。我们更多地将价值标杆为长期价值，即相对忽视当前利益，关注更长期的未来——这是SaaS制造商的视角。另一个视角是对企业的解释。我们都知道，企业不会选择更便宜的，因为你比他的产品便宜1000元。企业会看到谁给我带来了最大的价值；在这个商家看来，价值很难衡量，包括降低成本和提高效率、品牌溢价或简单的创始人偏好。维度太多了。我们只需要有一种感觉。这两个维度和MVP的验证结果有什么关系？目前，我公司还处于创业阶段，还没有到增长的时候。现阶段SaaS最大的特点是需求不完整，商家无法从多个维度解决您家中的问题；然后将单点问题切断，使该单点成为行业内最大的价值输出产品，从这个核心角度规划MVP，验证各种产品的功能。在我们得到验证结果后，我们需要做一个比较，现值和价值比较，完全偏向于长期价值可能导致早期增长疲软PMF继续运行——过于偏向现值会导致经验分散，大量MVP验证，团队压力，短期数据可观但很快达到增长极限，客户难度会增加，你发现商家认为你很好，但只是不能使用。因此，为了平衡验证点带来的结果的现值和长期价值，最好的状态是结果在我们预期的战略发展道路上是公正的。六、最后这篇文章和40万有什么关系？我们的团队从成立到现在花了大约40万元。我们踩了很多坑，做了很多不能说坏不能说好的产品功能。所以在一个焦虑的夜晚，我决定改变过去，把过去的反思和尝试总结成这篇文章，希望能激发你的深入思考。