如何验证一个SaaS应用的创意

用新的视角重新审视并重新验证你的目标细分市场和问题，你的目标细分市场有多少人，它是否持久，是否有人在寻找解决该问题的方法？

以下是一些搜索意图的方式，可以让你对数字有所了解。

• 谷歌趋势 - 检查你的目标细分市场的热门程度。我们希望看到的是稳定/增长而不是下降。

• Google关键词规划器 - 查找在你的目标细分市场中软件的大致搜索量。如果足够常见，可以将你具体的问题搜索项加入其中。

• Keywords Everywhere Chrome扩展 - （一个很好的微型SaaS应用想法的例子） - 重复上述操作，以获得搜索量的进一步指标。

• UberSuggest和AnswerThePublic - 获得更多的见解和进一步的想法。

接下来，进入在线社区，这些社区是你的细分市场的用户聚集地。这可能是Facebook群组，Reddit子版块，Slack，Discord等。

加入这些社区并使用平台上的搜索功能，找到人们对你考虑解决的问题和解决方法的看法。如果可能的话，以非垃圾邮件的方式向这些人之一发送消息，并适当地向他们概述你的高层次应用想法以获取他们的反馈。

要小心，因为他们更容易给你一个鼓励你构建的错误积极态度，所以一定要请求他们给予诚实的反馈，并了解他们愿意为这个解决方案付费多少。

接下来，检查问题的任何现有解决方案。如果没有解决方案或者只有手动解决方法，那么你可能认为你找到了机会，你的解决方案一定比没有解决方案好，对吗？

嗯，可能有很好的原因，为什么别人会错过这个机会，所以务必要仔细进行尽职调查，并考虑各个方面。

如果该问题已经有了一些解决方案，并不意味着它们全部都做对了，对你来说它不是一个非开端的。寻找现有解决方案中存在的差距或用户遇到的问题：

• **对于用户来说，他们的价格是否太贵以至于无法证明？**你是否可以生产出更实惠的东西？例如，Pabbly是Zapier的简化版，价格更低，因此越来越受欢迎，这证明了市场上对这两个平台都有足够的空间。

• **它们是否捆绑了过多的其他功能？**从只提供一个核心模块的应用开始，提供一个快速服务。

• **它们是否难以理解或使用？**构建一个更容易设置和使用的解决方案。

• **它们是否缺少关键功能？**将这些功能作为你的USP的主要功能进行构建。

你是否对看到的东西感到满意，并且准备将你的想法推向下一个层面？

然后，你可以通过创建应用程序的外观和功能的模型来衡量需求，并在承诺构建MVP之前获得反馈。

用户应该从对这些模型的一瞥中明显地了解到应用程序的功能。

然后，你可以通过私下与细分市场中的联系人共享此模型，或者甚至可以在细分市场的社区中公开发布它们，并要求他们给予诚实的反馈。

在公开发布时要注意窥探你的眼睛。如果在评论中有很多用户在尖叫“拿走我的钱”，那么该领域中的某个人可能会雇用开发人员来构建此应用程序。

我建议在获得你寻求的反馈后的一两天内删除帖子。这样，它将减少其他人窃取你的微型SaaS应用想法的机会。

你可以进一步进行操作，为应用程序构建一个简单的网站，其中包含上述模型以及一些简短的段落来概述关键功能。这个技术通过Tim Ferris的《每周工作4小时》一书而变得有名。

网站上会有按钮来鼓励访问者订购应用程序。在“订单”页面上，你可以选择：

• 仅说明应用程序正在开发中，并提示用户加入等待列表以获取折扣优惠。

• 将其构造成一款可供订购/预订的应用程序，并真正模拟接受他们的银行卡付款，以真正验证有多少人愿意为此付款。当然，并没有收取任何费用，并告诉用户。

然后，你可以通过付费广告来获取网站的流量，并检查“订购”按钮的点击率，以获取潜在用户的电子邮件，并在真正发布前进行收集。

就我个人而言，我并不需要创建上述的应用程序网站，以在发布之前尝试衡量需求，因为我已经在我的目标细分市场内看到了需求。

对于我的目标细分市场Merch By Amazon，我已经是该社区的一员。我在业余时间里听了很多播客，并观看了很多关于这个主题的YouTube视频。

