外国人创业在纽约-Producteev创始人Ilan Abehassera访谈

February 18, 2011 § Leave a comment

本文同步发表在36氪上。

Producteev是一款面向个人和团队的在线任务管理(task management)和协作工具,2008年12月上线,目前已经成为任务管理生产力工具领域的领先产品。公司的创始人兼首席执行官Ilan Abehassera是法国人。以往很多关注美国创业公司的访谈的对象通常是美国人,很少有外国人谈在美国的创业经历。今天利用Ilan在巴黎的机会,向他探讨了作为外国人在纽约创建Producteev的经验。

Notor:和我们谈谈你去美国和创立Producteev的经历吧?

Ilan:2004年我从马赛管理学院毕业,之后在欧莱雅做了一份实习,参与Giorgio Armani的市场营销工作。2005年,我找到一份在费城为巧克力高端品牌Michel Cluizel做零售商的实习,算是我来到美国的第一步。实习结束之后又转到迈阿密工作,为一家公司建立了French Network的社区网站。

当时互联网业正从上一个破裂的泡沫中慢慢开始爬起来,创业的机会不算少,但25岁的我能力和资源都非常有限,单干再寻找资金太困难了。于是我来到纽约加入了SCANBUY,这家创业公司开发了一款手机应用,为带照相功能的手机提供扫描商品条形码获取比价信息的服务。当时还是2006年,应用是在java平台上开发的。我们的产品思路很对,但是却远远跑在了市场前面。虽然最后这家公司没能成功地成长起来,但这段经历为我在美国创业领域建立良好的人际关系网络打下了基础。

2007年我又加入了一家法国创业公司Zlio,帮助他们打开美国市场。Zlio提供社会化电子商务服务,让用户能通过模板在短时间内创建自己的线上商店,并帮助他们从数量庞大的供货商手上挑选出最优的产品,我们通过从这些个性化的商店里产生的流量和完成的交易的收入分成来盈利。Zlio刚进入美国时非常成功,但是没多久,我们就发现Google在搜索结果中屏蔽了Zlio所有的页面。当时我们网站的流量几乎完全来自Google,这简直是致命一击。我们尝试通过各种渠道和Google联系,但是却没有收到任何回复。反思一下,应该是Zlio上很多受欢迎的商品因为被过多的用户商店收录,而且产品的介绍内容也被用户重复使用,所以被Google拉入了搜索结果排名欺诈的黑名单。这次经历给我的教训非常深刻,创业的时候千万不能对某个产品或者服务形成过分的依赖,应该主动发展多渠道,而且要对自己模式的弱点充分小心。

我一直使用一些任务管理的工具来提高工作效率,任务管理软件这个市场里产品很多,看似竞争很激烈。后来我意识到这个市场里其实没有真正的领先者(leader),一片红海都是表象,哪一款任务管理产品都不是足够令人满意,这里还有机会!于是我离开Zlio,创建了Producteev。 « Read the rest of this entry »

Advertisements

2010阅读总结-线上部分

January 31, 2011 § Leave a comment

过去的一年,线上部分的阅读活动主要是在Google Reader豆瓣上进行的,这是我主要的两个线上有效信息来源。虽然也在人人上花费很长时间,但是或许的大部分信息都是娱乐性的内容,看或不看都无关紧要。快到年末开始玩新浪微博,刚刚设置好了Google Buzz和新浪微博的同步,决心新的一年认真经营一下。在Facebook,Twitter以及Quora上偶尔逛逛,主要是为了获取一些在国外的朋友分享的英语和法语内容,占的比例也很小。

Google Reader统计下来,线上4000多篇的阅读量绝对远远超过线下部分,这还没有算上豆瓣上不占少数的那部分。最近被好几个“年度决不能错过的xx篇文章”帖子折磨,这些阅读总结列举出来的都是好文章,而且很多确实也没有读过,但是让人一篇一篇读下来也会是非常令人疲劳的一件事情。如果好的内容以过高密度的形式呈现,那么实际上降低了信息的可接受性。所以,再三考虑,还是放弃了在这篇总结里列举过去一年读过的最有价值的网文的打算。授人以鱼不如授人以渔,重点总结分享一下我阅读涉猎的领域的好的信息源头,以及我对个人知识管理与分享的理解。

« Read the rest of this entry »

Gmail的故事:Founders at Work节译

December 21, 2010 § Leave a comment

本文由Yurii原创,转载请注明来源: 乱象,印迹

本文链接 Gmail的故事:Founders at Work节译【待续】

Founders at Work是一本有意思的书,讲述了若干有意思的创业故事,我看得兴起,顺手把访谈Gmail创始人Paul Buchheit的一章翻译出来,给有兴趣的朋友看看。

欢迎转载,转载请注明出处。

Founders at Work, Chapter 12

Yurii 翻译

Paul Buchheit是Google第23名员工。他创造并领导开发了Google的Web邮件系统,Gmail,该产品引领了当今所谓“Web2.0”的众多特性。除此之外,Buchheit开发了Adsense的第一版原型,Google依靠这个程序在其它网站显示广告。在2000年一次关于公司价值的一次会议上,他提出了现在众所周知的公司信条:不做恶(Don’t be evil)。

