但从前年开始做产品。也就是说，没有明确的客户，也没有特定的客户调研，开发出来客户到底需要不需要不知道，客户买不买单不知道，客户希望多少钱购买也不知道。这就让营销部没有底儿了。
不能让产品闷死在研发部啊。我得想辙。老板和营销部也都认可公司应该由做项目提升到卖产品，但谁也没有经验，都是做大客户大项目出身的。而且现在的项目也做的不错，有软件单子都逮住，客户关系也不错，客户朋友都主动介绍单子过来，公司收入和增长发展也不错，于是研发产品就成了一个大家都认可的理想，但销售就是另外一码事。干吗费那劲呢？
人对自己不熟悉的东西是天生拒绝的，就如同我们黑夜走一条从来没有走过的路一样总以为会碰见鬼一样。
虽然我也内部写了不少文章来阐述新产品，但到底有多少人看，到底大家想法如何，都不得知。我每逢中午吃饭的时候，我还故意旁敲侧击问，但回答几乎相似：看过了，写的不错。或者是看了，但太忙，没细看。
我也忍不住向老板建议了多次，希望给营销部讲一次新产品。老板嗯了好几次。开季度会议的时候，我在全体高管会议上又提了出来，这才大家达成一个共识：星期一下午研发部给营销部培训新产品。
培训也做了，大家也都讨论了一下午，营销部对产品也提出来一些建议，我们都记了下来。但我们也修改完了，还是没有下文。大家可想一个新产品的推广有多难。所以说，一个好产品，研发阶段其实是非常简单的，也是非常短的时间的，设计、编码、测试都不是具有挑战性的工作。而一个好产品，要获得营销人员认同、老板认同、实施部门认同、支持部门认同，更要获得客户的认同，是需要非常多的运营和各环节的人员的支持。不少新做开发主管的网友也曾经和我反应过他们的郁闷，我说这些都是很普通的事情，完成产品研发，只占产品成功的10%而已。一个产品死在公司里无人知晓，很普遍。想让大家都支持你，凭什么？就凭你是研发他是营销，他必须配合？
到了新年度会议了，我又把新产品的推广销售提了出来。在年度会议期间，我给全体员工又做了一次培训。老板也参加了培训，感觉产品已经做了这么久还是做的不错的，是时候销售了。于是，开营销部会议的时候，就给营销部下了一个任务，新产品的销售必须加入新年度的销售计划，并且有销售任务，还要落实到具体人，还要有销售考核。
这下可捅了马蜂窝。营销部也算是客户打单风里来浪里去，什么人没见过什么阵势没见过什么突然诘问没见过，众多营销部人员群起攻之，借助他们的营销经验和客户经验，啪啪啪，提出的产品缺陷句句在理。老板也不置可否了，但仍然下了句话：我们肯定要今年推新产品，不过，可以不作为销售任务，但具体的负责人要明确。
销售部有了具体产品负责人。但负责人只是个销售新手，跑销售项目还只是个助手而已，更没做过产品销售（可想销售部的打算）。产品负责人新人没见过多大世面很是紧张，忙着安装软件学习软件。
但该产品负责销售人办了一些下面的事情：
1他试用软件，他感觉不太易用。他认为自己是一个普通的用户，自己感觉变扭客户也应该不舒服。就建议让开发人员修改。我也没大重视，我也不能说人家啥也不懂瞎胡闹。就这样，开发人员开始改动。从界面的颜色、图标、字体大小、文字命名、操作方法、说明文档，都按照他的要求改动了一遍。
2这个认真负责的销售人员，感觉软件不稳定，就召集了销售部一些人员来测试。估计连说明书也没有看，就开始测试。BUG倒是没有找到，销售部内部开始PK。他说他的操作方式更符合客户，他说他理解的流程更正确符合现实。这个销售人员一开始还和其他销售人员PK，毕竟这个软件的前期修改都是在他的思路框架下修改的，这次其他销售人员又提出不同的意见，这不就和他不一致了么。既然他负责这个产品，他就认为自己对这个产品理解更深透。但其他的销售人员的客户经验比他足，有时候别人说出来的理由他也不知道客户是不是那样想的。于是达成一些协议：都有理，先记下来，能改的让开发人员都改了。
开发人员问我怎么办？我说静观其变，先让他们内部PK。
两个月过去，啥销售动静都没有，就在家里闷头修改、测试。销售新手成了产品设计师、项目经理，控制了新产品的功能设计、进度、质量。这真是个奇怪的角色。我曾经在QQ群中也见过这种现象，有的网友说他们的组织形式就是这样，产品的定义归产品部。这个组织形式本来是没有问题的，就连微软的软件设计也是由程序经理提出的。而微软的程序经理就相当于产品经理，大多为MBA出身。但问题在于，微软的程序经理都是非常深刻理解软件的，也是非常深刻软件营销的。我曾经很惊讶微软的一个管理岗位出身的人居然对微软的开发工具的具体技术有如此深的了解。而国内，往往是划分了类似的组织结构，却无法配齐相应的人。做产品设计的，往往不懂软件。做软件的人，往往却只会编写代码。而一个既会做软件，又懂产品的人，如果没有可见的成功案例，也是被别人看作不懂软件不懂产品的人。
我给老板提了个建议：可以先去客户处调研一下。别老闷在家里，先听听客户怎么说。
于是这位销售听从老板指令，联系自己熟悉的客户去调研。
但调研过程让人大跌眼镜。我听我的开发人员回来反映说简直不是去调研了，而是去销售去了。
这就是一个销售的思维惯性。
当然，最后的结果是客户留下了演示版答应尝试使用。但仍然没有了下文。
季度会议，我提了出来：咱们的软件产品并不是在屋子里闭门造车，咱们的软件设计前期也是借鉴了多家客户的现有系统，并且在网上和客户交流了很久，也借鉴了很多其他同类的软件。咱们是骡子是马就拉出去遛遛。会不会游泳，在池子边是学不会的。一脚踢下水，呛几口，死不了，但会很快就学会游泳。
老板也询问了调研情况，但销售新手说不出多少重要的理由，老板于是亲自换人操盘。
新换的负责人是个典型销售型。软件有BUG？微软还有BUG。软件不完善？完善了怎么升级呀。
上来就是不断给他的客户打电话，寒暄过后问问现有系统的使用情况，然后根据客户现状引出现在这套产品。客户一听，好啊，我们正想有这样的功能。老销售说我们这套系统已经好多家试用了，都反响不错，而且能跟现在我们的系统无缝连接。
电话是打完了，演示版、说明书都给了客户。老销售的三把斧也玩完了。但谁也没做过产品销售，不知道怎么推新产品。问我接下来该怎么办？
我说，做灯塔客户。他们客户之间都互相走动，消息特灵通。先让他们中的有影响的客户先用起来，咱们给其他客户宣传推广的时候就容易的多。而且灯塔客户用的好，咱们的影响力就大的多。如果一开始怕失败怕困难，先做些小客户，反而费了半天努力起不了多大的水花。还不如咬咬牙顶一顶，成了也就成了。我想起了我9年前在其他公司做灯塔客户时的情景，那时候就是寻找了一家小客户，上线倒是挺快，也没修改多少，但也没有给软件的成熟带来啥提升，在业界的影响力也没有多大，金额单子也签的少，但最后的支持服务没少打电话，而且客户的IT能力有限有时还需要去出现场。唉，一切都归结于是第一个客户。客户处处拿这个拿捏我们，说我们拿他们做的实验小白鼠，就得送佛送到西。而且签的时候就故意找的当地的客户，就是为了做实施的时候成本低。但从此也形成了一种坏的实施毛病，就是程序员去实施，当场改程序的实施模式。这种模式的形成就在于做灯塔客户是程序员亲自去的，谁写的代码就谁去做灯塔客户实施，客户有什么需求就当场立即改掉，希望能很快把软件完善起来。但这样做就形成了惯性了，实施第二家灯塔客户仍然照旧如此，最后灯塔客户都做了好几家还无法交付给实施部门去做。差点把开发部变成开发、实施、支持全功能的部门。费了好大的劲做过渡转换，如今后遗症还不小。
他问我怎么选择灯塔客户？
我说，首先找喜欢创新的客户。产品，也是有生命周期的。一开始，不能找大的客户，也不能找小的客户。咱们的系统还算初出茅庐，大的客户会控制咱们，影响咱们未来的发展。而小的客户，做完了影响力也不大。所以，我们要从中不溜的客户中间挑选喜欢创新的客户。不喜欢尝鲜的客户是没有应用的积极性的，反而对新事物天生产生怀疑和拒绝。
这个创新的客户还需要系统建设方面有影响力。有些客户很喜欢业务创新，但天马行空的，不去想系统能不能实现，最后反而想的多说的多，系统方面却无法落实。这类客户也经常会看见。所以，我们要找的就是喜欢创新、系统建设重视的客户，而且这个客户需要规模在中等。这就是典型的灯塔客户。
只有灯塔客户做起了标杆，有影响力的有分量的大客户在推广的时候才能关注起来。这就好比江湖，江湖老大并不关注那些小喽啰，而他最关注的人恰恰是第二第三名，因为一不小心这些人就会超过。
灯塔客户为生命周期的第一拨，大客户为第二拨，第三拨就是看着创新激进派和大客户们都应用的不错，那些抱着怀疑的客户才会蜂拥而至。这类客户就如同企鹅一样，谁也不下水，怕水中有海豹。等其他的企鹅下水了没有事了才纷纷下水。
这位销售老手果然重点关注了几个喜欢创新又系统建设的不错的客户。啥也别说了，肯定能搞定，能不能借我一个星期开发人员，我要领到现场去给他们修改开发，肯定签单回来。
我有些犹豫，我怕重蹈覆辙。但第一个客户的单子又是如此的珍贵，毕竟要走出第一步。
我说去一个星期，但说好了，必须只能是一个星期，不管完成没完成，就一个星期。而且这次去了，还需要跟一位实施经理。你做项目经理，但你不能越位做产品设计。你负责好客户沟通、协调，上线推动，实施经理和开发人员调度就行。而开发人员不能直接面对客户，所有的客户需求必须由实施人员收集整理，按照咱们正规的实施流程走。
于是，三人上路了。在此过程中，销售担任项目经理、实施经理、开发人员作为组员。我还尽量控制，但仍然没有避免客户和每个人都谈需求。我严厉警告开发人员：没有我的确认，你不能开发。即使一个很小的改动，都必须给我报告回来。哪怕是MSN报告或电话报告都行。
我还不断让他们各自坚守各自角色。那一个星期，我花了大量的精力在不断区分他们的惧色，在客户要求和他们三人之间达到平衡，不要让他们三个人都变成需求人员和实施人员。
一个星期到了，销售说他已经签了单子，能不能让开发人员再留一个星期，让开发人员开发利索了再回去。
我说我要看看还剩下多少活儿。于是我让开发人员报了一下工作列表和工作量估计。我也听取了实施经理的实施效果和进度的报告。我也拿开发人员的工作列表找销售去确认了一下看看是否是这样子。三个人都确定好后，我又把期限宽了三天。三天内，开发人员要完成什么工作我都安排好，做完后离开。实施人员按照正规实施流程走，不能无限期在现场实施，否则客户永远会说自己不会。要在三天后安排培训、考试，不能实行目前的一对一培训。
那三天，真是很累的三天。销售要说服客户三天后离开，实施要编写培训课程和考试内容，开发要保证按时完成任务，谁都不轻松，每个人的压力都很大。
终于开发人员和销售回来了。实施经理留在现场，我又派了一位实施培训人员跟进。终于，实施流程和过去又保持一致了。虽然，销售回来后仍然被客户当作项目经理，但销售尽量的倾听客户，不过实施执行却转给了在现场的实施经理。开发人员仍然在按照实施流程中产生的需求列表修改着，和以往开发流程、实施流程一致。并没有因为这次的特殊性而改变。当然，实施经理几次着急上火直接给开发人员打电话，但我都让开发人员自己记录下来，排进需求管理工具中。这个过程当然痛苦，稍不加管理，开发人员就成了实施人员和支持人员，说不定为了救火还需要冲到现场。
好不容易，第一家灯塔客户上线验收了。第二家灯塔客户，就是这位实施经理带领培训专员去了，没有跟销售，也没有跟开发。和过去的实施一样。
我说：你还需要带一名实施经理和培训专员。
实施经理问我为什么？如果再多去人，那两个实施经理怎么分工。
我说：另外一组实施团队，只管培训课程课件制作、培训、考试。你管理好项目进度、需求协调。
于是，四人上路了。
第二家灯塔客户顺利了许多，实施时间也缩短了许多。正规的实施文档、课件都制作了出来，新产品的实施人员也带了出来。开发人员在办公室，有我做管理指导，有专业测试在每日测试，软件质量也得到保证。
现在，这个产品已经销售的很正常的，开发流程、实施流程仍然很流畅。
走出第一步，千万要把型塑好，千万不要特殊事情特殊处理，否则特殊处理很容易变成习惯处理，最后再也无法回到正常的流程上来了。
想让开发部不变成实施部，第一步很重要。
