在线咨询
技术分享

Pragmatic.ly团队分享:那些年我们一起走过的弯路

管理员
2026年2月10日 16:40
7 次阅读

从面向海外用户转向国内用户,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,我们更快更简单地做出了更好的产品。” 如果听到用户跟我们说这句话,将会是对我们的最大鼓励。面向挑战,我们已经准备好了。面对改变,你准备好了吗?

管理员

技术作者

2014年6月7日
7 次阅读

文章分类

技术分享

需要技术支持?

专业团队为您提供一站式软件开发服务

相关推荐

您可能还对这些文章感兴趣

数据库分库分表经验:团队协作经验分享
技术分享

数据库分库分表经验:团队协作经验分享

这篇文章讲了数据库分库分表一个常被忽略的关键点:团队协作比技术方案更重要。文章分享了作者团队的真实经验,指出如果只顾技术设计,而没让产品、开发、运维等各方统一思想、紧密配合,项目很容易翻车。比如开发会抱怨SQL难写,运维面对新架构手足无措。核心建议是,动手前一定要先开“统一思想会”,把所有人都拉到一起沟通清楚。

2026/3/16
后端技术趋势:踩坑经历与避坑指南
技术分享

后端技术趋势:踩坑经历与避坑指南

这篇文章讲了我们后端开发从“救火队员”到从容应对的转变。作者分享了一次因依赖冲突导致深夜故障的真实踩坑经历,并提出了两个关键的避坑方法:一是别让技术文档过时失效,二是要严格落实代码审查。文章用很亲切的口吻,把这些经验比作“摔跟头摔出来的”,就是想告诉大家,关注这些基础但重要的环节,能让整个研发流程更可靠,把精力更多放在创造价值上。

2026/3/16
就业市场分析:团队协作经验分享
技术分享

就业市场分析:团队协作经验分享

这篇文章讲了咱们技术人现在面临的一个现实:就业市场越来越看重团队协作能力,光会“单打独斗”已经不够了。文章结合我们做一物一码项目的实战经验,分享了技术趋势(像自动化测试、DevOps这些)如何推动团队从“各扫门前雪”变成“拧成一股绳”。核心就是告诉咱们,除了打磨硬技术,更得学会在团队里高效协作和沟通,这样才能让自己在市场上更“值钱”。

2026/3/16
技术人员职业发展规划:工具使用技巧分享
技术分享

技术人员职业发展规划:工具使用技巧分享

这篇文章讲了咱们技术人员怎么在忙碌工作中还能高效成长。作者说,职业发展其实是场效率赛跑,光加班没用,关键得会用工具、懂方法。文章分享的第一个“加速器”就是打造自己的效率工具箱,比如用好IDE插件、自动化重复操作,别再做“人肉CV工程师”。说白了,就是教咱们怎么把每天省出两小时,用来学习和提升自己,而不是一直陷在琐事里。

2026/3/16

需要专业的软件开发服务?

郑州微易网络科技有限公司,15+年开发经验,为您提供专业的小程序开发、网站建设、软件定制服务

技术支持:186-8889-0335 | 邮箱:hicpu@me.com