看到一篇关于产品从业人员入门级指南，不完全认可，但觉得写的还不错，以下内容为转载，原文地址：猛戳
　　最近公司产品业务调整相对比较多，人员变化也有些大，或多或少都会有一些残留问题，在处理过程中就会发现别人挖的坑，埋的雷，于是就要排雷，填坑。当然了，自己有时候也会挖坑，埋雷。其实我们不想挖坑，我们只是互联网的搬运工。

　　当你经历过坎坷成长为一名成熟的『产品经理』的时候，回头看看走过的道路，原来有那么多被你亲手挖出来后又填起来的『坑』。我这里所指的『坑』不是一个贬义词，因为经历过这些『坑』的磨练之后，你会积累更多宝贵的经验。注意，我这里要说But了，在你没有填补好这个『坑』并且走过去的时候，你会因为『深陷其中』而异常的痛苦，甚至想要放弃，相信我，这些感受我也都曾有过，所以，我们今天来一起看看这些『坑』都是什么，如何避免，又如何后知后觉。
继续阅读 →

　　百度贴吧这么多年来一直拥有很庞大的用户群体，这与最初学生吧，学校吧，地方吧，明星粉丝吧等大量贴吧的人气聚集密不可分，但是随着互联网逐步趋于移动端与商业化，小米借助QQ空间营销大获成功后，各种社交类产品也更加重视商业化纷纷成立商业化独立部门，企业也越来越重视有庞大用户群的社交媒体。
百度贴吧开放平台产品方向规划

方向一：B2C 精准用户

1、背景

　　百度在搜索算法中给予自身产品很大的权重，很多内容都有优先于贴吧内容和贴吧入口，在企业官方贴吧中，这一部分流量属于类SEM流量，很精准，并且目前免费，用户在搜索某一企业品牌词时可直达该贴吧，企业可以迅速聚集对自己企业或产品感兴趣的人于贴吧内

继续阅读 →

——如何让易信尽快摆脱死亡的阴影并真正引爆流行？
　　29天前，易信含着金钥匙携着巨大的啸声降生，虽然在最初几周，易信成功的获得了看似不错的安装量且近日这一数字陆续还在增长，但考虑到其非常低的使用率和微信超过95%的市场占有率，易信这个baby身上还是笼罩着死亡的阴影和淡淡的尸气。
是的，微信大势已成，用户习惯太强大了。虽然人人都承认易信交互更好通话更清晰，但我们还是每天不由自主的打开微信说话发朋友圈，而易信呢？他在一边凉快着呢
事到这份上，易信必须下3剂猛药，方有可能成活：

**猛药1:全面接管通讯录**

用户一安装，易信就是通讯录，所有通讯录里面的人都直接全部导入，而不是在模仿微信玩什么“今天2个明天3个的加好友把戏”
当然，所谓“接管”的意思是：不光要“导入”，还要能增改删，每次操作都等同于对通讯录进行操作（这主要指的是安卓）。
另外，导入的不光是用户的全部通讯录，还有全部短信记录。
继续阅读 →

　　前几天有朋友问我需求文档应该如何写作？需要注意点什么？其实需求文档在每个公司和每个人的产出的都可能是不一样的，基本上没有固定的格式，如果简明扼要的概括就是需求文档把你这个需求描述清楚你想要什么就可以了。

需求文档注定是给所有人看的，它就是产品的定义。

• 文档围观的人包括：你的老板（如果产品够大，还会需要老板的老板），设计师，工程师，测试工程师。有时还应该包括产品前端：如运营，销售，甚至市场部同事。
• 在通过各方的评审和签字后，一般来说，这个文档就是一锤定音的事。若有更改，就是需求变更了。
• 所以，在需求文档撰写前和撰写中，对产品方向和用户的把握要足够强，从产品目的，到每个链接的含义，都需要准确地定义。基本上，当你开始写文档时，应该万事俱备。一边想一边写，那说明你还没有想明白这个产品是怎么回事。
• 在有些公司，需求文档会包括产品的最终设计界面。即在文档提交给大家围观前，产品界面已经确定完毕。

需求文档写作的一些建议

• 格式无所谓。用WORD的多，HTML，在线文档都成，我还见过PPT写的！
• 产品定义部分一定要详细描述。按功能模块写，跨功能的定义用流程和关系来描述。多站在用户的角度上，去定义用户任务，用户流程，页面逻辑关系等。
• 使用准确的用语，注意边界情况。比如，一个文本框最多输入多少个字符？是阿拉伯数字还是皆可？超过字数会怎么样？
• 多画图。把原型包括进去，或者把产品界面包括进去，不然就画出来。否则除了你，没多少看得懂。

