我是如何从0开始做大一个SaaS产品的

Line 
S600 
5400 
5200 
Bar 
Day 
Week 
Month 
Quarter 
Year 
Jul 07, 19 
sep 30. 19 
Nov 30. 19 
Jan 31. 20 
Mar 31. 20 
May 31.20

对很多有创业精神的程序员来说,创建一个成功的SaaS的产品一直是一个梦想。在我创建我的SaaS的过程中,我发现和别的创业者一起分享和对比是这个过程中必不可少的部分。假如没有这些分享,我可能也没法创建一个个成功的SaaS的产品。本文,我就会分享,在我创建SaaS的过程中的所想所为,主要是我如何开始创建SaaS的产品以及到最后,我是如何获得第一个付费用户的。

不管你是想创建一个产品还是已经创建了产品,这篇文章都会对你有所帮助,你可以看看我是如何做的,然后和自己相比较,希望能带给你新的启发。

我个人每周都会特地去花5个小时分析别人是如何做的,我总是想看看新的想法,以及如何避免犯别人的错误,同时看看有没有什么新的策略可以用来提高用户的体验。

正是基于这样的原因,我的分享将不会有所保留,他会包括我已经做了的,以及什么我并没有做,我们的目标就是希望别人能够从中有所收获。

本文将按照时间顺序分为以下七个部分,基本上包含了所有我做过的事情:

  1. 探测问题
  2. 量化问题
  3. 分析竞争对手,并看他们是如何解决这个问题的。
  4. 开发第一个prototype
  5. 抛弃所有再次重新开始
  6. 得到第一个订阅
  7. 怎样继续前行

我开发的SaaS产品是Insepctor,他是一个实时的监控工具,可以用来帮助软件开发者检测他们的应用,以防止因为技术的故障而失去客户和金钱。

探测问题

过去10年和软件开发者打交道的经验告诉我,每天去处理和用户相关的技术问题,对他们来说太难了。

虽然开发团队和用户有着紧密的联系,但是这对开发软件产品的公司来说是非常危险的,因为当真的有问题的时候,你就会发现这种紧密联系是多么的脆弱。

客户不希望有问题,这个显而易见,没有人喜欢有问题,并且本能地会去把问题最小化。但是下意识的否则现实的问题其实并不能真正解决问题,甚至会让客户怀疑他是否还应该继续付费。

客户其实并没有兴趣帮你报告问题,他们只会简单的离开,选择一个新的应用,下次你再见到他可能也许是多年以后了。

尽管如此,很多我合作的团队还是在使用一个众所周知的方法来探测应用是否有问题:“假如有用户联系你,那么你的应用就是有问题的”,而这并不是一个技术的解决方案。

但是很奇怪的是,我们总是有各种各样的理由,比如budget有限,客户需要很急,管理的问题等等,让开发者有很大的压力,所以最终选择的总是一个修修补补的方案来解决这个问题。

我的经验告诉,这不是一个最终的解决方案。

量化问题

2019年的时候,我刚刚完成了一个项目,并且准备花点时间休息一下。以往几年,我总是用这样的机会来看看有没有什么商业上的机会,可以运用我的技术来帮助我做一些我自己的商业。

从我的开发经验来看,我发现一个简单的及时的检测系统将会帮忙开发团队来及时发现他们应用的问题,而不再需要依赖于用户来报告问题。但另一方面来说,我不需要一个能检测所有东西的工具,因为一般来说所有东西通常也意味着什么也不是。

并且我不想他很复杂,因为我不想让他们需要花费一一个月来学习怎么使用,或者需要雇佣一些人来专门做这件事,方便使用,易于上手是我的目标。

第一步,我需要看的是市面上是否已经有了类似的软件,所以我google了一下“应用检测”,出现了941,000,000条记录:

Google 
application monitoring 
Q All Images News Videos 
About 941.0001000 results (0.66 seconds) 
Maps 
Mora 
Settings 
Tools

哇,看起来这是一个很普遍的问题。那这个问题究竟是有普遍呢?

我们知道软件开发团队有时效率很低是因为一个工作的预估的复杂度和对商业的影响有时有很大的差别。尤其在大规模的情况下尤为明显,Twitter上有一个调查的结果如下:

0 
OverOps 
@overopshq 
Segui 
NEW POST: How much time do you spend as 
a developer only on production debugging? 
> > > bit.ly/2yTDvqn < < < 
O Traduci il Tweet 
0-10% 
50% of them spend up to 
12% 30-50% 
20:05 - 18 2017 
6 
Retweet 2 Mi piace 
50% of their time by simply 
checking that app is working 
eoe

50%的开发者花费超过50%的时间就是为了检测他们的应用是否还在正常的工作。

软件开发者的薪资都是很高的,通常我们付给他们钱是为了让他们开发程序,假如一个开发者每天都花费超过50%的时间来检测他们的应用是否正常工作,那么一个自动化的检测工具肯定是值得我们花钱去购买的。

那么问题来了,为什么还没有人来做这件事情呢?

评估竞争对手和他们解决问题的方法

我思考了一个公司在决定是否买一个工具来提供生产率的时候用来进行评估的两个参数:

  • 易用性 (方便安装和使用)
  • 功效 (我花费了x来解决问题,我得到了x+10,这样我就赚了10)

使用这两个参数,我把竞争对手的情况花了一个图,如下所示:

Easy to install and use 
Sentry 
Limited 
TOO complicated 
Complete 
New 
Stackify 
DATA OOG

等我收集了足够的信息,再回头看一下这张图,就很容易知道他们的问题所在。

总得来说,简单的工具并不能满足开发者的需求,而复杂的工具虽然可以满足要求,但是用起来太复杂,需要专业的人员来进行安装配置等等。

