启示录

启示录

前沿 | 4 Jan 2018 at 07:11

如果开发的产品没有市场价值,那么无论开发团队多么优秀也无济于事

产品是用来解决用户需求的,如果没有解决问题,用户是不会买单。做之前一定要想清楚你的产品是给谁做的,解决他们的什么问题的。

  1. 产品经理的任务是探索产品的价值、可用性、可行性。
  2. 探索(定义)产品需要产品经理、交互设计师、软件架构师通力合作。
  3. 开发人员不擅长用户体验设计,因为开发人员脑子里想的是实现模型,而用户看重的是产品的概念模型。
  4. 用户体验设计就是交互设计、视觉设计(对硬件设备来说,则是工业设计)。
  5. 功能(产品需求)和用户体验设计密不可分。
  6. 产品创意必须尽早地、反复地接受目标用户的试用,以便获取有效的用户体验。
  7. 为了验证产品的价值和可用性,必须尽早地、反复地请目标用户测试产品创意。
  8. 采用高保真的产品原型是全体队员成员了解用户需求和用户体验最有效的途径。
  9. 产品经理的目标是在最短的时间内把我复杂的市场/用户需求,确定产品的基本要求——价值、可用性、可行性。
  10. 一旦认定产品符合以上基本要求,它就是一个完整的概念,去掉任何因素,都不可能达到预期的结果。

这十条基本规律,基本涵盖了产品经理的一些工作流程,需求收集,需求分析,需求设计,实现,测试,迭代。产品价值在收集和分析部分,设计是根据需求产生解决方案的展示层;实现、测试,是尽快让产品与目标用户进行交流,验证价值、可用性、可行性;迭代,不断优化你的产品。

产品经理的主要职责分为两项:评估产品机会(product opportunity);定义要开发的产品。

想要评估产品机会,首先要收集,所以产品经理一定要有一个需求池,将平时碰到的需求都放到需求池里,定期回顾并且评估。

需求的来源主要渠道一般来自于以下几个:

  1. 战略:公司高管的意见
  2. 用户:用户的反馈
  3. 测试:可用性测试的结果
  4. 公司其它部门:如市场团队和营销团队的点子
  5. 竞品分析:同行的产品分析与业内人士的分析
  6. 自己的一些灵感

确定有价值且符合公司发展要求的产品机会后,还需要探索产品的解决方案,包括基本的产品特征和功能、产品的用户体验,产品的发布标准。这些也属于产品经理的工作范畴,而且是产品经理的核心职责。

需求确定之后,但满足需求的方案可不止一个,这时候就要以目标需求为基准,设计一个简单方便的使用流程,原则可以用结网提倡的三条“别让”规则——“别让我等,别让我想,别让我烦”。

产品经理和产品营销人员应该经常沟通、展开合作。一方面,营销人员是产品经理获取产品需求的重要来源;另一方面,产品经理是营销人员获取市场营销信息的重要来源。

营销,市场,客服这三个部分都是距离用户最近的部门。产品经理应该经常与这三个部门打交道,深入前线,参与一些直接与用户接触的工作,这样做的好处就是能够尽可能接近你的目标用户,观察用户,提炼需求。

产品管理与开发 | 8 Jan 2018 at 06:40

产品开发阶段难免会产生诸多问题,比如,用例丢失,用力设计考虑不周全等, 这很正常,最优秀的团队也避免不了。产品经理应该迅速采取行动,在维持产品基本功能、尽量避免修改的原则上,拿出解决方案。

在开发的时候进行修改的问题是无法避免的,比如产品在设计的时忘记了某些场景,需要增加一些功能。或者一些页面在设计的时候发现有缺失的功能,没有考虑完全等。毕竟在刚开始思考的时候很难方方面面都想的非常完美。我对于这种问题的建议是,在看静态的产品原型图时,将各个页面混合起来,从静态的让它变成动态的,在脑海中模拟使用场景,让原型更加的真实可以减少错误的发生,也可以直接作出带有交互的产品原型。

对于那些必须要改的需求,则是多想想,还有没有第三种解决方案,答案永远比问题多,想双赢的解决方案。实际生活中问题的解决方案并不是只有两个选项,多思考一段时间,你就有可能发现能够满足多个方面的解决方案。

你需要预留一定的技术能力,eBay称为余量(headroom)。很多因产品迅速膨胀产生的问题都与扩展规模有关,余量意味着避免触及技术能力的上限,为用户数量的增长预留空间,为事务增长预留空间,为新增功能预留空间,保证产品的技术构架能够满足国队的要求。

有的产品经理将功能的排期做的非常满,这样会导致开发人员将所有的精力都放在了新功能实现上,而没有时间放在维护上,如果用户数量增长过快,服务器如果没有做好准备就容易被压垮。

这样的结果是非常得不偿失的,将平时的时间流出20%左右,让开发人员自由分配,用这些时间来重写代码、完善架构等。给自己的增长留有余地。

