所谓时间飞逝、日月如梭，暮然回忆，突然发现自个出道伊始也快到十年了。回忆此前自个从前担任过的人物，不可谓不冗杂。从前做过翻译员、测验、开发、测验主管、项目司理、商品司理，乃至还做过出售，步行的街头巷尾的去访问潜在客户。此间我觉得最让自个慨叹的是当年做商品司理的时分的一些得失。所以这儿就计划写下来，与同行们共勉。
本来之前所做的“商品司理”这个人物，我以为是应当打个引号的。由于实在去跑商场、去全世界处处飞、去开掘需要的是德国那儿的一个搭档，仅仅开发团队在珠海这边，而我刚好英语交流才能还算能够，所以就把我安排到这个所谓的“商品司理”的人物上来了。
所以，假如把客户这个概念给笼统封装一下的话，咱们也能够说德国那个搭档本来即是咱们这个商品的客户了。所以说，本来商品司理这个概念是对比泛的。你能够是一个商品型的商品司理，一个商品的构思的诞生到终究完成推向商场交到客户的手上，全部进程你都必须把控;你也能够是一个商场型的商品司理，对于现已在卖的商品，开掘商场的需要，然后交给开发团队来不断的迭代;等等等等。
技能债款
这或许跟其时我做的这个“商品司理”的特殊性有联系吧，我其时花的绝大有些时间都是在咱们的商品backlog和每个sprint的backlog上面，不断的跟德国那儿进行需要的评论，不断的和团队进行需要的细化，再严重的去将功用进行优先级排序并和各路人马进行评论，然后投放到相应的sprint backlog上面去...
在一开端的一两个sprint里边本来全体状况也都还好，燃尽图也不算太丑陋。可是做到后来那条曲线就开端翘得越来越高，远远偏离了抱负曲线了。终究不得不由本来计划的7个sprint调整成10个sprint。
后来对这个疑问有进行仔细的反思，究其缘由，我觉得有好几个，可是其间最主要的应当即是没有及时的去对”技能债款“进行整理。
本来这个道理看上去很简单，基本上跑过灵敏开发的人都知道技能债款给项目所带来的损伤。可是在实在项目开端的时分，咱们通常又会由于赶时间而匆忙将新的功用进行完成，而忽略了代码的可扩展性和鲁棒性等，终究这些“技能债款”越累越高，越到后边越发觉尾大难掉，修正一个地方或许都会牵一发而动全身。
这儿看上去仅仅跟程序员有联系，事实上并非如此，这个更多是跟商品司理的理念有联系。像我之前，专心只想团队疾速的把商品backlog里边的功用疾速完成，而没有花满足的心思去思考商品表层下面的东西，没有去仔细去抓完成的质量的疑问。假如是将一个商品描述成一个修建的话，那我觉得功用即是客户所看到的地上以上的这一有些，而质量即是隐藏在地底下的这个地基这一有些。或许你现在看到的这栋房子外观雄伟功用彻底连厕所都完成了自动化，可是一旦碰到大点的风吹雨打，或许说想要加建一两层的话，或许整栋楼马上就坍塌了。
所谓欲速则不达，一个商品司理不该当仅仅把眼光盯着那份功用列表，还应当多花点时间在处理“技能债款”这些工作上面来。
用户体会
我相信没有哪个商品司理睬忽略用户体会的主要性。用户买你的商品/软件的时分，本来他们实在买的是处理他们的痛点的计划。假如用了你的商品以后，本来的痛点处理了，但差劲的运用体会却成为他们的新痛点，那用户的逃离也为时不远了。
依据自个之前做商品司理的阅历以及后来在一家创业公司的阅历，我发现咱们在用户体会方面很简单犯的过错主要有以下几个：
错把自个当用户：这格外简单发生在一个草创公司里边，由于公司本身的阅历不足，以及商品司理的过于自傲，一起也由于创业前期并没有把方针客户过早的相关到项目中来(本来在Scrum里边是很强调用户的参加的)，所以一个sprint下来开端demo的时分，通常demo的目标即是项目的同一帮人。而商品司理在思考下一sprint的用户体会的时分，又通常觉得自个能够像周鸿祎一样能刹那间变小白。所以循环往复，几个sprint下来，商品拿出去一试水，发现即是杳无音信，成果即是再也没有成果了。这个过错在灵敏团队里边也能够叫做是“小瀑布”过错，这即是没有让用户过早参加进来的后果。看上去是在跑Scrum，事实上确是将本来的瀑布模式分解成几个小瀑布，然后套用了Scrum的概念，有名而无实。
忽略了首次运用体会：本来用户是很没有耐性的，格外是互联网商品用户。你的商品或许功用很强壮，UI呈现也很活灵活现，但用户却要花大时间，乃至要阅读你几十页的用户运用手册才干搞清楚怎样运用你的商品来处理他们的痛点，终究发现处理他们痛点的那个功用居然埋藏在三级菜单乃至以下，那你还预期他们会爱上你的商品吗?
要处理这些疑问的办法我以为也很简单：
让用户尽早参加进来：比方咱们其时在创业公司的做法是，由于咱们其时做的是一个合适个人和小公司的私有云商品，所以咱们就到邻近大学里边找了些学生过来进行试玩以及给他们做demo，然后搜集反应。在他们试玩的进程中要有专人进行盯梢记载，且纪录人不能给对方任何提示。当然，终究别忘记了给学生们一些酬劳，咱们其时是送学生们100块摆布的话费充值卡。
竞品研讨：除非你在做的这个商品对错常有突破性的，业界还没有同类商品呈现，否则你必定能够在海内外找到一些有些功用附近的商品出来的。这儿或许你会说抄袭羞耻之类的话语，这儿我只能低沉的说句，你丫少在我面前装圣人，有本事你现在别用QQ别用微信，再来跟老子谈抄袭羞耻的疑问!这儿咱们听下传奇人物史玉柱是怎样说的：“抄袭不但要厚脸皮，还要开展和优化。假如你抄后，还逾越了对方，他人就不会说你抄了。“ 所以作为商品司理，你常常要做的工作还要是不断的去研讨他人的商品，而不是只盯着商品backlog这一亩三分地，而这儿说的还不仅仅仅仅用户体会上面，还包含其他功用点的调整，由于现在信息刹那间万变。对于这一点，下面还会有所阐述。
支持出售团队
这儿还要由咱们其时做的别的一个面向二手房的房源管理系统说起。其时二手房中介用的对比多的房xxx等商用房源管理软件(这儿就不点名了)，会把他们的房源数据上传到软件供货商自个的数据中心上面去。而房源信息本来一个中介的命脉，所以他们更期望是这个数据中心放在自个公司里边。所以咱们其时做的即是供给一个数据中心服务器，以及相应的一套房源管理软件，管理软件支持PC端和移动端。
MVP出来后，开端去跑各种二手房中介进行demo以搜集进一步信息。疑问来了，正如上面所说的，用户是没有耐心的，无论你说的天花乱坠，仍是眼见为实。可是将全部服务器架起来仍是需要不少时间的，他人还需要特意给你腾出空间和供给网络接入等，且更为难的是，由于这仍是很前期的商品，在你公司里边跑的时分通常很正常，跑到人家环境里边一跑的时分，不是这出疑问即是那出疑问。终究许多客户都是以有事忙为由，中断了该次演示。
本来这儿彻底没有必要在初度demo的时分就把全部环境给架构起来，彻底能够在数据操控层下面嫁接一个服务器模拟器，这么你的数据就不必非要经过网络和数据中心进行交互了(这儿触及到了MVC 分层架构-模型/视图/操控，如有不清楚的请自行baidu)。这么做了以后，出售人员去demo的时分只需要给对方看下服务器的外观，就能够在不接入服务器的状况下直接在电脑上把软件装上进行演示了。进程只需要向对方表明实在状况下数据是经过网络存储在数据中心的，仅仅现在为了便利demo而暂时存在本地罢了。
所以这儿商品司理要思考的不仅仅是实在的商品出来的状况，还需要思考怎么便利出售团队在外进行演示，格外是在商品前期获取用户反应的时分。否则你没有满足的用户反应支持的话，终究仍是走回了闭门造车的老路。
别默许架构师或许项目司理睬帮你思考好出售团队遇到的这些艰难，这个商品是你的(本来在Scrum里边，商品司理的名字叫做Product Owner，也即是商品具有者)，项目司理和架构师等团队成员仅仅负责将你交给他们的商品backlog在预期时间内完成出来罢了。
竞品剖析
上面在谈用户体会的时分有谈到过这一点，一个商品司理要时间留心着商场的动态，留心着竞争商品的意向。比方咱们一开端做的云商品就犯了这么的过错，一开端商场上难觅竞争者，阵线开端拉得太长，功用不断叠加，商品迟迟没有推出商场。某一天忽然跳出了个新闻，“baidu云1T持久容量 首先进入云空间T年代“，咱们的心几本上就现已凉了半截了。
当然，事实上咱们其时的商品迟迟没有推出商场的缘由错综复杂，可是，毫无疑问，对商场动态和竞品的剖析力度和把握的不行是其间一个不可忽略的缘由。
所以作为商品司理，要时间的眼观八路耳听四方，或许竞品新版本的一个新功用的呈现，你就需要马上有对于性的调整自个的商品的完成战略。
要知道，一个商品司理不该仅仅知道不断的往商品backlog中添加新的功用，更主要的是你要知道不断的为公司添加新的增值。（文章来自南京欣才PHP培训机构）