所以在我看来,问题不在于监测工具本身,而在于如何提高开发团队的效率。

所以,一个好的产品应该安装简单,配置方便,并且它的功能至少能够满足一个中型团队的实际需求。据此,我们Insepctor的定位如下图所示:

Easy to install and use 
Sentry 
Limited 
TOO complicated 
Stackify 
inspector 
Complete 
New 
Relic, 
OATADOG

开发第一个prototype

最终我决定来开发一个原型,在开发的过程中,我渐渐地明白了这种工具的各种问题所在,并且慢慢体会到用户在真实使用中可能会遇到的问题。

从技术角度来说,这个监测产品需要能够处理大规模的数据,同时我希望能够实时地处理这些数据。

73 20'

最终我花了很多时间在后端部分,甚至超过了我的预期。

抛弃所有再次重新开始

过去这些年,开发一个商业产品的梦想让我学习了很多市场的策略,并且不断地关注相关的信息。我开始在我的博客写一些文章,并把他们发布到不同的网页和社交媒体上,收集一个反馈。

虽然我的英语不是很好,毕竟不是我的母语,不过我还是受到了很多反馈:

  • 我不知道我用它能做些什么?
  • 我该如何安装它
  • 为什么我要使用它而不是XXX
  • 它提供的内容和别的有什么差别?

我很难客观地面对这些反馈,因为你知道,我只是一个开发者,不是一个市场人员或者sales,很多时候会有一些程序员特有的冲动。

教训1 – 专业的人做专业的事

作为一个技术人员,我最擅长的就是修改问题,而不是兜售产品,所以我需要做的仅仅是学习怎样交流,并找到解决问题的方法。

我花费了一个月写了关于这个产品的所有重要内容,包括我为什么要做它,我在开发过程中遇到了什么困难,我是怎么解决这些问题的,代码的示例,技术指导等等。

然后我把这些都交给了Robin,他是一个加拿大人,然后我帮我整理了所有的文档,并且重新用native的英文做了修改。

教训2 – 产品的不足

如何设计用户的产品交互界面是一个很麻烦的事情,尤其对我们技术人员来说。但是这又很重要,所以我不得不让我自己重新来做这件事,好的消息是我最终解决了大部分的技术问题,对一个程序员来说,解决designer的问题着实不易。

为了解决这个问题,我参加了两个图形接口开发的课程,读了三本关于设计和用户体验的书籍,直接使用了VueJs来作为我的前段框架。

教训3 – 不管怀疑,先试一试

当我们看一些书籍和视频的时候,尤其是关于商业和市场的内容,我们总能发现一些东西,在实际情况下并不是特别适用。

比如,我们有个口头禅“假如你等到所有的东西都好了,你将不可能开始你的商业”。这句话是正确的。

但是我们起初的体验却让我们的情绪产生了反应,这导致我们一直处于一种防御状态,这里有一个错误,就是创造一个值得购买的产品是一个过程,而不是某一个事件。

我们经常被启动这个词所误导,所以忘记它,集中精力在创造上面,一步一步地理解客户的需求,然后根据他们的需求来改进你的产品。这样才能取得最后的成功。

Inspector诞生

我又花费了两个月,在这些时间里,我决定从头开始重塑品牌,尝试不仅仅在产品方面而是在市场和营销方面都使用原型来体验。

Inspector — 在用户意识到问题之前就能定位到问题所在,而耗时一分钟以内。

137 
56544 ms 
1526 MB

我们不停地告诉自己,我们的目的不是监测本身,而是帮忙开发者自动化他们的操作:

  • 不需要花费任何力气
  • 不需要浪费时间在手动的操作上
  • 有需要的时候,要保证灵活性

得到第一个订阅

2019年七月14号,我的工具在Laravel News上线了,这是一个Laravel开发者最重要的社区网站,他们中很多人早就知道了我的这个工具。

4天之类,有2000个人访问了我们Inspector的网站,有大概100个公司注册了,最早的两个用户 — Holland和Switzerland — 订阅了我们。

我很难描述当我得到第一笔付款的时候我是多么的兴奋。那是一个夜晚,我感觉我这七个月就像驮着一个大象,而现在,我终于可以放下它并自由呼吸了。

在接下来的几个月中,我们遇到了很多问题,花费了很多时间,精力甚至是金钱才解决了它们。它们包括黑客攻击以及过载等等问题,它们甚至让我在圣诞节都不得不坐在电脑面前去解决它们。

还有一些问题会让你从天堂跌到地狱,你会意识到很多问题原来比你想象的要复杂得多。

第一个订阅让我知道,我的产品是有价值的,感谢网络和云技术,使得我的产品可以被全世界的人们所使用。现在有超过800个公司和个人已经使用过Inspector,并且我们还有超过20个活跃的订阅。

怎样继续前行

分享和比较是我能到今天这个地步的法宝,所以我会继续做这件事情。

我也意识到很有很多事情我们可以改进,甚至还有一些问题,我们完全忽略了。这也是为什么我们会在这里讲这个故事的原因。

我们的目标是把自己介绍给别的管理者,商务伙伴以及市场和技术专家,以便我们的产品能够进入到下一个level,并且被全世界所知道。

我们希望我们的产品能够让开发者摆脱无聊的,重复的人工操作,而把精力集中在更有价值的事情上。

总结

这篇文章中我分享了我创建弟弟一个SaaS产品的实践和新路历程。没有分享就没有Inspector的今天,所以感谢你的阅读,假如有什么意见,欢迎留言。

原文地址:https://hackernoon.com/how-i-designed-and-launched-a-saas-product-from-zero-to-the-first-10-customers-qj6r3umh

You may also like...

Leave a Reply

Your email address will not be published. Required fields are marked *