为了评估产品机会,我要求产品经理回答如下十个问题。

  1. 产品要解决什么问题?(产品价值)
  2. 为谁解决这个问题?(目标市场)
  3. 成功的机会有多大?(市场规模)
  4. 怎样判断产品成功与否?(度量指标或受益指标)
  5. 有哪些同类产品?(竞争格局)
  6. 为什么我们最适合做这个产品?(竞争优势)
  7. 实际合适么?(市场时机)
  8. 如何把产品推向市场?(营销组合策略)
  9. 成功的必要条件是什么?(解决方案需要满足的条件)
  10. 根据以上问题,给出评估及论。(继续或放弃)

这上面的十条问题,也是产品评估时候需要做的准备,产品价值,目标市场,市场规模,关键指标,竞争格局,竞争优势,市场时机,营销策略,成功条件,都阐述出来,最后加上自己的评估建议。

前期做好准备,表达的时候要充分,开会的时候同事才会给予你肯定,如果有什么问题,大家也会提出来。这个产品评估会是比较困难的,除了对产品本身的把握,还需要有一定的演讲能力。自己在这方面有所欠缺。下面在做知识体系的时候需要完善这部分内容。

我们通常只能利用软件工具了解用户在网上的活动,但是财务部门掌握着交易记录、支付信息、客户数据和经营报表。要注意哪些信息是你有权获取的,以及应该怎样利用这些信息。

这块还真是之前没有想到的,因为之前的了解渠道是客服,市场,运营这些人交流可以获得用户的信息,但是作者在这里提到的非常好,如果能够知道财务的部分信息将会更加的了解用户,毕竟这些真正参与交易的用户才是我们的深度用户。

软件项目可以划分为两个阶段:要弄清楚开发什么产品(定义正确的产品);开发该产品(正确的开发产品)。第一个阶段探索产品,第二个阶段则强调执行。

在探索产品的阶段,产品经理负责分析各种创意,广泛收集用户需求,了解如何运用新技术,拿出产品原型并加以测试,从全局思考产品方向,兼顾短期需求和长期规划。待项目确定了,开始进入执行阶段,这个阶段需要开发、测试、发布。需要解决并处理过程中遇到的问题,需求的变更,时间的延期,尽量保证产品能够按照预计的时间上线。

10 Jan 2018 at 06:54

合理的利用市场调研工具和方法可以回答以下几个关键问题。

  1. 谁是目标用户?
  2. 用户会怎样使用产品?
  3. 用户能想明白怎样使用产品吗?障碍在哪里?
  4. 用户为什么选用你的产品
  5. 用户喜欢差您的哪些特点
  6. 用户希望如何改进产品,增加哪些功能?

市场调研有它的局限性,但也有它的作用,合理的运用市场调研能够尽快的获得以上信息,在产品和功能的发布之后,与之前的预想相匹配,如果不符合,那么赶紧找到哪里出的偏差,以及合理性,尽早的加以改进。

局限性则在于,很难通过市场调研来定义新产品,一般都是用来提升产品体验,在原有的产品上修修补补。

产品管理的核心在于制定决策——应该抓住那些机会,解决什么问题,哪些功能最有价值,谁是主要用户。有决策就有失误,但要打造成功的产品必须保证大部分决策是正确的。

作为一个产品经理,在工作中经常需要做决策。提的需求做不做,为什么?什么时候做,怎么样做?解决什么问题,什么样的人有这种需求,频率是什么等等。想要尽可能的做对决策,你需要比谁都了解产品的用户,甚至比他们自己都了解他们。你要找到你的目标用户,加以分析,听他们说往往是没用的,用户是比较茫然,只有拿到产品之后才能知道这是不是他们想要的。

作为产品管理工具,人物角色的主要用途如下。

  1. 人物角色可以用来筛选重要的产品功能。
  2. 产品团队常常把自己的需求当成用户需求,使用人物角色可以避免犯这类的错误。
  3. 许多产品的用户类型不止一种。如果只是简单的针对每种用户添加功能,结果会是一团乱麻。使用人物角色有助于用户类型的优先级进行排序,识别需要重点考虑用户体验的地方。
  4. 有了人物角色,可以方便地向团队描述产品的目标用户是谁,他们怎样使用产品,他们关心产品的哪些方面。
  5. 人物角色可以帮助团队成员达成共识。从而提高工作效率

人物角色还有一个用途,是帮你找到使用场景的前提条件,你需要先确定有哪些人会用你产品,这些人可能都在什么时候使用你的产品,不同的人在这种场景下解决需求的方式是什么。这也是能够尽可能多的了解你产品的一种换位思考的方式。