尽管Buchheit算不上创始人,但他对Google的贡献,可能比其他许多创始人在创业时的贡献更大。Gmail其实是在Google内部诞生的——这是一个传奇般的项目,起初,它并不是公司的主要业务,只是由一小群人发起,而且,许多人开始并不看好它。

Livingston:讲讲事情的开头吧。Gmail是非正式项目(side project)还是公司指派的任务?

Buchheit:实际上两种因素都有。我很早就在做Email软件,当时大概是1996年,但只是个小项目。但Gmail的想法从来没有实现过。奇怪的是,大概因为一些别的理由,那时候我似乎就想叫它Gmail。这只是凑巧——它并不必然是Gmail的前身,却是我一直在思考的,因为我长久以来就对email不满意。
那时候我在学校念书,还没有hotmail。要看邮件,你得回宿舍。我想,这可真够傻的,我应该能在任何地方检查邮件。所以就想做基于web的邮件。我真的不知道那时候自己在干嘛,因此也没什么结果。我写了点程序,但一直没什么用处,也从来没投入实用。
中间内容就不提了,直接说最后:我到了Google,为Google Groups工作,groups和email不完全一样,但是有关系。等Google Groups的第一代产品差不多完善之后,他们问我,是否愿意开发某种email或是针对个人的产品。这只是一个粗略的意向。他们只是说:“我们觉得这类东西有点意思”。当然,我很高兴干这个。

« Read the rest of this entry »

Groupon HEC宣讲会笔记

December 14, 2010 § Leave a comment

Groupon刚刚拒绝了Google 60亿美元的收购出价,一下子倍受万众瞩目。我们项目刚好请到了Groupon.fr来HEC做一次宣讲介绍会。下面是关于这次会议的一些笔记。

Groupon.fr(Citydeal)的CEO Franz Zorn带着一只年轻的团队来做介绍。Franz看起来不超过30岁,应该是德国人,法语讲得比我还烂,居然却能做法国区的CEO…曾经在eBay做过在线市场的manager,之后在INSEAD读了MBA。团队的平均年龄在28岁左右,Groupon本来就很年轻,团队里有不少刚毕业不久的校友。

Groupon目前在全球超过35个国家开设了分站,有超过3500万的注册用户。2011年预计的销售营业额在20亿左右。是互联网增长速度前所未有的新兴公司。3年前在芝加哥创立,只用了9个月就开始盈利。关于最近的拒绝Google天价收购,业界一片哗然。有人将其与Facebook拒绝Yahoo!在2006年10亿美元的出价相比。但更多的是对Groupon能走多远的质疑,毕竟与Facebook相比,Groupon似乎并不具有足够的用户粘度,背后也没有强大的技术支持,商业模式也没有十足的创新之处。现在类似的克隆网站开始遍地开花,很难说其在这么低的竞争门槛之下能像Facebook一样成为明日之星。今晚现场提出的问题大多也集中于此。而且老实说,Franz的回答并没有让我相信他们盈利能力据有可持续性,我认为Groupon是一家风险很大的公司。以下记录几个主要的问答:

« Read the rest of this entry »

Web Socket和HTML5发展近况

May 6, 2010 § 11 Comments

刚刚开始在橙子公司为期4个月的实习,关于最近非常热门的Web Socket协议html5标准草案的一些应用原型开发,那么就来谈谈这个吧。

Web Socket其实是一个老早就应该实现推广的通信协议。现在的浏览器和服务器之间的通信,都是采用半双工(half-duplex)的方式,通常需要浏览器向服务器发出一个http request,服务器才会响应给予数据作为回应。服务器端只有在某些特殊实现中才有能力向客户端push数据。 那么对于一些需要实时更新内容的情况,比如通过网页显示实时(或者接近实时)股票价格,要么通过轮询(polling),每隔几秒向服务器请求更新数据;要么用(long polling)的办法,浏览器每次接到服务器的回应就再次向服务器发出一个http request,而服务器端在收到后保持等待,直到相关的数据(比如股票价格)更新了,再把更新的结果作为回应发给浏览器,之后反复,这样浏览器相当于一直保持监听服务器端内容变化的状态。 很明显,第一种方式会把信息传输浪费在不断的发送http request上,长长的header部分被不断重复,浪费带宽。第二种方式不会浪费带宽,可以接受,Comet技术通常就是采用Ajax实现的long polling方式模拟全双工的通信的,streaming是适用于其他情况(比如在线播放视频)的另一种方式。

而Web Socket实现了真正的浏览器和服务器间全双工通信,在这一协议规范下,服务器的push是很自然的通信行为。同polling相比,Web Socket连接一旦建立,只有在有必要的时候才发送帧(trame)通信,因此高效得多。即使与long polling相比,通信的次数虽然一样多,但是Web Socket的帧头的标记性部分也比long polling的request的header部分简洁得多(几个字节与几K字节的差别),显著减少了无效字节的传送。

« Read the rest of this entry »

Where Am I?

You are currently browsing the Tech Matters category at Notor.