产品观念的两个错误是什么

如题所述

一、被用户牵着走

我们都知道,产品是为了解决某个核心问题或者满足某个核心需求而诞生的。所以明确产品设计的目的很重要,想清楚我的产品到底是为了解决什么问题。 

很多的朋友都在做B端的行业解决方案,说好听一点是用数字化的手段助力行业升级,说直白一点就是外行指导内行,很多时候就被内行牵着鼻子走。

1. 真实场景

友人A所处行业是房产估价,传统做法是通过可量化的公式对房产价值进行评估,但公式本身非常复杂,算式项很多,估价师做一份估价报告要做很久。

针对这个问题,他们给出的解决方案是:一个报告自动生成功能。通过后台的特殊配置对计算过程做简化处理,用户只需要几次简单的点击就能够生成准确的评估结果。

但这个功能给客户的感觉就是:不够专业。他们很难接受这么复杂、专业的评估报告就用鼠标点几下就出来了。收到用户反馈后,他们又增加了一些“专业性”上的考虑,增加了一些花里胡哨的流程让报告显得更专业,效率大打折扣,最后让这个功能变成了一个鸡肋功能。

2. 分析

这种情况对应的主要问题是:产品的设计目的不明确,没有明确产品为客户所解决的核心问题是什么。

出报告这个环节的核心痛点就是效率问题,高效是当前场景的第一设计需要。从整个解决方案的呈现,每一个环节和交互,都是在提高整体的效率。能够一步得到的结果,绝不会为了照顾用户的心理需求,让流程变得更复杂。

在这个案例中,高效与专业显然不是互斥的需求,用户想要的是既高效,又符合专业需要的评估报告,所以我们思考的出发点是在合乎专业的基础上提高生产效率,所以不见得需要在流程上让报告更繁杂。

做tob的产品,我们面对不同群体的诉求,每个群体提出的诉求在他们看来都是实际要解决的并且非常重要的问题。这时候如果业务流程再复杂一些,分支情况再多一些,很多产品经理直接懵逼,丧失思考能力,用户说啥就是啥了。

3. 鸡汤

面对这样的问题,身为产品经理一定要保持独立思考,不要对客户的意见进行盲从,透过现象看本质,找出现这个问题的根源。而不是拆东墙补西墙,想不清楚,只顾解决当下的问题,这样的产品慢慢会做成四不像,成为“臃肿难懂、抱怨连天”的代名词。

道理很简单,但是在实践的过程中容易随着产品的演变发生变化,这种变化有好的一面也有坏的一面,需要产品经理们审慎把握好尺度。

二、需求范围不明确

灵魂拷问:什么样的产品才能称之为好产品?

如果好产品的定义是:解决用户的问题,那么我们的产品是不是解决越多的问题就代表越往好产品的方向发展呢?

1. 真实场景

友人B所处的是垂直领域的CRM产品,他们的产品已经做了很长时间,相对成熟,在业内也算是小有名气。但是他最近做得很不得劲,因为他总感觉产品做到一定程度以后就没太多内容可以做了,好像做的全是一些边边角角的需求。

而且用户提的需求严格来说也不能算是CRM产品的范畴,例如增加一些知识库和企业通讯之类的功能,这让他很迷茫,产品的边界到底在哪里,这种情况下,什么需求应该做什么需求不应该做?

2. 分析

产品的边界性是某个阶段内对产品的约束,可能是一个季度、一个版本甚至一次升级的约束,让我们在这个边界范围内去解决一些需求。做C端产品时经常会提到需求链,即用户顺延场景延伸的需求。

当我们设计一款产品时通常抓一个点,解决一个核心场景下的问题。当产品逐渐成熟之后我们就要开始思考需求的前面是什么,有什么场景可以进行更广度的覆盖,实际上这就是产品边界的延伸。

例如一款理财产品,当用户出现买基金这样的需求时,可能是因为客户需要理财,再往深入去探索可能是用户存在一次性大额消费的需求,这可能就是一款理财产品打通购物商城的缘由,所以对需求链的深入探索也是产品边界扩散的过程。

边界是会扩散的,随着产品被赋予不同的使命而向外进行更多的扩张。

边界扩散的方向是无法被预知或者被计划的,再好的棋者也只能掌控三步以内的棋局,对于互联网这个瞬息万变的行业也是一样,产品难以按照一条既定的路线去前行。

所以我们可以采用控制边界的方式来引导我们产品的发展走向。阶段性的目标要清晰、边界要明确,什么事情该在这个版本做什么事情不应该做都有了更加明确的定义方式。

温馨提示:答案为网友推荐,仅供参考