Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

做产品的主人

Posted on 06/29/201306/23/2019 by 四火

PM 产品经理怎样设计好产品?

有很多回答,我曾经见过好些执着于界面美观的产品经理,见过执着于梳理用户需求的产品经理,甚至听说过化身为 “用户邮件/文档分析师” 的产品经理。我是程序员,是工程师,但我觉得这些人都很不靠谱。这三种不靠谱的产品经理中,第一种最不靠谱。产品经理最好懂技术,但是即便不懂技术,也绝不能化身成为界面设计师。如果我是产品经理,有人有一天对我说,产品经理不就是设计用户界面的人吗?我应该和他拼命。

产品的最大价值,是能够解决用户的问题。所以,产品经理的最大职能,是要设计出能够解决用户问题的产品。你做的东西再丑,举个例子,12306.cn,铁道部的网站,即便再丑,只要用户能够通过它网上购票,而且是唯一的渠道,就必然被刷爆。

但是,只执着于 “用户的需求” 是不可能做好产品的,尤其是那些抱着 “用户是上帝” 荒谬态度的人。当然,你也许会说这样一种情况,要给甲方做产品,你恰好是悲催的产品经理,甲方把需求列得无比细致,你很无奈,没有太多发挥空间了,比如他说要支持 IE6,你就必须支持 IE6,那么,你其实并没有成为一个火力全开的产品经理,充其量只是人家的决策实现者而已。这也是很多传统软件行业经常遇到的无奈。

产品经理要做产品的主人。我在《从 “Google 地图八位版” 看国内的抄袭》这篇文章里曾经这样引用发明汽车的福特来举例:

发明了汽车的 Henry Ford 曾经这样说:“如果我问我的客户,他们要什么?他们的回答一定是:一匹更快的马。”

用户的问题是什么?需要更快的马?那只是问题表象。福特很清晰地抓住了用户的问题本质。产品经理也必然需要做到这种程度。

但这还称不上靠谱。靠谱的产品经理设计的产品还得 “温柔地引导目标用户”:

  • “目标用户”,指的是很清楚那些用户是应该关心的,用户是有层级的,哪些用户是应该被无视的。我们常说国内的豆瓣是一家有 “节操” 的公司,但是依然被无数人反感,豆瓣的风格简朴(有时真是让人觉得太简朴了),却很能因为一些小众爱好而聚集起用户群体。
  • “引导”,是说对于用户的问题,产品经理要给出合理的解决方案,让用户来使用和适应你的解决方案,这个方案在 99% 的情况下,也许不是用户提出的。高级用户、专业用户、资深用户,经常会在抱怨问题的时候,顺带给出解决方案,产品经理对此一定要敏锐和谨慎,始终记得谁才是产品的老大。
  • “温柔地”,是指给出的解决方案千万不能唐突,要让用户可以轻松舒服地适应产品的变革。尤其是对于大用户量的产品,如果你的产品缺乏独一性,很可能对于使用习惯很小的改变都会丢掉大量用户。当然很多时候,冒着掉用户的危险,也要把新的产品设计推广出去,以获得 “烟斗型反馈”,从好评到差评再到更好评。

程序员要不要参与产品设计?

当然要。程序员是产品实现最主要的人,作为重要的 stake holder,为什么要置身事外?首先,程序员在产品设计的技术实现层面需要有最高的话语权,这是毫无疑问的。但是,在产品设计方面,程序员也必须主动参与其中。产品经理应当是主导,但是工程师要给出设计上的见解。我们可以看到,工程师文化的企业,产品设计总是很简洁。

除了上面我提到的,在国内产品经理要做的事情太多,很多是关于团队管理、项目管理的,最终很多产品经理都成了老好人,既不想惹到重要客户,又不想讨工程师的嫌,这样的角色无疑是很难当的。其实,无论是谁,在做产品变革的时候,千万记得产品的初衷是什么,是要解决谁的什么问题,不要为了和谐、为了关系、为了用户量而丢了节操。

另外我还想说的是,程序员是一个积极乐观的群体,不仅仅是产品方面要做主人,在很多方面,都应该做主人,主动争取。这也是我在当前这家公司学到的一件事情。有这么两件事情:

去年有几位同事觉得显示器屏幕太小,几天后就去领了个大显示器,对于程序员的日常工作来说,一台性能不错的台式机再加上一台笔记本电脑是必不可少的,有些人还额外地再配置一台显示器或者一台主机,这依个人需求和习惯而定了。如果你需要,一定要正式提出来,抱怨不解决任何问题。

夏天到了,公司的饮料特甜,而且种类很少。我们团队(七个人,但在零食和水果方面都很能吃)就自己买了个冰箱,现在放了一堆碳酸饮料和垃圾食品(来自我的微博截图):

fridge

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 进阶过程:程序员做项目的独立性
  2. 有趣还是无趣?
  3. 为什么现在那么多人应聘产品经理岗位?
  4. 系统设计典型问题的思考
  5. 从工具使用的痛苦说开去

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Python Spark 互联网 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 程序员 管理 系统设计 缓存 编码 编程范型 英语 西雅图 设计 评审 问题 面试 项目

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Big Data and Machine Learning (5)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • + 1.943624 BTC.NEXT - https://graph.org/Ticket--58146-05-02?hs=9a9c6f8dfe3cdbe0074006e3e640b19b& on 所有文章
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
  • Dylan on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme