创业公司的特点：钱少，人不够，时间紧。
和大公司的成熟产品思路会有显著差别。
一，精益迭代，快速交付，快速验证
因此，第一点是要全员贯彻一个思路：瀑布流式的产品模式不再行得通，精益迭代是更好的办法。
精益迭代不是口头说说而已，而是贯穿整个开发过程的思路，核心思想就是：
关键点：
一：洞察需求后，快速完成demo来验证需求是否真实
二：根据验证结果来决定每一次迭代加强什么，减去什么
三：将需求拆分到每周可交付，每个月可上线更新
四：观察用户的行为：他最喜欢点哪里，他经常会点错哪里，他到哪里就不进行下去了，他抱怨什么，他问了什么问题，等等。
我们自己的例子：
在初期我们快速测试了4个模块的重要性：远程外包，程序员展示，用户活跃激励，解决方案。然后根据用户行为的反馈（对什么感兴趣，愿意点击哪个模块，不会关心什么，讨厌什么，等）来决定每一次迭代加强什么，减去什么，最终形成了现在的产品的路径。
每次测试的时间不超过2周，一周出demo,一周上线给用户使用。
探索期收获（3个月，用户0-1500）
快速测试寻找能够直接为用户带来利益的功能点（页面热点分析，用户反馈，访谈等）
外包分发（最热门且利润空间最大，但难度最大）
解决方案销售（开发者对于做售后比较排斥，有难度）
程序员招聘（热门但竞争激烈，难度小）
二：而进行优化充分满足需求的时候，又同时要考虑这么几点：
用户可感知：你的C端客户，B端客户，后台使用者
用户不可感知：系统性能提升,系统安全性，SEO
例子：只关注用户可感知的部分，不关注不可感知但是重要的部分，会有什么问题？
参考资料：论产品的内外兼修
要同时协调好这两个方面的规划，才能让你的产品内外兼修，带给用户持续的满意。
三，创业过程中，我认为重要的产品文档：
是要可以让阅读者一目了然自己要做什么，怎么做的。
复杂不是目的，沟通实现才是。
1：产品总述：
说明本次主要要做什么事情，优先级别如何，负责人是谁。
我自己web和 APP 的文档一般是分开写，这样负责人比较固定。
以下部分的文档，一般都会嵌入到总述里面，组成完整的产品文档。
2：产品架构图：产品的全局观
并不是每次迭代都要做，当你有部件上的改变的时候才需要更新。
相当于骨架。
产品架构图一般用脑图完成，目的在于描述整个产品的结构，模块以及页面数量。
3：业务流程图
就是用户如何通过产品来解决痛点的核心流程。
主要用于阐述核心业务流程，便于后端开发业务逻辑，以及各端配合。
4：产品线框图（每个页面布局及交互）-我们常说的原型
以程序员客栈某期的登录流程为例，线框图及交互的目的在于根据功能需求设计每个页面的布局，以及页面与页面之间的交互。
这一步的关键是布局，以及页面切换逻辑。高保真不是必要的。
可以使用的工具：
Axure, Sketch, modao,Balsamig mockups, PPT，one note, 都可以。
还可以用principle, pixate来做交互的辅助。
我自己一开始用modao, 然后当页数变多后墨刀的速度变慢，并且墨刀不能直接导出交互图（当时），因此改用sketch了, 一般效果如下：
5：页面描述表
这一步是对于主要页面进行分解详述，让设计师，开发者明白每个部分如何展现，作用是什么。
例子：待定。
6：测试用例
在从细节上反过来完善产品，以及为下个版本的优化提供素材。
7：产品的路径规划表：平衡资源，用户感知以及不可感知的部分，找到其中的节奏来发展产品。
四，最后来讲讲，怎么获取用户反馈
做客服：产品经理花时间来做客服是很值得的事情，每天兼职做1，2个小时，或者可以查看之前的客服记录，了解用户主要会针对哪些地方提问题，那么这些地方就是你之后要考虑解决的问题-真正的好产品，是让用户流畅使用下来没有问题的。
关注相关社区对于自己的讨论：我们会经常到V2EX, 知乎，或者其他的程序员社区去看是否有相关的讨论，并给予即时的回答。
为了能够及时获取相关讨论，我自己做了一个爬虫工具，每天爬取指定网站的信息，便于我及时了解并反馈。
鼓励用户在自己的社区讨论并给与即时的反馈：我们现在除了嵌入了可即时反馈的客服应对系统以外，还有一个公开展示的意见反馈栏。目的就是为了鼓励用户，有问题就提出来，我们会即时解决。
