又又又创业了朋友们！第三次，这次做改SaaS产品！

地里的朋友们，我又回来了。这次又又又创业了。之前在地里和大家分享两次创业的经验，感兴趣的朋友可以去下面的链接看一下。这篇文章也比较长，有兴趣的朋友可以慢慢看。

第一篇：https://www.1point3acres.com/bbs/thread-615727-1-1.html

第二篇：https://www.1point3acres.com/bbs/thread-681463-1-1.html

开始之前首先说一下第二篇里的创业项目结束的原因。我和我的合伙人执行力不错，产品做得快，在我把所有的功能，设计和tickets都按照优先级排好之后，他就快速的投入到了开发当中。而在这个过程当中，我主要负责的是测试，安排需要收集的数据，和准备下一步的上线计划。我们也是在8个礼拜以内就把第一个版本上线了，而且第一天也有差不多一百多个下载，基本都是我们自己通过社交平台上一些推广，让朋友和身边的人下载。接下来几天也陆陆续续的不断每天有几十个的下载。这其中也有别的网站，包括product hunt, reddit, linkedin等。差不多一个多礼拜以后，我们发现产品的留存率特别低。在这个过程当中我们又做了一次更新，这个更新我们把几个外卖平台的折扣信息也加入进了app，这个折扣信息可以让总价格相差$5以上。在开发更新的同时，我通过FB加了上百个美国各个地区的餐厅Group。这些group里就是各个地区的人推荐本地的一些餐厅，每个群从上千甚至到上万人都有，但这不代表每个群特别活跃。在推广app之前，我会先和群主沟通，说希望通过这个app帮用户省钱，也帮餐厅带去更多客流量。一般提前打好招呼群主通过审核的几率也高，因为这些群是不允许发广告。当时通过这种方式，也陆陆续续的获得了一些用户，但还是卡在留存这边。

另一个我们遇到的尴尬的问题就是没有一个好的赚钱模式。虽然外卖是个200亿+的市场，但这和我们没太大关系。同时因为餐厅的利润都特别低，如果想通过然他们在我们平台打广告来赚钱，除非我们的app流量很大， 否则也非常麻烦。

在留存和商业模式都没有一个清晰的下一步计划的情况下，我们最后就决定终止开发了。其实创业这个东西很多时候最初的想法确实很大概率会失败，比如这个外卖的想法，虽然没有成功，但如果我们想继续在餐饮行业摸索的话，我们其实也可以通过这个app作为一个切入点，不断的和商家或者用户去聊，去探索一些别的痛点。但因为餐饮这方面都不是我们特别了解的行业，后来发现也没有太多的热情，所以我们最后没有继续下去。

结束第二个项目之后，我们得出了一个总结，就是我们之后尽量找我们适合并且熟悉的行业。第二就是尽量不要做消费者类产品，因为推广实在太难，而且没有办法很准确的定位。不过这也可能也是我自己能力原因哈哈。基于上面两点的总结，我们决定未来做SaaS产品，最解决部分人群的问题，而不是试着做一个产品去解决大部分人的问题。SaaS还有一个好处就是商业模式方面比较清晰，一般都是subscription。

总结完之后我们没有立刻开始去做别的项目，我们这次花很多时间在探索上面。因为大家都wfh的原因，我对远程协作和distributed workforce的未来走向很感兴趣。毕竟越来越多的公司开始慢慢转型wfh，所以我觉得这在未来是个很大的市场。比如dropbox也完全wfh，而这当中很大的一个原因就是他们未来产品的方向主要是解决远程协作的痛点。而大家wfh之后，也确实出现了很多这方面的问题。

首先我遇到的一个痛点是一个新人加入公司onboarding的问题，但是对于普通onboarding其实已经有很多HR相关的solution了，比如rippling。所以我把这个范围缩小到了engineer onboarding，比如我们公司就有海外的团队，他们加入团队之后有一段时间不知道该做什么，或者说不了解产品逻辑。这个就是因为我们在做团队engineer onboarding的时候没有一个很好的process。基于这个发现，我采访了身边很多的程序员，从startup，到中型的公司比如OKTA, Twilio, 再到大场LinkedIn，Amazon，Apple，Google等等。好家伙，每个公司甚至到每个组都完全不一样。这个痛点的一个挑战在于因为每个公司每个组都不一样，很难在onboarding上找到一个特别好的规律。不过在这个采访当中，我发现了一个共同点就是文档（documentation）。但经过我仔细了解后，文档本身也是个非常大的痛点，这里包括创建文档和维护文档。作为一个小的团队，也不可能一上来就开发一个特别大的app去解决这些很大的问题，最后发现没人愿意用。所以我们又再继续缩小，最后缩小到了截图这一部分。

