【创业说】纯技术团队创业,那些年我们一起走过的弯路

标签: 创业 技术 团队 | 发表时间:2013-09-14 20:10 | 作者:[email protected] (yedingding)
出处:http://www.36kr.com/

编者按:本文作者是 Pragmatic.ly 创始人叶玎玎。Pragmatic.ly 是一个纯技术背景出身的团队,在两年的创业中走了不少技术型团队很很容易会走入的弯路,本文作者分享了其中的一些经验和教训。原文最先发布在他的 个人博客,你可以通过微博联系他 @yedingding

弯路和未来

准确说,Pragmatic.ly 从有这个想法到现在已经有 2 年了。11 年 10 月份的一个晚上跟 Daniel 和 Terry 在对我们所有用过的项目管理工具吐完槽以后,然后决定自己造一个,12 年春节前后真正当个事做,4 月底 Ben 加入,7 月份发布 Beta,先在海外做了差不多 8 个月,今年 4 月份开始调整方向,转向国内,6 月底重新上线到现在,整个过程各种状况各种弯路,但是每天都能感觉到变化,每天都是新的学习,乐在其中。

那些年我们一起走过的弯路

现在回过头看看,我们犯了好几个大的错误,当然,也许这些可能很多技术型团队必须得走的弯路。

过早和过多地做开发

我们创始团队的构成是两个开发和一个设计,技术能力很强,市场能力很弱。当我们决定要启动这个项目的时候,我们没有去找更多的用户聊天,聆听他们的想法,而是选择直接进入了开发阶段,美其名曰解决自己的问题。我们不停得去假想用户的需求,所有人都在做开发,直到发布。而整个过程,我们甚至没有去外界透露我们的产品目标,没有去收集潜在客户,这也造成了后面的被动。也就是说,我们在整个前期过程中,没有一个清晰的特定的用户群,没有去了解这个用户群到底存在什么问题,再去打造适合他们的产品,而是做出了产品后,再去寻找那个适应于我们产品的用户群体。所以当产品发布后,我们发现推广很难做,各种阻力,因为定位不清晰,也就很难传递合适的信息给适合的人。

在 YCombinator 有个理论,在产品发布前,你应该专注并只专注两件半事情,1 开发 + 1 跟用户聊天 + 0.5 锻炼身体。了解你的用户群体,很重要。

太注重工程正确性

对于一个技术型创业团队而言,而且是外包团队出身,技术研究总是能让人很兴奋,所以很容易就会沉迷于工程细节。开始编码时先设计个好的架构结构,看到不好的代码就忍不住来几下重构,用 TDD、BDD 恨不得 100% 测试覆盖率,Backbone.JS、Ember.JS、Angular.JS、Marionette,不停地调研哪个最适合自己的项目。总之,洁癖太重,不停地在追求工程上的正确性,没有把时间花在正确的地方,没有花在能给用户带来真正价值的地方。我们最需要的是什么?是能快速地发布快速地迭代,有反馈才能有改进,而代码写得再漂亮对你的用户也是没有价值的。

即使到今天,我们也很难做到非常 quick and dirty 的做事情。不过比起第一天开始的时候,我们已经"改进"了很多,Make it work, ship it and then improve it.

天使用户获取成本太高

从去年发布 Beta 到年初,我们一直在做国外市场,因为认为国外的市场成熟,教育用户的成本低,而且付费习惯也更好。这些都是对的,但是问题是为什么用户要选择你而不是其他产品。Pragmatic.ly 做为一个协作产品,在海外市场有很多的竞争者,所以做为市场上的新玩家,需要寻找到一个特定的用户群体,找差异化寻找突破口,也就是天使用户。而做为一个面向 B 端的产品,天使用户之所以选择你,是因为他们信任你,信任你这个人,信任你做的这个事。这种信任,有可能因为你们是朋友、或者朋友的朋友,有可能是因为你们在一个活动一次会议上相聊甚欢,有可能是因为你在们网上深度交流过,但是,当我们试图在中国做海外市场,语言差异,文化不同,认知度缺乏,用户获得的成本很高,更不要提客户了。

而当我们开始专注做国内,很多原来无从下手的一些问题就得到解决了,现在也有不少不错的天使用户,也有非常好的反馈,让我们对产品的改进有方向有目的可循。

冷冰冰的文案

