注：本文中的所有“产品”，均指“互联网产品”；其他行业的执行细节可能不同，但大体思路是一样的。
在找到合作伙伴，确定产品方向之后，就需要开始打造产品原型了。值得一提的是，在当前的互联网创业环境下，业界对产品原型的要求已不再是一个画在纸上，或者用原型工具做出的Mockup，而是一个不够完美、有些瑕疵、会出bug，但可以使用的beta产品；这个产品是可以小范围投放给用户，来验证市场的。
要打造这样一款产品原型，大概需要这么几个角色：业务掌舵人、产品经理、开发工程师、UI设计师；如果能够找到身兼数职的人，当然是最好的。其实这些角色也是一个初期创业团队的标配了，缺一不可。
当这样一个初期团队组成后，打造产品就是一件顺水推舟的事情了，无非就是几个大步骤：
业务掌舵人和产品经理主导，其他人参与，根据前期调研得知的解决方案，设计出产品草图及流程图；
内部头脑风暴，外部了解调研，改进产品草图及流程图；
设计师主导，其他人参与，根据产品草图及流程图，出设计稿；
内部头脑风暴，外部了解调研，改进设计稿；
产品经理和开发工程师主导，其他人参与，评估技术难点，制定开发排期，开始开发；
beta产品面世，用户试用反馈，持续迭代改良；回到第1步。
纸上得来终觉浅，绝知此事要躬行。理论上看似简单的6步，在执行过程中会衍生出无数让大家焦头烂额的问题，创业者要做的就是各个击破，不留死角。
作为一个创业菜鸟，我没有办法针对每个人可能碰到的问题给出一个确切的解决方案；但是我想针对创业初期大家可能踩的3个坑，谈谈我的看法，希望我踩过的坑，大家就不要再踩了；或者大家自己踩的时候，能摔得轻点：
大坑1：对产品理解的片面化、狭隘化
刚创业的时候，正是移动开发最火热的档口，我对产品的理解比较片面，认为产品就是一款App；被各种创业文章洗了脑，觉得就凭一款App，随随便便融个几千万不是轻轻松松的事吗
️半年之后我们的App出来了，于是信心满满地开始找投资人了，结果我被啪啪打脸
印象最深的，是跟晨兴创投的合伙人刘芹
在他们闹中取静的办公室从下午5点多聊到晚上9点；虽然刘总对我们的项目概念非常感兴趣，但因为我们自己都没有想清楚，所以对他在商业模式、业务闭环等落地环节上提出的问题都仅给出了模棱两可的回答，导致这次会议变成了我们的自说自话，刘总的不知所云。
当然，最后的结局是，我们得到了礼貌的回绝，且再也没能踏进晨兴的大门。痛定思痛，当我在一年半之后的今天回想当时的情景，试图找出问题的根源时，发现不是我们准备不充分，不是刘总问题太尖锐，也不是项目方向太小众，而是我对产品的理解太狭隘——
在互联网时代，一个完整的商业产品，是由解决方案、商业模式、业务闭环等方方面面因素综合形成的。单一的App，顶多只能算是解决方案的某一部分的具体实现，只是产品的1/N。
也就是说，刘总口中的产品，和我口中的产品完全不是同一个概念；我翻来覆去说的那些东西，根本不能称之为产品。刘总不惜对牛弹琴4个小时，苦口婆心地点醒我这个菜鸟，刘总费心了，跪谢！
从此之后，我就开始有意识地从更宏观的产品角度来考虑问题，并且把我的反思运用在我自己的产品上，来验证我的想法。如同我在《奔向三张，不破不立：一个iOS开发工程师的职业规划思考》所说，我给《iOS应用逆向工程》的定位，从最开始就是一个互联网产品。这个产品要解决的问题，是帮助iOS逆向工程菜鸟入门这项技术。为了解决这个问题，我出了2版书、建了QQ群、开通了微博、搭建了论坛、开源英文版，还有今年下半年准备实施的某个行动，暂且卖个关子。
好了，考考大家：试问，2版书、QQ群、微博、论坛、英文版，它们是___个产品？
A. 5 B. 6 C.1 D.7
请留言写下你的选项，看看你对产品的理解片面吗
大坑2：对产品实现自动化的过度追求
在《我的失败与伟大 —— 创业方向的选择》一文中，我提到：
计算机能做的事情，人一般都能做，尽管效率低点、耗时长点。一个基于计算机的解决方案，一般也是可以通过人工来完成的，或者起码有部分工作是可以通过人工来完成的。
我的建议是，在确定方案，技术人员开始动手写代码前，先全员出动，把解决方案的整个流程用纯人工的方式跑一遍（部分人做起来效率极低的工作，可以用程序完成），一看跑不跑得通，二看问题解决没。如果得到的答案都是肯定的，那就可以由技术人员开始动手实现了；否则就继续打磨解决方案，直到流程跑通、问题解决为止。
也就是说，解决方案本身是否可行，跟它是由人工执行还是机器执行一般是无关的，区别可能仅在于效率和速度。因此，在初创公司当前资源还不足以支撑产品实现的100%自动化时，不妨把一些环节抽取出来，由人工完成；这个阶段更重要的任务是验证解决方案可行性，我们要得到的答案是行不行，而不是好不好。
等解决方案可行性得到了充分验证，业务多到人手都忙不过来时，投资人可能就持币上门了
有了资源，再把解决方案朝着100%自动化的目标打造嘛！
一些公司给自己的定位是“互联网科技公司”，做事的准则之一，是
机器能完成的事情，就不要让人来做。
我非常同意这一准则，但绝不能生搬硬套，要根据公司当前的状况量力而行，找到适合公司的方案；不管是人工还是机器，都是手段，而不是目的。
节选Peter Thiel著作《Zero to One》中第12章“Man and Machine”中发生在PayPal的一个小故事，希望能够给大家带来一些灵感：
Complementarity between computers and humans isn’t just a macro-scale fact. It’s also the path to building a great business. I came to understand this from my experience at PayPal. In mid-2000, we
had survived the dot-com crash and we were growing fast, but we faced one huge problem: we were losing upwards of $10 million to credit card fraud every month. Since we were processing hundreds
or even thousands of transactions per minute, we couldn’t possibly review each one—no human quality control team could work that fast.
So we did what any group of engineers would do: we tried to automate a solution. First, Max Levchin assembled an elite team of mathematicians to study the fraudulent transfers in detail. Then we
took what we learned and wrote software to automatically identify and cancel bogus transactions in real time. But it quickly became clear that this approach wouldn’t work either: after an hour or two,
the thieves would catch on and change their tactics. We were dealing with an adaptive enemy, and our software couldn’t adapt in response.
The fraudsters’ adaptive evasions fooled our automatic detection algorithms, but we found that they didn’t fool our human analysts as easily. So Max and his engineers rewrote the software to take a
hybrid approach: the computer would flag the most suspicious transactions on a well-designed user interface, and human operators would make the final judgment as to their legitimacy. Thanks to this
hybrid system—we named it “Igor,” after the Russian fraudster who bragged that we’d never be able to stop him—we turned our first quarterly profit in the first quarter of 2002 (as opposed to a quarterly loss of $29.3 million one year before). The FBI asked us if we’d let them use Igor to help detect financial crime. And Max was able to boast, grandiosely but truthfully, that he was “the Sherlock Holmes of the Internet Underground.”
This kind of man-machine symbiosis enabled PayPal to stay in business, which in turn enabled hundreds of thousands of small businesses to accept the payments they needed to thrive on the
internet. None of it would have been possible without the man-machine solution—even though most people would never see it or even hear about it.
大坑3：对早期产品技术选型过分纠结
今年5月14、15两天，我作为PHP创始人Rasmus的随身翻译，去北京国际会议中心参加了第2届PHP全球开发者大会。虽然我对自己的英语比较有信心，但当得知Rasmus原籍是欧洲之后，也担心这哥们的口音太重，我听不懂，所以提前在网上搜了一些他的资料，看看听听，稍作了解。
在会议的宣传文案里，我看到Rasmus的介绍是这么写的：
编程语言PHP的创始人，编写了PHP的头两个版本，并参与PHP后续版本的开发。2002年9月至2009年11月6日间，在Yahoo!公司担任基础设施架构师。2010年，加入WePay公司帮助开发其API。2011年起，担任创业顾问。
因为我正好在创业嘛，所以就对他“创业顾问”的角色比较好奇，想找机会请教一下Rasmus，在创业方面有没有什么经验可以分享一下。
Rasmus的演讲在15号下午2点左右，他12点半就到会场调试设备，调整讲稿，非常认真。这个时候，大多数人都去吃饭了，会场里人不多，我就在那一边给他打打下手，一边跟他唠会儿嗑。于是我就问他（大意）：“作为创业顾问，你应该给不少创业公司做过咨询了。这次参会的许多工程师，也有创业的想法，你对我们有什么建议吗？”
他说（大意）：“我见过许多的创业公司，在最初的技术选型上纠结不已；到底是用PHP，还是用Java，亦或是用Go？他们在工具的选择上投入了过多的时间精力，却忽略了应该用工具解决的问题。这是彻头彻尾的本末倒置，是错误的，你们应该避免。”
我想起了自己用Objective-C语言写爬虫的一段经历。如果你百度一下“爬虫 语言”，就会发现，编写爬虫，最广泛使用的语言是Python，几乎没人用Objective-C。但是我的实际情况是：
我有比较多的闲置iOS设备，爬虫所占资源不多，在一台iPod Touch上，完全可以跑得起来；
我对Objective-C的熟练程度远高于Python。
从我的实际情况出发，选择Objective-C无疑比选择Python更好：
我的闲置设备可以用起来，不至于放在那里吃灰；
因为对语言较熟悉，所以爬虫代码的质量有保证。
然后我利用清明节假期3天时间，完成了7个爬虫的编写；其中4个明文协议，3个密文协议，需要通过逆向工程来还原加密算法；这个爬虫跑在我的一台闲置iPod Touch 4上，从清明节之后一直到现在，没有出过问题。
多多动脑，不要教条，鞋大鞋小，冷暖自了。没必要盲目跟风，适合自己最重要。
最后，给大家来个彩蛋。我很喜欢知乎上一位朋友对他参加第2届PHP全球开发者大会动机的阐述：
我去参加参加大会的动机是沐浴大神的气息，特别是父与鸟哥的气息。气息这种事情很虚，远比“PHP7为什么这么快”虚无缥缈难以捉摸，但是影响深远，一旦捕获受益终生。
这种事情很难线上体验，会有很多缺失。但是其他的如分享的内容，你总是可以免费得到的，无非就是晚一点。找基友也有群，也不用太腼腆。
新浪微博的架构师胡波，录制了一段Rasmus的演讲（英文，无中文翻译）和问答（从50分开始，英文，有中文翻译）视频。大家可以看看创造者和使用者看待问题的不同方式，听听他对“工具”的理解，隔着屏幕感受一下“父”的气息，相信你会有所收获
继续阅读下一篇《我的失败与伟大 —— 初次融资的门道》或者回到目录。
转载自http://iosre.com/t/topic/4152
本文作者沙梓社，《iOS应用逆向工程》第一作者，以技术合伙人身份创业18个月，未果。本篇文章节选自他的《我的失败与伟大》系列创业心得，原文全文共9则篇章。
阅读作者这个系列的全部文章，可以移步这里