我自己的工作是一名PM，而其中一部分工作内容就是我需要经常收集很多我们产品的截图，通过这些截图来做各种文档。每次我打开app，然后一页页的截图是非常花时间的事。除了我自己之外，我们开发团队也经常通过使用截图来交流。比如说某个地方和design不一样，或者有一些文字有问题，又或者说上传截图来问团队的意见等等。所以我们就迸发了一个想法，有没有可能我们把产品页面的截图在每一次产品build和deploy的时候就自动截图并且分享到Slack或者Jira上。这样的话开发人员不需要手动截图，而这个截图自动发送到slack里之后，里面的所有人都能看到。

有了这个想法之后，我上周和我的合伙人沟通了一下，觉得这是个不错的起点。他也开始了准备工作和做一些研究，而我也在上周做好了我们产品的landing page。希望大家过目并且给我们提供一些意见和反馈。我们现在产品还在开发当中，也希望可以通过这个landing page收集一些可能感兴趣的用户。非常欢迎大家的反馈，一起交流！

网站：https://www.airsnap.io/

补充内容 (2021-05-13 12:43 +8:00):
大家好。我们在开发的同时也在做用户调研，有兴趣交流的朋友可以加我微信panixjason.

看了下来觉得有几点楼主可以考虑 第一 真需求 不是自创需求 很多创业小伙伴 可能是自己的需求来做事情 第二 需求大小与频次 这个其实很简单 实用 是不是 也使用 更可能是不是 适用 ，这个量级要有，要不然就是自嗨！ 第三 建议 项目本身市场空间以及可替代性 这个很关键

最后 最重要的 无论什么 如何运营推广 留存 很关键 你应该缺少 懂的人

5cents，仅供参考，作为投资人，你这是to B的项目了，不能用to C的那种 idea爆款 模式。

to B 你要先去公司里找客户，拿着几个草图说假设有这么一个产品，你们用不用，1%的人会说用，然后你跟他们签协议，规定自己做出来之后，他们保证会用1年，否则赔钱。
然后你拿着这几十份协议，雇佣几个国内的eng，几周做出来，然后客户用上，给你反馈，你再拿着这个v0产品找更大的客户，签更大的协议，Repeat Repeat Repeat。

好多年之前也想过exactly 这个idea
直接截很多屏应该没人会看的
需要截“有改动部分”的屏，并且要能显示出变化，
代码层面如何知道code change是否能产生一个肉眼可见的变化，under what conditions, etc
产品“稍微”复杂以后，code path 非常多，要清晰分辨出变化，选取视觉上可见的差异这一步应该是很难自动化的
考虑到是per CI or CD run 收费，应该会产生大量大量的数据，所以做区分是 Must have, 而不是nice to have.

另外一个团队里面，假定 1 个 PM 10 个 DEV，做 1 个 sprint 假设有 5 个屏幕的差异（已经很多了）
截屏这个动作一般就是消耗一个人（PM）的少量一些时间，绝大部分人应该感受不到价值。

楼主执行力超强，看好楼主。希望能和楼主交个朋友...


（但是没有很看好这次的项目🙊

microarron 发表于 2021-5-11 16:00
楼主执行力超强，看好楼主。希望能和楼主交个朋友...

很高兴可以交个朋友哈。

请问对于产品本身有反馈吗？比如说你是程序员，然后觉得这个产品并没有办法帮助解决一些沟通的问题或者节省时间成本。谢谢！

自动截图确实省了pm的时间但是程序员会看吗？感觉主要还是大家看不看的问题……
赞楼主的执行力！

lz执行力超强啊！！！

看过楼主几次，想跟LZ加个朋友，作为工程师平时即使onboard一个新的项目也很麻烦，但是这个问题个大公司都有，主要是大家都懒得documentation，完全取决于manager愿不愿意推进

gloriasuns 发表于 2021-5-12 06:32
自动截图确实省了pm的时间但是程序员会看吗？感觉主要还是大家看不看的问题……
赞楼主的执行力！

是个好问题。我们的程序员有些时候在pr里都会自带一个screenshot。还有就是为了满足现在wfh，解决一个远程协作，大家不是同时在线的问题。这样放一个截图好过于用文字表达。不过还是得多花时间验证。

K姐 发表于 2021-5-12 09:04
好多年之前也想过exactly 这个idea
直接截很多屏应该没人会看的
需要截“有改动部分”的屏，并且要能显示 ...

谢谢反馈。这个其实和合伙人也讨论过，我们最开始想法是做recording，但后来想先从截图入手，感觉比较好做个mvp做实验。但确实如果有能够直接识别变化而不是整个屏幕截图会比较好。

说到具体屏幕的分布，考虑到开发都是分开的，有自己的feature branch，所以验证也是分开验证。也就是说可能一个人改的是一个页面的信息，另一个人改另一个页面的，或者两个人在一个页面但做的是两个不同的部分。所以一般最早的commit是feature based。全部merge到一起之后才会有个整体的截图。可能牵扯到的use case会比较不一样。

其实这些截图另一个use case更多考虑的是远程协作交流的问题。如果一个UI update完成之后自动发布到pr或者slack里，这样大家可以不同时间看到不同的更新。

最近也一直在做一些用户调研。如果你有兴趣跟我聊聊的话可以加我微信哈。panixjason