去年,我们的文案很简单,介绍了 Pragmatic.ly 是什么,有哪些特性,而且还刻意限定在一个页面里,让用户不需要翻页就能了解所有信息,事实证明这是个非常糟糕的设计。我们假想着列出的一些特性就能吸引到用户,但是问题是用户永远不关心你在做啥,用户关心的是你做的东西能怎样帮助到他。所以,当一个真正的用户来到 Pragmatic.ly 上,我们应该让他看到的是 Pragmatic.ly 能怎么的帮助他更好地管理项目,更高效地工作,一个好的文案,应该要做到像在跟用户对话一样,非常有针对性,告诉目标群体我们是如何如何理解你的问题并是如何解决这些问题的,是另外一个层面的交流。

目前 Pragmatic.ly 的文案比起第一版时已经是很大的进步,信息传达更明确,也刻意有一些吸引用户的 tricks,可能还缺乏的是给用户更大信任和信心的成功案例,不过因为我们希望是真正的客户们在现身说法,所以还需要一段时间。

Pragmatic.ly 的目标

如同 36氪的报道一样,我们不想打造一个企业平台的应用商店,而是以任务管理为基础,为小团队初创企业做一个真正提供价值的高效协作工具。目前国内企业级软件需求足够,但是进展行程却十分迟缓,尤其是在 Pragmatic.ly 面对的小团队市场来说,价值和价格没有做很好的匹配。人们习惯用自己看得到的能理解的来衡量一个东西的价值。比如,如果我今天买了一个游戏,那么只要今天这个游戏给我带来了快乐,我就觉得这钱花得没问题。但是像 Pragmatic.ly 这样的协作类软件,并不具有这个特性,它需要整个团队一段时间的试用,才能看到效果,才能知道是否是好东西。问题摆在眼前,在教育用户的同时,需要我们更专注,耐得住寂寞,做好长跑的准备,做精,做少,做美。

我们希望每一个购买 Pragmatic.ly 的客户,都是对我们产品满意的用户。如果你购买了我们的服务却没有使用起来,那么我宁愿不赚这个钱。所以,除了要让掏钱的人满意之外,我们也很注重使用者的体验感受。我们会继续保持着它的简单,没有定制,没有过多的配置,不需要培训,也能上手即用,即使是对一些非技术背景出身的人来说。在未来你可能还是不会在 Pragmatic.ly 看到知识管理系统、在线群组系统等等,但是我们会努力让任务管理体验做到极致,进度、状态,才是项目的真正立身之本。Pragmatic.ly 也不需要太聪明,限制用户做这做那。一个工具,不管怎样最终也只是一个工具,很多事情毕竟还是需要人来做,所以应该是工具去灵活地适应团队,而不是逼迫用户削履适足,反被其所俘。

"因为用了 Pragmatic.ly,我们更快更简单地做出了更好的产品。" 如果听到用户跟我们说这句话,将会是对我们的最大鼓励。面向挑战,我们已经准备好了。面对改变,你准备好了吗?

欢迎个人博客作者在36氪分享自己的优质原创内容,内容需符合36氪的读者群且当天发布在自己博客的文章,投稿请发到:【tips#36kr.com】,附带自己的简单介绍以及原始链接,我们会在文章给出首发地址,也可 在线提交

除非注明,本站文章均为原创或编译,转载请注明: 文章来自 36氪

36氪官方iOS应用正式上线,支持『一键下载36氪报道的移动App』和『离线阅读』 立即下载!

相关 [创业 技术 团队] 推荐:

说说技术型创业团队的技术选型

- rhyttr - DBA Notes
看到微博上《程序员杂志》在征集"一分钟先生"的话题:如何做好公司/团队的技术选型. 其实大公司或者大一点的团队选型几乎不需要太多讨论的 -- 最后会不可避免的绕到技术官僚的话题上去. 这里我想简单说说技术型创业团队技术上的选型问题. 如果只能选择微软的技术路线,比如团队几个人只会用微软的技术做开发,甚至也不想学别的,那么似乎没有别的办法,将就一下吧.

工程师在创业团队的技术挑战

- cong - DBA Notes
曾经有不少人对我问过类似的问题:作为技术人员在创业团队(或是小公司)工作,技术上没什么挑战,觉得自己得不到锻炼,我该怎么办. 的确,就说互联网这个领域吧,创业团队或是小公司的网站规模往往并不大,或者至少要从小做起,用户访问量和那些大型网站在当下自然没法比,从这个角度上看,很多中小网站的确暂时面临不到这些高并发、大流量、高可用的这些"严峻挑战",另外,团队的职能岗位甚至也没有大型公司那么齐全,人家连做配置管理的团队规模甚至都比你整个公司人多,似乎在小团队作技术的出门都低人家一头,见面不好意思打招呼,真的有必要妄自菲薄么.