产品说明文档应该满足以下要求

  1. 产品说明文档应该完整的描述用户体验——不只是用户需求,还包括交互设计和视觉设计。
  2. 产品说明文档必须准确的描述软件的行为。
  3. 产品说明文档的手中比较广——开发人员、测试、客服、市场营销、运维、销售、管理等等。因此,产品说明文档必须以某种直观的方式把产品信息和产品行为告诉所有人。
  4. 产品说明文档应该可以修改。可以随时更新
  5. 撰写产品说明文档的过程会出现许多衍生物,比如,按优先级排列的需求列表、线框图、实体模型,但应该有一个主题来代表产品,避免混淆不清,版本错乱。

产品文档的格式和方式实际上是没有标准的,只要你能够将产品的体验顺利的传达相关的工作人员就足够了。图文并茂,详细说明都是必不可少的。

由于开发的是基本产品,一代进入产品开发环节,产品经理就不能再随意修改设计。过去产品经理经常要求更改产品设计,主要是因为一开始构思不全面、不彻底。设计高仿真原型能够迫使产品经理改掉这个坏毛病。

设计高仿真原型,能够迫使产品经理尽可能的考虑更多的情况,并且尝试使用起来,当脑海中的产品设计出来之后并且能过做简单的交互的时候,才能更多的发现之前没有发现的问题。我做这块也是有顺序的,第一步是画流程,然后根据流程画页面,这样能够避免在界面上耽误思考流程的时间。

17 Jan 2018 at 06:47

可用性测试往往能发现么能成功实现的产品需求,如果测试得当的话,甚至能发现原本被忽略的产品需求。最好规划多次迭代测试,确保实现最佳的用户体验效果。

可用性测试可以在正式的产品上线前,先找几个真实的用户进行测试,可以使用高保真的原型,让用户真的使用,而你在旁边不能指点,要观察用户的使用过程。真实的用户是可以给你带来宝贵的反馈,如果是其他人就不一定,会直接导致可用性测试的结果不准确。

价值测试可以和可用性测试同时进行,使用的原型也是一样的。只不过可用性测试中在观察用户如何设法完成必要的操作,而价值测试中在观察用户是否喜欢这些功能,是否满意功能的具体实现方式。

如果产品仅仅是能开发出来,方便使用,是不够的。还需要用户是否愿意为它买单,价值测试就是为了验证用户是否喜欢。不论是可用性测试还是价值测试,使用的原型越接近真实,得到的反馈也是最真实并且也是最有效。所以高保真的原型是非常必要。

如果没有专业训练的用户,是没办法从简单的产品原型直接感受到最终产品呈现的结果。

第22章 原型测试 | Prototype Testing

读者应该知道我把高保真产品原型当作描述产品的最基本方式。比起写在纸上的产品说明文档,产品原型更有效,但这还不是使用产品原型的最主要原因,最主要的原型是产品原型可以让用户验证产品的创意,加深产品经理对产品的理解,避免开发团队浪费时间和精力开发没有把握的产品。

现在对于高保真的原型制作成本已经大大降低,尤其是互联网产品,我目前正在使用的就是sketch,比较容易完成高保真的原型,实际应用起来,相比于需求文档来说,同事更加愿意直接看原型,也是因为更加的直观,操作细节的问题直接在上面实际使用,有的时候沟通一些交互并不是非常容易,直接做出来能够更加直观也能让开发更加的了解最终的效果。

物色测试者

  1. 如果你已经有用一批特约用户,可以邀请他们参加测试。如果你手头没有特约用户,现在就需要开始物色特约用户。

特约用户对于产品开发来说是必不可少的,只有获得了真实的反馈,才能知道你的产品是否对你的目标用户是有效的。这就是为什么有些产品的网站会露出产品交流,bug提交等类似的功能。还有一点就是在产品正式上线前,一定要尽早的让目标用户接触到产品。得到他们的真实反馈。

  1. 如果是企业级产品,同类产品的产销会是寻找目标用户的好出去。
  2. 可以在分类信息网站上发布广告,征集测试者。时候打电话给你感兴趣的应征者,了解对方的一项,进一步筛选合适的测试者。
  3. 如果是大众产品,可以邀请自己的亲朋好友参加测试,但是要避开过于器皿的人和科技行业的从业者,除非他们就是目标用户。另外,测试着不能只局限于亲友。
  4. 如果手头有用户的电子邮件列表,可以从中筛选测试者。
  5. 可以通过公司的网站征集志愿者。但还是需要打电话联系并筛选应征者,避免参加测试的全是产品尝鲜者。
  6. 建议较大的公司定期开展原型测试活动,每次邀请10~20位测试者参加。让所有的产品经理自己申请时段,安排每位测试者参加测试一两个原型。
  7. 离开公司,到街头巷尾去,到用户群居的地方去。
  8. 如果是出于商业目的,应该补偿测试者为此损失的时间。如果是大众网络服务产品,通常真诚的说声谢谢,送上一顶印有公司标志的帽子就足够了。
  9. 即使和测试者约定了测试见,还是有人会忘记时间,爽约的几率大约是30%。在测试前一天致电测试者,可以把这个比例降到5%~10%,但是发邮件的效果不是那么好。

