做产品，一直以来都是我的目标
最开始，无非是有了 idea，觉得自己的想法很棒，可以 Make a difference, 能够给别人带来帮助 而现在的想法，是 Build something people want, build something people love.
于是每做一个原型设计，都会想，我正在做的这个东西，真正能让别人“爱”上吗？ 说实话，从小到大上网这么久，还真的没有“爱”过哪个产品。拿这个标准一比，就觉得离目标真是太远。
原来，总是想着，要是真的能进入互联网大公司，做产品，就太好了。现在，却不敢了
原来如果让我去面产品岗，我会信誓旦旦地说，我可以做出好的东西 但现在，我在想 假如我真的成了一个产品经理 我怎么保证我做出来的方案设计，是真正有意义的东西，而不是在坑工程师兄弟呢？
能够给别人带来帮助
把“别人“具体化到一个有消费力的人群，比如“喜欢古典摇滚的吉他手”， “单身富人基督徒”或者“卖女鞋的淘宝店主”然后在这个人群里面混段时间，就是产品追着你了
产品是给人用的。与其纠结产品，不如去熟悉你要服务的人
我想了想我喜欢的产品，都没有哪个是产品经理设计出来的。
Joel Spolsky 在微软的时候职称是 Excel 经理，但是自己肯定要编程，他在博客里分享了盖茨拿他的项目书里的每一个技术细节问他，都被他答上来了。后来他自己开了家叫 Fog Creek 的公司，他的理念是：
最好的工作条件 -> 最好的程序员 -> 最好的软件 -> 利润！
然后他先后创建 Stack Exchange，Trello。Trello 是公司内部的创业项目，8 个程序员分成 4 组，每组做一个原型，Trello 最后脱颖而出做大。
Stack Exchange 的另一个创始人 Jeff Atwood 一直就把自己定位为 software developer，现在他又在领导目前最好的论坛项目：Discourse。
Basecamp 前身是一家 Web 设计公司。
Twitter 最先是 Jack Dorsey 提出点子，然后和 Biz Stone 花了两周时间用 Rails 开发出原型。
Google 的产品设计流程就是“去跟工程师谈谈”（现在设计师也是第一位了）。
Github 最开始两个创始人，一个负责 Git 后端和设计，一个负责 Web 应用。
……
要讲程序员或设计师成功做出产品的例子多不盛数，要说由一个既不是开发也不是设计的纯粹产品经理设计出的成功项目，我没想到有哪个。
当然，国内公司的流程可能是这样的：老总看到别人在某个领域成功了，有搞头，于是更改公司的战略目标，把具体事务交给某个高管负责，然后这个高管召集手下的“产品经理”，详细分析对手的产品，然后要求经理们利用公司的资源做一个，然后经理们召集程序员和设计师开会，开始做 PPT，做原型……
这真的是产品经理吗？我觉得称为产品助理才对，因为决定做什么，怎么做的人是老总和高管，助理只是帮助把上级想法具体化，老总和高管才是产品经理。
不知道这份工作是不是楼主需要的。我觉得很奇怪，要组建一个一流乐队，谁会把目标定在乐队经理人？
觉得什么都可能是有意义的，也可能是么意义的。
比如口渴了，喝水就很有意义。但不渴了，要他水喝，就是没意义的。
再比如，有的程序员，就是想要做高大上的东西。那么用高大上的架构，高大上的语言，做些高大上的东西。对于这些人就是有意义的。说白了就是，带我装逼，带我飞。能装逼，能飞，就是有意义的。
再比如，有的程序员是要做事，要解决问题。比如我这种，去重构代码，考虑的只是是否更可维护，至于美不美观（其实 beautifu code 的标准就是是否可维护，而不是看起来爽不爽），跟我没关系。最终的产品，能解决问题，对我来说就是有意义的。至于产品是否高大上，是否好看，对我来说，没有什么意义。
扯远点。王守仁说，无善无恶心之体，有善有恶意之动。 如果人心连善恶都没有，何来的意义？当然也是我个人的理解，很可能是误解:)。
说句闲话，我倒是很喜欢王守仁的处事态度，方式不重要，目的才重要。不在乎如何达到目标（高大上的语言框架不重要，能解决问题的话，有没有技术都不重要），而只在乎是否能达到目的和目的是什么。其实这和 BDD 是契合的，这也是我当初选择当程序员的原因。
集体来讲，共同目的很重要。比如我上学的时候，每年要站着回家，20 个小时左右。我每年都要坐！不是因为多么喜欢身边的乘客，而是，火车能送我回家。如果不能送我回家的车，我一分钟都不想上。
(以上纯属个人观点，不见得是对的，倒是很有可能是愚蠢的 :) )
#3 楼 @blacktulip 觉得敏捷还有一点，就是不做没有价值的事情。比如 DHH 在产品的演示阶段，不会去修 bug，因为这个流程的目的就是尽可能的确定需求，既我要做的，到底是不是客户想要的。有没有 bug 一点不影响这个目的，所以完全没必要浪费这个时间。
觉得试错也要让代价尽可能小，比如 lo-fi ui。画出来了，流程就有了。比做 design，线框图实在多了。
做事可以有两种，一种靠试错。一种靠推断。 试错，其实一定程度上，假定了，不可知。就是我不知道用户需要什么，我也不知道市场需要什么。很多公司用 20% 的时间让员工做自己想做的事情，除了为了调节心情，也是基于此考虑。
预测。考已有的知识，预测结果。比如 100+100 我不要用计算机，就知道结果。
假定了不可知，其实也是有套路可言。比如，没有公司拿 50% 的时间做尝试。再比如经济理论上是不可测的。在比如有人靠极小概率的负面时间获利（《黑天鹅》的作者）。一定程度上是，承受小程度的损失，获得巨大的潜在李毅。
预测。 人的行为，有的时候又很大程度可以被预测的。人除了食、色这些本能的需求外。需求其实无外乎是地位（面子），确定性（稳定），关系，自主性，公平。（引自《Your Brain At Work》）
比如今年的 ruby Conf 上。有个做 A/B 测试的例子。大体是一个中级的收费，被给成 limitation 后，就有更多的人购买了 pro（30% 几吧？具体忘了。。。）。
人其实会花一些钱，购买自主性。所以 limitation 会不受待见。这个就是一个推断。
如果相信“推断”是有道理的，那么大可不必做这个 A/B 测试。也就可以省些成本。
#3 楼 @blacktulip 抱着试错的想法去做产品，那要 pm 干什么，你们 RD 自己去玩就好了。RD 想到什么，agile 迭代上线就好了。
我不太赞同楼上各位的观点
程序员做的产品都有这个特点：产品的缔造者本身就是产品的典型用户。如 Github，Stackoverflow，Basecamp，风车。
一旦脱离这个范畴，就必须要有产品经理梳理需求。在医学、物流、自然科学、建筑、绘画等垂直领域，缺了 PD，程序员啥也做不了。
除非它是个交叉型人才，比如 Paul Graham。