比如现比较推崇的Agile敏捷开发，会更强短平快，削弱文档的沟通而加强团队的直接交流，简化流程，快速反馈，快速迭代等等。这种情况下，需求文档会极大简化，咱就不在这探讨了。

比较正规的文档目录

1. 文档信息，版本记录，责任人等
2. 项目背景，产品目的
3. 文档约定（采用的标准，通用名词等）
4. 可行性分析
   • 前期调研
   • 产品预期
   • 对其他产品的影响
5. 产品定义功能详述（文档主体部分）
   • 功能模块
   • 用例
   • 用户流程
   • 数据需求
   • 业务规则流程
6. 产品非功能需求
   • 对性能的需求
   • 安全性需求等
7. 产品风险或潜在问题

这种文档现在更多的出现在软件行业和严谨开发行业，对于互联网而言已经慢慢简化了需求文档的冗余程度，只要这个文档能很清晰的把这个产品描述清楚就好。

如：微博上有好友推荐关系，需求文档中可以描述为

向用户A 推荐 用户B 为他有共同爱好的人，那么他们需要有>10个共同关注的人；
向用户A 推荐 用户C 为他可能感兴趣的人，那么他们需要有共通过的粉丝>10人；

　　这两句话描述了微博用户推荐机制产品经理需要给开发产出的需求描述，也经常遇到会有开发问“他们之间怎么关联在一起”“这两个表不在一个数据库“等问题，如果产品经理是开发转型能提供解决方案并且时间很充裕可以协助一下，但大多数产品经理也许不会开发，所以这些问题开发要自己想办法解决，不要凡事遇到问题就找产品经理。产品经理也是人，不是神；

本文译自Facebook产品设计总监Julie Zhuo 发表于Medium的《How to Work with Designers》。以下为译文；本文转自公众微信：互联网er的早读课（zaoduke）

　　多年前，我曾当过产品经理，然后是工程师，而过去七年我从事的是设计工作。每天我都跟担任这些角色的人一起工作，每一天，我对产品开发背后的责任、挑战和艺术都有新的体会。对于想要搞经楚设计这个奇怪、锐利、helvetica-typed 世界的工程师和产品经理们，这篇文章正是为你们而写。

若想使用设计师语言，请停止说那些指标的事，改聊使用者。

　　其实大多数的情况下，「指标」跟「使用者」意思不会相去太远。举例来说，你或许是希望设定一个目标，让注册页面的转换率提高X%；另一种说法其则是：你想要扫除那些阻止使用者注册、使用产品的障碍。但是你看，「说法」在这里就变得很重要——让使用者更容易注册vs. 优化注册流程的转换率。前者谈的是对使用者的价值，后者则是公司为了成功所产生的需求。设计师做事的心态一般来说是比较偏向使用者这边。
继续阅读 →

　　接触金融网销市场也有一年多了，与之前做的产品设计基本上属于两个思路，前些日子在做新版首页改版时讨论到一个对电商很重要的问题「搜索」对保险电商的重要性如何？

1、保险非实物并且大多属于同质化产品
2、购买保险的用户意向很明确需求不明确
3、不知道搜什么

以上几个观点是为什么得来的呢？

1、保险同质化

　　其实现在市面上大多数如：国内旅游险、短期意外险，这种简单的险种保险责任基本相同，不同的只有保险公司、保费、保额的区别，也许个别公司会增加几个特殊的保障责任；

2、意向明确、需求不明确

　　为什么这么说呢，模拟一下比如我们是一个驴友，要去欧洲旅游需要买申根签证保险，这个是大使馆要求的这种保险需要医疗险达到30万，这个是必须买的所以用户知道我要去旅游，我要买申根签证保险，但是具体买什么公司的保险，买什么保险他并不知道；

3、不知道搜什么

　　综合以上两点特别是第二点，用户并不知道我要搜索什么，不像淘宝、京东，意向和需求都很明确（如：我的电饭煲坏掉了，我要买个电饭煲；夏天了我要买个空调）。

　　如果用户不知道搜索什么内容我们把搜索模块设计的非常突出就没有必要了，开心保在新版设计时我将搜索模块弱化，需求导向强化按需求进行流量导入如：我要去旅行、意外保障、家庭责任、投资理财、团体订购；让用户可以一目了然看到按照需求进行分类筛选好的保险产品，在做搜索的竞品分析时有一家知名保险电商将搜索模块放在显著位置但是搜索规则又很弱很不明白这个是如何设计的。