上面的九条内容是如何获取特约用户的一些帮助建议,核心点则是找到你产品的核心用户,从他们的身上获取真实的反馈。让目标用户也参与进产品开发中。

准备测试

确定可用性测试的内容,并拟出问题,就产品的价值向测试者提问。

为了避免浪费不必要的思考时间,产品经理要提问的问题要提前都准备好,不宜太多,5~10个差不多。最好有录像,或能记录用户的测试的过程的录屏,但一定要和用户提前说明。

  1. 事先拟定好测试内容。
  2. 你只有一次机会了解测试者未接触产品原型前如何解决产品要解决的问题。

比如一个订餐网站,先不要让测试者直接登录产品原型的页面,提供一个空白浏览器,看看他会怎么做。他们会访问那些点评网站?是否用搜索引擎来搜索餐馆,订餐的习惯是按照地点、菜式、还是价格?这些信息也是非常重要的,如果直接测试原型,很可能会忽略这些细节,造成隐患。

  1. 测试原型钱还有一件事要做,几观察测试者能否从原型首页看出产品要解决什么问题,那些地方最能吸引他们(对他们有价值)。一旦进入测试任务,就不会再有首次访问的感觉。
  2. 带测试者完成测试任务,了解产品用途后,通过聊天进一步收集信息。沟通的目的是了解测试者对产品原型的评价。
  3. 为每个问题的答案打分(比如0~10分),或者干脆让测试者用户用数字来回答问题,以此记录每个阶段产品原型的表现。
  4. 不必等到完整原型完成后在测试,可以先测试主要项目,即使某些功能空着也没关系。如果测试上遇到功能上的死胡同,问问他们“接下来希望发生什么”。

测试环境

  1. 正规测试环境
  2. 只要能放得下笔记本电脑,加几把椅子就足够了。这种环境可以让测试者更加的放松,回答问题更坦诚
  3. 用户的办公室也是上佳的测试场所。第一是更加放松,更健谈。熟悉的办公环境可以让他们充分展示日常工作中使用产品的习惯。还可以了解显示器大小,处理器能力,网速大约是多少,如何与同事沟通等等。
  4. 还有一些远程测试工具,能够看到鼠标动作和点击内容。

产品经理应该尽量参与测试,这样可以更接近你的目标用户,只有你更了解你的用户,你才能对产品有者更高的把握程度。还有一点就是要带着一种空杯的心态,从用户得到的反馈是重要的信息,自己的产品不是完美的,他们的反馈能让你的产品更上一层。不要急着反对用户的反馈信息,这是完善产品的最佳途径。

测试原型 | 19 Jan 2018 at 06:55

  1. 测试前不宜与测试者交谈过多,简单的寒暄几句,递上一杯咖啡或一瓶水即可开始测试。告诉测试者完成测试后在深入交谈。事先谈的越多,透露的产品线索就越多,测试者就不可能说出他们对产品的地印象。
  2. 寒暄之后务必告诉测试者:这是产品原型,是初步的产品创意,不是正式产品;请说出真实的看法(不管好坏),不必碍于情面所保留;测试的对象是原型,不是测试者,测试者不必担心测试失败,只有原型会通不过测试。
  3. 测试时,尽量让测试者保持平和的情绪,千万不要让他们陷入吹毛求疵的状态。测试的重点是看测试者能否轻松完成测试任务,以及他们是否喜欢产品的功能。如果测试者提出页面上的元素难看,应该去掉或换掉,就跑题了。
  4. 测试时尽量保持安静,不要给测试者提示。
  5. 通常有三种测试结果:测试者在没有提示的情况下,顺利完成测试项目;测试者遇到麻烦,但通过反复尝试,最终完成了测试项目;测试者受挫,最终放弃。有些人很快就想放弃,可以鼓励他们继续尝试。如果测试者表示放弃其他同类产品,说明他们真的放弃。
  6. 要尽量避免提示测试者,更不能引导他。
  7. 可以像鹦鹉学习,使用自言自语的技巧。这可以避免引导用户,还可以帮助记录员几下测试要点。
    8.测试的作用是理解目标用户如何看待产品要解决的问题,发现原型与用户期望不一致或不相容的地方,也就是原型不符合用户预期和习惯地方。
  8. 从测试者的肢体语言和语气里可以发现许多有用的信息。

测试原型的目的标是减少工作人员对测试者的影响, 获取测试真最真实的反馈。上面的1、4、6、7、条都是相关的阐述,第二是减少测试者的压力,上面的2、3、5,第三是详细的观察记录测试者的反馈,不论是谈论还是肢体语言,上面的8、9是相关阐述。

更新原型

测试原型的目的是找出原型中需要修改的部分,提高原型的可用性和价值(吸引力)。因此,应该尽快纠正发现的缺陷。

