【产品经验】技术人做产品容易忽略的几件事

【产品经验】技术人做产品容易忽略的几件事
Photo by Cody McLain / Unsplash

前两篇聊了需求发现和验证,这篇想聊聊技术人在做产品时经常踩的坑。这些问题往往不是技术能力不够,而是思维方式的差异导致的。

【产品经验】如何判断一个想法是否值得做
Thoughts, stories and ideas.
【产品经验】参加哥飞黑客松的观察:技术人出海的几个常见卡点
Thoughts, stories and ideas.

最大的误区:炫技 vs 解决问题

想做一个"秒杀所有人"的产品

黑客松现场最常见的想法:我要做一个功能超强的产品,比市面上所有的都要好。

听起来很励志,但往往会掉进炫技的陷阱。

一个典型例子:

同样是给小孩的涂鸦生成精美图片的需求,有两种实现方式:

  • 炫技版本:用户需要上传多张参考图、填写详细的风格描述、写超长的提示词,然后等待3-5分钟生成
  • 简单版本:拍照上传,等10秒,直接出结果

技术人往往更倾向于做第一种,因为觉得功能更强大,技术含量更高。但用户更喜欢第二种,因为更简单直接。

从技术角度 vs 从用户角度思考

技术人习惯思考"我能做什么",用户关心的是"我的问题能不能被解决"。

这个思维差异会导致产品方向的偏离。

功能深度 vs 用户体验

Instagram信息查询工具的对比

现场有两个技术同学都做了Instagram相关的工具:

A同学的产品:

  • 输入Instagram账户名称
  • 查看公开信息(粉丝数、帖子数等)
  • 功能就到此为止了

B同学的产品:

  • 同样可以查看公开信息
  • 还能下载Instagram的post照片、视频
  • 支持批量下载

结果B同学的产品明显更受欢迎,用户留存也更高。

为什么会有这个差异?

A同学想的是:我实现了Instagram API的调用,能获取公开数据。 B同学想的是:用户拿到这些信息后还想干什么?他们可能想保存这些内容。

这就是技术思维和产品思维的区别。技术思维关注实现了什么功能,产品思维关注用户的完整流程。

交互设计的重要性被低估

法律文件格式复制工具的案例

现场有个小伙伴做了一个"法律文件格式复制"工具,想法很好:

  • 法律文书中有很多特殊符号
  • 律师经常需要复制这些符号
  • 做个工具让复制更方便

但实际产品有几个问题:

  1. 符号没有穷举 - 只放了常见的几个,但法律文书的符号种类很多
  2. 没有分类优化 - 不同法系、不同文书类型需要的符号不同,没有做分类
  3. 介绍太多,功能展示太少 - 页面大部分都在解释这个工具是干什么的,真正的功能区域很小

这里可以发一个我自己在现场一遍参会一边写的一个小作品,也是符号复制,但是我多想:用户要什么?用什么最方便的方式给他。

特殊符号复制工具 - 1000+符号一键复制到Word
专业的特殊符号复制工具,包含数学符号、货币符号、箭头等1000+特殊字符,一键复制到Word、Excel、PowerPoint,提升文档编辑效率

技术人的盲区

这个案例反映了技术人容易忽略的几个点:

1. 功能完整性 技术人容易觉得核心功能实现了就够了,但用户需要的是完整的解决方案。

2. 用户场景细分 同样的需求,在不同场景下的具体要求可能很不一样。

3. 界面设计的重要性 技术人往往觉得功能最重要,界面差一点无所谓。但用户的第一印象很大程度上决定了他们会不会继续使用。

从技术完美到用户满意

优先级的重新排序

技术人的优先级通常是:

  1. 功能实现
  2. 代码质量
  3. 性能优化
  4. 用户体验

但做产品时应该是:

  1. 用户体验
  2. 功能实现
  3. 性能优化
  4. 代码质量

这不是说代码质量不重要,而是说在产品初期,用户体验的权重应该更高。

一些具体的调整建议

1. 多问"然后呢" 实现了一个功能后,多想想用户拿到这个结果后还想做什么。

2. 减少用户的认知负担 不要让用户学习复杂的操作流程,能自动化的就自动化,能简化的就简化。

3. 重视第一印象 用户打开页面的前10秒体验,决定了他们会不会继续使用。

4. 关注完整流程 不要只考虑核心功能,要考虑用户从发现问题到解决问题的完整路径。

数据驱动 vs 用户感受

技术人对数据的过度依赖

技术人习惯用数据说话,这没错。但在产品初期,用户的主观感受可能比客观数据更重要。

举个例子:

  • 网站加载速度从2秒优化到1秒,数据上提升了50%
  • 但如果用户觉得界面混乱、不知道该点哪里,这个优化就没有意义

平衡数据和感受

  1. 定量数据告诉你what(发生了什么)
  2. 定性反馈告诉你why(为什么会这样)

两者都重要,但在产品早期,用户反馈可能更有指导意义。

一些实用的建议

1. 找非技术朋友试用

技术人很容易陷入"专家的诅咒",觉得理所当然的操作,普通用户可能完全不懂。

找几个非技术背景的朋友试用,观察他们的使用过程,往往能发现很多问题。

2. 关注用户的抱怨,而不是夸奖

用户的夸奖听听就好,抱怨才是改进的方向。

特别是那些"你这个工具不错,但是..."后面的内容,往往就是下一步优化的重点。

3. 先做减法,再做加法

技术人容易想着一次性解决所有问题,但产品初期应该专注于解决一个核心问题。

把这个问题解决得足够好,再考虑其他功能。

4. 重视文案和说明

技术文档可以写得很技术,但产品文案要让普通用户看得懂。

多用用户的语言,少用技术术语。

下一步

技术人做产品,最大的优势是执行力强,想到就能做出来。但要让产品真正成功,需要补齐产品思维的短板。

下一篇想聊聊变现方式的选择。毕竟做出了好产品,如何合理地收费,也是技术人经常纠结的问题。是一次性付费好,还是订阅制好?怎么定价?这些问题的答案可能和你想的不一样。