在Facebook群组和这些意见领袖的节目中，我能够发现在细分市场中有很多人在抱怨的问题中发现了一些重复出现的问题。这让我有足够的信心，至少要构建一个MVP版本的应用程序来解决这些问题。

与其创建一个带有虚拟订单/预订单页面的网站，实际上，我是通过提供一些简单的免费Chrome扩展程序开始的。用户只需注册他们的电子邮件地址即可使用这些扩展程序。

这有助于在社区中建立信任，并在准备发布主要应用程序时收集到一个成熟且有前景的潜在用户邮件列表。

MVP是我们的概念验证，它将找到以下关键问题的答案：

• 这个应用程序是否解决了一组真实用户的真实问题？

• 这些用户是否愿意为此解决方案付费？

• 是否可以定位和吸引用户？

我们大多数软件开发人员都是有点完美主义的人。你必须抛开这个习惯，或者为你的MVP冒着没有充分理由失去几周/几个月的风险。

你必须快速行动，快速失败...积极推进失败。

应用程序的第一个版本应该很简单，缺少很多功能，可能会有一些问题。但是，要关键的是，它必须正常运行。

第一印象很重要，我们的目标是让用户的反应是_"哇喔，有人开始解决我的问题了，我怎么支持他们改进他们的应用程序，让它对我起作用更好"，而不是"这个应用程序看起来像一个5岁的孩子设计的，而且到处都是错误"_。

在我看来，当你创建MVP时，你有两个选择：

1. 将其混合在一起，以便它可以实现一项工作，并证明是否有对该产品的需求。如果你的MVP得到了认可，那么抛弃它并重新开始。
2. 在MVP上花费更多时间，打算为你将来构建的最终应用程序打下基础。

在某些情况下，你甚至可以使用无代码解决方案来快速创建一个可用的MVP。无代码工具（如Bubble.io）功能越来越强大，如果你的应用是一个Web / Mobile / Desktop应用程序，它们非常有用。但是，如果你的应用程序是Chrome扩展或生态系统插件，你将很难走无代码路径。

在我们实际发布MVP之前，理想情况下，我们要从细分市场的用户那里获得一些反馈，以帮助在它公开发布之前塑造MVP。

假设你没有现成的目标受众可以利用，你将希望深入研究你的细分市场社区，并找到一些测试用户，以帮助你对MVP提供有价值的反馈。

找到最近的帖子，人们在其中抱怨你的应用程序所提出的问题。在这个帖子下评论或将消息私下发送给用户，让他们知道你正在创建一个应用程序来解决这个问题。

告诉他们你将在X周内发布一个微型SaaS应用程序的beta版本，并希望他们在X周的时间内提供对它的反馈。作为交换，你可以提供折扣价购买或者甚至免费终身访问。

你需要5-10个Beta测试人员来获得一些可观的初步反馈。

将他们放在一个组织（Facebook群组/ Slack Workspace）中，这样他们可以看到彼此的反馈。这将确保他们不会重复彼此的问题和建议。

构建并简化反馈循环，使其对他们来说非常简单，因为他们的反馈对你来说将非常宝贵。

快速的现实检验 - 和其他事情一样，有些Beta测试者永远不会打开应用程序，并且只会失去你的视野。这就是为什么你理想情况下需要一些实际参与的人以获得有价值的反馈。

好了，你离拥有一个功能完善且没有错误的MVP版本越来越近了，而且我们的Beta测试人员对此感到满意。

很可能你的Beta组会不断向你提出功能请求，那么制定一个快速的高级功能路线图将是值得的，你可以在自己的网站上展示它，向潜在用户展示你的应用程序将如何发展。

在我的情况下，我的微型SaaS应用是我的Chrome扩展程序。自从我推出它们以来，它们为我带来了平均每月10,000美元的重复收入（MRR），这使我几年前能够辞去我的糟糕的全职工作。

经过几年的扩展我的应用程序，我以一笔改变生活的巨额现金支付款的方式出售了它们。自那以后，我一直致力于帮助全球的不满的软件开发人员通过微型SaaS逃离9-5。

无论是开始一个有利可图的兼职工作，还是建立一个救生筏，让他们最终能够跳船并辞去工作，成为自己的微型SaaS老板。