得到了测试的结果,先不要着急改,先分析收集来的数据,是否靠谱,如果是真实有效的数据,在这个基础上进行修改是会提升产品可用性和价值,如果数据错了,那么改也是错误的。

  1. 只要对测试反馈迅速作出相应,就能显著加快完善产品的速度。你不用等到连续收到八位用户的打击后,猜意识到需要解决问题。只要两三个用户反映了同一个情况,就动手解决吧。

快速迭代,小步快跑,两三个不同的用户反映了同一个情况,就应该开始重视问题,然后尝试找到解决方案。如果有六位测试者理解和欣赏产品的价值,而且能完成关键的测试项目,就算完成了原型测试任务。

改进现有产品 | improving Existing Products

*开发新产品的第一步时要明确目标。*改进产品不是简单地满足个别用户的要求,也不能对用户调查的结果照单全收。能提高指标的功能才是你关注的重点。你应该找准方向,分析关键指标,有针对性地改进产品

有的时候想开发新产品的目标是不够明确,这样会导致产品做出来之后很容易和之前的产品发生问题,简单来说就是意图不明。所以第一步时要确定目标,然后根据这个目标查找现有产品的关键指标,通过拆解,找到相关的指标,在想办法分别提高各个指标的数值。开发新产品的时候不要想着做一个全新的产品,全新的功能,大部分的时候往往都是针对过往产品的提升和修改。

平滑部署 | Gentle Deployment

通常情况下,用户不喜欢变化。虽然他们也希望产品更完善,功能更丰富,但前提是不改变已有的使用习惯,大多数人不愿意花时间学习、适应新的使用方式。

实际上作者所说的这种情况就是让产品经理谨慎的考虑升级,要有目的性的升级,明确增加新功能或者完善老的逻辑,这些升级应该是增加用户体验,并且不改变原有的使用习惯。但如果是一些莫名的,跨度较大的升级,则要多考虑用户的学习成本,和用户引导和教育,来挽回一些口碑。

快速响应阶段 | Rapid Response

一旦问题反馈回来,产品团队(产品经理、交互设计师、主程序员、客户服务人员、市场营销人员等)应该至少每天召开一次简短会议,讨论问题的轻重缓急,确定最佳解决方案。

即使有非常完备的测试团队,但也无可避免问题的发生,但是这里的关键点是,如何快速的解决问题,给予反馈。有些问题就是因为反馈不当,或者时间过长,从开始的无所谓,到后期的不可收拾。所以一定要重视各种反馈,产品发布之后要每天定时收集产品数据,快速的发现问题,并进行修改。产品上线并不是终点,只是一个开始。

合理运用敏捷方法 | Succeeding with Agile Methods

  1. 产品经理即使产品负责人,他们代表了客户的需求,因而需要与产品开发团队保持密切的联系,协助督促开发进程,没事解决出现的问题。
  2. 使用敏捷方法绝不等于省略产品规划。产品经理仍然要明白产品的方向和目标,设定衡量产品成功与否的标准。只不过在敏捷环境里,规划周期应该适度缩短,反复迭代,采用轻量级的机会评估方法替代冗长的市场需求文档。
  3. 产品经理和设计师的工作进度应该比开发团队领衔一两个迭代周期,确保你们有足够的时间攻克难题。
  4. 尽量把产品设计工作拆分成独立的部分,分而治之,但也不能拆得太细。目标是设计出符合基本要求的产品。
  5. 产品经理的主要任务是定义有价值、可用的产品原型和用户故事,作为开发基础。务必要请用户测试原型,根据反馈意见反复迭代修改原型设计,确保交给开发团队的是有价值的结果,避免任何浪费。
  6. 让开发人员自主划分迭代周期。有的产品功能可以在一个迭代周期完成,有的却需要好几次迭代才能完成。
  7. 产品经理和交互设计师必须出席每天的晨会。
  8. 除非达到了产品经理的要求,否则不要轻易发布新版本。确保给用户的产品能正常运行。过度频繁更新版本会让用户感到不安。
  9. 每次迭代完成后,产品经理应该向团队展示产品现状,以及下次迭代的产品原型,让大家看到工作成果,同时加深大家对产品的理解,增强团队对这种开发方式的信心。
  10. 在团队内展开敏捷培训。

不是所有的团队都适用于敏捷开发,敏捷开发对于团队的要求是比较高的。这个高在于团队的配合程度,每个成员的能力等等。只有充分的沟通和了解,然后给予空间,能够让队员充分发挥自己的优势。并且每个成员都需要一定的全局视角。这样才不会陷入自己的速度,而忽略了团队的速度(这可能又快有慢)。如果使用了敏捷开发,一定要内部展开敏捷开发的培训,这点非常重要。

敏捷开发的方法并不会让工作变得更轻松,相反他对你和团队的水平有着较高的要求。某种程度上来说这种开发方式,能够让那些有能力的人更容易发挥出自己的水平。提高产品体验。

