人人都是产品经理01“做”产品与“做好”产品( 二 )


但 , 功能运行结果 , 不等同于功能的作用 , 为多少用户提供了某种特定服务 , 才是功能的作用 。
通常情况 , 我们认为功能的作用与使用人数呈现正比关系 , 使用人数越多 , 功能作用越大 , 但这是一种后置的分析方法 , 是建立在功能已经实现后的对比分析 , 只具备复盘总结的意义 , 不具备前置的决策指导意义 。
另一组关系对比 , 更适合对功能做前置的分析:
功能的作用与“潜在用户规模”成正比关系:潜在用户规模越大 , 功能的作用越大;潜在用户规模越小 , 功能的作用越小;潜在用户为0 , 或接近为0的功能 , 则不会产生作用 。
产品里的每一位用户对产品的使用倾向会有些许差异 , 以电商为例 , 有的用户热衷优惠券购物 , 有的用户热衷秒杀 , 有的用户热衷团购 , 还有的热衷更加快捷的直接购物 , 这些功能被一部分用户使用 , 同时也被一部分用户弃用 。
案例中 , AB两款产品每天下单用户都是10000人 , A产品每天有50人购买多件商品 , B产品 , 每天有5000人购买多件商品 。
产品用户相同 , 潜在用户规模却截然不同 , 购物车的作用就完全不同了 。
这也意味着 , 评估功能是否会产生作用时 , 不能建立在产品有多少用户的基础上 , 而是要建立在功能有多少潜在用户的基础上 。
并不是所有产品的用户 , 都是功能的用户 , 只有那些已经出现特定行为 , 遇到特定问题 , 对功能具备诉求的用户 , 才是功能的第一批用户 。
03 向用户传递的信息
一款新上线的内容社区产品 , 每天有10000人使用 , 但产品上线时间太短 , 沉淀的内容只有5000 条 。
这款产品没有向用户提供搜索功能 , 所以 , 经常会有用户向产品经理反馈 , 希望产品能上线搜索功能 。
搜索功能的开发成本并不高 , 团队也完全有资源快速实现这项功能 。
你是产品经理 , 你会怎么做呢?
做出判断之前 , 我们需要先思考一个问题 , 用户的需求是搜索功能? 还是搜索结果?
产品为用户提供的任何一项可操作的功能 , 都在向用户传递不同的信息 , 不论设计者是有意的 , 还是无意的 , 这些信息都将影响用户后续的使用行为 。
为用户提供搜索功能 , 意味着用户可以使用搜索功能快速寻找自己想要阅读的内容 , 这是用户所理解的功能的作用 , 也是功能向用户传递的信息 。
但这条信息并不完整 , 还需要加上功能的结果 , 才是完整的向用户传递的信息 。
搜索功能有可能向用户传递出两种信息:“你可以搜索 , 并且 , 可以找到你想要查找的内容” 以及“你可以搜索 , 但找不到你想要查找的内容” 。
如果是前者 , 这条信息将会拉近用户与产品的距离 , 会增加粘性和信任度 , 但 , 如果是后者 , 这条信息就会让用户感到失望 , 产生负面情绪 , 并且这个情绪还会和产品挂钩 。
案例中的产品 , 如果满足了用户的需求 , 为用户提供了搜索功能 , 就是向用户传递出了第二种信息“你可以搜索 , 但找不到你想要查找的内容” , 因为5000条内容 , 相对于10000用户对内容的搜索需求而言 , 显得微不足道 。
功能的操作效果与功能的结果共同构成了向用户传递的信息 , 前者相当于信息的序言 , 类似于交流前的自我介绍一样 , 后者才是信息的正文 , 才是用户真正关心的 , 会对用户行为产生影响的内容 。
由用户提出的搜索需求 , 实际上 , 也是对搜索结果的需求 , 而不是搜索这项功能 , 不能提供搜索结果的搜索功能 , 对于用户而言 , 没有任何意义 。
现实工作中 , 设计者容易疏忽信息的正文部分 , 仅仅对信息的序言部分进行解读 , 似乎这些需求都是合理的需求 , 成本可控的情况 , 都是可以满足的需求 。
然而 , 恰恰是提出这些需求的用户 , 在需求实现后会最先流失 。