续——冯大辉谈技术性创业团队的技术选型[原创]

- huyun - 运维进行时
       原文冯大辉谈技术性创业团队的技术选型提到了天涯,好吧. 站在一个天涯从事6年运维工作的角度,我就多说几句,天涯属于破釜沉舟要摆脱这种束缚的这一类. 原因不用多说,文中提到的问题天涯多少都有碰到或存在. 目前已全面拥抱开源技术,这不是一时头脑发热所做出的决定. 根据现状、未来的发展策略理性来选择的.

【创业说】纯技术团队创业,那些年我们一起走过的弯路

- - 36氪 | 关注互联网创业
编者按:本文作者是 Pragmatic.ly 创始人叶玎玎. Pragmatic.ly 是一个纯技术背景出身的团队,在两年的创业中走了不少技术型团队很很容易会走入的弯路,本文作者分享了其中的一些经验和教训. 原文最先发布在他的 个人博客,你可以通过微博联系他. 准确说,Pragmatic.ly 从有这个想法到现在已经有 2 年了.

技术出身的创业者管理销售团队的七条成功秘笈

- - 互联网的那点事
销售是公司的血液供应线,销售管不好公司可能会走向破产. 作为技术出身创业者如何管理公司销售团队尤为重要,小编在此摘录一些相关销售案列供大家学习参考. 挑个好销售太难了,你不懂销售怎么判断呢?我认为要想把复杂的看人角度简化的话,你主要判断他是否会勤奋以及他是否知道销售工作流程就够了. 多数半吊 子销售人员其实并不知道单子是怎么拿下来的,他们通常只能跟你说”我要满足客户需求,我要让客户知道我们的产品和服务能够和他需求对接”.

谈技术团队目标

- - Tim[后端技术]
技术主管新年想得最多的一件事必定是如何比上一年做得更好. 宏大的目标设定每个团队都会做,谈几个不引人注意的小问题. 见过一些技术团队将计划定义为“按时完成需求”,需求驱动并没有什么不对,但是研发工作仅考虑被动需求的话是很难做好. 之前完成的许多需求有什么共性. 经常出问题/bug/故障的项目/功能/模块是哪些.

了解豆瓣技术团队必看

- - 张沈鹏
文 挑灯看剑@ douban.com. 以下内容按照时间倒叙排列,方便各位阅读,以后不定期更新:. (之前发布的内容,不保证符合现状). 豆瓣首席科学家、算法组leader在程序员杂志上发文《下一代个性化推荐系统》. 豆瓣高级工程总监段念在letagilefly会议上讲豆瓣的技术团队敏捷实践. 豆瓣设计师在极客公园讲豆瓣FM的设计.

创业团队怎样邀请伙伴

- wen - 坏脾气的小肥
可能是因为我长得帅,最近几个月收到了十几个创业团队的邀请. 在与创业团队接触的过程中,略微吃惊地发现,大部分邀请没什么技巧,甚至有明显不得体的地方. 我不知道这种邀请方式能有多大效果. 对普通员工,人家跟你谈的是待遇;对核心伙伴,又显得傲慢或者轻率. 不止一个团队在初次接触我的时候,一来就问,你在哪家公司,担任什么职务.

对创业团队组建随感

- - 人月神话的BLOG
最近有朋友问我对于组建一个创业型团队有哪些建议或感想,我自己没有真正组建过,不敢谈真正的建议,只能说根据自己的一些观察有一些这方面的杂感. 如果你完全是牵头人,组建的时候自己一定要出钱,不要是自己只出技术完全靠别人出钱,这跟知道哪支股票要涨缺自己不愿意投钱,借别人的钱来投资,还告诉别人赚钱了平分亏钱了你担着一样的道理.

如何做好企业/团队的技术选型?

- 【虎.无名】 - 《程序员》杂志官网
好的技术选型,能最大程度地提高企业和团队的效率,从而开发出满足用户需求的产品. 作为一线的技术管理者,他们都是怎样做的呢. 大公司或者大一点的团队的技术选型几乎不需要太多讨论,因为最后会不可避免地绕到技术官僚的话题上去. 这里我简单说说技术型创业团队的技术选型问题. 如果只能选择微软的技术路线,比如团队只会用微软技术,也不想学别的,那么似乎没有别的办法,将就一下吧.