合理运用瀑布是开发方法 | Succeeding with the Waterfall Process | 24 Jan 2018 at 06:52

瀑布是开发方法的基本原则

  1. 采用阶段式开发,软件开发过程被事先分成固定的几个阶段:撰写书面的需求说明文档、设计高层软件架构、设计底层细节、编写代码、测试、部署。
  2. 采用阶段式评审,每个阶段结束后,对该阶段提交的成果进行评审,评审通过后才能进入下一个阶段。

按照瀑布流的两个原则进行开发,好处就是流程可预测,管理层非常的习惯,只要能准确的理解需求和技术,而且不在变更,那么开发团队就可以批量且精确的开发产品。但实际上是很少见的。

还有一个好处就是每个阶段结束后的评审,有了详细的书面文档和材料,所以大家都认为是经过了深思熟虑得出的结果。但实际上这种心理也是不对的。真正运行的是软件,应该以数据做支撑,而不是材料。要以数据来作为依据,因为之前的过程虽然可能没问题,但可能方向上是错误的。

瀑布是开发方法让产品经理头疼的地方

*产品验证严重滞后。*产品经理必须等到软件开发的尾声,才能看到可以运行的软件。也就是说,在投入大量人力和资金前,软件的可用性无法得到验证。

验证的滞后性,是最严重的问题,这样会导致已经浪费了时间和资金的成本之后才能验证产品。如果产品流产,会产生极大的浪费,这要求产品经理把握需求的能力比较高。

产品经理在开发之前,就要将产品的可用性测试做完,可以利用高保真原型,邀请用户测试的方法。这样保证产品交给开发团队之前,产品的可用性是可行的。

*变更计划代价不菲。*在瀑布流开发过程中,任何对前期决策的修改都会打乱开发流程,大量工作需要重投来过,不仅浪费资金,而且耗费精力。此外,在开发和测试过程中常常会发现前期设计的缺陷,临时修补也会严重延误开发进度。

这种情况可以说是经常会发生,之前的设计,无法做到完备,只有在真正实现的时候问题才会一一展现。这时候在修改,无法避免的会导致工作内容的增加,和任务的延期。

产品经理在这里,一定要把握住主要的核心业务逻辑,逻辑的修改造成的问题会非常严重,展示细节的问题要小很多,这块尽量避免的就是修改大的业务逻辑。需求确定了,之后才进入开发。

无法适应快速的市场变化。瀑布式开发方法严重依赖文档和流程,在这方面开销很大。哪怕是一点小小的改动都要花费不少功夫。这是的产品经理的压力倍增,因为一方面产品经理要尽量确保提交的产品设计通过验证、没有缺陷;另一方面,产品发布后产品经理仍然提心吊胆,随时准备和产品团队以最快的速度修补产品。

时间成本属于产品成本的中的隐形成本。这成本非常重要,因为这块是主要和外部竞争的主要因素,同一个功能可能就比其他软件慢两个星期,就可能造成人员的流逝,而想要把他们在找回来,耗费的成本可能是双倍的。

第一是做先驱者,站在市场的前端,遇见下一步的方向,提前准备,这是非常难做到的。所以还有一点就是尽可能的加快团队磨合,招聘一些水平较高的团队。

小结

如果不得不使用瀑布式开发方法,产品经理首要的工作是在探索(定义)产品阶段,制作产品原型,请目标用户试用,确保产品设计是有价值的、可用的、可行的。只有这样才能提高产品成功的几率,同时节约开发团队的时间成本。

只有在前期确定方向的时候保证是正确的,才能保证后面的工作的努力是靠近目标的。如果前期目标都定错了,团队就不应该继续前进,因为现在的方向是正在远离你的目标。

创业型公司的产品管理 | Startup Product Management

关键在于产品探索

  1. 创建体现用户体验的高保真原型;
  2. 邀请真实的目标用户验证产品原型。

利用这种方式可以低成本的通过市场反馈来的到可用性高的产品,在敲定了高可用性,可行性之后,在将原型提交给开发团队,这样开发团队可以直接根据原型进行开发,通过实际的原型比说明文档更能加深开发团队的理解。

大公司如何创新 | Innovating in Large Companies

主动观察

观察和倾听是最贱的创新途径。仔细观察用户使用公司产品或同类产品的一举一动。

大公司是有着用户基础的,所以数据变得非常重要,一定要得到数据,并且能看懂数据。数据是反应产品的真实情况。这是与创业公司不同的一点。

创新不是发现新问题,而是用新方法解决已有的问题。观察人们对现有产品的不满,是创新的最佳途径。

产品经理应该时时刻刻的都关注平时的细节,只有注意到用户平时的不满,才能知道产品提升的方向。观察现在用户已经存在的模式,发现这个模式的问题,用更简单并且更舒服的方式加以改进。

在大公司施展拳脚 | Succeeding in Large Companies

  1. 了解公司制定决策的方式,每家公司的企业文化都不相同,制定决策的方式也千差万别。
  2. 建立人脉网络,在大公司工作必须与人合作,如果你喜欢单枪匹马工作,创业型公司更适合你。
  3. 臭鼬工程,在大公司凭空申请创新资源是很困难的。想靠画几张产品幻灯片来说服老板是不切实际的,可行的事找几个志同道合的朋友,在工作之余做出产品原型来。
  4. 自己顶上,在大公司里员工虽然众多,但真正需要帮手的时候,却总找不到人。
  5. 有选择地据理力争,在大公司工作,多一个敌人不如多一个朋友。有分歧了,不要随便发脾气,除非这件事对你确实重要。但与人辩论也要小心,要做到对事不对人。
  6. 会前沟通,形成默契,在重要的决策会议上,如果有人公开反对你的提议,你会变得非常被动。
  7. 合理分配时间,大公司频繁开会,有些人每天忙于参加大大小小的会议,要留出自己的工作时间。
  8. 分享信息,不管在哪种组织里,沟通都是难题,大公司尤为如此,分享信息会让你获得更多的朋友和资源。
  9. 向上司借力,学会利用上司的关系,可以更好的开展工作。
  10. 传播你的产品理念,多想同时传播你的产品理念,向大家描绘产品愿景,介绍产品策略,岩石产品原型,分享用户反馈信息。

凡事都有两面性,在大公司工作有着条条框框,有着各种限制,但在资源上有着创业公司无法比拟的优势。如果你能了解大公司的运行机制,那么你会在大公司里混的如鱼得水。在小公司,则没有那么多限制,可能更加的自由,没有那么多条条框框。但资源就啥都没有。一切靠你自己。

苹果公司给我的启示 30 Jan 2018 at 07:07

  1. 硬件为软件服务,与其他硬件公司不同,苹果公司明白硬件必须为软件服务,这种关系不能颠倒。软件直接服务用户,满足用户需求。
  2. 软件为用户体验服务,所有的公司都把用户体验挂在嘴边,只有苹果公司把它放在心里。
  3. 用户体验为情感服务,他们比谁都清楚是什么让消费者为产品疯狂,他们知道怎样抓住用户的情感需求。
  4. 产品为真正的需求服务,手机并非苹果公司首创,但他们挖掘出尚未被满足的用户需求。

想要说明苹果公司的成功,原因有太多太多了,并且每个人对他成功的因素看法也不尽相同。强大的整合能力,出色的产品,绝妙的用户体验等等。他们对自己产品的有着非常清楚的认识,或者说是对使用他们产品的人非常了解。乔布斯老人家说过,他们从不做用户调研。他观察用户,从真实的动作来看用户最真实的反应。所以他们的产品体验能够做的复合人性。原来用苹果设备会有一个非常奇特的感觉,第一次拿上手,有什么东西不会,只要跟着感觉走,它就能完成你的目标,你想要的东西永远在你想象的位置上呆着。

堤防有特殊要求的产品

我反复强调产品需求不能用户说了算,原因如下:
第一,在看到具体的产品之前,用户很难知道自己需要什么;第二,用户不知道怎么样的产品是可行的(在目前的技术条件下可以实现);第三,用户之间缺少沟通,需求很难统一。

从这里能看出作者非常崇拜苹果公司,这几条都能让我看到苹果公司做产品的身影。不要追着用户走,你要观察用户,用户调研不是想知道用户说了什么,而是要观察用户表现出什么。你要真正的挖掘到用户最底层的需求。而且用户提出的要求一般来说都是基于自己的生活环境和认知所总结出来的方案,这个方案没办法代表其他用户也很可能是不可行的。

新瓶装老酒 | The New Old Thing

成功的产品往往不是什么新鲜事物,知识新瓶装老酒,之所以成功,是因为这个“新平”做得更好、更方便、更便宜,改变了消费者对“老酒“的印象。

[[结网]] 中所提到的,开创新产品的创新者最后往往都失败了,而那些后来的改进者,往往能够最终获得市场的确认并取得成功。第一,创新者最大的优势就是能够获得一些时间红利,对于市场来说,可能也就半年左右的时间。如果这段时间没有形成用户规模的壁垒,要被改进者追上来是非常容易的。第二个就是创新者更不容易修改自己的产品,他们创新往往基于创新的创新。而不是基于用户需求创新。等到发现的时候就已经晚了。

恐惧、贪婪、欲望 | Fear, Greed and Lust

只有从情感的角度重新观察市场上的产品和服务,你才能体会用户的真实感受。他们通过什么途径满足这些情感需求?哪种视觉设计更能抓住这些情感?哪些功能更能满足这些情感需求?哪些产品特性阻碍用户宣泄情感?

人是一个感性的动物,做决定的时候往往都是处于满足自己的感性需求。外卖app,是懒惰。企业客户是恐惧,我如果不买你的产品就可能被其他人拉下。知识付费也是恐惧。社交软件是欲望,想要和其他人有交集。但是还有一点非常重要的,用户有着不同的情感需求,即使使用的是一款产品。要从情感层面去分析产品,做原型测试的时候,除了观察测试者能否使用产品外,还应该趁机了解测试者的情感需求。

明确目标用户的情感需求后,问问你自己谁还能满足用户的这种需求。他们才是你真正的竞争对手。许多情况下,你的竞争对手不是创业型公司或大型门户网站,而是大众的线下生活方式。

这实际上是“老酒”和“新瓶”的区别,有时候你的竞争对手不是同行,而是老的行为模式,这里指的是你的产品没有出现的时候,大家通过什么方式来解决这种需求。新产品一定要比老产品满足不了的需求,或者场景。如果你的产品的方式还没有老方法来的更简单直接,那这个产品就是一个失败的产品。

情感接纳曲线 | The Emotional Adoption Curve

产品经理应该注意研究非理性消费者的行为,避免被技术爱好者误导。
非理性消费是对不满情绪的过度反应,是放大后的情感需求在“作祟”。非理性消费着夸大了产品的价值,产品经理如果深入了解他们的想法和感受,就能抓住这种情感需求。
非理性消费着能够帮助产品经理发现产品的内在价值。
非理性消费者内心弥漫着强烈的不满情绪,这种情绪可能会慢慢减弱,但不会消失。技术爱好者并不关心产品要解决的问题,吸引他们的是产品采用的新技术。

技术爱好者和非理性消费者接触的产品的时间往往是一致的,如果都知道谁是谁,那么可能误导就不会存在,困难的就是你要判断这个需求提出的人是技术爱好者还是非理性消费者。

技术爱好者是指那些尝鲜新技术的消费者,他们通常为新技术买单

非理性消费者是指那些与消费者相同的心里,但是这种心理成都更加的强烈,他们才是产品经理应该研究的人。他们和理性消费者有着相同的心里因素,不同的是他们的程度更为强烈,满足他们的需求往往会花出超过原本解决问题的精力,但是只要搞定了他们,理性消费者就会过来。

最佳实践经验 | Best Practices Summary | 2 Feb 2018 at 07:21

  1. 产品管理的职责,许多产品经理将大把时间浪费在与产品管理无关的工作上,比如,营销管理和项目管理,这些都不是产品经理应该干的活。
  2. 用户体验,对于大多数软件产品来说,用户体验就是产品的生命。产品经理应该与交互设计师、开发人员密切合作,设计良好的用户体验,打造有实用价值的产品。
  3. 机会评估,使用方便快捷的机会评估方法取代过时的市场需求文档。动手设计产品前明确产品要解决什么问题,为谁解决问题,以及评估产品的标准。
  4. 特约用户,有些产品团队企图绕过用户,直接设计、开发产品。打造优秀的产品没有任何捷径,只能请用户反复使用产品,不断改进。
  5. 产品原则,产品管理工作的主要内容是制定决策。明确的产品原则可以帮助产品经理和产品团队梳理清晰的标准,做出果断的决策。
  6. 人物角色,人物角色是协助产品经理制定决策的另一项工具。把目标用户按特征分类,逐一分析、理解其感情和行为,以此作为决策的依据。
  7. 探索(定义)产品,产品经理的主要则职责是探索(定义)有价值的、可用的、可行的产品。除非产品经理确定这三点,否则同事的努力都将付之东流。
  8. 使用原型,使用高保真原型是探索(定义)产品的关键步骤。原因如下:第一,迫使产品经理深入定义解决方案;第二,可以让真实的用户参与测试、实验产品创意;第三,可以直观地向团队展示产品的设计思路。
  9. 用户参与原型测试,有了产品原型,产品经理可以方便的请用户验证产品创意。原型测试是所有产品经理和产品设计师都必须掌握的工作技能。获取有效的用户反馈是产品经理最重要的工作。
  10. 根据数据改进产品,成功的产品经理懂得利用数据来改进现有产品。改进产品不是根据客户要求以为增加新功能,而是根据产品的实际应用情况,不断地提升产品的各项指标,逐步完善产品。

作者总结了十条产品经理的经验,我从产品开发维度来看重新排了一下顺序,应该是产品管理职责,机会评估,探索(定义)产品,人物角色,使用原型,特约用户,用户参与原型测试,用户体验,产品原则,根据数据改进产品。

你首先要明确自己的工作职责,将百分之八十的精力都放在核心工作里面,剩下的时间做其他事情。收集需求,进行机会评估,然后通过删减出合理的方向进行探索(定义)产品,找到一个想法,然后去定义人物角色,了解你的用户。根据初步的假设,创作高保真原型。去找特约用户,让用户来参与原型测试,根据测试来对产品进行可用性测试,确定产品原则。然后设计开发产品,产品上线了,有数据了,就根据数据来改进你的产品。